Project proposal: Remove the Permanent Generation

Thu May 31 00:08:24 PDT 2012

Coleen,

Sorry for the late reply on this. I have been going through the perm gen 
removal changes with Stefan over the past few weeks. Overall I think it 
looks great! You are all doing an excellent job!

Stefan has made several changes based on our code walk through we did. 
Below are a few minor things that he did not have time to fix. I am not 
sure any of them are particularly important.

Bengt

CardTableModRefBS::write_ref_needs_barrier()
This does not seem to be used anymore and is now implemented as 
ShouldNotReachHere(). Is there a plan to start using it again or should 
it be removed?

ConcurrentMarkSweepGeneration::update_counters(size_t used)
It looks like this method lost its implementation. Was this intentional?

GCCause::_permanent_generation_full
Should maybe be renamed to "metadata"-something when we trigger a GC due 
to too much memory being allocated for metadata.

PermGen flags. What are the plans for the existing PermGen flags? Will 
they be replaced, ignored or reused?
I've seen: PermSize, MaxPermSize, CMSPermGenPrecleaningEnabled, 
CMSTriggerPermRatio, CMSInitiatingPermOccupancyFraction, 
CMSIsTooFullPercentage, AdaptivePermSizeWeight, PermGenPadding, 
MinPermHeapExpansion, MaxPermHeapExpansion and PermMarkSweepDeadRatio.

The comments for these class data sharing flags mention perm gen and 
should probably be updated:
UseSharedSpaces, RequireSharedSpaces, SharedReadWriteSize, 
SharedReadOnlySize

On 2012-05-09 20:45, 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.