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

Roman Kennke rkennke at openjdk.org
Thu Mar 16 09:05:39 UTC 2023


On Thu, 16 Mar 2023 08:36:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - More RISCV changes (by Fei Yang)
>>  - Use -w instructions in fast_unlock()
>>  - Increase stub size of C2HandleAnonOwnerStub to 18
>
> 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.

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

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


More information about the serviceability-dev mailing list