IBM JDK 5 can share classes between JVM processes. This feature improves performance since class byte code needs to be loaded only once. Specifically, server startup time can be improved quite a bit this way. In this artile, we will dig deep into how class sharing works and how to configure the behavior. After reading this article, you should be able to enable class sharing in your own Java application.


Class byte code is loaded into a shared cache. This cache is then accessed by multiple JVMs to run the class bytecode. Currently, in Windows and UNIX, a cache is implemented as a memory mapped file. Because the byte code is cached in a file, it reduces demand for memory.

Every cache has a name. A JVM must attach itself to a cache to share classes from it. This is done using the -Xshareclasses argument. For example:

java -Xshareclasses:name=myCache -jar MyApp.jar

When this command is run for the first time, a cache called myCache is created. Classes (core Java classes and application classes) are cached there. If another JVM is launched with the same command line, classes will be shared between processes.

A cache lives beyond the life time of a JVM. It can be explicitly deleted. It is also deleted when the OS is rebooted.


Set the cache size using -Xscmx. The following will create a 10KB cache.

java -Xshareclasses:name=myCache -Xscmx10k -jar MyApp.jar


Cache statistics can be viewed using the java command. In this case, the JVM is not launched. The program simply prints output.

List all caches:

java -Xshareclasses:listAllCaches

This will print all cache names and last time a JVM disconnected from it. For example:

Shared Cache Last detach time
myCache Thu Apr 12 22:05:34 2007
sharedcc_bibhas In use
webspherev61 Thu Apr 12 21:23:17 2007

View cache statistics:

java -Xshareclasses:printStats,name=myCache

This will print out:

base address = 0x6B070058
end address = 0x6C06FFF8
allocation pointer = 0x6B3EEE98
cache size = 16777128
free bytes = 13078148
ROMClass bytes = 3665472
Metadata bytes = 33508
Metadata % used = 0%
# ROMClasses = 748
# Classpaths = 2
# URLs = 0
# Tokens = 0
# Stale classes = 0
% Stale classes = 0%

The ROMClasses row shows the number of classes cached.

To view a detailed report of which classes are in the cache:

java -Xshareclasses:printAllStats,name=myCache

This will print something like:

1: 0x6C06C27C ROMCLASS: com/webage/report/Dialog at 0x6B1BA518.
Index 2 in classpath 0x6C06C2B4
1: 0x6C06C254 ROMCLASS: com/webage/report/LoginDialog at 0x6B1B9750.

This shows the classes and their source Jar file that are in the cache.


To delete a cache do:

java -Xshareclasses:destroy,name=myCache

You can not delete a cache while it is in use.


WebSphere v6.1 automatically configures and uses a class sharing. The name if the cache is webspherev61.

You can use class sharing from your custom Java application. This will help, if your application launches multiple JVMs. Because the classes are cached in a file and the cache lives after the JVMs are shutdown, even a single instance of JVM will benefit from class caching.

We did a benchmark of WebSphere v6.1’s startup time. First we measured the startup time with the class cache already created. In this case, WebSphere does not need to load classes from JAR files.

With existing cache, startup time is 12s.

Next, we measured the startup time when the cache does not exist. That is, we first deleted the cache and then started WebSphere. Note: At this point (April 2007), there is no way to disable the use of cache in WebSphere 6.1. IBM has made an e-fix available on this. Anyway, in this case, classes are loaded from JAR files.

With the added overhead of building the cache, startup time is 14s.