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

[David Holmes]

On Wed, 15 Nov 2023 07:22:25 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> 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.

I would not go so far as to say the unstructured locking case is common. Sure we are on the slow-path, which may be due to unstructured locking, or we may be here through deop (also a slow path) or through the native method wrapper, or ... but yes this is not really performance critical.

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

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