The ability to share classes between Java virtual machines (JVMs) was first introduced in IBM JRE for Java 5 and continues to be supported and enhanced in Java 6. When classes are loaded by the JVM, they can be placed in a cache. When subsequent requests for that class are made, these requests are satisfied from the cache if possible rather than loading the class from a corresponding .jar file. A JVM typically compiles Java methods to native code while the program executes. This native code is generated every time the program is run. The IBM JRE for Java 6 SR1 JVM introduces the ability to compile Java methods using Ahead of Time compilation technology to create native code that can not only be used in the current JVM but can also be stored into a shared class cache. Another JVM launched using a shared class cache that has been populated with AOT code during previous invocations of Java programs, can use the AOT code stored in the cache to reduce startup time. This reduction is delivered by saving the time needed for compilation and by faster execution of methods as AOT code. AOT code is native code and generally executes faster than interpreted code (although it is not likely to run as fast as JIT-generated code). Enhance Performance With Class Sharing reviews the changes and provide examples demonstrating the benefits using Eclipse and Apache Tomcat as a sample client-and server-side operating environment. It provides installation instructions so that you can try things out for yourself. IBM JRE SE 6 is available for Linux, AIX, and Windows.
- Posted by: Eugene Ciurana
- Posted on: October 08 2008 10:29 EDT
- Re: Enhanced Performance With Class Sharing by A D on October 08 2008 10:48 EDT
- Similar to Apple's Class Data Sharing? by Matthew Passell on October 08 2008 11:42 EDT
Very interesting. Can it be made to work across VM launched on different machines. And the real question is, Will it reduce the memory footprint and increase the performance of the Websphere hogs...
Very interesting. Can it be made to work across VM launched on different machines.I don't think that request makes much sense.
And the real question is, Will it reduce the memory footprint and increase the performance of the Websphere hogs...If there are multiple websphere instances then I imagine it would but I doubt by much. I can't imagine that a significant portion of memory in websphere is used for class definitions. The biggest potential benefit I can see from this is improved JVM startup time.
The AOT compilation and the sharing of its output between JVMs may be novel, but Apple introduced what it called "class data sharing" a long time ago (in a 1.4.x JVM, I believe). The approach, and perhaps some of the code, was then incorporated into Sun's Windows and Solaris JVMs not long after. Other than the AOT stuff, what does IBM's approach offer beyond Apple's/Sun's? --Matt Passell
As I know, (please correct me if I wrong) Sun JRE's "class data sharing" does only share "JRE core classes". Before finish the JRE installation, it will compile some classes of JRE and dump into a static readonly file. It will not cache or share your own class, and even not all class which you can find in the JRE. And the shared class data won't be update on runtime. I am not yet look into the IBM JRE way, but the AOT sounds like .NET native assembly in the global assembly cache. So, I have a different question, What does IBM's approach offer beyond Microsoft's?
The AOT compilation and the sharing of its output between JVMs may be novel, but Apple introduced what it called "class data sharing" a long time ago (in a 1.4.x JVM, I believe). The approach, and perhaps some of the code, was then incorporated into Sun's Windows and Solaris JVMs not long after. Other than the AOT stuff, what does IBM's approach offer beyond Apple's/Sun's?This is answered in another article linked to by the one above: http://www.ibm.com/developerworks/java/library/j-ibmjava4/
The principle of sharing loaded classes between Java virtual machine (JVM) processes is not new. Sun's CDS feature, for example, writes system classes into a read-only file that is memory-mapped into the JVM.The Shiraz feature in the IBM z/OS® 1.4.2 JVM used a master JVM to populate a class cache that was then shared by slave JVMs. The IBM implementation of the 5.0 JVM takes the concept a step further by allowing all system and application classes to be stored in a persistent dynamic class cache in shared memory. This Shared Classes feature is supported on all of the platforms on which the IBM implementation of the JVM ships. The feature even supports integration with runtime bytecode modification, which this article discusses later.
Thanks Dennis and James! That was exactly what I was looking for. Anyone have an answer for Dennis's IBM AOT vs. Microsoft GAC question?