[master] RFR: Implement non-racy fast-locking [v5]

[Roman Kennke]

On Thu, 28 Jul 2022 12:59:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> One question: I tried to find out how you grow the LockStack array if we hit the limit while attempting to lock in compiled code. Looks to me you don't do that, or? Beyond recursive locking, that is another case where we inflate?

I don't do that in compiled code. Instead, I'm checking for overflow, and call into the runtime for growing the array. No need to inflate the monitor, though.

> Also, I tried to understand in which cases LockStack::remove() is used. Obviously, if we recursively enter a lock we own, we inflate and remove the oop from our LockStack.

Right. Whenever a fast-lock is inflated, we remove the corresponding oop from the lock-stack.

> But how does that work if another thread inflates a lock we have already fast locked?

In this case, the other thread sets the owner of the new monitor to anonymous. As soon as we arrive at monitorexit, we know that the owner must be us, so we set that in the monitor, remove/pop the oop from the lock-stack, and perform a regular monitor exit to hand over the monitor to the other thread.

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

PR: https://git.openjdk.org/lilliput/pull/51