<div dir="ltr">Thank <span style="font-size:12.8px">Yasumasa and </span>Stefan<span style="font-size:12.8px"> for the responses.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Good to know that the patch is not blocked due to breaking some internal invariants/assumptions, but just due to its P5 status.</span></div><div><span style="font-size:12.8px">Is it possible to push it to P4?</span><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-Man</div></div></div>
<br><div class="gmail_quote">On Wed, Sep 20, 2017 at 5:16 AM, Yasumasa Suenaga <span dir="ltr"><<a href="mailto:yasuenag@gmail.com" target="_blank">yasuenag@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
(CC'ed hotspot-runtime-dev)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the reason is that this bug is a P5. The compressed class space belongs to the runtime code, so you might get more traction for this on the hotspot-runtime-dev list.<br>
</blockquote>
<br></span>
I will send review request against jdk10/master or jdk10/hs after repos are opened.<br>
<br>
<br>
Thanks,<br>
<br>
Yasumasa<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 2017/09/20 20:53, Stefan Karlsson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Man,<br>
<br>
On 2017-09-13 20:55, Man Cao wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Yasumasa, Stefan,<br>
<br>
Do you have any thoughts on why this patch has been pending for 2+ years? This patch could really save us from some annoying issues since we are automatically monitoring hsperfdata counters.<br>
</blockquote>
<br>
I think the reason is that this bug is a P5. The compressed class space belongs to the runtime code, so you might get more traction for this on the hotspot-runtime-dev list.<br>
<br>
StefanK<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Man<br>
<br>
On Mon, Aug 21, 2017 at 3:46 PM, Man Cao <<a href="mailto:manc@google.com" target="_blank">manc@google.com</a> <mailto:<a href="mailto:manc@google.com" target="_blank">manc@google.com</a>>> wrote:<br>
<br>
Hi all,<br>
<br>
I wonder if there is any recent update on the patch for JDK-8087291.<br>
Is it possible to push this patch into JDK9? Except for its low<br>
priority (P5),<br>
is there any complication that prevents this patch getting approved<br>
(for example, some JVM logic requires CompressedClassSpaceSize to be<br>
1GB by default)?<br>
<br>
I work in the Java Platform Team at Google. We have encountered<br>
annoying issues that the hsperfdata counter<br>
"sun_gc_metaspace_maxCapacity" reporting<br>
a too large value (about 1GB) even if user sets<br>
-XX:MaxMetaspaceSize=100m, as well as GC log shows the confusing 1GB<br>
memory reserved by metaspace,<br>
regardless of MaxMetaspaceSize value. The root cause for these<br>
issues is that CompressedClassSpaceSize is not automatically capped<br>
by MaxMetaspaceSize<br>
during VM initialization, and this patch seems fix the root cause.<br>
(I'm aware that even after this patch, the reserved size could still<br>
be up to 2*MaxMetaspaceSize,<br>
but it is better than the current situation.)<br>
<br>
Thanks,<br>
Man<br>
<br>
On 6/19/2015 00:34, Yasumasa Suenaga wrote:<br>
<br>
Thank you for your comment!<br>
> Try running a debug JVM with your patch with this command line.<br>
><br>
> java -XX:MaxMetaspaceSize=4195328 -version<br>
Sorry, I've fixed it and uploaded webrev:<br>
<a href="http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.02/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~ys<wbr>uenaga/JDK-8087291/webrev.02/</a><br>
<<a href="http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.02/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~y<wbr>suenaga/JDK-8087291/webrev.02/</a><wbr>><br>
It works on fastdebug VM.<br>
Please review again.<br>
<br>
Thanks,<br>
Yasumasa<br>
<br>
On 2015/06/18 10:45, Jon Masamitsu wrote:<br>
> Yasumasa,<br>
><br>
> Try running a debug JVM with your patch with this command line.<br>
><br>
> java -XX:MaxMetaspaceSize=4195328 -version<br>
><br>
> On a linux system I get this when I build with your patch.<br>
><br>
>> java -XX:MaxMetaspaceSize=4195328 -version<br>
>> # To suppress the following error report, specify this argument<br>
>> # after -XX: or in .hotspotrc:<br>
SuppressErrorAt=/metaspace.cpp<wbr>:2324<br>
>> #<br>
>> # A fatal error has been detected by the Java Runtime<br>
Environment:<br>
>> #<br>
>> # Internal Error<br>
>><br>
(/export/jmasa/java/jdk9-gc-co<wbr>de_review/src/share/vm/memory/<wbr>metaspace.cpp:2324),<br>
>> pid=19099, tid=0x00007ff4b9b92700<br>
>> # assert(size > MediumChunk || size > ClassMediumChunk)<br>
failed: Not a<br>
>> humongous chunk<br>
>> #<br>
><br>
><br>
> Jon<br>
><br>
><br>
> On 6/17/2015 7:54 AM, Yasumasa Suenaga wrote:<br>
>> I want to continue to discuss about CompressedClassSpace and<br>
MaxMetaspace in this (RFR) thread.<br>
>><br>
>><br>
<a href="http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013873.html" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/p<wbr>ipermail/hotspot-gc-dev/2015-J<wbr>une/013873.html</a><br>
<<a href="http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013873.html" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/<wbr>pipermail/hotspot-gc-dev/2015-<wbr>June/013873.html</a>><br>
>>>> Should I resize CompressedClassSpaceSize than to show<br>
error message?<br>
>>> If you add slightly better heuristics for the setup of the<br>
CompressedClassSpaceSize flag, for example lowering the<br>
CompressedClassSpaceSize when MaxMetaspaceSize is set, then it<br>
might be less likely that you'll hit the OutOfMemoryError when<br>
the system is set up with strict overcommit settings.<br>
>><br>
>> I've uploaded new webrev:<br>
>> <a href="http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.01/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~ys<wbr>uenaga/JDK-8087291/webrev.01/</a><br>
<<a href="http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.01/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~y<wbr>suenaga/JDK-8087291/webrev.01/</a><wbr>><br>
>><br>
>> This patch checkes MaxMetaspaceSize,<br>
CompressedClassSpaceSize, and<br>
>> InitialBootClassLoaderMetaspac<wbr>eSize.<br>
>><br>
>> I add to check CompressedClassSpaceSize in<br>
Arguments::set_use_compressed_<wbr>klass_ptrs().<br>
>> If InitialBootClassLoaderMetaspac<wbr>eSize is greater than<br>
MaxMetaspaceSize,<br>
>> VM will fail with error message.<br>
>><br>
>> InitialBootClassLoaderMetaspac<wbr>eSize will be set to<br>
MaxMetaspaceSize<br>
>> when UseCompressedClassPointers is not set in<br>
Metaspace::ergo_initialize().<br>
>><br>
>><br>
>> Thanks,<br>
>><br>
>> Yasumasa<br>
>><br>
<br>
<br>
</blockquote></blockquote>
</div></div></blockquote></div><br></div></div>