Request for review - 7197557

Jon Masamitsu jon.masamitsu at
Wed Sep 19 22:30:03 UTC 2012

On 9/18/2012 12:04 PM, Srinivas Ramakrishna wrote:
> ....
> Great; thanks a lot for that information. I am assuming that in general
> full gc's as a result of the Java heap
> filling up will, in most cases, take care of reclaiming enough space in the
> metadata spaces, so that no explicit
> collection is needed for the total size of the metadata spaces to stay
> within the HWM computed. By the way, I assume that

That's my experience.    GC's happen much more often because the heap 
gets  full
and the GC's (full) unload classes.

> there is some way that we can set the starting and maximum metaspace size
> to the same value, analogous
> to setting PermSize to MaxPermSize? (Essentially saying that the initial
MetaspaceSize,                                          \
           "Initial size of Metaspaces (in 
bytes)")                          \
   product(uintx, MaxMetaspaceSize, 
max_uintx,                               \
           "Maximum size of Metaspaces (in 
bytes)")                          \

Those might even be at the same lines as PermSize and MaxPermSize used 
to be  :-)

> size of the meta space is its maximum size
> and that Max/Min free ratio must be ignored.) Anyway, I'll look at the code
> and play with the JVM to learn more, but it would be
> great if you folks could also put out a brief whitepaper giving an overview
> of the implementation and
Sounds like you've blocked out of your memory what life is like here.  
:-)  Whitepaper?  More likely
sparse release notes.

> describing the transition to the new perm gen world and how one might size
> these thresholds so as to empirically
> "right-size" the heap based on the GC log data etc.

That's actually something we don't know yet.  Performance seems to be 
neutral and I'll take that
given the number of lines we've touched.  And we do have more 
performance measurements
to do.

> thanks a lot again! And sorry for hijacking the review thread for this
> side-conversation.
> -- ramki

More information about the hotspot-gc-dev mailing list