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

[David Holmes]

Hi Erik,

On 1/08/2022 8:26 pm, Erik Osterlund wrote:
> Hi David,
> 
> I think the change does have merits on its own, if it can 1) remove the complexity of stack locking, without regressing, and 2) create integration independence between JOM and Liliput.

Lets ignore Lilliput. A proposal for a new fast-locking mechanism has to 
pass all the right functional and performance hurdles to get accepted. 
So as long as it does that I'm good with it. But where are the 
performance results?

> And the direction of the sync code is similar to what we want with JOM, it’s just skipping the “let’s do this in Java” step, which of course is the main focus of the JOM project to solve. I would be more opposed if it ran in a completely opposite direction with different concepts, but me and Robbin have been in the loop and I think it aligns well and might have synergies.

It also has to fit in with other project directions e.g. valhalla.

Cheers,
David
-----

> My 50c…
> 
> /Erik
> 
>> On 31 Jul 2022, at 03:18, David Holmes <david.holmes at oracle.com> wrote:
>> 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