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

[Thomas Stüfe]

>
>
> > 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.

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, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/lilliput-dev/attachments/20220801/7f56cb66/attachment.htm>