Request for review - 7197557

[Vitaly Davidovich]

Hi Jon,

Do the Metaspace size args allow use of size specifiers (e.g. "g", "m",
etc) like Xmx/Xms? I don't have code in front of me but it's a bit unclear
from the option descriptions since they mention that the value is in bytes.

Thanks

Sent from my phone
On Sep 19, 2012 6:31 PM, "Jon Masamitsu" <jon.masamitsu at oracle.com> wrote:

>
>
> 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
>>
>   product_pd(uintx, 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.
>
> Jon
>
>> thanks a lot again! And sorry for hijacking the review thread for this
>> side-conversation.
>> -- ramki
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120919/f0932988/attachment.htm>