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

[Robbin Ehn]

On Thu, 16 Mar 2023 09:02:19 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I like -XX:+UseNewLocks, too. I wouldn't overcomplicate things: this flag is meant to be transitional, it is not meant to be used by end-users (except the bravest nerds) at all. When it lands, the Lilliput flag (e.g. +UseCompactObjectHeaders) will also control the locking flag. Eventually (e.g. release+1) both flags would become on by default and afterwards (e.g. release+2) would go away entirely, at which point the whole original stack-locking would disappear.
>
>> @rkennke I must be missing something. In aarch64, why do we handle the non-symmetric-unlock case in interpreter, but not in C1/C2? There, we just seem to pop whatever is on top.
> 
> C1 and C2 don't allow assymmetric locking. If that ever happens, they would refuse to compile the method. We should probably check that this assumption holds true when popping the top entry in an #ASSERT block.

> > > @rkennke I must be missing something. In aarch64, why do we handle the non-symmetric-unlock case in interpreter, but not in C1/C2? There, we just seem to pop whatever is on top.
> > 
> > 
> > C1 and C2 don't allow assymmetric locking. If that ever happens, they would refuse to compile the method. We should probably check that this assumption holds true when popping the top entry in an #ASSERT block.
> 
> Thanks for clarifying. Yes, asserting that would make sense.

FYI:
I'm trying to convince folks that JVMS should be allowed to enforce asymmetric locking.
We think most people don't know they will be stuck in interpreter, unintended.
What was discussed latest was to diagnose and warn about this behavior as a first step.

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

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