RFR: JDK-8087291: InitialBootClassLoaderMetaspaceSize and CompressedClassSpaceSize should be checked consistent from MaxMetaspaceSize
Man Cao
manc at google.com
Wed Sep 13 18:55:50 UTC 2017
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.
-Man
On Mon, Aug 21, 2017 at 3:46 PM, Man Cao <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/
>> 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/20170913/2d20ef9c/attachment.htm>
More information about the hotspot-gc-dev
mailing list