Transcript Java6_WUG_SharedClasses_Ext

JAVA Technology Centre - Hursley
Class Sharing Past and Present
Ben Corrie
Java 6 VM Development
March 2008
Java6 Development
© 2008 IBM Corporation
What is Class Sharing?
 Java code is contained in java “classes” which are loaded from the filesystem 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”.
2
© 2008 IBM Corporation
Memory Usage – no class sharing
System Memory
Class Memory Segments
JVM 1
Object Memory (Heap)
JIT Code Cache
Classes
on
disk
Class Memory Segments
JVM 2
Object Memory (Heap)
JIT Code Cache
3
© 2008 IBM Corporation
Memory Usage – with class sharing (cold cache)
System Memory
Object Memory (Heap)
JVM 1
Classes
on
disk
JIT Code Cache
Shared Class Cache
JVM 2
Object Memory (Heap)
JIT Code Cache
4
© 2008 IBM Corporation
Memory Usage – with class sharing (warm cache)
System Memory
Object Memory (Heap)
JVM 3
Classes
on
disk
JIT Code Cache
Shared Class Cache
JVM 4
Object Memory (Heap)
JIT Code Cache
5
© 2008 IBM Corporation
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
6
© 2008 IBM Corporation
Memory Footprint (Windows)
Impact of Class sharing on Middleware Application Servers
116
118
77
78
115
76
116
116
Middleware Server
7
5th Server Memory
4th Server Memory
3rd Server Memory
2nd Server Memory
1st Server Memory
76
124
Middleware Server + Class Sharing
© 2008 IBM Corporation
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%
8
© 2008 IBM Corporation
Startup Time Examples
80
70
60
50
No sharing
40
Cold cache
Warm cache
30
20
10
0
Win32 (2 JVMs)
Linux32 (2 JVMs)
Win32 (16 JVMS)
AIX32 (16 JVMs)
Linux32 (32 JVMs)
Time taken to run a Java Application that loads 10,000 classes.
JVM/Processor ratio = 2/1
9
© 2008 IBM Corporation
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
10
© 2008 IBM Corporation
Java 5 Runtime
Locking controlled
by semaphore
Semaphore
Cache in
Shared memory
JVM 1
JVM 2
Control Files
for memory/
semaphore
11
Cache contents:
- Classes -
Classes
on disk
© 2008 IBM Corporation
Java 6 Runtime
Locking controlled
by file locks
Cache on disk
Cache Contents:
- Classes - AOT code - Byte data - String table -
Page protection
JVM 1
JVM 2
Optional filter
Classes
on Disk
12
© 2008 IBM Corporation
Java 6 Feature Summary
 Persistent cache support
– memory mapped files instead of IPC shared memory









13
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)
© 2008 IBM Corporation
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
14
© 2008 IBM Corporation
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
15
© 2008 IBM Corporation
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
16
© 2008 IBM Corporation
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)
17
© 2008 IBM Corporation
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.
18
© 2008 IBM Corporation
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
19
© 2008 IBM Corporation