PermGen Elimination project is promoting

[Srinivas Ramakrishna]

jmap -permstat, -heap ?(probably yes?)  -dump? (probably not? probably not
needed because of the existence of suitable corresponding shadow objects in
the regular heap?)

-- ramki

On Wed, Sep 26, 2012 at 11:55 PM, Srinivas Ramakrishna <ysr1729 at gmail.com>wrote:

> Also I am assuming stuff like heap histograms will (continue to) produce
> summary info on the metadata as well? Or perhaps not anymore?
>
> -- ramki
>
>
> On Wed, Sep 26, 2012 at 10:23 PM, Jon Masamitsu <jon.masamitsu at oracle.com>wrote:
>
>> Kirk,
>>
>> There is some information labeled with "Metaspace" in the GC output
>> that says how much memory is being used for class metadata.   It's
>> not really GC info but can be affected by GC (i.e., class unloading
>> during GC will reduce the used class metadata).  There are jstat
>> counters that currently carry the same name as the old perm
>> gen names.   Those names WILL change.  I'm checking on what
>> else there will be.
>>
>> Jon
>>
>>
>> On 9/26/2012 9:24 PM, Kirk Pepperdine wrote:
>>
>>> +1 on the summary comment.
>>>
>>> I've always wondered if the removal of perm gen was going to buy us
>>> (Java community) anything. Now I see with the move of meta-data to C heap
>>> that was it has bought us is the move of data from a space where we had
>>> tools to analyze problems that cropped up to a space where we don't. So, my
>>> question is; what facilities will be put into place that would allow us to
>>> view the class meta-data in a production VM?
>>>
>>> Regards,
>>> Kirk
>>>
>>> On 2012-09-27, at 5:06 AM, Srinivas Ramakrishna<ysr1729 at gmail.com>
>>>  wrote:
>>>
>>>  Nice summary, thanks!
>>>>
>>>> ysr1729
>>>>
>>>> On Sep 26, 2012, at 13:31, Jon Masamitsu<jon.masamitsu@**oracle.com<jon.masamitsu at oracle.com>>
>>>>  wrote:
>>>>
>>>>  We're expecting to promote hotspot with the perm gen elimination
>>>>> changes
>>>>> into JDK8 this week.  The last webrev for initial integration into
>>>>> hotspot
>>>>> is at
>>>>>
>>>>> http://cr.openjdk.java.net/~**coleenp/metadata8/<http://cr.openjdk.java.net/%7Ecoleenp/metadata8/>
>>>>>
>>>>> Basically this is the removal of the permanent generation and the use
>>>>> of native memory for hotspot's representation of class metadata.
>>>>>
>>>>> Generally speaking this change is invisible to the
>>>>> Java application.  However, depending on the allocation
>>>>> behavior, more Java heap may be used.  Also the
>>>>> amount of native memory used for the class metadata may be
>>>>> less than or more than the memory used previously by the
>>>>> permanent generation.  Basically the message is that
>>>>> you should not see any differences but then again you
>>>>> may.
>>>>>
>>>>> This change is in hsx 25 b2 and is expected to promote
>>>>> into jdk8 b58.
>>>>>
>>>>> These are some of the details.
>>>>>
>>>>>    - Most allocations for the class metadata previously
>>>>> done out of the permanent generation are now allocated
>>>>> out of native memory. Some miscellaneous  data has
>>>>> been moved to the Java heap.
>>>>>
>>>>>    - The permanent generation has been removed. The
>>>>> PermSize and  MaxPermSize are ignored and a warning is
>>>>> issued if they are present on the command line.
>>>>>
>>>>>    - The klasses that were used to described class
>>>>> metadata have been  removed (klassKlass and it's derivatives).
>>>>>
>>>>>    - By default class metadata allocation is only limited
>>>>> by the  amount of available native memory. Use the new flag
>>>>> MaxMetaspaceSize to limit the amount of  native memory used
>>>>> for class metadata. It is analogous to MaxPermSize.
>>>>>
>>>>>    - In 64bit VM when compressed oops are used a special
>>>>> fixed size  space is used for classes to set a compressed
>>>>> class pointer in object's header. The size  of that
>>>>> class's space is controlled by ClassMetaspaceSize flag
>>>>> with default value 2Mbytes.
>>>>>
>>>>>    - A garbage collection may be induced to collect dead
>>>>> classloaders  and classes. The first garbage collection
>>>>> will be induced when the class metadata  usage reaches
>>>>> MetaspaceSize (12Mbytes on the 32bit client VM and 16Mbytes
>>>>> on the 32bit  server VM with larger sizes on the 64bit VM's).
>>>>> Set MetaspaceSize to a higher value to delay the induced garbage
>>>>> collections. After an induced garbage collection the
>>>>> class metadata usage needed to induce the next garbage
>>>>> collection may be  increased.
>>>>>
>>>>>    - Whereas class metadata was previously garbage
>>>>> collected as part of the permanent generation, without
>>>>> the permanent generation the storage for class metadata
>>>>> is explicitly managed. C-heap allocation is not used.
>>>>>
>>>>>    - jstat counter names for metadata allocations
>>>>> have not been  updated. The old permanent generation names
>>>>> are still used but will be updated in the  near future.
>>>>>
>>>>
>