On Fri, 28 Oct 2022 09:32:58 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, 14 Nov 2022 22:59:22 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
On Fri, 28 Oct 2022 09:32:58 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 Fri, 28 Oct 2022 01:47:23 GMT, David Holmes 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? Neste
On Fri, 11 Nov 2022 14:35:22 GMT, Roman Kennke 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
t; 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\,
On Fri, 28 Oct 2022 09:32:58 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
On Fri, 28 Oct 2022 03:32:58 GMT, Remi Forax wrote:
> i've some trouble to see how it can be implemented given that because of lock
> coarsening (+ may be OSR), the number of time a lock is held is different
> between the interpreted code and the compiled code.
Correct me if I'm wrong, only C2
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
> 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
On Fri, 14 Oct 2022 15:39:41 GMT, Roman Kennke wrote:
>>> > > > > > Here is the basic support for RISC-V:
>>> > > > > > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
>>> > > > > > -- I adapted this from AArch64 changes, and tested it very
>>> > > > > > lightly. @RealFYang, can
On Fri, 14 Oct 2022 14:53:57 GMT, Fei Yang wrote:
> > > > > > > Here is the basic support for RISC-V:
> > > > > > > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
> > > > > > > -- I adapted this from AArch64 changes, and tested it very
> > > > > > > lightly. @RealFYang, can I le
On Fri, 14 Oct 2022 14:39:01 GMT, Roman Kennke wrote:
> > > > > > Here is the basic support for RISC-V:
> > > > > > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
> > > > > > -- I adapted this from AArch64 changes, and tested it very lightly.
> > > > > > @RealFYang, can I leave
On Fri, 14 Oct 2022 14:32:57 GMT, Fei Yang wrote:
> > > > > Here is the basic support for RISC-V:
> > > > > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
> > > > > -- I adapted this from AArch64 changes, and tested it very lightly.
> > > > > @RealFYang, can I leave the testing
On Fri, 14 Oct 2022 14:26:20 GMT, Roman Kennke wrote:
> > > > Here is the basic support for RISC-V:
> > > > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
> > > > -- I adapted this from AArch64 changes, and tested it very lightly.
> > > > @RealFYang, can I leave the testing and
On Fri, 14 Oct 2022 13:45:07 GMT, Fei Yang wrote:
> > > Here is the basic support for RISC-V:
> > > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
> > > -- I adapted this from AArch64 changes, and tested it very lightly.
> > > @RealFYang, can I leave the testing and follow up fi
On Fri, 14 Oct 2022 01:19:27 GMT, Fei Yang wrote:
> > Here is the basic support for RISC-V:
> > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
> > -- I adapted this from AArch64 changes, and tested it very lightly.
> > @RealFYang, can I leave the testing and follow up fixes to y
On Thu, 13 Oct 2022 10:34:04 GMT, Roman Kennke wrote:
> It used to be very stable before that. I have backed out that change, can you
> try again?
Seems fine now, thanks.
-
PR: https://git.openjdk.org/jdk/pull/10590
On Wed, 12 Oct 2022 11:26:16 GMT, Aleksey Shipilev wrote:
> Here is the basic support for RISC-V:
> https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
>
> -- I adapted this from AArch64 changes, and tested it very lightly.
> @RealFYang, can I leave the testing and follow up fixes t
On Tue, 11 Oct 2022 20:41:57 GMT, Robbin Ehn wrote:
> Regarding benchmarks, is it possible to get some indication what
> fast-locking+lillput result will be? FinagleHttp seems to suffer a bit, will
> Lillput give some/all of that back, or more?
That particular benchmark, as some others, exhibi
On Thu, 13 Oct 2022 08:46:45 GMT, Robbin Ehn wrote:
> On aarch64 (linux and mac) I see these variations of crashes in random tests:
> (asserts in debug, crash in release it looks like)
>
> ```
> # Internal Error src/hotspot/share/c1/c1_Runtime1.cpp:768),
> pid=2884803, tid=2884996
> # a
> 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
On Thu, 13 Oct 2022 07:33:48 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
On Tue, 11 Oct 2022 20:01:32 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 Tue, 11 Oct 2022 20:01:32 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 Tue, 11 Oct 2022 13:25:30 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/fast-locking' into fast-locking
>> - Re-use r0 in call to unlock_object()
>
> 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
> 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
On Thu, 6 Oct 2022 10:23:04 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. That
On Thu, 28 Jul 2022 19:58:34 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. Tha
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, because it
On Thu, 28 Jul 2022 19:58:34 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. Tha
On Mon, 12 Sep 2022 07:54:48 GMT, Roman Kennke wrote:
>>> How have you handled the interpreter lock-stack-area in your
>>> implementation? Is it worth to get rid of it and consolidate with the
>>> per-thread lock-stack?
>>
>> At the moment I had to store a "frame id" for each entry in the lock
On Mon, 12 Sep 2022 07:54:48 GMT, Roman Kennke wrote:
>>> How have you handled the interpreter lock-stack-area in your
>>> implementation? Is it worth to get rid of it and consolidate with the
>>> per-thread lock-stack?
>>
>> At the moment I had to store a "frame id" for each entry in the lock
On Mon, 12 Sep 2022 07:54:48 GMT, Roman Kennke wrote:
> Nice! From your snippets above I am gleaning that your implementation has the
> actual lock-stack in Java. Is that correct? Is there a particular reason why
> you need this? Is this for Loom? Would the implementation that I am proposing
>
On Mon, 12 Sep 2022 06:37:19 GMT, Robbin Ehn wrote:
> > How have you handled the interpreter lock-stack-area in your
> > implementation? Is it worth to get rid of it and consolidate with the
> > per-thread lock-stack?
>
> At the moment I had to store a "frame id" for each entry in the lock sta
On Fri, 9 Sep 2022 19:01:14 GMT, Roman Kennke wrote:
> How have you handled the interpreter lock-stack-area in your implementation?
> Is it worth to get rid of it and consolidate with the per-thread lock-stack?
At the moment I had to store a "frame id" for each entry in the lock stack.
The fram
On Tue, 30 Aug 2022 11:52:24 GMT, Roman Kennke wrote:
>> I didn't realize you still also is using the frame basic lock area. (in
>> other projects this is removed and all cases are handled via the threads
>> lock stack)
>> So essentially we have two lock stacks when running in interpreter the f
On Wed, 17 Aug 2022 15:34:01 GMT, Roman Kennke wrote:
>>> Strictly speaking, I believe the conditions check for the (weaker) balanced
>>> property, but not for the (stronger) structured property.
>>
>> I know but the text says:
>> - "every exit on a given monitor matches a preceding entry on th
On Wed, 17 Aug 2022 07:29:23 GMT, Robbin Ehn wrote:
> > Strictly speaking, I believe the conditions check for the (weaker) balanced
> > property, but not for the (stronger) structured property.
>
> I know but the text says:
>
> * "every exit on a given monitor matches a preceding entry on
On Tue, 16 Aug 2022 16:21:04 GMT, Roman Kennke wrote:
> Strictly speaking, I believe the conditions check for the (weaker) balanced
> property, but not for the (stronger) structured property.
I know but the text says:
- "every exit on a given monitor matches a preceding entry on that monitor."
On Tue, 16 Aug 2022 15:47:58 GMT, Robbin Ehn wrote:
> > @robehn or @dholmes-ora I believe one of you mentioned somewhere (can't
> > find the comment, though) that we might need to support the bytecode
> > sequence monitorenter A; monitorenter B; monitorexit A; monitorexit B;
> > properly. I ha
On Thu, 11 Aug 2022 11:39:01 GMT, Robbin Ehn wrote:
>>> > Thanks for giving this PR a spin. I pushed a fix for the aarch64 build
>>> > problem (seems weird that GHA did not catch it).
>>>
>>> NP, thanks. I notice some other user of owning_thread_from_monitor_owner()
>>> such as DeadlockCycle::
On Thu, 11 Aug 2022 11:39:01 GMT, Robbin Ehn wrote:
> > > > Thanks for giving this PR a spin. I pushed a fix for the aarch64 build
> > > > problem (seems weird that GHA did not catch it).
> > >
> > >
> > > NP, thanks. I notice some other user of
> > > owning_thread_from_monitor_owner() such a
On Thu, 28 Jul 2022 19:58:34 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. Tha
On Thu, 11 Aug 2022 11:19:31 GMT, Roman Kennke wrote:
> > > Thanks for giving this PR a spin. I pushed a fix for the aarch64 build
> > > problem (seems weird that GHA did not catch it).
> >
> >
> > NP, thanks. I notice some other user of owning_thread_from_monitor_owner()
> > such as Deadlock
On Tue, 9 Aug 2022 11:05:45 GMT, Robbin Ehn wrote:
> > Thanks for giving this PR a spin. I pushed a fix for the aarch64 build
> > problem (seems weird that GHA did not catch it).
>
> NP, thanks. I notice some other user of owning_thread_from_monitor_owner()
> such as DeadlockCycle::print_on_wi
On Tue, 9 Aug 2022 09:32:47 GMT, Roman Kennke wrote:
> I am not aware, please refresh my memory if you know different, of any core
> hotspot subsystem just being replaced in one fell swoop in one single
> release. Yes this needs a lot of testing but customers are not beta-testers.
> If this go
On Tue, 9 Aug 2022 10:46:51 GMT, Roman Kennke wrote:
> Thanks for giving this PR a spin. I pushed a fix for the aarch64 build
> problem (seems weird that GHA did not catch it).
NP, thanks.
I notice some other user of owning_thread_from_monitor_owner() such as
DeadlockCycle::print_on_with() whi
On Tue, 9 Aug 2022 09:19:54 GMT, Robbin Ehn wrote:
> I got this build problem on aarch64:
Thanks for giving this PR a spin. I pushed a fix for the aarch64 build problem
(seems weird that GHA did not catch it).
-
PR: https://git.openjdk.org/jdk/pull/9680
On Mon, 8 Aug 2022 18:29:54 GMT, Roman Kennke wrote:
> > I ran some test locally, 4 JDI fails and 3 JVM TI, all seems to fail in:
> > ```
> > #7 0x7f7cefc5c1ce in Thread::is_lock_owned
> > (this=this@entry=0x7f7ce801dd90, adr=adr@entry=0x1 > memory at address 0x1>) at
> > /home/rehn/sourc
On Mon, 8 Aug 2022 15:44:50 GMT, Robbin Ehn wrote:
> I ran some test locally, 4 JDI fails and 3 JVM TI, all seems to fail in:
>
> ```
> #7 0x7f7cefc5c1ce in Thread::is_lock_owned
> (this=this@entry=0x7f7ce801dd90, adr=adr@entry=0x1 memory at address 0x1>) at
> /home/rehn/source/jdk/ongit
On Thu, 28 Jul 2022 19:58:34 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. Tha
On Mon, 8 Aug 2022 13:45:06 GMT, Roman Kennke wrote:
> The bar for acceptance for a brand new locking scheme with no fallback is
> extremely high and needs a lot of bake time and broad performance
> measurements, to watch for pathologies. That bar is lower if the scheme can
> be reverted to th
On Mon, 8 Aug 2022 12:14:38 GMT, David Holmes wrote:
> The bar for acceptance for a brand new locking scheme with no fallback is
> extremely high and needs a lot of bake time and broad performance
> measurements, to watch for pathologies. That bar is lower if the scheme can
> be reverted to th
On Thu, 28 Jul 2022 19:58:34 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. Tha
On Sun, 7 Aug 2022 12:50:01 GMT, Roman Kennke wrote:
> > Happens when the main thread detaches itself upon VM exit. VM attempts to
> > release OMs that are owned by the finished main thread (side note: if that
> > is the sole surviving thread, maybe that step could be skipped?). That
> > happe
On Wed, 3 Aug 2022 07:17:51 GMT, Thomas Stuefe wrote:
> Happens when the main thread detaches itself upon VM exit. VM attempts to
> release OMs that are owned by the finished main thread (side note: if that is
> the sole surviving thread, maybe that step could be skipped?). That happens
> befo
On Thu, 28 Jul 2022 19:58:34 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. Tha
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, because it
67 matches
Mail list logo
