When C becomes too slow, the JVM has to be written in Java... project Maxwell
"Java is slow, interpreted language." This statement was true at least in the very first years (or months) of Java. Since JDK 1.3/1.4 the peformance is getting better and better. The newest JVMs becomes even more efficient, than C. The c-compiler is static, so once compiled code cannot be optimized any more. The HotSpot is able to perform optimization on the fly, but the optimizations are based on statistics, which are not available at compile-time. Now the conclusion: because HotSpot is written in C itself, it cannot be so fast as Java :-). Beyond that C is not very good to maintain. This is basically the idea of the research project maxwell (actually a cool name). James Gosling mentioned this project during the informal interview at the Sun Tech Days in Frankfurt, and said something like: "it begins to turnaround". It's really an interesting idea - a short (21 pages) description is available as well.
Viva La Revolution and death to C :P
Posted by MythProgrammer on December 06, 2007 at 06:26 PM CET #
If you ask me, all code names are nice. Problems arise when teams are told to use a "real product name" :)
Posted by Alexis MP on December 06, 2007 at 09:28 PM CET #
Alexis: You mean names like ...Glassfish? :-)
Posted by Adam Bien on December 06, 2007 at 09:33 PM CET #
MythProgrammer -> I wouldn't like to kill C - then we wouldn't be able in few years to demonstrates how many times Java will be faster than C :-)
Posted by Adam Bien on December 06, 2007 at 09:38 PM CET #
I've been at the Sun Tech Days in Frankfurt too and thought that Sun should have made some t-shirts with "Java is not slow" printed on them...
It made some nice talking point as it was repeated by many of the speakers... ;-)
But I still don't get why they are still pressing on this. I think it's not news anymore that the current Java runtimes are indeed fast compared to other languages.
Posted by Kristian on December 06, 2007 at 09:56 PM CET #
This was David Ungar's project at SunLabs, he left when they started to cut funding and the mass layoffs. He's now with IBM Research. It's pretty much a dead project now, no one's working on it.
Posted by 69.111.133.190 on December 07, 2007 at 09:46 AM CET #
I don't believe that с is slower than Java...
hm...
Posted by YouNeedJava on December 07, 2007 at 10:47 AM CET #
an interesting project which profiles the vm compiler.
http://blogs.sun.com/geertjan/entry/masters_thesis_on_the_netbeans
>don't believe that с is slower than Java...
believe it or not, vm based languages (->also C#) have faster memory allocation/deallocaton times than other languages.
So it always depends what your software does.
Posted by mbien on December 07, 2007 at 11:10 AM CET #
I'm betting this project will go nowhere.
Even assuming that it even completes, the performances will probably be on par with the current Hotspot implementation and therefore with no reason for the end user to switch. It's just another project to keep a few bored SunLabs people who couldn't care less about end users busy.
I wish Sun was as good at writing Java as they are at writing C, but unfortunately, all their Java code is usually far behind their competitors in quality.
Posted by Foo on December 10, 2007 at 05:39 AM CET #
Foo,
however it is really interesting, observing the activities in this area... This makes Java still interesting :-)
Posted by Adam Bien on December 10, 2007 at 06:37 PM CET #
So basically, it'll be a JVM, that will need another JVM to run ? And that JVM, will also need another JVM to run ?
J/K but it sounds funny :)
Cheers
KiLVaiDeN
Posted by KiLVaiDeN on December 10, 2007 at 08:32 PM CET #
Java optimization gets better the longer the program runs. I would imagine that the optimizing JIT compiler burns most of its machine cycles early in the application program's execution, and fewer and fewer cycles optimizing as the application program runs (despite continual, statistics-based optimization).
So, coding the JIT compiler in Java will make it slower at the beginning when it does most of its work, and faster later on when most of its work is already done. And for that trade-off, you now keep two JIT compilers in memory (one to run the application, and the other to run the first JIT compiler), hence more page swaps.
Conclusion: It could be faster, but only for the most long-running programs executed on machines with abundant memory.
Posted by Frank Silbermann on December 11, 2007 at 05:52 PM CET #
Frank,
yes, you are right. But why not persist the optimizations on the disc? The next time the application starts it could already use the gain knowledge.
Posted by Adam Bien on December 21, 2007 at 10:23 PM CET #