8042933: assert(capacity_until_gc >= committed_bytes) failed

[Jon Masamitsu]

Erik,

I think the answer to my question  is no.

Change  looks good.  Reviewed.

Jon

On 5/29/2014 2:51 PM, Jon Masamitsu wrote:
> Erik,
>
> Is it correct that this fix allows us to allocate more space
> than MaxMetaspaceSize for metadata?  And if, yes, why
> do that instead of fail initialization?  I can see that it might
> be a mess to actually fail during start up but maybe fail
> in the post_initialize().
>
> Jon
>
> On 5/28/14 4:10 AM, Erik Helin wrote:
>> Hi all,
>>
>> this is the second attemp to fix JDK-8034852 [0], but since I backed
>> out the previous attempt, I have to use a new bug [1] (you can't use
>> the same bug-id for two different committs).
>>
>> For a background to the original problem, please see the old email
>> thread [2]. This patch is just and updated version of the original
>> patch [3]. The issue with the original path is that
>> MetaspaceGC::allowed_expansion can, during special circumstances,
>> allow the Metaspace high-water mark (HWM aka
>> MetaspaceGC::_capacity_until_GC) to become larger than the amount of
>> committed memory. Keeping the HWM less than or equal to how much we
>> have committed is an invariant we would like to be true in Metaspace
>> at all times to make it easier to reason about the sizing heuristics.
>>
>> This patch changes MetaspaceGC::allowed_expansion to always enforce
>> the invariant that HWM <= committed_bytes. However, we still want to
>> allow the VM to allocate as much metadata it wants during
>> initialization. To achieve this, we set the HWM to MaxMetaspaceSize
>> when initializing Metaspace and then reset the HWM to
>> max(MetaspaceSize, HWM) once the initialization is done. Thanks
>> StefanK for coming up with this approach!
>>
>> MetaspaceGC::allowed_expansion previously also allowed the VM to
>> allocate as much metadata it wants when the GC lock is active and we
>> are awaiting a GC. The new behaviour will be to try to expand the HWM
>> and then allocate (the expand_and_allocate call in
>> CollectorPolicy::satisfy_failed_metadata_allocation). Under very
>> special circumstances this might cause a thread to now await the GC in
>> GC_locker::stall_until_clear instead of getting its metadata and
>> continue executing.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ehelin/8042933/webrev.00/
>>
>> Testing:
>> - JPRT
>> - Ad-hoc testing (on all platforms):
>>    - Kitchensink
>>    - runThese
>>    - Parallel Class Loading testlist
>>    - Metaspace testlist
>>    - GC nightly testlist
>>    - OOM testlist
>>    - Quick testlist
>>    - JTREG tests in both VM and JDK
>>
>> Thanks,
>> Erik
>>
>> [0]: https://bugs.openjdk.java.net/browse/JDK-8034852
>> [1]: https://bugs.openjdk.java.net/browse/JDK-8042933
>> [2]: 
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013716.html
>> [3]: http://cr.openjdk.java.net/~ehelin/8034852/webrev.00/
>>
>