On Thu, 30 Mar 2023 11:45:54 GMT, Roman Kennke wrote:
>> I have another question about the asymmetric unlocking code in
>> `InterpreterMacroAssembler::unlock_object`.
>>
>> We go through here for both fast-locked and fat OM locks, right? If so,
>> shouldn't we do the asymmetric lock check only
On Sat, 25 Mar 2023 08:55:25 GMT, Thomas Stuefe wrote:
> I have another question about the asymmetric unlocking code in
> `InterpreterMacroAssembler::unlock_object`.
>
> We go through here for both fast-locked and fat OM locks, right? If so,
> shouldn't we do the asymmetric lock check only for
On Tue, 28 Mar 2023 16:00:34 GMT, Thomas Stuefe wrote:
>> Please also verify against over- and underflow, and better than just null
>> checks check that every oop really is an oop. I added this to my code:
>>
>> assert((_offset <= end_offset()), "lockstack overflow: _offset %d
>> end_offset
On Tue, 28 Mar 2023 10:53:10 GMT, Roman Kennke wrote:
>> src/hotspot/share/runtime/threads.cpp line 1422:
>>
>>> 1420: }
>>> 1421:
>>> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list,
>>> oop obj) {
>>
>> Is this thread-safe?
>
> My last commit changed that code to o
On Fri, 24 Mar 2023 16:54:59 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/runtime/lockStack.cpp line 42:
>>
>>> 40:
>>> 41: #ifndef PRODUCT
>>> 42: void LockStack::validate(const char* msg) const {
>>
>> Would you also like to check there are no `nullptr` elements on stack here?
>
> Please a
On Fri, 24 Mar 2023 11:17:05 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly afte
On Fri, 24 Mar 2023 10:50:39 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly afte
On Fri, 24 Mar 2023 10:47:11 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly afte
On Fri, 24 Mar 2023 02:49:11 GMT, David Holmes wrote:
> > Is anybody familiar with the academic literature on this topic? I am sure I
> > am not the first person which has come up with this form of locking. Maybe
> > we could use a name that refers to some academic paper?
>
> Well not to dimin
On Fri, 24 Mar 2023 06:55:55 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Fri, 24 Mar 2023 06:15:31 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Mon, 27 Mar 2023 18:47:31 GMT, Roman Kennke wrote:
> > > > > > @rkennke Question about ZGC and LockStack::contains(): how does
> > > > > > this work with colored pointers? Don't we have to mask the color
> > > > > > bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
>
> > >
On Mon, 27 Mar 2023 17:30:03 GMT, Roman Kennke wrote:
>>> @rkennke Question about ZGC and LockStack::contains(): how does this work
>>> with colored pointers? Don't we have to mask the color bits out somehow
>>> when comparing? E.g. using `ZAddress::offset()` ?
>>
>> That would be a question f
On Fri, 24 Mar 2023 06:39:18 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Mon, 27 Mar 2023 17:30:03 GMT, Roman Kennke wrote:
> > > > @rkennke Question about ZGC and LockStack::contains(): how does this
> > > > work with colored pointers? Don't we have to mask the color bits out
> > > > somehow when comparing? E.g. using `ZAddress::offset()` ?
>
> > >
>
> > >
>
On Fri, 24 Mar 2023 06:16:14 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Mon, 27 Mar 2023 15:53:47 GMT, Roman Kennke wrote:
> > @rkennke Question about ZGC and LockStack::contains(): how does this work
> > with colored pointers? Don't we have to mask the color bits out somehow
> > when comparing? E.g. using `ZAddress::offset()` ?
>
>
>
> That would be a questi
On Mon, 27 Mar 2023 15:53:47 GMT, Roman Kennke wrote:
>> Is anybody familiar with the academic literature on this topic? I am sure I
>> am not the first person which has come up with this form of locking. Maybe
>> we could use a name that refers to some academic paper?
>
>> @rkennke Question ab
On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Mon, 27 Mar 2023 02:46:31 GMT, David Holmes wrote:
> > AFAIU, these places now could get outdated information from the contains
> > function: either getting a false positive or a false negative when asking
> > for a given object. But if I understand correctly, this had been the case
> > bef
On Fri, 24 Mar 2023 17:11:46 GMT, Thomas Stuefe wrote:
> AFAIU, these places now could get outdated information from the contains
> function: either getting a false positive or a false negative when asking for
> a given object. But if I understand correctly, this had been the case before,
> to
On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 16 Mar 2023 20:56:15 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
On Fri, 24 Mar 2023 11:36:24 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly afte
On Fri, 24 Mar 2023 07:00:35 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Fri, 24 Mar 2023 10:10:58 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly afte
On Thu, 16 Mar 2023 20:56:15 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
On Fri, 24 Mar 2023 07:00:35 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after fa
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke wrote:
> Is anybody familiar with the academic literature on this topic? I am sure I
> am not the first person which has come up with this form of locking. Maybe we
> could use a name that refers to some academic paper?
Well not to diminish this i
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 23 Mar 2023 13:25:52 GMT, Jesper Wilhelmsson
wrote:
> UseNewLocks... Surely there must be a better name? For how long will these be
> the new locks? Do we rename the flag to UseOldLocks when the next locking
> scheme comes along? There must be some property that differentiates these
>
On Thu, 16 Mar 2023 20:56:15 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
On Wed, 22 Mar 2023 09:46:04 GMT, Roman Kennke wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 670:
>>
>>> 668: get_thread (scrReg);// beware: clobbers ICCs
>>> 669: movptr(Address(boxReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)),
>>> scrReg);
>>> 670: xorpt
On Wed, 22 Mar 2023 09:47:47 GMT, Roman Kennke wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 791:
>>
>>> 789: Compile::current()->output()->add_stub(stub);
>>> 790: jcc(Assembler::notEqual, stub->entry());
>>> 791: bind(stub->continuation());
>>
>> Why use stub
On Wed, 22 Mar 2023 00:25:43 GMT, Vladimir Kozlov wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>> - Set condition flags correctly after
On Thu, 16 Mar 2023 20:56:15 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
On Thu, 16 Mar 2023 20:56:15 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
> 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
49 matches
Mail list logo
