IBM User Guide for Java V7 on Windows > Performance > Class data sharing between JVMs

Class data sharing

Class data sharing provides a method of reducing memory footprint and improving JVM start time.

Enable class data sharing using -Xshareclasses. The JVM connects to an existing cache or creates a new cache if one does not exist.

All bootstrap and application classes loaded by the JVM are shared by default. Custom class loaders share classes automatically if they extend the application class loader. Otherwise, they must use the Java Helper API provided with the JVM to access the cache.

The JVM can also store ahead-of-time (AOT) compiled code in the cache for certain methods to improve the startup time of subsequent JVMs. The AOT compiled code is not shared between JVMs, but is cached to reduce compilation time when the JVM starts. The amount of AOT code stored in the cache is determined heuristically. You cannot control which methods get stored in the cache. You can set upper and lower limits on the amount of cache space used for AOT code, or you can disable AOT caching completely.

The JVM stores zip entry caches for bootstrap jar files into the shared cache. A zip entry cache is a map of names to file positions used to quickly find entries in the zip file. Storing zip entry caches is enabled by default, or you can choose to disable zip entry caching.

Cache access

A JVM can access a cache with either read/write or read-only access. Any JVM connected to a cache with read/write access can update the cache. Any number of JVMs can concurrently read from the cache, even while another JVM is writing to it.

You must take care if runtime bytecode modification is being used.

Dynamic updating of the cache

The shared class cache persists beyond the lifetime of any JVM. Therefore, the cache is updated dynamically to reflect any modifications that might have been made to JARs or classes on the file system. The dynamic updating makes the cache independent of the application using it.

Cache security

Access to the shared class cache is limited by operating system permissions and Java security permissions. Only a class loader that has registered to share class data can update the shared class cache.

The cache memory is protected against accidental or deliberate corruption using memory page protection. This protection is not an absolute guarantee against corruption because the JVM must unprotect pages to write to them. The only way to guarantee that a cache cannot be modified is to open it read-only.

If a Java SecurityManager is installed, classloaders, excluding the default bootstrap, application, and extension class loaders, must be granted permission to share classes. Grant permission by adding SharedClassPermission lines to java.policy. The RuntimePermission createClassLoader restricts the creation of new class loaders and therefore also restricts access to the cache.

Cache lifespan

Multiple caches can exist on a system and you specify them by name as a suboption to the -Xshareclasses command. A JVM can connect to only one cache at any one time.

You can override the default cache size on startup using -Xscmx<n><size>. This size is then fixed for the lifetime of the cache. Caches exist until they are explicitly deleted using a suboption to the -Xshareclasses command or the cache file is deleted manually.

Cache utilities

All cache utilities are suboptions to the -Xshareclasses command. Use -Xshareclasses:help to see a list of available suboptions.

Parent: Class data sharing between JVMs

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.