RFR: JDK-8087291: InitialBootClassLoaderMetaspaceSize and CompressedClassSpaceSize should be checked consistent from MaxMetaspaceSize
Yasumasa Suenaga
yasuenag at gmail.com
Tue Sep 26 09:36:27 UTC 2017
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-gc-dev
mailing list