RFR: Parallel safepoint cleaning

[Roman Kennke]

Am 23.05.2017 um 19:49 schrieb Aleksey Shipilev:
> On 05/23/2017 07:28 PM, Roman Kennke wrote:
>> http://cr.openjdk.java.net/~rkennke/par-sp-cleaning/webrev.01/
> Cursory review:
>
> s/ShenandoahSPCleanup/ShenandoahMergeSafepointCleanup/g ?
> s/ParallelSPCleanup/ParallelSafepointCleanup/g ?
>
> vm_operations_shenandoah.hpp:
>  *) Methods can reside in VM_ShenandoahOperation super-class, no?
>
> synchronizer.cpp:
>  *) Better name: deflate_tl?
> 1689 void ObjectSynchronizer::deflate_idle_monitors(bool deflate_tl) {

I implemented all your suggested changes.

I also found the cause for the crash: we need to initialize nmethod
marking once, and not once-per-worker thread, otherwise we corrupt
internal structures.
I also found the cause for the massive slowdown when running
parallelized: we need to call needs_rehashing() on StringTable and
SymbolTable before rehashing, otherwise we'd be rehashing them all the
time. This takes ~10ms here and fully explains the slowdown. Note: if we
want to improve safepoint cleanup even more, we might want to look into
those two cleanup passes and see if we can fold them into GC processing too.

http://cr.openjdk.java.net/~rkennke/par-sp-cleaning/webrev.02/
<http://cr.openjdk.java.net/%7Erkennke/par-sp-cleaning/webrev.02/>

Performance doesn't suffer in my measurements with
+parallel_safepoint_cleanup and/or +shenandoah_safepoint_cleanup, I even
see a slight but consistent improvement (but then again, on my miniscule
workloads it doesn't weight much...)

ok now?