2.13 IBM Technology for Java Shared Classes

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.

 

#AllowOptions

 

-Xscmx16M

-Xshareclasses:name=myJSM

 

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.

 

QSH

 

/QOpenSys/QIBM/ProdData/JavaVM/jdk60/64bit/bin/java -Xshareclasses:listAllCaches

 

    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.

 

QSH

 

/QOpenSys/QIBM/ProdData/JavaVM/jdk50/64bit/bin/java -Xshareclasses:destroy,name=myJSM

 

JVMSHRC010I Shared Cache "myJSM" is destroyed

Unable to create Java Virtual Machine.