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 Tue, 2 May 2023 22:46:44 GMT, Dean Long wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add missing new file
>
> My review applies to the aarch64 changes.
> I have looked at the aarch64 changes twice and the lat
On Tue, 2 May 2023 22:46:44 GMT, Dean Long wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add missing new file
>
> My review applies to the aarch64 changes.
> I have looked at the aarch64 changes twice and the lat
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
On Fri, 5 May 2023 14:59:36 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
On Fri, 5 May 2023 14:59:36 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 14:59:36 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 14:59:36 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 14:59:36 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 14:48:35 GMT, Daniel D. Daugherty wrote:
>> Roman Kennke has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 172 commits:
>>
>> - Merge branch 'master' into JDK-8291555-v2
>> - Disable new lightweight locking in Z
On Fri, 5 May 2023 14:53:32 GMT, Daniel D. Daugherty wrote:
>> src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 2562:
>>
>>> 2560: Register lock = op->lock_opr()->as_register();
>>> 2561: if (LockingMode == LM_MONITOR) {
>>> 2562: if (op->info() != null) {
>>
>> Hmmm... other pl
> 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
On Fri, 5 May 2023 14:40:52 GMT, Daniel D. Daugherty wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Relax zapped-entry test when calling thread is not owning thread
>
> src/hotspot/share/runtime/lockStack.cpp line
On Fri, 5 May 2023 13:38:58 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
On Fri, 5 May 2023 05:54:29 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
> 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
On Fri, 5 May 2023 09:56:44 GMT, Aleksey Shipilev wrote:
> Full `make images` for `macosx-aarch64-zero-fastdebug` requires #13827. After
> that, it survives the build with all two `LockingModes`, but not with
> LockingMode = LM_LIGHTWEIGHT:
This requires significantly more time to implement fo
On Fri, 5 May 2023 08:44:12 GMT, Aleksey Shipilev wrote:
> > ```
> > * zero builds are still failing in the Oracle CI; can you check out zero
> > builds on your end?
> > ```
>
> Can you tell which Zero builds exactly? GHA Zero sanity checks look fine.
>
> My local Zero builds are fine with `ma
On Thu, 4 May 2023 21:54:11 GMT, Roman Kennke wrote:
> * zero builds are still failing in the Oracle CI; can you check out zero
> builds on your end?
Can you tell which Zero builds exactly? GHA Zero sanity checks look fine.
My local Zero builds are fine with `make hotspot`:
macosx-aarch6
On Thu, 4 May 2023 22:11:56 GMT, Daniel D. Daugherty wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address @dcubed-ojdk review comments
>
> I have a Tier3 test failure:
> https://bugs.openjdk.org/browse/JDK-82915
On Fri, 5 May 2023 06:21:18 GMT, David Holmes wrote:
> Updates look good to me. Thanks.
Nice, thank you!
The PR has 4 approvals now. Are we good to go, or should I wait for others to
approve? (And if so, who?)
-
PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-15357
On Fri, 5 May 2023 05:54:29 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, 4 May 2023 22:11:56 GMT, Daniel D. Daugherty wrote:
> I have a Tier3 test failure:
> https://bugs.openjdk.org/browse/JDK-8291555?focusedCommentId=14579239&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579239
*sigh*
This looks relatively harmless, thoug
> 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
On Thu, 4 May 2023 21:10:14 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, 4 May 2023 21:46:02 GMT, Coleen Phillimore wrote:
> Do you have GHA configured?
Yes I do. Why?
(Btw, GHA does Zero builds too and they're looking ok.)
-
PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1535460100
On Thu, 4 May 2023 21:25:50 GMT, Daniel D. Daugherty wrote:
> I think we are nearing the finish line. A couple of things:
>
> - zero builds are still failing in the Oracle CI; can you check out zero
> builds on your end?
I've been wondering about those too. I just built zero 64 and 32 bit loca
On Thu, 4 May 2023 21:10:14 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, 4 May 2023 21:10:14 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, 4 May 2023 20:59:58 GMT, Roman Kennke wrote:
>> src/hotspot/share/runtime/lockStack.inline.hpp line 53:
>>
>>> 51: bool is_owning = &JavaThread::cast(thread)->lock_stack() == this;
>>> 52: assert(is_owning == (get_thread() == thread), "is_owning sanity");
>>> 53: return is_owning;
On Fri, 28 Apr 2023 19:01:41 GMT, Roman Kennke wrote:
>> This project is currently baselined on jdk-21+21-1701. However, that build-ID
>> contains very noisy test failures in Tier[234] and probably higher. If you
>> could
>> rebase on:
>>
>> jiefu: [452cb8 -
>> OpenJDK](https://orahub.oci.orac
> 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
On Thu, 4 May 2023 19:35:58 GMT, Daniel D. Daugherty wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address @dholmes-ora's review comments
>
> src/hotspot/share/runtime/lockStack.inline.hpp line 53:
>
>> 51: bo
On Thu, 4 May 2023 20:49:22 GMT, Roman Kennke wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 666:
>>
>>> 664: // Invariant: tmpReg == 0. tmpReg is EAX which is the implicit
>>> cmpxchg comparand.
>>> 665: lock();
>>> 666: cmpxchgptr(scrReg, Address(boxReg,
>>> OM_OFFSET_NO
On Thu, 4 May 2023 19:32:23 GMT, Daniel D. Daugherty wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address @dholmes-ora's review comments
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 666:
>
>> 664: /
On Wed, 3 May 2023 09:33:24 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, 28 Apr 2023 19:01:41 GMT, Roman Kennke wrote:
>> This project is currently baselined on jdk-21+21-1701. However, that build-ID
>> contains very noisy test failures in Tier[234] and probably higher. If you
>> could
>> rebase on:
>>
>> jiefu: [452cb8 -
>> OpenJDK](https://orahub.oci.orac
> 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
On Wed, 3 May 2023 03:12:00 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add missing new file
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 659:
>
>> 657: // Invariant: tmpReg == 0.
On Tue, 2 May 2023 18:38:11 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, 2 May 2023 18:38:11 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, 2 May 2023 18:38:11 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
> 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
> 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
On Wed, 26 Apr 2023 16:07:33 GMT, Daniel D. Daugherty
wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary comments
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line
On Wed, 12 Apr 2023 05:26:23 GMT, Stefan Karlsson wrote:
>> The old code is "racy but safe - it basically answers the question "what
>> thread held the lock at the time I was asking?" and if we get a stack-addr
>> as the owner at the time we ask, and that stack-address belongs to a given
>> th
On Fri, 28 Apr 2023 19:23:24 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, 28 Apr 2023 19:23:24 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
On Fri, 28 Apr 2023 16:48:12 GMT, Daniel D. Daugherty
wrote:
> http://bugs.openjdk.java.net/browse/JDK-8307103
Should be based on JDK-8307103 now. Thanks for all your testing!
-
PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1527972396
On Fri, 28 Apr 2023 11:32:54 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
On Fri, 28 Apr 2023 07:43:24 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, 26 Apr 2023 18:58:13 GMT, Roman Kennke wrote:
>>> @rkennke - I'm planning to do another crawl thru review next week.
>>
>> Thanks! That is greatly appeciated!
>
>> @rkennke - finished my second crawl thru review of 60/68 files changed. I
>> only skipped the RISC-V files since I know nad
On Wed, 26 Apr 2023 18:35:45 GMT, Thomas Stuefe wrote:
>> src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 649:
>>
>>> 647:
>>> 648: __ flush();
>>> 649: return AdapterHandlerLibrary::new_entry(fingerprint, i2c_entry,
>>> c2i_entry, c2i_unverified_entry);
>>
>> This change seems out of plac
On Fri, 28 Apr 2023 07:43:24 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
On Thu, 27 Apr 2023 07:52:23 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
On Wed, 26 Apr 2023 18:33:28 GMT, Roman Kennke wrote:
>> src/hotspot/share/logging/logTag.hpp line 80:
>>
>>> 78: LOG_TAG(exceptions) \
>>> 79: LOG_TAG(exit) \
>>> 80: LOG_TAG(fastlock2) \
>>
>> So why 'fastlock2'? Where's 'fastlock1'? Or 'fastlock'?
>
> It's currently only used in the ar
On Wed, 26 Apr 2023 11:00:33 GMT, Quan Anh Mai wrote:
>> How would I check if we are emitting code?
>>
>> I am not sure I understand. The check for ANONYMOUS is only relevant when we
>> observe an already-inflated monitor. I think this is the right place to put
>> it.
>
> The entry barrier doe
On Wed, 26 Apr 2023 18:29:36 GMT, Thomas Stuefe wrote:
>> src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803:
>>
>>> 1801: #ifdef ASSERT
>>> 1802: // Poison scratch regs
>>> 1803: POISON_REGS((~savemask), t1, t2, t3, 0x1001);
>>
>> Should this poison value be: 0x2002
>
> The poiso
On Mon, 24 Apr 2023 22:51:10 GMT, Daniel D. Daugherty
wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary comments
>
> src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803:
>
>> 1801: #ifdef ASSERT
On Mon, 24 Apr 2023 22:51:10 GMT, Daniel D. Daugherty
wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary comments
>
> src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803:
>
>> 1801: #ifdef ASSERT
On Mon, 24 Apr 2023 19:42:35 GMT, Roman Kennke wrote:
>> Hi there,
>> what is needed to bring this PR over the approval line?
>
>> @rkennke - I'm planning to do another crawl thru review next week.
>
> Thanks! That is greatly appeciated!
> @rkennke - finished my second crawl thru review of 60/6
On Mon, 24 Apr 2023 19:42:35 GMT, Roman Kennke wrote:
>> Hi there,
>> what is needed to bring this PR over the approval line?
>
>> @rkennke - I'm planning to do another crawl thru review next week.
>
> Thanks! That is greatly appeciated!
@rkennke - finished my second crawl thru review of 60/68
On Wed, 26 Apr 2023 10:43:48 GMT, Roman Kennke wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 701:
>>
>>> 699: // ZFlag == 0 count in slow path
>>> 700: jccb(Assembler::notZero, NO_COUNT); // jump if ZFlag == 0
>>> 701:
>>
>> `DONE_LABEL` is conditionally jumped into from a l
On Thu, 20 Apr 2023 11:15:47 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, 26 Apr 2023 13:16:26 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
On Wed, 26 Apr 2023 03:09:53 GMT, Quan Anh Mai wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary comments
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 691:
>
>> 689: jccb(Assembler::no
On Wed, 26 Apr 2023 10:52:29 GMT, Roman Kennke wrote:
>> This stub has 2 instructions, and it seems not really uncommon, is it worth
>> it to have a stub here?
>
> Ok I will change the value.
> Yes, this path is relatively uncommon (monitors are inflated only once, and
> not necessarily via ANO
On Wed, 26 Apr 2023 09:03:07 GMT, Quan Anh Mai wrote:
>> src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 81:
>>
>>> 79: // C2CodeStubList::emit() will throw an assertion and report the
>>> actual size that
>>> 80: // is needed.
>>> 81: return 33;
>>
>> This should be 36 with `ASSERT` and 2
On Wed, 26 Apr 2023 08:12:41 GMT, Quan Anh Mai wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary comments
>
> src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 81:
>
>> 79: // C2CodeStubList::emit()
On Thu, 20 Apr 2023 11:15:47 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, 20 Apr 2023 11:15:47 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, 17 Apr 2023 20:00:58 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 156 commits:
>>
>> - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2
>> - A few more LM_ pr
On Mon, 17 Apr 2023 20:00:58 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 156 commits:
>>
>> - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2
>> - A few more LM_ pr
> 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
On Thu, 6 Apr 2023 14:38:20 GMT, Daniel D. Daugherty wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> RISCV update
>
> src/hotspot/share/services/management.cpp line 1131:
>
>> 1129: if (maxDepth == 0) {
>> 1130:
On Mon, 17 Apr 2023 20:10: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
On Fri, 14 Apr 2023 11:19:32 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
> 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
> 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
1 - 100 of 368 matches
Mail list logo
