Java technology, IBM style: class sharing

The concept of sharing a loaded class between Java virtual machine (JVM) processes is not new. For example, the Sun's CDS feature writes system classes to a read-only file, which is mapped to the JVM in memory. The Shiraz feature in the IBM z/os®1.4.2 JVM populates the class cache with a main JVM, which can then be shared from the JVM.

The IBM implementation of JVM 5.0 further developed this concept, allowing all system classes and application classes to be stored in a consistent dynamic class cache in shared memory. This shared class feature is supported on all platforms that support the IBM implementation of the JVM. This feature even supports integration with Run-time bytecode modifications, which are discussed later in this article.

The shared class feature is designed from scratch and is an option that can be turned on and off to reduce virtual memory footprint and improve JVM startup time. As a result, it is ideal for environments where multiple JVMs run similar code or where the JVM often restarts.

In addition to the Run-time class sharing support in the JVM and its class loaders, there is a common Helper API that integrates class-sharing support into a custom class loader, which is discussed in detail in this article.

How it works

Let's take a look at the technical details of how shared class features operate.

Enable class sharing

The way to enable class sharing is to add-xshareclasses[:name=<cachename> to an existing Java command line. When the JVM starts, it looks for the class cache for the given name (if no name is provided, select a default name), and connect the existing cache or create a new cache as needed.

Use parameter-xscmx<size>[k|m|g to specify the size of the cache; This parameter applies only to situations where the JVM creates a new cache. If this option is omitted, select a platform-dependent default value (usually 16MB). Note that some operating system settings may limit the amount of shared memory that can be allocated, for example, SHMMAX on Linux is typically set to approximately 20MB. The details of these settings can be found in the Shared Classes section of the appropriate user's Guide (see Resources for links).

Class caching

Class caching is a fixed-size shared memory area that persists beyond the lifecycle of the JVM that uses it. There can be any number of shared class caches on a system, which is limited only by operating system settings, but a JVM can only connect to one cache in its lifecycle.

The JVM does not have a cache or a master/from JVM concept; in fact, any number of JVMs can read and write caching in parallel. Caching is removed in two cases: using the JVM utility to explicitly destroy it, or when the operating system restarts (the cache cannot persist when the operating system restarts). The size of the cache cannot grow, and when it is filled, the JVM can still load the class from it, but it cannot add any classes to it. There are many JVM utilities used to manage the active cache, which are discussed later in the "Shared Class Utilities" section.

How do I cache a class?

When the JVM loads a class, it first looks at whether the required class already exists in the cache. If so, then it loads the class from the cache. Otherwise, it loads the class from the file system and writes it to the cache (in the defineclass () call). Therefore, a JVM that does not share has the following class loader lookup order:

Class Loader Cache

Parent class Loader

File system

Instead, the JVM for sharing takes the following order:

Class Loader Cache

Parent class Loader

Shared cache

File system

Using the public Helper API to read and write classes in the cache, this API has been integrated into the IBM implementation of Java.net.URLClassLoader. Therefore, any extended Java.net.URLClassLoader class loader automatically obtains class-sharing support.