RFR: 8291555: Implement alternative fast-locking scheme [v26]

[Roman Kennke]

On Wed, 15 Mar 2023 19:14:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> > Would it be possible to open/send me the failing test that triggers vframeArray assert
> > or extract a reproducer that you could publish?
> 
> I have started an internal discussion at Oracle to see what it would take to move that test from closed to open. Will keep you posted.

Thank you!

Regarding moving this PR back to draft, I am not sure. I can do that, yes. But really the fundamental algorithm and implementation is basically fixed since half a year already. I have re-worked it into a fresh PR based on the request to put it behind a flag. The recent change to a fixed-size lock-stack has probably invalidated part of your previous reviews, and I am sorry for that. On the upside, it removed a lot of complexity in the JIT compilers and assembly code generators.

What else do I expect to happen?

Thomas is working on an ARM(32) port, but this is quite separate and could even land after this PR is done.

I still don't quite like the naming. Fast-locking doesn't really say anything and it's not (meant to be) faster than the previous stack-locking. It is an alternative (and less racy, on the object header) way to implement a thin-locking layer before inflating monitors, that is all. So maybe -XX:+UseNewThinLocking? It is somewhat temporary anyway. At least my hope is that when we eventually switch to Lilliput turned on by default, we would entirely remove stack-locking.

I would also add some code in arguments.cpp to keep this new thin locking turned off on platforms that don't yet support it.

Besides that, from my POV, it is pretty much done.

What do you think?

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

PR: https://git.openjdk.org/jdk/pull/10907