java technology centre - hursley java6 development presentation subtitle: 20pt arial regular, teal...

JAVA Technology Centre - Hursley

Java6 Development © 2008 IBM Corporation

Class Sharing Past and Present

Ben CorrieJava 6 VM Development

March 2008

2 © 2008 IBM Corporation

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”.


Memory Usage – no class sharing

Class Memory Segments

JVM 1

Classeson

disk

Object Memory (Heap)

JIT Code Cache

Class Memory Segments

JVM 2 Object Memory (Heap)

JIT Code Cache

System Memory


Memory Usage – with class sharing (cold cache)

Shared Class Cache

JVM 1

Classeson

disk


JIT Code Cache


JIT Code Cache

System Memory


Memory Usage – with class sharing (warm cache)

Shared Class Cache

JVM 3

Classeson

disk


JIT Code Cache


JIT Code Cache

System Memory


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


Memory Footprint (Windows)

116

116

115

118

116

124

76

76

78

77

Middleware Server Middleware Server + Class Sharing

Impact of Class sharing on Middleware Application Servers

5th Server Memory

4th Server Memory

3rd Server Memory

2nd Server Memory

1st Server Memory


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%


Startup Time Examples

0

10

20

30

40

50

60

70

80

Win32 (2 JVMs) Linux32 (2 JVMs) Win32 (16 JVMS) AIX32 (16 JVMs) Linux32 (32 JVMs)

No sharing

Cold cache

Warm cache

Time taken to run a Java Application that loads 10,000 classes.JVM/Processor ratio = 2/1


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


Java 5 Runtime

JVM 2

Classes on disk

Cache inShared memorySemaphore

JVM 1

Control Filesfor memory/semaphore

Cache contents:- Classes -

Locking controlledby semaphore


Java 6 Runtime

JVM 2

Classes on Disk

JVM 1

Cache on diskLocking controlled

by file locks

Page protection

Cache Contents:- Classes -

- AOT code -- Byte data -

- String table -

Optional filter


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)


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


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


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


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)


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.


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