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

[Roman Kennke]

Hi David,

I've done some measurements and included results in the upstream PR:

https://github.com/openjdk/jdk/pull/9680

I'll add more data as soon as I do more measurements.

Thanks,
Roman

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