Class sharing in the IBM Technology for Java SDK's offers a transparent and dynamic means of sharing all loaded classes, both application classes and system classes, and placing no restrictions on JVMs that are sharing the class data (unless runtime bytecode modification is being used).
Sharing all immutable class data for an application between multiple JVMs has obvious benefits:
Therefore, class sharing also benefits applications that regularly start new JVM instances doing similar tasks.
The cost to populate an empty cache with a single JVM is minimal and, when more than one JVM is populating the cache concurrently, this activity is typically faster than both JVMs loading the classes from disk.
Key points to note about the IBM class sharing feature are as follows.
Creating shared classes
You switch on shared classes with the SystemDefault.properties -Xshareclasses and -Xscmx command-line options.
-Xscmx<size> Specifies cache size. This option applies only if a cache is being created and no cache of the same name exists. Default cache size is platform-dependent. You can find out the size value being used by adding -verbose:sizes as a command-line argument. Minimum cache size is 4 KB. Maximum cache size is platform-dependent.
The size of cache you can specify is limited by the amount of physical memory and paging space available to the system. Because the virtual address space of a process is shared between the shared classes cache and the Java heap, increasing the maximum size of the Java heap will reduce the size of the shared classes cache you can create.
-Xshareclasses:<suboptions> Enables class sharing. Can take a number of suboptions, some of which are cache utilities. Cache utilities perform the required operation on the specified cache, without starting the VM. You can combine multiple suboptions, separated by commas, but the cache utilities are mutually exclusive.
Listing shared classes
When listing caches, you must use the same JVM as the shared class cache was created for, except versions JDK 6 which can list all version caches.
With JDK5, if the JVM listing the shared classes does not find a compatible shared class, it exits with the JVMSHRC005I message regardless of what shared classes exist.
With JDK6, the VM will usually recognize shared class caches from other J9 VM's but will list them as an incompatible shared class.
Hint: Instead of setting the JAVA_HOME environment variable, use the absolute path to the JDK java shell script file.
Listing all caches in cacheDir /tmp/javasharedresources/
Cache name level persistent last detach time
Compatible shared caches
myJSM Java6 64-bit yes In use
Incompatible shared caches
myJSM Java5 64-bit no Wed Jun 25 14:49:44 2008
myJSM Java5 32-bit no Wed Jun 25 14:46:06 2008
myJSM Java6 32-bit yes Wed Jun 18 12:18:59 2008
Note: There are four my JSM caches, one for each of the STRJSM JVM versions that had been started.
Destroying shared classes
When destroying caches, you must use the same JVM as the shared class cache was created for.
JVMSHRC010I Shared Cache "myJSM" is destroyed
Unable to create Java Virtual Machine.