|
|
|
|
Back to newsletter 177 contents
Java 9 retires our old friend of the Java performance community, hprof. The hprof profiler was added in to the JVM distribution in Java 1.2, and it's been a part of the JDK ever since. Probably many of you have never used hprof explicitly, or even been aware of it being in the JDK, but if you ever got a heap dump from the JVM, then you've used it implicitly. Don't worry, heap dumps will still be available in Java 9; even though hprof is being removed - they're retaining the heap dump capability.
The hprof profiler (you run it with the -Xrunhprof option to the command line, and it accepts a variety of sub-options to configure exactly what profiles you want to generate) was introduced as a demonstration profiler for using the JVMPI (and retained as a demonstration for the replacement JVMTI, though was completely rewritten to be more stable just as JVMTI was itself more stable than JVMPI). It's always been a little fiddly to use, and prone to crashing the JVM, but when it was first introduced it was free, and better than anything else that was free at the time. JHat was created to handle the memory dumps generated by the hprof profiler (JHat is also being retired for Java 9). The retirement rationale is that there are many better free tools out there, so there's no point in maintaining hprof, and that's true. jvisualvm is a better profiler and eclipse memory analyser (MAT) is a better heap dump analyser.
For those of you who like trivia, "hprof" stood for "heap profiler", although it profiled CPU execution as well as the heap. The reason you ran it with "-Xrunhprof" was because "-Xrun" is a generic command to the JVM to run a shared library agent given by the name of the subsequent characters, ie "-Xrunxyz" would run the shared library agent "xyz". In this case, it ran "hprof" - on unix there will be a "libhprof.so" file somewhere under the JRE distribution, on windows a "hprof.dll". It was part of the actual JRE, not only the JDK, because the JRE needed the ability to dump the heap that hprof provided.
Hprof stored all it's profile information outside the heap, in the C-side of the data, to minimize the profiler itself affecting Java object measurements. It included both generic types of cpu execution profilers, sampling (it simply spawned a separate thread which repeatedly slept for a specified number of microseconds then sampled the stacks of all threads), and timing (it used bytecode-insertion to insert timing code into every method entry and exit point). And it included two heap profilers, one which you know dumps the heap, and one which used bytecode-insertion to get the stack for every object allocation and then tracked objects; this latter profiler provided sufficient information to find what was creating objects, both for object allocation profiling and for object heap profiling.
Finally gone in Java 9 along with jhat, bye bye hprof. Now on to all our usual sections: links to tools, articles, news, talks and as ever, all the extracted tips from all of this month's referenced articles .
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 177 contents
