IBM User Guide for Java V7 on Windows > IBM SDK for Java

Class data sharing

The class sharing feature in the IBM Version 7 SDK offers the transparent and dynamic sharing of data between multiple Java™ Virtual Machines (JVMs). When enabled, JVMs use shared memory to obtain and store data, including information about: loaded classes, Ahead-Of-Time (AOT) compiled code, commonly used UTF-8 strings, and Java Archive (JAR) file indexes.

This form of class sharing is an advancement on earlier JVMs that have offered some form of class sharing between multiple JVMs; for example, the IBM Persistent Reusable JVM on z/OS, Oracle Corporation "CDS" feature in their Java 5.0 release, and the bytecode verification cache in the i5/OS™ Classic VM.

You can enable shared classes with the -Xshareclasses command-line option. For reference information about -Xshareclasses, see JVM command-line options.

For diagnosing problems with shared classes, see Shared classes diagnostic data.

When loading a class, the JVM internally stores the class in two key parts:

• The immutable (read only) portion of the class.
• The mutable (writeable) portion of the class.

When enabled, shared classes shares the immutable parts of a class between JVMs, which has the following benefits:

• The amount of physical memory used can be significantly less when using more than one JVM instance.
• Loading classes from a populated cache is faster than loading classes from disk, because classes are already partially verified and are possibly already loaded in memory. Therefore, class sharing also benefits applications that regularly start new JVM instances doing similar tasks.

Caching AOT methods reduces the affect of JIT compilation when the same classes are loaded by multiple JVMs. In addition, because a shared classes cache might persist beyond the life of a JVM, subsequent JVMs that run can benefit from AOT methods already stored in the cache.

Key points to note about the IBM class sharing feature are:

• Class data sharing is available on all the platforms that IBM supports in Java V7, apart from the Oracle Solaris and HP hybrids.
• 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.
• A JVM can connect to a cache with either read-write or read-only access. Using read-only access allows greater isolation when many users are sharing the same cache.
• The class cache memory can be protected from accidental corruption using memory page protection.
• The JVM determines how many AOT methods get added to the cache and when. The amount of AOT method data is typically no more than 10% of the amount of class data cached.
• The JVM automatically removes and rebuilds a class cache if it decides that the cache is corrupted, or if the cache was created by a different level of service release.
• A separate, independent cache is created for each JVM version. For example, if you are running both 31-bit and 64-bit JVMs, two caches are created. If you are running Java 6 and Java 7, two caches are created.
• The file system location of the cache files can now be specified on the command line. Persistent cache files can be moved and copied around the file system. Persistent cache files can also be moved and copied between computers that use the same operating system and hardware.
• Filters can be applied to Java class loaders to allow users to limit the classes being shared.
• 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 removed. Persistent caches remain even after the operating system is shut down. Non-persistent caches are lost when 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 retransformed and redefined bytecode 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.
• The classes cache stores class LineNumberTable and LocalVariableTable information in a reserved region of the cache during debugging. By storing these attributes in a separate region, the operating system can decide whether to keep the region in memory or on disk, depending on whether debugging is taking place.

Parent: IBM SDK for Java

Error 404 - Not Found

The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.