Project proposal: Remove the Permanent Generation
Bengt Rutisson
bengt.rutisson at oracle.com
Thu May 31 22:46:18 PDT 2012
Jon,
Thanks for the feedback. Sounds good to me.
Bengt
On 2012-05-31 18:08, Jon Masamitsu wrote:
>
>
> 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.
>>
>>
More information about the hotspot-dev
mailing list