Slashdot Mirror
Java VM & .NET Performance Comparisons
johnhennessy writes "Just came across some good virtual machine performance benchmarks (on Mono's mailing list). It covers executing java bytecode via a host of different Java runtimes and also the mono runtime. Not only does it give numbers for IBM's runtime (1.4.2 and 1.3.1), Sun's runtime (1.5.0 and 1.4.2), GCJ, Mono, Jikes and much more! These numbers are also given for both Intel and Opteron (where relevant). Before the flames begin, don't forget to read the authors description of how the benchmark was carried out. Hopefuly this should inspire educated discussion on ones favourite JVM/CLR."
It's no surprise Sun's JDK seems to perform the best out of the other versions. They know Java the best since they created it, and thus are able to optimize it better than the other versions. This would probably change if Sun had a more open licensing scheme for Java. Just my two cents.
US businesses that currently accept chip and PIN/signature
HotSpot, the Sun JVM, has had 8 byte object headers for years (at least since version 1.3).
.NET and Mono, we know that. What's your point?
So it still has 8 byte object headers, after all these years, instead of 4 bytes or less. (I qualified my statement only because I thought Sun might have fixed this in 1.5, but apparently not.)
NET still only [...] Mono actually uses the Boehm GC,
Yes, the Sun Java implementation is more mature than
Sun has made the right decision to keep the reference-type-only system
Right for their slice of the market perhaps. Wrong for general purpose computing. Give it another decade, and most Java compilers will probably target the CLR.
There's research for having more packed object headers, or for ways to even get rid of them (allocation in special pools,...). All of this can be implemented without adding special semantics, and this are areas for future JVMs.
The semantics of value classes are supposed to be different. Giving everything reference semantics would be the wrong thing to do even if the compiler managed to perform every possible optimization.
Sure... it's not available today, but 10 years back, Java was a simple bytecode interpreter with a mark-sweep GC.
There was no reason to create such a poor implementation back then; generational GCs, incremental GCs, dynamic compilation, and most of the other features used in Sun's JDK were already well-known at the time. Sun simply didn't use them.