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

[Roman Kennke]

>      > Lilliput is at a point where I'm planning to start upstreaming it so
>      > that 64bit headers can make it into JDK21. And the new locking scheme
>      > would be one of the first prerequisite steps towards that goal.
> 
>     I hope you are presenting this as an opt-in alternative mechanism
>     not as
>     an outright replacement? Until the Lilliput JEP is accepted for
>     delivery
>     in a particular release, any upstreaming must be for changes that stand
>     on their own merit even if Lilliput were not to go ahead.
> 
> 
> We recently had a discussion about what could be done better with 
> very-large-scale JEPs in the wake of the Loom porter pains: 
> https://mail.openjdk.org/pipermail/jdk-dev/2022-May/006635.html 
> <https://mail.openjdk.org/pipermail/jdk-dev/2022-May/006635.html>.
> 
> I have thought about what could be done and thought about this rule. 
> While I understand the "every change has to stand on its own feet" 
> spirit, I find it too strict in practice. There is a large gray area 
> where code restructurings and cleanups would not be vitally important 
> upstream but can be very helpful for reducing the final load on 
> reviewers if the JEP gets pushed. And, before the final push, in keeping 
> the delta to the JEP branch small and focused on the main changes. One 
> example is https://bugs.openjdk.org/browse/JDK-8280525 
> <https://bugs.openjdk.org/browse/JDK-8280525>, where I tried to bring 
> some minor metaspace changes upstream that came up during Lilliput 
> development. The merits for upstream would have been minor; but I still 
> think it would be a good idea to do this.


If I'm not mistaken, the integration issue of a JEP can have multiple 
sub-tasks, each is its own issue and would be reviewed separately, but 
would only be pushed to mainline when all sub-tasks are ready. That's 
probably how I would deliver Lilliput.

Roman