WASKB-030 UNDERSTANDING CLASS SHARING IN IBM JDK 5 TUTORIAL
INTRODUCTION
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.
BASIC MECHANISM
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.
SETTING THE CACHE SIZE
Set the cache size using -Xscmx. The following will create a 10KB cache.
java -Xshareclasses:name=myCache -Xscmx10k -jar MyApp.jar
VIEWING CACHE STATISTICS
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: 0x6C06C2B4 CLASSPATH C:tempLogReportxit.jar C:tempLogReportswt.jar C:tempLogReportLogReport.jar 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.
DELETING A CACHE
To delete a cache do:
java -Xshareclasses:destroy,name=myCache
You can not delete a cache while it is in use.
PRACTICAL USAGE
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.