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:
- The virtual memory footprint reduction when using more than one JVM instance can be significant.
- Loading classes from a populated cache is faster than loading classes from disk, because the classes are already in memory and are already partially verified.
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.
- Classes are stored in a named "class cache", which is either a memory-mapped file or an area of shared memory, allocated by the first JVM that needs to use it.
- Any JVM can read from or update the cache, although a JVM can connect to only one cache at a time.
- The cache persists beyond the lifetime of any JVM connected to it, until it is explicitly destroyed or until the operating system is shut down.
- When a JVM loads a class, it looks first for the class in the cache to which it is connected and, if it finds the class it needs, it loads the class from the cache.
- Otherwise, it loads the class from disk and adds it to the cache where possible.
- When a cache becomes full, classes in the cache can still be shared, but no new data can be added.
- Because the class cache persists beyond the lifetime of any JVM connected to it, if changes are made to classes on the file system, some classes in the cache might become out of date (or "stale"). This situation is managed transparently; the updated version of the class is detected by the next JVM that loads it and the class cache is updated where possible.
- Sharing of bytecode that is modified at runtime is supported, but must be used with care.
- Access to the class data cache is protected by Java permissions if a security manager is installed.
- Classes generated using reflection cannot be shared.
- Only class data that does not change can be shared. Resources, objects, JIT compiled code, and similar items cannot be stored in the cache.
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 myJSM 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.