On Fri, 5 May 2023 16:49:38 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 Mon, 8 May 2023 17:04:29 GMT, Aleksey Shipilev wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Only allow lock-stack verification for owning Java threads or at safepoints
>
> src/hotspot/cpu/arm/c1_MacroAssemble
On Fri, 5 May 2023 16:49:38 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, 5 May 2023 16:49:38 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, 5 May 2023 16:49:38 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, 5 May 2023 16:49:38 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, 5 May 2023 16:49:38 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, 5 May 2023 16:49:38 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 Mon, 8 May 2023 01:13:36 GMT, David Holmes wrote:
> updates seem fine.
Thanks!
@dcubed-ojdk are you good with testing? If you could approve this PR again, I
would integrate it later today?
-
PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1537901860
On Fri, 5 May 2023 16:49:38 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, 5 May 2023 17:19:11 GMT, Daniel D. Daugherty wrote:
> Slowdebug had a better stack trace:
>
>
>
> --- T H R E A D ---
>
>
>
> Current thread (0x7fe4ad0062d0): WorkerThread "GC Thread#0"
> [id=19715, stack(0x74416000,0x74516000) (102
On Fri, 5 May 2023 16:49:38 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
13 matches
Mail list logo
