Project proposal: Remove the Permanent Generation

[Coleen Phillimore]

We want to keep the openjdk community aware of the changes to remove the 
permanent generation.   We are nearing completion of the functional 
changes.  The webrev below has been generated as side effect of syncing 
to the latest hotspot-gc repository.

http://cr.openjdk.java.net/~coleenp/metadata3

Since the last webrev that we sent out, these areas have been completed:

1. G1 and CMS (concurrent mark sweep) garbage collectors are now supported.
2. Metadata is now allocated from chunks in mmap space(s).  The chunks 
are still freed when the class loader that owns the metadata is unloaded.
3. Many cleanups, including removing is_parseable is_conc_safe and 
is_partially_loaded, and others.
4. Bug fixes from internal test runs.

There are a few large changes coming to this repository very soon:

1. Allocate CompiledICHolders (once oops) out of CHeap memory.
2. Serviceability Agent changes to reflect the new metadata types.
3. Class data sharing.

The last change we'll make is to rename the metadata types to remove the 
Oop suffixes and capitalize type names.

Please feel free to comment, ask questions and/or make suggestions.

Thanks,
Coleen

On 3/20/2012 10:40 AM, Jon Masamitsu wrote:
> You may have noticed that this project proposal never got
> any farther then this mail.  Somewhat due to indecision on
> our part, this work is not going to become its own project
> but will be integrated through the hsx/hotspot-gc/hotspot
> repository.  We wanted to provide a preview of the work
> so prepared this webrev from an recent merge of the perm gen
> removal work with hotspot-gc.  We're still working on it
> but thought this intermediate webrev would be of interest.
>
> http://cr.openjdk.java.net/~coleenp/metadata2
>
> In this webrev
>
>     Allocations for the class metadata are made from the C heap.
>     More work is coming here.  The infrastructure for the perm
>     gen has not yet been removed but nothing is allocated in
>     the perm gen.
>
>     The klasses that were used to described class metadata have
>     been removed (klassKlass and it's derivatives).
>
>     Class metadata type (instanceKlass) has been changed and is
>     being separated from oops.  It still derives from Klass but
>     Klass now derives from metadataOop and not Klass_vtbl. Please
>     note that metadataOop does not derive from oop. In an attempt
>     to stay sane we're not changing everything at once.  The
>     separation of instanceKlass from oop is being done in a staged
>     way and we're not done.  You'll see klassOop, constantPoolOop,
>     and constantPoolCacheOop but they are not oops.  For example
>     klassOop is typedef'ed to Klass and these types will be renamed
>     to remove the Oop extension and capitalize the first letter
>     to be consistent with other Hotspot type names.
>
>     instanceKlass, constantPoolOop, and constantPoolCacheOop
>     have been restructured to reduce the number of oops they contain.
>     constantPoolKlass and cpCacheKlass are gone.
>
>     Data structures have been added to represent class loaders and
>     dependencies between class loaders (ClassLoaderData and
>     ClassLoaderDataGraph, respectively). Class unloading is directly tied
>     to the liveness of the class loaders.
>
>     All the garbage collectors have been modified to find and follow
>     oops in class metadata. The work for the CMS collector is not
>     complete.
>
>     Changed interpreter to support the move of oops out of the constant
>     pool.
>
>     Within the compilers and associated code most of the changes
>     involved separating the oop and metadata types, which required
>     changes throughout the compiler interface, relocations, dependencies,
>     nmethods, debug info and the type systems of the compilers 
> themselves.
>     Code generation is for the most part unchanged.
>
>
> On 11/28/11 09:20, Jon Masamitsu wrote:
>> I am going to be proposing the permanent generation
>> removal as  a OpenJDK project shortly.  The project is
>> described in the JEP 122
>>
>> http://openjdk.java.net/jeps/122
>>
>> This is not the formal proposal of the project but rather
>> a chance to ask questions ahead of that proposal.