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.java.net/pipermail/hotspot-gc-dev/attachments/20170920/df26fb2d/attachment.htm>


More information about the hotspot-gc-dev mailing list