RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads
Per Liden
per.liden at oracle.com
Sat Apr 27 20:49:29 UTC 2019
Hi Coleen,
Not a review, just a comment on your comment:
+ // There are a couple of existing locks that will sometimes have a
safepoint check and
+ // sometimes not when acquired by a JavaThread, but these locks are
set up carefully
+ // to avoid deadlocks. TODO: Fix these locks and remove
_safepoint_check_sometimes.
Once _safepoint_check_sometimes is gone, we can simplify things even
further and remove the {lock,wait}_without_safepoint_check() functions,
and ditch the Mutex::SafepointCheckFlag argument in the constructors for
MutexLocker and MonitorLocker. Everyone can just call lock()/wait(), and
the lock itself knows what to do. That would be great!
cheers,
Per
On 04/26/2019 06:10 PM, coleen.phillimore at oracle.com wrote:
> Summary: Use safepoint_check_always/safepoint_check_never instead of
> safepoint_check_sometimes for locks that are taken by JavaThreads and
> non-JavaThreads
>
> This patch moves all but 3 of the locks to not be
> safepoint_check_sometimes. We have plans to fix these three. Also,
> this patch allows for being explicit about safepoint checking or not
> when the thread is a non-java thread, which is something that Kim
> objected to in my first patch.
>
> Tested with mach5 tier1-3.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8074355.03/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8074355
>
> Thanks,
> Coleen
More information about the hotspot-dev
mailing list