Class Sharing Past and Present

1. Class Sharing Past and Present Ben Corrie Java 6 VM Development March 2008

2. What is Class Sharing? • Java code is contained in java “classes” which are loaded from the file-system when the JVM starts up. • The JVM creates “objects” from these classes in the JVM heap and stores the classes themselves in local memory. • Each JVM loads its own copy of the java classes into its local memory and if there is >1 JVM, there is therefore duplication. • Class sharing attempts to reduce this duplication by allowing JVMs to “share” loaded classes, so that they are only loaded into memory once. These are stored in a “shared class cache”.

3. Memory Usage – no class sharing System Memory Class Memory Segments JVM 1 Object Memory (Heap) Classes on disk JIT Code Cache Class Memory Segments JVM 2 Object Memory (Heap) JIT Code Cache

4. Memory Usage – with class sharing (cold cache) System Memory Object Memory (Heap) JVM 1 JIT Code Cache Classes on disk Shared Class Cache JVM 2 Object Memory (Heap) JIT Code Cache

5. Memory Usage – with class sharing (warm cache) System Memory Object Memory (Heap) JVM 3 JIT Code Cache Classes on disk Shared Class Cache JVM 4 Object Memory (Heap) JIT Code Cache

6. Class Sharing in Java5 • Features • JVMs can share immutable class data, stored in a class cache • Bootstrap and application class data is shared • It is transparent to the application using it • Class cache is kept up-to-date automatically • Any VM can read or update the class cache • Class cache persists beyond JVM lifetime • Benefits • Reduces virtual memory consumption • Reduces JVM startup time (with a populated cache) • Shipped on all Java5 platforms

7. Memory Footprint (Windows)

8. Class Sharing Benefits • Virtual memory size • Shared classes exist in shared memory, so smaller JVM process size • If class cache gets full, classes in cache can still be shared • JVM startup time • Populating new cache has minimal overhead (around 0-5%) for 1 JVM, but faster for multiple concurrent JVMs • Reading classes from populated cache • Classes loaded from memory, not from disk • Classes are partially pre-verified • Improves JVM startup time typically by 15-40%

9. Startup Time Examples

10. Java 5 Feature Summary • Shared memory area and locking achieved with OS semaphore • Control files stored on disk which index the memory and semaphores • Only class data stored in memory area • One-to-one relationship with JVMs and caches • Caching story is completely dynamic • The experience running with a cache should be totally transparent • Eg. If the class does not exist on disk, but exists in the cache, the class is not loaded • JVMTI support for managing different versions of the same class • Basic cache management/housekeeping functions

11. Java 5 Runtime Cache in Shared memory Semaphore Locking controlled by semaphore Cache contents: - Classes - JVM 1 JVM 2 Control Files for memory/ semaphore Classes on disk

12. Java 6 Runtime Cache on disk • Cache Contents: • Classes - • AOT code - • Byte data - • String table - Locking controlled by file locks Page protection JVM 1 JVM 2 Optional filter Classes on Disk

13. Java 6 Feature Summary • Persistent cache support • memory mapped files instead of IPC shared memory • AOT code cacheing • Shared string table (ROMClass compression) • Cache memory page protection • Open a cache read/only • Improved detection and support for corrupt caches • JVMTI enhancements eg. Cache retransformed classes • Cache utilities (listAllCaches etc) also operate on Java5 caches • Apply custom filters to ClassLoaders to limit sharing • Improved RAS support (eg. Assertion tracepoints)

14. Using and deploying shared classes • Class sharing is enabled using –Xshareclasses • Add –Xshareclasses to application command-line • Class cache utilities are sub-options to –Xshareclasses • Cache size is set using –Xscmx<size>[k|m|g] • JVM connects to an existing cache, or creates a new cache • Multiple caches can exist, but JVM can only connect to one cache • JVM looks for classes first in class cache… • If class found in cache, class is loaded from cache, otherwise class is loaded from disk and added to the cache • No restriction on JVM classpaths, system properties or VM settings • Multiple JVMs can concurrently populate the cache or read from it • Custom ClassLoaders can not automatically share • Java API and Javadoc provided for integrating custom ClassLoaders

15. How it works • JVM initialization • Persistent cache: looks for memory-mapped file on disk • Non-persistent: Looks for a shared memory area and semaphore • UNIX defaults: Information about all caches held on filesystem in /tmp • Windows defaults: Information about caches held on filesystem in C:\Documents and Settings\<username>\Local Settings\Application Data • If permissions/disk space problems, this is currently fatal. • “Nonfatal” can be specified, in which case the JVM starts up regardless and tries to do the best it can. Eg. It will try to open a cache read/only if read/write fails. • JVM runtime (class loading) • Cache/parent/disk lookup order becomes cache/parent/shared cache/disk. If class not found in cache, it is loaded and added. • ROMClass built into ClassLoader ROMClass segment and then copied into the cache • Java Class then built from ROMClass in the cache. • JIT may then choose to add compiled code for hot methods

16. How it works • ClassLoader access • Bootstrap loader has direct internal native access to the cache. • Application ClassLoaders must access the cache via a Java API (called “Helper API” – classes in com.ibm.oti.shared.*). • Essentially 2 functions: findSharedClass and storeSharedClass. • Current support in java.net.URLClassLoader • ClassLoaders must register to be able to access the shared class cache. • Cache metadata • Class is stored along with the full classpath it was loaded from and the timestamps of classpath entries. • Cache can also be partitioned for storing modified bytecode • Cross process locking • Uses IPC semaphores for non-persistent caches and file locks otherwise

17. Security and integrity • Cache access governed by operating system security • Created as “user access” by default, option to create “group access” • Java2 Permissions required for custom ClassLoader • Only applies if a SecurityManager is being used • Can grant “read”, “write” or “read,write” access • A ClassLoader must register for sharing • No access to the cache is possible without a ClassLoader • The cache access granted to a ClassLoader cannot be changed • Only classes defined by that ClassLoader may then be shared with that access (it cannot be stolen/used by other ClassLoaders)

18. Security and integrity • Cache corruption • Persistent caches can be moved/FTP’d etc, so accidental corruption is now more likely. • Page protection ensures JNI code cannot write to cache memory. • Data integrity on a JVM crash, so no corruption. Other JVMs notified. • CRC of cache checked on shutdown and startup. • String table rebuilt if crash detected while holding string table mutex. • If corruption is detected during runtime, the cache is immediately closed to new classes and all JVMs connected to it are notified • If a cache is determined to be corrupt on startup, the JVM automatically tries to delete and recreate it. • Cache is part of system dump so if a crash occurs, the cache memory can be accessed.

19. Questions and Demo • More information can be found on DeveloperWorks • “Java: IBM Style” series • http://www-128.ibm.com/developerworks/java/library/j-ibmjava4/index.html • JVM User/Diagnostics Guides • http://www.ibm.com/developerworks/java/jdk/index.html