<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> Lilliput is at a point where I'm planning to start upstreaming it so<br>
> that 64bit headers can make it into JDK21. And the new locking scheme<br>
> would be one of the first prerequisite steps towards that goal.<br>
<br>
I hope you are presenting this as an opt-in alternative mechanism not as <br>
an outright replacement? Until the Lilliput JEP is accepted for delivery <br>
in a particular release, any upstreaming must be for changes that stand <br>
on their own merit even if Lilliput were not to go ahead.<br>
<br></blockquote><div><br></div><div>We recently had a discussion about what could be done better with very-large-scale JEPs in the wake of the Loom porter pains: <a href="https://mail.openjdk.org/pipermail/jdk-dev/2022-May/006635.html">https://mail.openjdk.org/pipermail/jdk-dev/2022-May/006635.html</a>.</div><div><br></div><div>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 <a href="https://bugs.openjdk.org/browse/JDK-8280525">https://bugs.openjdk.org/browse/JDK-8280525</a>, 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.</div><div><br></div><div>Cheers, Thomas</div><div><br></div></div></div>