RFR: Parallel safepoint cleaning

Roman Kennke rkennke at redhat.com
Tue May 23 17:52:44 UTC 2017


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 ?

Ok, those are better names ;-)
> vm_operations_shenandoah.hpp:
>  *) Methods can reside in VM_ShenandoahOperation super-class, no?
Not really. Some VM_Ops (e.g. init-ur) cannot take over sp cleanup. I
could do it in superclass, and only override those who cannot to return
false though.

> synchronizer.cpp:
>  *) Better name: deflate_tl?
> 1689 void ObjectSynchronizer::deflate_idle_monitors(bool deflate_tl) {

deflate_thread_local_monitors ?

I also found a bug:
 #  guarantee(result == NULL || !result->is_zombie() ||
result->is_locked_by_vm() || is_error_reported()) failed: unsafe access
to zombie method

This seems to happen only with -XX:+ParallelSPCleanup
-XX:-ShenandoahSPCleanup (i.e. parallel processing enabled, but
shenandoah takeover disabled). Curious. Will debug this and send another
webrev when done.

Roman


More information about the shenandoah-dev mailing list