Re: RFR: 8291555: Implement alternative fast-locking scheme [v26]

2023-03-15 Thread Thomas Stuefe
On Thu, 16 Mar 2023 06:31:42 GMT, Roman Kennke wrote: > > > Agreed. But I don't think "Thin locks" is an option as that was > > > specifically an IBM locking implementation. Historically Hotspot's > > > locking mechanism has internally been referred to as stack-locks, so I > > > would suggest

Re: RFR: 8291555: Implement alternative fast-locking scheme [v26]

2023-03-15 Thread Roman Kennke
On Thu, 16 Mar 2023 06:05:38 GMT, Thomas Stuefe wrote: > > > > Agreed. But I don't think "Thin locks" is an option as that was > > specifically an IBM locking implementation. Historically Hotspot's locking > > mechanism has internally been referred to as stack-locks, so I would > > suggest U

Re: RFR: 8291555: Implement alternative fast-locking scheme [v26]

2023-03-15 Thread Roman Kennke
On Wed, 15 Mar 2023 19:40:33 GMT, Roman Kennke wrote: >>> Would it be possible to open/send me the failing test that triggers >>> vframeArray assert >>> or extract a reproducer that you could publish? >> >> I have started an internal discussion at Oracle to see what it would take >> to move tha

Re: RFR: 8291555: Implement alternative fast-locking scheme [v26]

2023-03-15 Thread Thomas Stuefe
On Thu, 16 Mar 2023 05:45:29 GMT, David Holmes wrote: > Agreed. But I don't think "Thin locks" is an option as that was specifically > an IBM locking implementation. Historically Hotspot's locking mechanism has > internally been referred to as stack-locks, so I would suggest > UseNewStackLocks

Re: RFR: 8291555: Implement alternative fast-locking scheme [v26]

2023-03-15 Thread David Holmes
On Wed, 15 Mar 2023 19:40:33 GMT, Roman Kennke wrote: >>> Would it be possible to open/send me the failing test that triggers >>> vframeArray assert >>> or extract a reproducer that you could publish? >> >> I have started an internal discussion at Oracle to see what it would take >> to move tha

Re: RFR: 8291555: Implement alternative fast-locking scheme [v26]

2023-03-15 Thread Roman Kennke
On Wed, 15 Mar 2023 19:14:09 GMT, Daniel D. Daugherty wrote: > > Would it be possible to open/send me the failing test that triggers > > vframeArray assert > > or extract a reproducer that you could publish? > > I have started an internal discussion at Oracle to see what it would take to > mo

Re: RFR: 8291555: Implement alternative fast-locking scheme [v26]

2023-03-15 Thread Daniel D . Daugherty
On Wed, 15 Mar 2023 09:36:25 GMT, Roman Kennke wrote: > Would it be possible to open/send me the failing test that triggers > vframeArray assert > or extract a reproducer that you could publish? I have started an internal discussion at Oracle to see what it would take to move that test from clo

Re: RFR: 8291555: Implement alternative fast-locking scheme [v26]

2023-03-15 Thread Roman Kennke
On Wed, 15 Mar 2023 01:25:33 GMT, Daniel D. Daugherty wrote: > I did Mach5 Tier{1,2,3} on v25. Please see the bug report for the gory > details: > > Tier1 - 1 known, unrelated failure Tier2 - 4 closed, unknown, related test > failures Tier3 - 8 closed, unknown, related test failures; 2 open,

Re: RFR: 8291555: Implement alternative fast-locking scheme [v26]

2023-03-14 Thread Daniel D . Daugherty
On Tue, 14 Mar 2023 18:52:39 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current >> stack-locking implementation. It retains the advantages of stack-locking >> (namely fast locking in uncontended code-paths), while avoiding the overload >> of the

Re: RFR: 8291555: Implement alternative fast-locking scheme [v26]

2023-03-14 Thread Roman Kennke
> This change adds a fast-locking scheme as an alternative to the current > stack-locking implementation. It retains the advantages of stack-locking > (namely fast locking in uncontended code-paths), while avoiding the overload > of the mark word. That overloading causes massive problems with Li