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

[Axel Boldt-Christmas]

On Tue, 14 Nov 2023 22:39:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It wasn't the recursions I was querying but the unstructured locking aspect.
>
> To be clear, my concern is that for a simple exit we not only have to first check for a recursive exit (fine) but also this unexpected rare unstructured locking recursive case. Thinking it through part of the problem is that a simple-exit does itself allow for unstructured locking. Is it worth adding an additional case to peek at the top of the lock-stack and then do an exit with a pop for the most common non-recursive case? That way we in effect handle things as follows:
> - recursive exit
> - direct exit
> - recursive unstructured exit
> - direct unstructured exit

First of let us note that when reaching this code the unstructured exit is the common case. The normal exit and recursive exit is usually handled in the emitted code (this includes the interpreter). We reach this because either a CAS failed somewhere due to a concurrent hashCode instalment, or the exit was unstructured. Inflated monitors exit just jumps passed this code (everything is conditioned on `mark.is_fast_locked()`). 

Is this motivated by the structure/layout of the C++ code. Or an optimisation?

If it is motivated by the structure/layout. Then we can lay it out as you described. It would add some code duplication.

If it is motivated as an optimisation then after the recursive exit fail, we should just call remove and act based on the return value.

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

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