Summary

Remove the permanent generation from the Hotspot JVM and thus theneed to tune the size of the permanent generation.

Non-Goals

Extending Class Data Sharing to application classes.Reducing the memory needed for class metadata.Enabling asynchronous collection of class metadata.

Success Metrics

Class metadata, interned Strings and class static variables will bemoved from the permanent generation to either the Java heap ornative memory.

The code for the permanent generation in the Hotspot JVM will beremoved.

Application startup and footprint will not regress more than 1%as measured by a yet-to-be-chosen set of benchmarks.

Motivation

This is part of the JRockit and Hotspot convergence effort. JRockitcustomers do not need to configure the permanent generation (sinceJRockit does not have a permanent generation) and are accustomed tonot configuring the permanent generation.

Description

Move part of the contents of the permanent generation in Hotspotto the Java heap and the remainder to native memory.

Hotspot's representation of Java classes (referred to here as classmeta-data) is currently stored in a portion of the Java heap referredto as the permanent generation. In addition, interned Strings andclass static variables are stored in the permanent generation. Thepermanent generation is managed by Hotspot and must have enough roomfor all the class meta-data, interned Strings and class statics usedby the Java application. Class metadata and statics are allocated inthe permanent generation when a class is loaded and are garbagecollected from the permanent generation when the class is unloaded.Interned Strings are also garbage collected when the permanentgeneration is GC'ed.

The proposed implementation will allocate class meta-data in nativememory and move interned Strings and class staticsto the Java heap. Hotspot will explicitly allocate and free thenative memory for the class meta-data. Allocation of new classmeta-data would be limited by the amount of available native memoryrather than fixed by the value of -XX:MaxPermSize, whether thedefault or specified on the command line.

Allocation of native memory for class meta-data will be donein blocks of a size large enough to fit multiple pieces of classmeta-data. Each block will be associated with a class loader andall class meta-data loaded by that class loader will be allocatedby Hotspot from the block for that class loader. Additional blockswill be allocated for a class loader as needed. The block sizeswill vary depending on the behavior of the application. The sizeswill be chosen so as to limit internal and external fragmentation.Freeing the space for the class meta-data would be done when theclass loader dies by freeing all the blocks associated with theclass loader. Class meta-data will not be moved during the lifeof the class.

Alternatives

The goal of removing the need for sizing the permanent generationcan be met by having a permanent generation that can grow. There areadditional data structures that would have to grow with thepermanent generation (such as the card table and block offset table).For an efficient implementation the permanent generation wouldneed to look like one contiguous space with some parts that arenot usable.

Testing

Changes in native memory usage will need to be monitored during testingto look for memory leaks.

Risks and Assumptions

The scope of the changes to the Hotspot JVM is the primary risk. Alsoidentifying exactly what needs to be changed will likely only bedetermined during the implementation.

This is a large project that affects all the garbage collectorsextensively. Knowledge of the permanent generation and how itworks exists in both the runtime and compiler parts of the hotspot JVM.Data structures outside of the garbage collectors will be changedto facilitate the garbage collector's processing of the classmeta-data in native memory.

Some parts of the JVM will likely have to be reimplemented as partof this project. As an example class data sharing will be affectedand may require reimplementation in whole or in part.

Class redefinition is an area of risk. Redefinition relies on thegarbage collection of class meta-data during the collection ofthe permanent generation (i.e., redefinition does not currentlyfree classes that have been redefined so some means will be necessaryto discover when the meta-data for classes that have been redefinedcan be freed).

Moving interned Strings and class statics to the Java heap may resultin an Out-of-memory exception or an increase in the number of GCs.Some adjustment of -Xmx by a user may be needed.

With the UseCompressedOops option pointers to class meta-data(in the permanent generation) can be compressed in the same wayas pointers into the Java heap. This yields a significantperformance improvement (on the order of a few percent).Pointers to meta-data in native memory will be compressedin a similar manner but with a different implementation. Thislatter implementation may not be as high performance ascompressing the pointers into the Java heap. The requirementsof compressing the pointers to meta-data may put an upper limiton the size of the meta-data. For example if the implementationrequired all meta-data to be allocated below some address (forexample below the 4g limit) that would limit the size of themeta-data.

Dependences

Tools that know about the permanent generation will need to bereimplemented. The serviceability agent, jconsole, Java VisualVM andjhat are examples of tools that will be affected.

Impact

• Other JDK components: Tools that have knowledge of the permanentgeneration.

• Compatibility: Command line flags relating to the permanent generation willbecome obsolete.

• Documentation: References to the permanent generation will need to beremoved.