PermGen Elimination project is promoting
staffan.larsen at oracle.com
Thu Sep 27 01:36:40 PDT 2012
Is some of this need covered by the native memory tracking feature? Other parts could be added as Diagnostic Commands in the JVM, runnable by jcmd.
On 27 sep 2012, at 10:15, Kirk Pepperdine <kirk at kodewerk.com> wrote:
> 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