RFR: Refactor ShenandoahHeapLock

[Roman Kennke]

Am 25.08.2017 um 12:31 schrieb Aleksey Shipilev:
> Three improvements:
>  a) Move ShenandoahHeapLock to a separate file, split lock and locker;
>  b) Pad the lock state to avoid false sharing against other fields;
>  c) Reuse the spin-lock mechanism from Thread (probably written by Dave Dice);
>
> Webrev:
>  http://cr.openjdk.java.net/~shade/shenandoah/heaplock-refactor/webrev.01/
>
> Improves -UseTLAB scores ~25% under heavy allocation, and also levels out some allocation outliers,
> see e.g:
>  http://cr.openjdk.java.net/~shade/shenandoah/heaplock-refactor/stalls-before.txt
>  http://cr.openjdk.java.net/~shade/shenandoah/heaplock-refactor/stalls-after.txt
>
> Testing: hotspot_gc_shenandoah, some benchmarks
>
> Thanks,
> -Aleksey
>
This looks a bit odd:

- ShenandoahHeapLock lock(this);
+ ShenandoahHeapLocker lock(locker());

You ask for a ShenandoahHeapLocker() via locker(). This creates on-stack
a SHL using the _lock. Then this is copied (or optimized away) into
another SHL on-stack, via (implicit) copy-constructor. This works, but
it would look less confusing to just write:

ShenandoahHeapLocker locker(lock());

or even

ShenandoahHeapLocker locker;

(and let the SHL constructor ask for  the SH::_lock ... because it
should always just use this one lock I think).

In some places you actually do that:

     // Rebuild the free set
- ShenandoahHeapLock hl(this);
+ ShenandoahHeapLocker lock(&_lock); Other than that, looks good! Roman