RFR: 8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize

Aleksey Shipilev shade at redhat.com
Mon Jan 21 09:54:58 UTC 2019

On 1/21/19 9:52 AM, Yasumasa Suenaga wrote:
> I filed this issue to JBS:
>   https://bugs.openjdk.java.net/browse/JDK-8217432
> I investigated it, and I found that `minimum_desired_capacity` and
> `maximum_desired_capacity` in `MetaspaceGC::compute_new_size()`
> might exceed MaxMetaspaceSize. They shouldn't exceed MaxMetaspaceSize.

Yes, looks like it. I was wondering in my recent Epsilon tests why setting very low MaxMetaspaceSize
did not OOM. With your patch, it OOMs on low MMS, as expected.

I think you can construct the non-GC-specific regression test. Take the sample class generator from
here: http://hg.openjdk.java.net/jdk/jdk/file/tip/test/hotspot/jtreg/gc/epsilon/TestClasses.java and
feed different MaxMetaspaceSize settings via ProcessTools, like here:

> I uploaded webrev for this bug. Could you review it?
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8217432/webrev.00/

It is weird to see this block in expand_and_allocate:

1498     if (!incremented && SafepointSynchronize::is_at_safepoint()) {
1499       // Cannot expand metaspace more.
1500       return NULL;
1501     }

Maybe we should instead fall-through in inc_capacity_until_GC?

 141   if (new_value < old_capacity_until_GC) {
 142     // The addition wrapped around, set new_value to aligned max value.
 143     new_value = align_down(max_uintx, Metaspace::commit_alignment());
 144   }
 146   if (new_value > MaxMetaspaceSize) {
 147     return false; // instead, new_value = MIN2(new_value, MaxMetaspaceSize);
 148   }

...that would naturally exit the loop, AFAIU.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20190121/c09f5153/signature.asc>

More information about the hotspot-gc-dev mailing list