PING: RFR: JDK-8087291: InitialBootClassLoaderMetaspaceSize and CompressedClassSpaceSize should be checked consistent from MaxMetaspaceSize
Yasumasa Suenaga
yasuenag at gmail.com
Wed Oct 4 12:37:32 UTC 2017
PING:
Could you review and sponsor it?
> http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.04/
Thanks,
Yasumasa
On 2017/09/27 12:05, Yasumasa Suenaga wrote:
> Hi all,
>
> I added a testcase for this issue in new webrev:
>
> http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.04/
>
>
> Thanks,
>
> Yasumasa
>
>
>
> 2017-09-26 18:36 GMT+09:00 Yasumasa Suenaga <yasuenag at gmail.com>:
>> Hi all,
>>
>> I uploaded webrev for this issue against jdk10/hs.
>> Could you review it?
>>
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.03/
>>
>>
>> I cannot access JPRT. So I need a sponsor.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>>
>> 2017-09-21 3:11 GMT+09:00 Man Cao <manc at google.com>:
>>> Thank Yasumasa and Stefan for the responses.
>>>
>>> Good to know that the patch is not blocked due to breaking some internal
>>> invariants/assumptions, but just due to its P5 status.
>>> Is it possible to push it to P4?
>>>
>>> -Man
>>>
>>> On Wed, Sep 20, 2017 at 5:16 AM, Yasumasa Suenaga <yasuenag at gmail.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> (CC'ed hotspot-runtime-dev)
>>>>
>>>>> 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.
>>>>
>>>>
>>>> I will send review request against jdk10/master or jdk10/hs after repos
>>>> are opened.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>>
>>>> On 2017/09/20 20:53, Stefan Karlsson wrote:
>>>>>
>>>>> Hi Man,
>>>>>
>>>>> On 2017-09-13 20:55, Man Cao wrote:
>>>>>>
>>>>>> Hi Yasumasa, Stefan,
>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> StefanK
>>>>>
>>>>>>
>>>>>> -Man
>>>>>>
>>>>>> On Mon, Aug 21, 2017 at 3:46 PM, Man Cao <manc at google.com
>>>>>> <mailto:manc at google.com>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I wonder if there is any recent update on the patch for JDK-8087291.
>>>>>> Is it possible to push this patch into JDK9? Except for its low
>>>>>> priority (P5),
>>>>>> is there any complication that prevents this patch getting approved
>>>>>> (for example, some JVM logic requires CompressedClassSpaceSize to be
>>>>>> 1GB by default)?
>>>>>>
>>>>>> I work in the Java Platform Team at Google. We have encountered
>>>>>> annoying issues that the hsperfdata counter
>>>>>> "sun_gc_metaspace_maxCapacity" reporting
>>>>>> a too large value (about 1GB) even if user sets
>>>>>> -XX:MaxMetaspaceSize=100m, as well as GC log shows the confusing 1GB
>>>>>> memory reserved by metaspace,
>>>>>> regardless of MaxMetaspaceSize value. The root cause for these
>>>>>> issues is that CompressedClassSpaceSize is not automatically capped
>>>>>> by MaxMetaspaceSize
>>>>>> during VM initialization, and this patch seems fix the root cause.
>>>>>> (I'm aware that even after this patch, the reserved size could still
>>>>>> be up to 2*MaxMetaspaceSize,
>>>>>> but it is better than the current situation.)
>>>>>>
>>>>>> Thanks,
>>>>>> Man
>>>>>>
>>>>>> On 6/19/2015 00:34, Yasumasa Suenaga wrote:
>>>>>>
>>>>>> Thank you for your comment!
>>>>>> > Try running a debug JVM with your patch with this command
>>>>>> line.
>>>>>> >
>>>>>> > java -XX:MaxMetaspaceSize=4195328 -version
>>>>>> Sorry, I've fixed it and uploaded webrev:
>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.02/
>>>>>> <http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.02/>
>>>>>> It works on fastdebug VM.
>>>>>> Please review again.
>>>>>>
>>>>>> Thanks,
>>>>>> Yasumasa
>>>>>>
>>>>>> On 2015/06/18 10:45, Jon Masamitsu wrote:
>>>>>> > Yasumasa,
>>>>>> >
>>>>>> > Try running a debug JVM with your patch with this command
>>>>>> line.
>>>>>> >
>>>>>> > java -XX:MaxMetaspaceSize=4195328 -version
>>>>>> >
>>>>>> > On a linux system I get this when I build with your patch.
>>>>>> >
>>>>>> >> java -XX:MaxMetaspaceSize=4195328 -version
>>>>>> >> # To suppress the following error report, specify this
>>>>>> argument
>>>>>> >> # after -XX: or in .hotspotrc:
>>>>>> SuppressErrorAt=/metaspace.cpp:2324
>>>>>> >> #
>>>>>> >> # A fatal error has been detected by the Java Runtime
>>>>>> Environment:
>>>>>> >> #
>>>>>> >> # Internal Error
>>>>>> >>
>>>>>>
>>>>>> (/export/jmasa/java/jdk9-gc-code_review/src/share/vm/memory/metaspace.cpp:2324),
>>>>>> >> pid=19099, tid=0x00007ff4b9b92700
>>>>>> >> # assert(size > MediumChunk || size > ClassMediumChunk)
>>>>>> failed: Not a
>>>>>> >> humongous chunk
>>>>>> >> #
>>>>>> >
>>>>>> >
>>>>>> > Jon
>>>>>> >
>>>>>> >
>>>>>> > On 6/17/2015 7:54 AM, Yasumasa Suenaga wrote:
>>>>>> >> I want to continue to discuss about CompressedClassSpace and
>>>>>> MaxMetaspace in this (RFR) thread.
>>>>>> >>
>>>>>> >>
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013873.html
>>>>>>
>>>>>> <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013873.html>
>>>>>> >>>> Should I resize CompressedClassSpaceSize than to show
>>>>>> error message?
>>>>>> >>> If you add slightly better heuristics for the setup of the
>>>>>> CompressedClassSpaceSize flag, for example lowering the
>>>>>> CompressedClassSpaceSize when MaxMetaspaceSize is set, then it
>>>>>> might be less likely that you'll hit the OutOfMemoryError when
>>>>>> the system is set up with strict overcommit settings.
>>>>>> >>
>>>>>> >> I've uploaded new webrev:
>>>>>> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.01/
>>>>>> <http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.01/>
>>>>>> >>
>>>>>> >> This patch checkes MaxMetaspaceSize,
>>>>>> CompressedClassSpaceSize, and
>>>>>> >> InitialBootClassLoaderMetaspaceSize.
>>>>>> >>
>>>>>> >> I add to check CompressedClassSpaceSize in
>>>>>> Arguments::set_use_compressed_klass_ptrs().
>>>>>> >> If InitialBootClassLoaderMetaspaceSize is greater than
>>>>>> MaxMetaspaceSize,
>>>>>> >> VM will fail with error message.
>>>>>> >>
>>>>>> >> InitialBootClassLoaderMetaspaceSize will be set to
>>>>>> MaxMetaspaceSize
>>>>>> >> when UseCompressedClassPointers is not set in
>>>>>> Metaspace::ergo_initialize().
>>>>>> >>
>>>>>> >>
>>>>>> >> Thanks,
>>>>>> >>
>>>>>> >> Yasumasa
>>>>>> >>
>>>>>>
>>>>>>
>>>
More information about the hotspot-runtime-dev
mailing list