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

2023-05-04 Thread Daniel D . Daugherty
On Thu, 4 May 2023 20:59:58 GMT, Roman Kennke wrote: >> src/hotspot/share/runtime/lockStack.inline.hpp line 53: >> >>> 51: bool is_owning = &JavaThread::cast(thread)->lock_stack() == this; >>> 52: assert(is_owning == (get_thread() == thread), "is_owning sanity"); >>> 53: return is_owning;

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

2023-05-04 Thread Roman Kennke
On Thu, 4 May 2023 19:35:58 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address @dholmes-ora's review comments > > src/hotspot/share/runtime/lockStack.inline.hpp line 53: > >> 51: bo

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

2023-05-04 Thread Roman Kennke
On Thu, 4 May 2023 20:49:22 GMT, Roman Kennke wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 666: >> >>> 664: // Invariant: tmpReg == 0. tmpReg is EAX which is the implicit >>> cmpxchg comparand. >>> 665: lock(); >>> 666: cmpxchgptr(scrReg, Address(boxReg, >>> OM_OFFSET_NO

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

2023-05-04 Thread Roman Kennke
On Thu, 4 May 2023 19:32:23 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address @dholmes-ora's review comments > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 666: > >> 664: /

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

2023-05-04 Thread Daniel D . Daugherty
On Wed, 3 May 2023 09:33:24 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 [v71]

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