Project proposal: Remove the Permanent Generation

[Jon Masamitsu]

This is the webrev for the latest sync with hotspot-gc.   Most changes 
are cleanups
or bug fixes.  One large change is the removal of the (unused for a 
while now)
perm gen from the generational hierarchy.

http://cr.openjdk.java.net/~jmasa/6964458/webrev.00/

As we've said the pervasive renaming of data structures will be done
just before we integrate in order to ease the burden of the syncs.

Now's the time to look at the code in your area of interest.

On 5/9/2012 11:45 AM, Coleen Phillimore wrote:
>
> Please find below the webrev of the Permgen elimination changes from 
> our latest merge with the hotspot-gc baseline.   We have completed the 
> major functional changes and are now working on cleanups, testing and 
> bug fixes.  There are a few items left to do that we will file as 
> RFE's when this is integrated.   We'll have a couple of other webrevs 
> before integration which we will again solicit code review comments.   
> But don't wait!   This is huge so your comments in advance regarding 
> areas within your expertise.
>
> You can also get a patch file and patch against 
> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot changeset 
> 9f059abe8cf2 .
>
> http://cr.openjdk.java.net/~coleenp/metadata4
>
> Changes since last webrev include serviceability agent support, 
> compiledICHolders are allocated in C Heap and class data sharing 
> support (CDS).   Left to do is the big rename of the metadata from a 
> lower case name to upper case name without the OopDesc.   We're taking 
> suggestions for what to rename constantPoolCacheOopDesc since it's 
> never been a cache and it's now not an oop either.
>
> Thanks!
> Coleen
>
>
> On 4/13/2012 6:50 PM, Coleen Phillimore wrote:
>>
>> 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.