RFR: 8058963: CollectorPolicy::satisfy_failed_metadata_allocation can avoid some safepoints

Erik Helin erik.helin at oracle.com
Fri Sep 26 14:45:20 UTC 2014


Hi Bengt,

On 2014-09-26 12:49, Bengt Rutisson wrote:
>
> Hi Erik,
>
> The change looks good.

thanks!

On 2014-09-26 12:49, Bengt Rutisson wrote:
> One minor thing is that Metaspace::expand_and_allocate() and
> Metaspace::allocate() have different exposure even though they are both
> supposed to be internal to Metaspace. It would be nice to treat them the
> same way. Talked to Erik and we think that keeping the friend
> declaration of CollectorPolicy makes sense and in that case we can move
> expand_and_allocate() from being public to being private.

Good idea, I've uploaded new webrevs:
- full: http://cr.openjdk.java.net/~ehelin/8058963/webrev.01/
- inc: http://cr.openjdk.java.net/~ehelin/8058963/webrev.00-01/

Thanks,
Erik

> Thanks,
> Bengt
>
>
> On 2014-09-23 17:15, Erik Helin wrote:
>> Hi all,
>>
>> this small change enables us to skip two possible safepoints in
>> CollectorPolicy::satisfy_failed_metadata_allocation:
>>
>> 1. When a thread continues a loop after having been stalled due to a
>> GC_locker initiated Full GC.
>> 2. When the VM_CollectForMetadata VM operation's prologue fails
>> because a full GC has already been run just prior to the
>> CollectForMetadata VM operation.
>>
>> The way this is done is simply by trying to allocate at the start of
>> the loop. This way, whenever we loop around and a full GC has
>> happened, the allocation request might be satisfied and we can do an
>> early return.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ehelin/8058963/webrev.00/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8058963
>>
>> Testing:
>> - JPRT
>> - Aurora:
>>   - Kitchensink
>>   - Weblogic+Medrec
>>   - runThese
>>   - vm.quick, regression, gc, compiler, runtime, parallel class loading,
>>     metaspace, oom
>>   - JTReg tests
>>
>> Thanks,
>> Erik
>



More information about the hotspot-gc-dev mailing list