On Tue, 4 Apr 2023 22:12:03 GMT, David Holmes wrote:
>>> Given the owner could release the monitor the moment after we check I don't
>>> see how false results are an issue here. The existing code should be safe
>>> when not executed at a safepoint..
>>
>> I checked again. It looks like the Dea
On Tue, 4 Apr 2023 19:04:03 GMT, Roman Kennke wrote:
>>> Not at all clear to me how this fits here. ??
>>
>> This block checks whether the monitor is in waiting state. When it is
>> anonymously locked it must be waiting. I added a comment.
>
>> Given the owner could release the monitor the mome
On Tue, 4 Apr 2023 12:57:38 GMT, Thomas Stuefe wrote:
>> Thanks @tstuefe . I see at that level if the object doesn't match the top of
>> the lock-stack then we take the slow path. But then I'm lost - AFAICS the
>> slow path is `InterpreterRuntime::monitorexit` and that doesn't have any
>> fast
On Tue, 4 Apr 2023 19:01:44 GMT, Roman Kennke wrote:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java
>> line 85:
>>
>>> 83: ( // we have marked ourself as pending on this monitor
>>> 84: mark.monitor().equals(thread.getCurrentPendingMonitor()) ||
On Tue, 4 Apr 2023 12:57:38 GMT, Thomas Stuefe wrote:
>> Thanks @tstuefe . I see at that level if the object doesn't match the top of
>> the lock-stack then we take the slow path. But then I'm lost - AFAICS the
>> slow path is `InterpreterRuntime::monitorexit` and that doesn't have any
>> fast
On Tue, 4 Apr 2023 06:46:02 GMT, David Holmes wrote:
> One thing I can't quite get clear in my head is whether the small window
> where an object's monitor is inflated and the object is still in the thread's
> lock-stack, could cause an issue for any external observers trying to
> determine th
On Mon, 3 Apr 2023 11:05:41 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 Tue, 4 Apr 2023 12:25:19 GMT, David Holmes wrote:
>> That is done one layer up in InterpreterMacroAssembler::unlock_object.
>
> Thanks @tstuefe . I see at that level if the object doesn't match the top of
> the lock-stack then we take the slow path. But then I'm lost - AFAICS the
> slow path
On Tue, 4 Apr 2023 08:17:14 GMT, Thomas Stuefe wrote:
>> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9739:
>>
>>> 9737: get_thread(thread);
>>> 9738: #endif
>>> 9739: subl(Address(thread, JavaThread::lock_stack_top_offset()), oopSize);
>>
>> Is this code used for monitorexit or only ret
On Tue, 4 Apr 2023 05:54:09 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9739:
>
>> 9737: get_thread(thread);
>> 9738: #endif
>>
On Mon, 3 Apr 2023 11:05:41 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
12 matches
Mail list logo
