RFR: JDK-8087291: InitialBootClassLoaderMetaspaceSize and CompressedClassSpaceSize should be checked consistent from MaxMetaspaceSize

Man Cao manc at google.com
Mon Oct 9 21:07:52 UTC 2017


Thanks for you both updating and sponsoring the webrev!
We plan to back-port it to our JDK9 once it is submitted.

-Man

On Mon, Oct 9, 2017 at 6:15 AM, <coleen.phillimore at oracle.com> wrote:

> Hi, this looks reasonable but I would prefer that the code in
> arguments.cpp call something in metaspace.cpp, like check_metaspace_sizes()
> so that you don't have to tell arguments what the MediumChunk size is.
>
> I will sponsor this for you.
>
> thanks,
> Coleen
>
>
> On 9/26/17 11:05 PM, 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-J
>>>>>>> une/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/~ys
>>>>>>> uenaga/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