RFR: JDK-8087291: InitialBootClassLoaderMetaspaceSize and CompressedClassSpaceSize should be checked consistent from MaxMetaspaceSize
Man Cao
manc at google.com
Wed Sep 20 18:11:17 UTC 2017
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/~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
>>> >>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170920/df26fb2d/attachment.htm>
More information about the hotspot-gc-dev
mailing list