PermGen Elimination project is promoting
kirk at kodewerk.com
Thu Sep 27 01:15:26 PDT 2012
You only need to keep a handle on the data structure referring to them and then scavenge... I just don't see this being a Java based tool unless Unsafe is involved.
On 2012-09-27, at 9:58 AM, Srinivas Ramakrishna <ysr1729 at gmail.com> wrote:
> 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:
> 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?
> On 2012-09-27, at 5:06 AM, Srinivas Ramakrishna<ysr1729 at gmail.com> wrote:
> Nice summary, thanks!
> 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
> 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
> 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