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

[Bengt Rutisson]

Hi Erik,

The change looks good.

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.

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