On Thu, 27 Oct 2022 20:38:57 GMT, John R Rose wrote:
> So the data structure for lock records (per thread) could consist of a series
> of distinct values [ A B C ] and each of the values could be repeated, but
> only adjacently: [ A A A B C C ] for example.
@rose00 why only adjacently? Nested l
- Original Message -
> From: "John R Rose"
> To: hotspot-...@openjdk.org, serviceability-dev@openjdk.org,
> shenandoah-...@openjdk.org
> Sent: Thursday, October 27, 2022 10:41:44 PM
> Subject: Re: RFR: 8291555: Replace stack-locking with fast-locking [v7]
>
On Mon, 24 Oct 2022 11:01:01 GMT, Robbin Ehn wrote:
> Secondly, a question/suggestion: Many recursive cases do not interleave
> locks, meaning the recursive enter will happen with the lock/oop top of lock
> stack already. Why not peak at top lock/oop in lock-stack if the is current
> just push
On Mon, 24 Oct 2022 08:03:13 GMT, Roman Kennke wrote:
>> This change replaces the current stack-locking implementation with a
>> fast-locking scheme that retains the advantages of stack-locking (namely
>> fast locking in uncontended code-paths), while avoiding the overload of the
>> mark word.
On Mon, 24 Oct 2022 08:03:13 GMT, Roman Kennke wrote:
>> This change replaces the current stack-locking implementation with a
>> fast-locking scheme that retains the advantages of stack-locking (namely
>> fast locking in uncontended code-paths), while avoiding the overload of the
>> mark word.
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that 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 Lilliput, bec
