File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Performance and the fly likes Java's New HotSpot....Anybody tried it Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "Java Watch "Java New topic
Author

Java's New HotSpot....Anybody tried it

Ramnath Krishnan
Ranch Hand

Joined: Feb 10, 1999
Posts: 37
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.
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20542
    ∞

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.

permaculture Wood Burning Stoves 2.0 - 4-DVD set
Jack Shirazi
Author
Ranch Hand

Joined: Oct 26, 2000
Posts: 96
See the 'Please welcome Jack Shirazi, author of "Java Performance Tuning" thread.' for more discussion of HotSpot.
Siegfried Heintze
Ranch Hand

Joined: Aug 11, 2000
Posts: 381
Can someone give me a URL for this?
Eric Lind
Greenhorn

Joined: Oct 25, 2000
Posts: 1
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.
Ed Parks
Greenhorn

Joined: Oct 31, 2000
Posts: 5
Is it true that the JDK1.3 includes the new HotSpot compiler?
Jack Shirazi
Author
Ranch Hand

Joined: Oct 26, 2000
Posts: 96
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.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Is the difference large enough to justify installing a HotSpot 2 (Server) on top of a 1.3 JVM for pure long-lived server-side use?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Jack Shirazi
Author
Ranch Hand

Joined: Oct 26, 2000
Posts: 96
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.
Patrick Mey
Greenhorn

Joined: Dec 07, 2000
Posts: 2
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
 
Don't get me started about those stupid light bulbs.
 
subject: Java's New HotSpot....Anybody tried it