<br><br><div class="gmail_quote">On Mon, Sep 17, 2012 at 10:06 PM, Jon Masamitsu <span dir="ltr"><<a href="mailto:jon.masamitsu@oracle.com" target="_blank">jon.masamitsu@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
... This is the top of the stack trace of the thread doing the GC.  It is actually a live lock where<br>
the GC has already entered the infinite loop that keeps trying to do a GC (checks the<br>
results of the gc_prologue) until the GC succeeds.  We needed to check for an active<br>
GC_locker.  A thread trying to release a JNI critical section was blocking on a<br>
safepoint.<br>
<br>
=>[1] GC_locker::is_active_internal(<u></u>), line 88 in "gcLocker.hpp"<br>
  [2] GC_locker::is_active_and_<u></u>needs_gc(), line 104 in "gcLocker.hpp"<br>
  [3] VM_GC_Operation::skip_<u></u>operation(this = 0xfffffd7fec9d5358), line 92 in "vm<br>
GCOperations.cpp"<br>
  [4] VM_GC_Operation::doit_<u></u>prologue(this = 0xfffffd7fec9d5358), line 111 in "vm<br>
GCOperations.cpp"<br>
  [5] VMThread::execute(op = 0xfffffd7fec9d5358), line 587 in "vmThread.cpp"<br>
  [6] CollectorPolicy::satisfy_<u></u>failed_metadata_allocation(<u></u>this = 0x432558, loade<br>
r_data = 0x52a62f8, word_size = 0x3a99U, mdtype = NonClassType), line 765 in "co<br>
llectorPolicy.cpp"<br>
  [7] Metaspace::allocate(loader_<u></u>data = 0x52a62f8, word_size = 0x3a99U, read_onl<br>
y = true, mdtype = NonClassType, __the_thread__ = 0x348d800), line 2953 in "meta<br>
space.cpp"<br>
  [8] Array<unsigned short>::operator new(size = 0x8U, loader_data = 0x52a62f8,<br>
length = 0xea60, read_only = true, __the_thread__ = 0x348d800), line 322 in "arr<br>
ay.hpp"<br>
  [9] MetadataFactory::new_array<<u></u>unsigned short>(loader_data = 0x52a62f8, length<br>
 = 0xea60, __the_thread__ = 0x348d800), line 38 in "metadataFactory.hpp"</blockquote><div class="im"><br>Makes sense; thanks!<br> <br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A somewhat orthogonal question:<br>
Could you tell me if there is any a-priori limit that the JVM sets on the<br>
c-heap space used for the metadata?<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
No limit.  The space is actually not C-heap space.  It is allocated using Virtualspaces which<br>
means mmap'ed space on unix systems.  You can set a limit on the command line with<br>
MaxMetaspaceSize which is analogous to MaxPermSize.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If yes, can that limit be changed from the command-line? If there is no<br>
such a-priori limit, could you shed any light<br>
on a comparison of the memory footprint between the pre-NPG world and the<br>
new post-NPG world for<br>
some benchmarks that exercise class load/unload etc.?<br>
</blockquote>
<br></div>
We do induce GC to do class unloading.  We have a high water mark (HWM) for class metadata<br>
used.  When the used class metadata hits the HWM, we induce a GC.  The initial value of the<br>
HWM is 12Mbytes to 16Mbytes depending on the platform  The HWM may be increased after the<br>
GC depending on how much free metadata space there is.  Think MinFreeRation / MaxFreeRatio<br>
kind of policy.<br>
<br>
For small benchmarks that don't do extensive class loading, the footprint may look<br>
less because we don't reserve the space for the perm gen.  In general it is comparable.<br>
We do loose some space to fragmentation and need to do more tuning in that<br>
area.<br></blockquote><div><br>Great; thanks a lot for that information. I am assuming that in general full gc's as a result of the Java heap<br>filling up will, in most cases, take care of reclaiming enough space in the metadata spaces, so that no explicit<br>
collection is needed for the total size of the metadata spaces to stay within the HWM computed. By the way, I assume that<br>there is some way that we can set the starting and maximum metaspace size to the same value, analogous<br>
to setting PermSize to MaxPermSize? (Essentially saying that the initial size of the meta space is its maximum size<br>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<br>
great if you folks could also put out a brief whitepaper giving an overview of the implementation and<br>describing the transition to the new perm gen world and how one might size these thresholds so as to empirically<br>
"right-size" the heap based on the GC log data etc.<br><br>thanks a lot again! And sorry for hijacking the review thread for this side-conversation.<br>-- ramki<br></div></div><br>