[crac] RFR: RCU Lock - RW lock with very lightweight read- and heavyweight write-locking [v6]

[Dan Heidinga]

On Thu, 13 Apr 2023 15:01:28 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> This implementation is suitable for uses where the write-locking happens very rarely (if at all), as in the case of CRaC checkpoint, and we don't want to slow down regular access to the protected resource.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add forgotten condition.signal() call

src/java.base/share/classes/jdk/crac/RCULock.java line 209:

> 207:             lockImpl = lockSwitchPoint.guardWithTest(noop, readLockImpl);
> 208:             unlockSwitchPoint = new SwitchPoint();
> 209:             unlockImpl = lockSwitchPoint.guardWithTest(noop, readUnlockImpl);

After spending a lot of time digging through the Hotspot C2 code, I don't think this use of SwitchPoints will be optimized in the way we might want (ie: deopt on SwitchPoint invalidation).

SwitchPoint is implemented as a special MutableCallSite that changes from a known target MH that returns true to a known target MH that returns false.  This is all wrapped into a standard guardWithTest MH (basically a MH "if" statement).

As far as I can tell, to benefit from C2 optimizing the SW, we need to have the MutableCallSite or the GuardWithTest MH rooted in a static final field or in an invokedynamic bytecode. See the code in type.cpp::make_constant_from_field which asserts a Dependency between the CallSite and the target MH for the current method.  Otherwise, we don't have a Dependency to rely on and trigger the eventual deopt.

The above analysis may be wrong so any corrections by C2 experts would be appreciated.

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

PR Review Comment: https://git.openjdk.org/crac/pull/58#discussion_r1171436557