Check out Intel's new instructions to Rockton round the clock from the Inquirer. This is consistent with what Geir Magnusson said in his (very good) OSCON presentation; that Intel might like to load a custom JVM with secret code that took advantage of their inside knowledge of the silicon, so Java would run better on Intel; one reason they might have preferred Apache to GPL licensing for the Sun Java code. Me, I’m puzzled. If there are special instructions to make Java bytecodes (or .NET CLR code) run fast, uh, how are they going to keep them secret, and why wouldn’t they end up in every JVM and CLR implementation? And why wouldn’t this be good for Intel? There are disassemblers and so on, you know, and plenty of hackers who are accomplished at picking apart x86 binaries. Maybe there’s something else we don’t know. [Update: Check the comments. That Inquirer article is from way last year, and Geir Magnusson says I’m all wrong about Intel. So maybe there’s no story here.]
Contributions
Comment feed for ongoing:
From: Tkil (Nov 30 2006, at 13:09)
I suspect that Intel's "secret sauce" is actually their compiler technology (and the Inquirer article seems to bear that out, since they mention "JIT in hardware"). In the same way that Intel's C compiler has stayed 30-40% faster than GCC for certain classes of problems, it's plausable that their JIT technology could also present similar wins -- and I can see them not wanting to have to GPL it, since their fear is that AMD could take it and tweak it to get good performance on AMD chips with only a fraction of the investment.
[link]
From: John Cowan (Nov 30 2006, at 13:28)
Perhaps there's some way to use these instructions for DRM, so that disassembling becomes (shudder) *circumvention*.
[link]
From: Andrew Sidwell (Nov 30 2006, at 14:30)
The date on that article appears to be "Thursday 21 July 2005, 09:16". That would indicate perhaps it's a little outdated?
[link]
From: Tim Bray (Nov 30 2006, at 15:03)
Hey Andrew, you're right, hadn't noticed that, and can't remember what pointer I followed to turn it up. It's still consistent with what I've heard elsewhere.
[link]
From: Dalibor Topic (Nov 30 2006, at 18:21)
The fun research around Intel's ORP is over at http://scholar.google.com/scholar?hl=en&lr=&q=+Intel+ORP&btnG=Search
I'm not aware of anything that would fit a secret CPU instruction set, but given that ARM has Jazelle, I can see how it can make some sense on embedded devices. But on a multi-core high-end CPU? Unlikely, unless Intel expects Singularity to replace Vista RSN. ;)
[link]
From: Simon Phipps (Dec 03 2006, at 07:56)
> one reason they might have preferred Apache to GPL licensing for the Sun Java code.
I wasn't aware Intel had expressed a view on this? They are investing in Harmony but that existed long before OpenJDK was considered and I don't think they have a track record of opposing the GPL.
[link]
From: Geir Magnusson Jr (Dec 03 2006, at 08:04)
(Note : I don't speak for Intel, I'm just an employee)
Goodness gracious, Tim! This from the guy that was complaining about recent misrepresentation of his own work on TSS? LOL. And using an 18 month old article from "The Inquirer" as the basis for it?
You say : "This is consistent with what Geir Magnusson said in his (very good) OSCON presentation; that Intel might like to load a custom JVM with secret code that took advantage of their inside knowledge of the silicon, so Java would run better on Intel;"
Thanks for the compliment, but that's not factual. I've never said anything of the sort. When people ask why Intel is contributing to Apache Harmony, I simply point out that Intel likes to make software run as fast as it can, because Intel sells hardware - therefore, fast and efficient software on fast hardware results in better value for users that care about performance. Using the features of the instruction set for the machine you are targetting in the low-level (non-user-facing) parts of the JVM is simply good engineering - it's the fundamental idea behind the JIT. Sun does the same thing with HotSpot, as do all VM vendors (IBM, BEA, others). Having all implementations of Java be compatible doesn't mean they all run slowly...
You then say : "one reason they might have preferred Apache to GPL licensing for the Sun Java code."
I can't undestand what this means - either you are confusing Apache Harmony with "Sun Java code", which it isn't (it's an independent implementation) or you are trying to get people to think that Intel has made a statement like IBM, Oracle and others regarding your choice of the GPLv2 for your code. I am not aware of any such statement from Intel, and challange you to find one. Further, Intel contributed code to Apache Harmony over a year before Sun created OpenJDK, so that can't be an indicator of licensing preference.
You finish with : "Me, I’m puzzled. If there are special instructions to make Java bytecodes (or .NET CLR code) run fast, uh, how are they going to keep them secret, and why wouldn’t they end up in every JVM and CLR implementation? And why wouldn’t this be good for Intel? There are disassemblers and so on, you know, and plenty of hackers who are accomplished at picking apart x86 binaries. Maybe there’s something else we don’t know."
Maybe it makes no sense because you created a strawman out of whole cloth? They are contributing to Harmony under the Apache License. Why would you think that they could keep anything secret?
To try to salvage something positive out of this, I'll note that you accidentally did stumble across the conclusion that you should have drawn in the first place : the technology can freely end up in every VM (JVM, CLR, RubyVM..) implementation for anyone who chooses to take advantage of it. It doesn't detract from anyone else's work, and benefits the overall "managed runtime" ecosystem.
geir
[link]
From: Tim Bray (Dec 03 2006, at 08:27)
Oops, sorry, Geir. Clearly the understanding I took away from the OSCON talk was wrong; I really had the impression that you'd said more or less what I wrote you said. Fortunately, I didn't report what I thought you'd said about IBM's feelings! Since, as I wrote, it didn't seem to make sense, I'm glad to hear I got it wrong
[link]
From: Geir Magnusson Jr (Dec 03 2006, at 09:04)
"IBM's feelings"?
[link]
From: Wes Felter (Dec 03 2006, at 10:39)
Tim, I think you have uncovered a secret Java instruction conspiracy, but not at Intel. Both ARM and Atmel keep their Java modes secret; why?
Geir, by donating code to ASF isn't Intel implicitly expressing a preference for ASL? After all, you could have donated DRLVM to the FSF under GPL instead.
[link]
From: Geir Magnusson Jr (Dec 03 2006, at 16:58)
(Usual disclaimer : I don't officially speak for Intel)
Wes, I don't really know how to answer that. Personally, I like both Zinfandel and Cabernet Souvignon, and how I choose between them is rather complicated and situational.
Intel has contributed lots of software under both the Apache License (it's not "ASL" by the way, just "AL") and the GPL. To me, the donation of DRLVM to Apache Harmony made sense, as it was the only open source project at the time dedicated to creating a compatible, conventional implementation of Java SE 5. (Now there is another, OpenJDK). There was no FSF project trying to do that. GNU Classpath was trying to create just the classlibrary (and w/o ever looking at the spec!), and as far as I could tell at the time, they were working on Java 1.4.
There are also aspects related to Intel contributing code with the intention for anyone to be able to pick up and use, under whatever license. The GPL doesn't allow that. (I touched on this aspect, how the Java ecosystem has a substantial proprietary component to it that isn't going away anytime soon, in a comment here : http://blogs.codehaus.org/people/geir/archives/001459_no_virginia_there_is_no_problem_with_the_apache_license.html)
As for keeping "Java modes secret", I do wonder why anyone cares - if the implementation passes the TCK and is compatible, does it really matter? That's the beauty of Java - with an open source immplementation like Apache Harmony or OpenJDK, there really is no "Java Trap" - you can choose among many implementations, both free and proprietary, and the "compatibility promise" means that your programs will do what you expect (assuming you wrote them correctly :) no matter what implementation you are running on.
(Tim, I wish you had a "preview" mode for comment posts...)
[link]
From: Mark Wielaard (Dec 04 2006, at 02:11)
Geir, stop claiming you didn't know anything about GNU Classpath and the community around it. We started Harmony together http://article.gmane.org/gmane.comp.java.classpath.devel/5521 you, Dalibor (Kaffe) en me http://www.dwheeler.com/essays/images/magnusson-topic-wielaard-big.jpeg travalled around the world to tell people about how great the community would be http://www.dwheeler.com/essays/fisl2005.html#javaimp , that we had finally united all the projects in true Harmony together and that we made plans for how to concur the world (FSF, ASF, GNU and Apache side-by-side) http://developer.classpath.org/support/escape-26-nov-2005.html
I understand that you felt the need to split off from that community and decided to start your own thing after you couldn't convince the community that it should be the apache way or the high way http://lwn.net/Articles/184967/ and of course that is your right, that is what Free Software is all about. But don't claim you don't know what the community is about, what they were working on and that we do want to do this together. Yes, including working with Sun now.
I am happy that Sun did see the value of the existing community.
[link]
From: Dalibor Topic (Dec 04 2006, at 02:19)
Given that Harmony was started by Mark Wielaard, Tom Tromey, me and a bunch of cool guys at Apache as a way to push GNU Classpath through the TCK process using ASF's good connections, (among other things that Geir managed to drop in his screwed up Harmony project announcement :) and I was one of the people bugging Calvin Austin, the Java 1.5 lead, to help make the change of terms for 1.5 possible to allow free runtimes to certify, the idea that we weren't targeting 1.5 in projects around GNU Classpath and GNU Classpath itself is new to me, as is the idea of working without specifications.
My stack of JCP spec books tells me something different, but then again, what could I possibly know about my goals, means, and purpose. :)
[link]
From: Mark Wielaard (Dec 04 2006, at 04:04)
Simon, Intel does indeed not have any strong preference for a particular license or community. GNU Classpath contains several contributions from Intel (they contributed all the work to make JBoss really work and perform). At one point GNU Classpath even distributed patches for Orp to make cooperation easier http://www.gnu.org/software/classpath/docs/orp.html And we of course contributed patches back to the Orp runtime.
What I understood of their contributions and efforts they were mostly concerned with being able to publish performance reports with (tweaked) runtimes on their chips. Something which was apparently not allowed (or took too many layers of lawyers) with the proprietary class library and runtimes.
Same is true for IBM btw. They even published a report on why for their research they prefer free software and why they switched their JikesRVM project to GNU Classpath (to make it more accessible to researchers around the world and make it able to run Eclipse, which wasn't possible with their inhouse proprietary library) http://www.research.ibm.com/journal/sj/442/alpern.pdf
They also helped us refine the platform/runtime interfaces by contributing back to GNU Classpath (something which also helped other runtimes with 'non-traditional' designs).
[link]
From: Geir Magnusson Jr (Dec 04 2006, at 08:01)
This is getting out of hand :)
Mark - I knew that you were creating the classlibrary. You were missing the VM and the tools necessary for the SE platform. When we started Harmony, we certainly reached out to all the open and free projects out there, including GNU Classpath becase our goal was and is finding ways to build bridges between the communities, in whatever way we could. Clearly there was misunderstandings regarding what could happen with licensed code, but there was and still is plenty of opportunity for collaboration, in modularity, VM interfaces, portability, etc. IIRC, you refused to allow your name to be added to a proposed committer list, as you would *never* make any contribution to any codebase that could be used by "software hoarders" (your words). I'm glad to see you've since changed your mind.
Dalibor - I'm not going to debate the nuances of who started what - we clearly reached out to all of you when we started Harmony. I'm not sure what I 'screwed up' in the project proposal, other than accidentally dropping "GNU", but we were never going to be a vehicle for anyone outside of the project to access the TCKs w/o it being an Apache project activity. Clearly GNU Classpath was on the way to being a classlibrary for Java 1.5 eventually, but at the time, it was still focused on 1.4, right? And didn't have a VM or tools to create a JDK.
Re the "looking at specs", I apologize if I misspoke - I was under the impression that no one looked at the Java specifications. My apologies.
[link]
From: Mark Wielaard (Dec 04 2006, at 08:01)
Wes, at least Amtel seems to document its AVR32 JEM (java extension module) fully http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=10877
[link]
From: Geir Magnusson Jr (Dec 04 2006, at 08:36)
Whenever a discussion that I'm involved in "flares", I have a rule to stand back and figure out why, as I know that I can have problems "seeing past my own muzzle flash".
I think that in this case, I misunderstood Tim's original post, overreacted, and owe him an apology for that. So Tim, I apologize. I hold you in very high regard, which is why my misunderstanding of your post was so upsetting to me.
I misread what he wrote to be something about me stating that there was a secret Intel JVM or something like that. I'm very open and very consistent on why Intel contributes software technology, and yes, making JVMs run faster on Intel hardware is clearly a goal here. And as for "IBMs feelings"? I'm not sure, but I think I'm not inconsistent with my past statements when I suggest that it's reasonable to assume IBM wants to have an independent class library to work with their independent VM under terms compatible with their chosen distribution license, so their distro of Java SE is unfettered by contractual oblications to competitors. I don't know for sure (I don't work there), but it's not a bad guess.
I'm very sensitive to these issues, because I suspect that 95% of all the acrimony in the Java ecosystem is based on misreading, misunderstanding and overreacting to the intentions of others, and I don't mean this only on the personal scale, but on the corporate scale as well. I overracted here. QED :)
Apache Harmony, Sun OpenJDK, GNU Classpath, Kaffe, GCJ, etc - all are FLOSS implementations of Java (whatever version, whatever part of the JDK) and IMO, it's good to have all of it.
Now, back to our regularly scheduled infighting....
geir
[link]
From: Wes Felter (Dec 04 2006, at 12:15)
Mark, thanks for the link. I was reading the main AVR32 arch. manual and though it was odd that Java mode was excluded. Mea culpa.
[link]
From: Dalibor Topic (Dec 04 2006, at 12:37)
Geir, no worries, I was just teasing you a bit, and look forward to talk about it in a bar in Antwerp after your presentation at JavaPolis. ;)
I think a bit of fun barbs back and forth (I know I screwed up a ton of things in the past few years that I can be roasted over in public for a loong time, those Harmony archives will tell of the flames for a while ;) just shows the passion with which everyone is/was going at making all this happen in the best possible ways, and that's a good thing.
Keep up the good work, all of you.
[link]