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

[David Holmes]

On 1/08/2022 5:21 pm, Thomas Stüfe wrote:
> 
>      > 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.

Yes but we are not talking about code restructuring and cleanups here, 
this is a proposal for a completely new form of fast-locking to replace 
stack-locks. There are a lot of implications as a lot of code knows 
about stack-locks.

Cheers,
David
-----

>  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.
> 
> Cheers, Thomas
>