RFR: 8267653: Remove Mutex::_safepoint_check_sometimes

David Holmes dholmes at openjdk.java.net
Wed May 26 00:52:13 UTC 2021


On Tue, 25 May 2021 13:20:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Since SR_lock is removed, this state of declaring locks as sometimes safepoint checking and not is no longer used.  JavaThreads either always or never check for safepoint, depending on the lock.  The Heap_lock was always a bit special because it's taken by a JavaThread after it exits, but the code in mutex::lock_contended already deals with this (ie doesn't safepoint check while exiting).
> Tested with tier 2-3 and tier1 in progress.
> Thanks to Zhengu for testing and confirming shenandoah (I built and ran shenandoah tests too).

Hi Coleen,

This seems fine. Working through the thread and VM termination logic is always tricky. Just to be clear the condition for the mutex not checking safepoints is that the thread has terminated, not just that it is exiting, so I've suggested an additional assert before taking the Heap-lock.

Thanks,
David

src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 543:

> 541:   } else {
> 542:     // Heap_lock protects external pending list
> 543:     MonitorLocker ml(Heap_lock);

For performance you could leave the _no_safepoint_check flag.

src/hotspot/share/runtime/thread.cpp line 3420:

> 3418:     // we'll never emerge out of the safepoint before the VM exits.
> 3419: 
> 3420:     MutexLocker ml(Heap_lock);

Can you add an assert before this that the thread is_terminated() as that is the key to the mutex acquisition not doing a safepoint check.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4184


More information about the shenandoah-dev mailing list