PermGen Elimination project is promoting

Jon Masamitsu jon.masamitsu at
Wed Sep 26 22:23:05 PDT 2012


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.


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>  wrote:
>> Nice summary, thanks!
>> ysr1729
>> On Sep 26, 2012, at 13:31, Jon Masamitsu<jon.masamitsu at>  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
>>> 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.

More information about the hotspot-dev mailing list