Hi, I was reading about Java's New HotSpot. I added it to my Jdk 1.2.2. The performance improvement is remarkable but why does the improvement visible when you run the program 2nd or third time, the first time, its the same as running the regular jdk1.2.2. Please if anyone can shed some light in this matter and also what are the dis-advantages of using this in your jdk environment. Thanks.
I'm no hotspot expert, but I do know the advantage is the optimizing compiler. It will recompile your code in many different ways and try them all to see which way is the fastest. So the more you run it, the faster it will get.
I do know that the new runtime included as part of the JDK 1.3 has introduced some unusual new bugs into development. JRun 3.0, from Allaire, does not like running as an underlying service on Windows NT, when 1.3 is used. The reason? Hotspot doesn't handle some of the logging off events that NT generates, thus killing off the Java process. 'Twould be nice to use an optimizing compiler for JSPs and Servlets.
Is it true that the JDK1.3 includes the new HotSpot compiler?
Joined: Oct 26, 2000
Here's a copy of my answer from the other thread. The 1.3 VM uses a HotSpot engine, where 1.2.2 is pure JIT. In case you missed what HotSpot technology means, the basic idea is that the VM profiles the code while it's running, then only generates native code for those bits of the app that are bottlenecked. The VM does this by running the app in interpreted mode with an internal profiler runnning at the same time. The app profile is constantly monitored, and if some code (method or loop) is staying too long at the top of the execution stack (the "hot spots" in the app), the VM generates native code for that method/loop, and swaps the interpreted bytecode for the native-code. In HotSpot 1.0, the VM had to wait until a method completed before the swap could happen, but in HotSpot 2.0 (which is the engine used in 1.3) the swap can happen while a method/loop is running. Unlike the server-side HotSpot VMs (called HotSpot 1.0 and 2.0) the 1.3 VM is tuned for client-side running, which basically means "don't hang about as long before generating native code, and don't apply as many optimizations when the native code is generated, so that the code is not held up as long.". If you have a long-running process, you are probably better off using the server-side HotSpot since the longer running time can be taken advantage of by the VM. The upshot is that 1.3 VM effectively acts like it has a low-level performance tuning expert running inside the VM. He can speed up the code in the bits that need speeding up the most. But he only ever applies a limited set of optimizations. The result is that some things run quite a bit faster - I've seen double the speed for some tasks. On occasion the VM can get it wrong, but not often. However, 1.1.6 and later 1.1.x JIT VMs can outperform 1.2 and 1.3 VMs for some tasks because those VMs have different task loads. In addition, people are pretty clever, and manual optimizations can often outperform the HotSpot optimizations. I have an article at http://java.oreilly.com/news/javaperf_0900.html which runs through a basic tuning exercise on running a query against a collection. The article shows how HotSpot VMs start by outperforming, but can end up lagging after manual optimizations are applied.
I seem to get a few percent speedups for long running JVM tests when comparing HotSpot 2.0 JVm to the 1.3 JVM. Although this is only a small speedup, on the basis that this is a free speedup with almost no maintenance overheads, I would say yes. My only caveat is that on some server sites who moved from 1.2.x to HotSpot 1.0, they said the resulting JVMs were less stable. But I would guess this is less of an issue between 1.3 and HotSpot 2.0, since the JVMs are considerably closer in architecture - they probably both have the same (lack of?) robustness.
I must say, that I had problems with the Hotspot VM (I don't know wich version came with jdk1.3 for Linux) It was not possible to interrupt a thread who tried to connect to an non-existing host. (Neither was it possible to stop it) With the Classic VM 1.3 I had no problems. Pat