RFR: 8319797: Recursive lightweight locking: Runtime implementation [v3]

[Roman Kennke]

On Mon, 13 Nov 2023 09:26:31 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 395:
>> 
>>> 393:       // Always go into runtime if the lock stack is full.
>>> 394:       return false;
>>> 395:     }
>> 
>> It isn't obvious that it is beneficial to check what should be a rare occurrence. Why do this?
>
> All lightweight enters must check if the lock stack is full. Both push and try_recursive_enter have that as a pre condition. All code paths emitted C2, emitted shared code and the runtime does the is full check first. 
> 
> The reason that quick_enter does this without checking the mark word (for monitor) is that we go into the runtime from the emitted code if the lock stack is full. So we want to enter the runtime to inflate and make room, to not get into scenario where we have to go into the runtime on every monitor enter because we are locking on new objects in a loop with a full lock stack.

FWIW, when I did the original LW-locking implementation, and when the lock-stack was not yet fixed-size, I experimented with an optimisation for this problem: instead of doing the check for every monitorenter, I let C2 analyse the maximum lock-stack depth that the method is going to require, and do the check (and growing of the lock-stack) at method-entry. However, I haven't seen a case where this was beneficial, and there have been several problems with the approach as well (maybe that's why it wasn't beneficial). But maybe it is worth revisiting at some point? OTOH, with recursive locking we need to load and check the top-offset anyway, which makes the extra cost to check for overflow even smaller.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16606#discussion_r1390858880