RFR: 8291555: Implement alternative fast-locking scheme

Roman Kennke rkennke at openjdk.org
Wed Jan 18 15:48:14 UTC 2023


On Wed, 18 Jan 2023 14:57:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Here are some tests that seems provide some reproducability (mac/linux aarch64): runtime/handshake/HandshakeDirectTest.java vmTestbase/gc/gctests/ObjectMonitorCleanup/ObjectMonitorCleanup.java (crashes in AccessInternal::PostRuntimeDispatch<CardTableBarrierSet::AccessBarrier<594020ul, CardTableBarrierSet>, (AccessInternal::BarrierType)2, 594020ul>::oop_access_barrier(void*)+0x1c) vmTestbase/nsk/jdi/stress/serial/heapwalking00X
> 
> (options don't seem to matter)
> 
> Well of course you need to turn it on. I was running with this applied:
> 
> ```
> diff --git a/src/hotspot/share/runtime/globals.hpp b/src/hotspot/share/runtime/globals.hpp
> index f07a37b3d9f..c01c4f450a6 100644
> --- a/src/hotspot/share/runtime/globals.hpp
> +++ b/src/hotspot/share/runtime/globals.hpp
> @@ -1986 +1986 @@ const int ObjectAlignmentInBytes = 8;
> -  product(bool, UseFastLocking, false, EXPERIMENTAL,                        \
> +  product(bool, UseFastLocking, true, EXPERIMENTAL,                         \
> ```

Thanks, Robbin! Turns out that this bug has been caused by one of the most recent commits: I used tnbz to branch to the exit of fast_unlock, but this doesn't set the ZF properly. I need to use regular tst & br instead. I pushed a fix, together with a number of minor improvements (avoid some conditional branches). Could you re-test? Thank you!

Roman

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

PR: https://git.openjdk.org/jdk/pull/10907


More information about the serviceability-dev mailing list