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

Stefan Karlsson stefan.karlsson at oracle.com
Wed Sep 20 11:53:55 UTC 2017


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