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

Man Cao manc at google.com
Fri Nov 10 23:11:41 UTC 2017


Hi Yasumasa,

Yes, that sounds good. I haven't submitted any code to OpenJDK yet. This is
a good starter patch to get me familiar with the process.

-Man

On Fri, Nov 10, 2017 at 12:15 AM, Yasumasa Suenaga <yasuenag at gmail.com>
wrote:

> Hi Man,
>
> 2017-11-10 11:31 GMT+09:00 Man Cao <manc at google.com>:
> > Hi Yasumasa,
> >
> > I'm looking at if this patch can fix the original issue with hsperfdata
> > counters sun_gc_metaspace_maxCapacity and
> > sun_gc_compressedclassspace_maxCapacity being too large when user has
> set
> > -XX:MaxMetaspaceSize=100m or some value less than 1GB. However, it does
> not,
> > these counters still reports around 1GB if MaxMetaspaceSize is less than
> > 1GB.
> >
> > The reason is that the code added in this patch to
> > Metaspace::ergo_initialize()  is AFTER the two lines:
> >
> >  CompressedClassSpaceSize =
> > align_size_down_bounded(CompressedClassSpaceSize, _reserve_alignment);
> >  set_compressed_class_space_size(CompressedClassSpaceSize);
> >
> > So set_compressed_class_space_size() still gets the old value of
> > CompressedClassSpaceSize that is too large, making the reserved size of
> > metaspace too large.
> >
> > Should these two lines be moved after the code added in this patch?
>
> I agree with you.
> Can you send review request for it? According to OCA signatories [1],
> Google signs OCA, so I think you can contribute it to OpenJDK.
>
> I can file this to JBS, and create webrev and changest. But I cannot
> push it to jdk/hs repo. So you need to find a sponsor.
> I'm a reviewer of OpenJDK. So I can +1 to your change when you send
> review request.
>
>
> Thanks,
>
> Yasumasa
>
>
> [1] http://www.oracle.com/technetwork/community/oca-486395.html
>
>
> > Thanks,
> > -Man
> >
> > On Tue, Oct 17, 2017 at 12:46 PM, <coleen.phillimore at oracle.com> wrote:
> >>
> >>
> >> Hi Yasumasa,
> >> This looks good.  I can sponsor this for you.
> >> thanks,
> >> Coleen
> >>
> >>
> >> On 10/12/17 1:16 AM, Yasumasa Suenaga wrote:
> >>>
> >>> Thanks David!
> >>>
> >>> I've fixed:
> >>>
> >>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.08/
> >>>
> >>>
> >>> Yasumasa
> >>>
> >>>
> >>> 2017-10-12 13:55 GMT+09:00 David Holmes <david.holmes at oracle.com>:
> >>>>
> >>>> On 12/10/2017 2:47 PM, Yasumasa Suenaga wrote:
> >>>>>
> >>>>> Hi David,
> >>>>>
> >>>>>> You may have time to fix these in place before anyone else sees the
> >>>>>> webrev
> >>>>>
> >>>>>
> >>>>> I've fixed that:
> >>>>>
> >>>>>     http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.07/
> >>>>>
> >>>>>
> >>>>> I checked raw text of your email, so I believe the indent is correct.
> >>>>> If I have mistake(s), please tell me.
> >>>>
> >>>>
> >>>> Sorry they are off. Basic rules:
> >>>>
> >>>> var =
> >>>>      some long value;
> >>>>
> >>>> indent by 4.
> >>>>
> >>>> foo(arg1, arg2,
> >>>>      arg3, arg4);
> >>>>
> >>>> align the args on the two lines as shown.
> >>>>
> >>>> Hope that is clearer.
> >>>>
> >>>> Thanks,
> >>>> David
> >>>>
> >>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Yasumasa
> >>>>>
> >>>>>
> >>>>> 2017-10-12 13:22 GMT+09:00 David Holmes <david.holmes at oracle.com>:
> >>>>>>
> >>>>>> Hi Yasumasa,
> >>>>>>
> >>>>>> On 12/10/2017 2:10 PM, Yasumasa Suenaga wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> This change was tried to push via JPRT, but it failed because
> >>>>>>>
> >>>>>>> test/hotspot/jtreg/runtime/SharedArchiveFile/
> MaxMetaspaceSizeTest.java
> >>>>>>> was failed.
> >>>>>>> Also I heard the comment that the changes in arguments.cpp which
> set
> >>>>>>> ergonomic value to CompressedClassSpaceSize should be moved to
> >>>>>>> Metaspace::ergo_initialize().
> >>>>>>>
> >>>>>>> I uploaded new webrev. Could you review again?
> >>>>>>> This webrev works fine on test/hotspot/jtreg/runtime/Metaspace and
> >>>>>>> test/hotspot/jtreg/runtime/SharedArchiveFile.
> >>>>>>>
> >>>>>>>      http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.06/
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I'll let Coleen cover the technical details, I'll just pick up a few
> >>>>>> style
> >>>>>> nits:
> >>>>>>
> >>>>>> 3328   /* Initial virtual space size will be calculated at
> >>>>>> global_initialize() */
> >>>>>>
> >>>>>> Use // comment
> >>>>>>
> >>>>>> 3329   size_t min_metaspace_sz =
> >>>>>> 3330                    VIRTUALSPACEMULTIPLIER *
> >>>>>> InitialBootClassLoaderMetaspaceSize;
> >>>>>>
> >>>>>>              ^ should indent only to here
> >>>>>>
> >>>>>> 3336         FLAG_SET_ERGO(size_t, CompressedClassSpaceSize,
> >>>>>> 3337                                       MaxMetaspaceSize -
> >>>>>> min_metaspace_sz);
> >>>>>>                              ^ should indent only to here
> >>>>>>
> >>>>>> 3341     FLAG_SET_ERGO(size_t, InitialBootClassLoaderMetaspaceSize,
> >>>>>> 3342 min_metaspace_sz);
> >>>>>>
> >>>>>>                           ^ should indent only to here
> >>>>>>
> >>>>>> You may have time to fix these in place before anyone else sees the
> >>>>>> webrev
> >>>>>> :)
> >>>>>>
> >>>>>> Thanks,
> >>>>>> David
> >>>>>> -----
> >>>>>>
> >>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Yasumasa
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2017-10-10 21:02 GMT+09:00  <coleen.phillimore at oracle.com>:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Hi Yasumasa,  I like this better.  I will sponsor it.  I think it
> >>>>>>>> only
> >>>>>>>> needs
> >>>>>>>> one reviewer, unless there were more?  Please send me the result
> of
> >>>>>>>> hg
> >>>>>>>> export.
> >>>>>>>> thanks,
> >>>>>>>> Coleen
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 10/9/17 11:09 PM, Yasumasa Suenaga wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Hi Coleen,
> >>>>>>>>>
> >>>>>>>>>>> I will sponsor this for you.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>> Hi, this looks reasonable but I would prefer that the code in
> >>>>>>>>>>> arguments.cpp call something in metaspace.cpp, like
> >>>>>>>>>>> check_metaspace_sizes()
> >>>>>>>>>>> so that you don't have to tell arguments what the MediumChunk
> >>>>>>>>>>> size
> >>>>>>>>>>> is.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I added new function calculate_min_metaspace_size() in
> >>>>>>>>> metaspace.cpp
> >>>>>>>>> to get minimum metaspace size, and uses return value from this
> >>>>>>>>> function in metaspace initialization and metaspace size check.
> >>>>>>>>>
> >>>>>>>>>       http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.
> 05/
> >>>>>>>>>
> >>>>>>>>> Could you review again?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Yasumasa
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2017-10-10 6:07 GMT+09:00 Man Cao <manc at google.com>:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks for you both updating and sponsoring the webrev!
> >>>>>>>>>> We plan to back-port it to our JDK9 once it is submitted.
> >>>>>>>>>>
> >>>>>>>>>> -Man
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Oct 9, 2017 at 6:15 AM, <coleen.phillimore at oracle.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Hi, this looks reasonable but I would prefer that the code in
> >>>>>>>>>>> arguments.cpp call something in metaspace.cpp, like
> >>>>>>>>>>> check_metaspace_sizes()
> >>>>>>>>>>> so that you don't have to tell arguments what the MediumChunk
> >>>>>>>>>>> size
> >>>>>>>>>>> is.
> >>>>>>>>>>>
> >>>>>>>>>>> I will sponsor this for you.
> >>>>>>>>>>>
> >>>>>>>>>>> thanks,
> >>>>>>>>>>> Coleen
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 9/26/17 11:05 PM, Yasumasa Suenaga wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I added a testcase for this issue in new webrev:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.04/
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yasumasa
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2017-09-26 18:36 GMT+09:00 Yasumasa Suenaga
> >>>>>>>>>>>> <yasuenag at gmail.com>:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I uploaded webrev for this issue against jdk10/hs.
> >>>>>>>>>>>>> Could you review it?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8087291/webrev.03/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Yasumasa
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2017-09-21 3:11 GMT+09:00 Man Cao <manc at google.com>:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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-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-runtime-dev mailing list