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

[Yasumasa Suenaga]

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
>>          >>
>>
>>