PermGen Elimination project is promoting

[Srinivas Ramakrishna]

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.