PermGen Elimination project is promoting

[Kirk Pepperdine]

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