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

2023-05-05 Thread Roman Kennke
On Fri, 5 May 2023 14:40:52 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Relax zapped-entry test when calling thread is not owning thread > > src/hotspot/share/runtime/lockStack.cpp line

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

2023-05-05 Thread Daniel D . Daugherty
On Fri, 5 May 2023 05:54:29 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 [v73]

2023-05-04 Thread Roman Kennke
On Fri, 5 May 2023 06:21:18 GMT, David Holmes wrote: > Updates look good to me. Thanks. Nice, thank you! The PR has 4 approvals now. Are we good to go, or should I wait for others to approve? (And if so, who?) - PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-15357

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

2023-05-04 Thread David Holmes
On Fri, 5 May 2023 05:54:29 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 [v73]

2023-05-04 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