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

[David Holmes]

On 28/07/2022 7:05 pm, Roman Kennke wrote:
> On Wed, 27 Jul 2022 21:16:06 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> I also intend to upstream this change (minus the Lilliput-specific parts) soon, that will help Lilliput upstreaming and later on the JOM project.
>>
>> I would need a lot of convincing that we should be doing anything upstream in this area "soon" given the current status of the two projects, but look forward to seeing such a proposal and its performance etc.
> 
> I don't know about JOM's status, because unfortunately the project is not public (otherwise I wouldn't have had to re-do it). 

As I've explained before the JOM "project" was still in its infancy and 
not ready for sharing. The code was/is very prototypical looking mainly 
at basic functionality not any optimisation, and there are a lot of open 
issues to resolve in the context of doing Java-in-Java. That project has 
also been on hold since May due to other priorities, which is why there 
have also been very few cycles to look at what you have been doing with 
Lilliput.

I hope Robbin was able to give a lot of input as the code to manage 
inflation and "ownership transfer" had a number of subtleties in particular.

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

> Performance in Lilliput: see above. I'd expect it to be neutral outside
> of Lilliput because there the benefit of faster load-Klass does not
> exist, and the benefit of faster i-hash is probably not significant.

It is the performance of the fast-locking code compared to the existing 
locking code that I (and others) am interested in.

Cheers,
David
-----

> 
> -------------
> 
> PR: https://git.openjdk.org/lilliput/pull/51