Hot Spot Vm

Sun provides a virtual machine for Java which is called Hot Spot

Research into fast Smalltalk led to the SelfProject?. A company called Anamorphic (I think) fed this back into a commercial Smalltalk IDE. Sun bought it before it was released, and spent some years adapting the technology to Java. (Some Smalltalkers feel bitter about this.) -- DaveHarris

What's current VM performance comparison, please? -- rj

As of last week (Nov 1x, 1999), on Windows:

JDK1.1.*: Compiling to native code and don't need a GUI ? Use TowerJ (fastest, period). Interpreting, or need a GUI, and want an FCS product? Use IBM's JIT. Interpreting, or need a GUI, and willing to live with a good beta ? Use SUN's JDK1.3 (which is, from my usage, about 20% faster than IBMs product. But, on the other hand, it's beta. And there are incompatibilities between 1.1.x and 1.3).

JDK1.2.* or 1.3.*: The only game in town at this point is HotSpot. There are three versions, though: HotSpot 1.01, HotSpot 2.0, and HotSpot Client. 1.01 is FCS, 2.0 and Client are beta. 2.0 is better for server tasks than Client; Client is better for client tasks than 2.0. Both 2.0 and Client are better than 1.01 for just about anything (1.01 is from a previous release cycle).

Microsoft and Symantec (the JIT that ships with the "Classic VM") are nowhere near the leading edge of performance.

-- WilliamGrosso

My knowledge is similar to William's: IBM's JDK is probably the fastest VM available right now, but it's only 1.1.x. HotSpot on 1.2 is close. JDK 1.3, tbd in early 2000, should have very fast GUI speed, faster than what IBM has now.

As for native compilation, both Symantec's and IBM's compiler are _slower_ than the leading JIT's. TowerJ is supposed to be very good, though. Has anyone used Instantiation's JOVE?

-- StuCharlton

Oracle claims to have an extremely fast JVM in their new products. A technical manager, speaking to the Saint Louis Java User's Group (Java SIG) said a bunch of things, which I took to mean that...

They translate ".class" files into C++ at installation time,
then compile them into machine code,
to be dynamically linked in at run time.

That is, compile and optimize to native machine code when installed - not at run time.

[Please correct the above if you have better information. Thanx!]

To me, that last arrangement seems unlikely to be the full explanation for blazing performance. Java classfiles (as .class or .jar) can be much more compact than native binaries. There was some work done on disk seek time versus in-memory JIT compile for Oberon slim binaries, and small binaries which 'need some work' turned out better than native code [http://caesar.ics.uci.edu/oberon/research.html]. It seems likely oracle have made some assumptions (like: no roll-yer-own classloader) and applied some global optimizations - something you can't really do with class-at-a-time JIT compilation. BTW, gcc can compile java to native if you link the resulting binaries to glibj. I have no idea of how this performs though.

On April 20, 2001:

Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cn130-20010207 (JIT enabled: jitc)

 C:\tmp>c:\jdk1.3.0_02\bin\java -classic TextFileTest?
 Vector time (secs): 27.299
 ArrayList time (secs): 25.257

Java HotSpot(TM) Client VM (build 1.3.0_02, mixed mode)

 C:\tmp>c:\IBMJDK13\bin\java -Xmx256m -Xms256m TextFileTest?
 Vector time (secs): 0.761
 ArrayList time (secs): 0.711

See JavaTextFilePerformance

-- StevenNewton

WhitePapers?:

  Html: http://java.sun.com/products/hotspot/docs/whitepaper/Java_HotSpot_WP_Final_4_30_01.html
  Pdf:  http://java.sun.com/products/hotspot/docs/whitepaper/Java_HotSpot_WP_Final_4_30_01.pdf

CategoryJava