Project proposal: Remove the Permanent Generation

Thu May 31 09:08:17 PDT 2012

On 05/31/12 00:08, Bengt Rutisson wrote:
>
> 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?

I've removed it.  It's easy enough to add back if needed.

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

That looks like a mistake.  I'll add it back.

>
>
> 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.

I have a repository where this is replaced by _metadata_GC_threshold
>
>
> 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.

PermSize, MaxPermSize, MinPermHeapExpansion, MaxPermHeapExpansion will 
be replaced.

I think we keep CMSIsTooFullPercentage.  I think this is used to decide 
to unload classes
even if CMSClassUnloadingEnabled is false.

The others are obsolete and will be added to the ObsoleteFlag in 
arguments.cpp

Jon

>
>
> 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.
>
>