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

[Man Cao]

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/
> 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
> >>>> 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/
> >>
> >> 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/20170821/99bf5e35/attachment.htm>