Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-18 Thread Roman Kennke
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >>

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread Roman Kennke
On Tue, 16 Jul 2024 12:37:43 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> -

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread Roman Kennke
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >>

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v6]

2024-07-12 Thread Roman Kennke
On Fri, 12 Jul 2024 15:56:59 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/share/runtime/synchronizer.cpp line 390: &

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v3]

2024-07-12 Thread Roman Kennke
On Tue, 9 Jul 2024 20:43:06 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Add JVMCI symbol exports >> - Revert "More graceful JVMCI VM option interaction" >> >>This

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v6]

2024-07-12 Thread Roman Kennke
On Fri, 12 Jul 2024 05:57:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >>

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v6]

2024-07-12 Thread Roman Kennke
On Fri, 12 Jul 2024 05:57:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >>

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v6]

2024-07-12 Thread Roman Kennke
On Fri, 12 Jul 2024 05:57:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >>

Re: RFR: 8329655: Cleanup KlassObj and klassOop names after the PermGen removal [v2]

2024-04-04 Thread Roman Kennke
On Thu, 4 Apr 2024 12:18:24 GMT, Stefan Karlsson wrote: >> We have a few places that uses the terms `KlassObj` and `klassOop` when >> referring to Klasses. This is old code from before the PermGen removal, when >> Klasses also were Java objects. >> >> These names tripped me up when I was

Re: RFR: 8329655: Cleanup KlassObj and klassOop names after the PermGen removal [v2]

2024-04-04 Thread Roman Kennke
On Thu, 4 Apr 2024 12:08:23 GMT, Stefan Karlsson wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1202: >> >>> 1200: ldrw(scan_temp, Address(recv_klass, Klass::vtable_length_offset())); >>> 1201: >>> 1202: // %%% Could store the aligned, prescaled offset in the klassoop.

Re: RFR: 8329655: Cleanup KlassObj and klassOop names after the PermGen removal

2024-04-04 Thread Roman Kennke
On Thu, 4 Apr 2024 09:45:58 GMT, Stefan Karlsson wrote: > We have a few places that uses the terms `KlassObj` and `klassOop` when > referring to Klasses. This is old code from before the PermGen removal, when > Klasses also were Java objects. > > These names tripped me up when I was reading

Integrated: 8318895: Deoptimization results in incorrect lightweight locking stack

2023-11-10 Thread Roman Kennke
On Wed, 8 Nov 2023 19:00:53 GMT, Roman Kennke wrote: > See JBS issue for details. > > I basically: > - took the test-modification and turned it into its own test-case > - added test runners for lightweight- and legacy-locking, so that we keep > testing both, no matter w

Re: RFR: 8318895: Deoptimization results in incorrect lightweight locking stack [v3]

2023-11-10 Thread Roman Kennke
On Fri, 10 Nov 2023 10:41:16 GMT, Roman Kennke wrote: >> See JBS issue for details. >> >> I basically: >> - took the test-modification and turned it into its own test-case >> - added test runners for lightweight- and legacy-locking, so that we keep &

Re: RFR: 8318895: Deoptimization results in incorrect lightweight locking stack [v3]

2023-11-10 Thread Roman Kennke
oned in the JBS issue) with the modification to only > inflate when exec_mode == Unpack_none, as explained by Richard. > > Testing: > - [x] EATests.java > - [x] tier1 > - [ ] tier2 Roman Kennke has updated the pull request incrementally with one additional commit since the last r

Re: RFR: 8318895: Deoptimization results in incorrect lightweight locking stack [v2]

2023-11-09 Thread Roman Kennke
oned in the JBS issue) with the modification to only > inflate when exec_mode == Unpack_none, as explained by Richard. > > Testing: > - [x] EATests.java > - [x] tier1 > - [ ] tier2 Roman Kennke has updated the pull request incrementally with one additional commit since the last

RFR: 8318895: Deoptimization results in incorrect lightweight locking stack

2023-11-08 Thread Roman Kennke
See JBS issue for details. I basically: - took the test-modification and turned it into its own test-case - added test runners for lightweight- and legacy-locking, so that we keep testing both, no matter what is the default - added Axels fix (mentioned in the JBS issue) with the modification

Re: RFR: 8319376: ParallelGC: Forwarded objects found during heap inspection [v6]

2023-11-08 Thread Roman Kennke
On Tue, 7 Nov 2023 18:12:45 GMT, Roman Kennke wrote: >> See JBS issue for details. >> >> Testing: >> - [x] gc/logging/TestUnifiedLoggingSwitchStress.java -XX:+UseParallelGC >> - [x] tier1 -XX:+UseParallelGC >> - [x] tier2 -XX:+UseParallelGC >> - [

Integrated: 8319376: ParallelGC: Forwarded objects found during heap inspection

2023-11-08 Thread Roman Kennke
On Fri, 3 Nov 2023 12:42:46 GMT, Roman Kennke wrote: > See JBS issue for details. > > Testing: > - [x] gc/logging/TestUnifiedLoggingSwitchStress.java -XX:+UseParallelGC > - [x] tier1 -XX:+UseParallelGC > - [x] tier2 -XX:+UseParallelGC > - [x] hotspot_gc This pull

Re: RFR: 8319376: ParallelGC: Forwarded objects found during heap inspection [v6]

2023-11-07 Thread Roman Kennke
> See JBS issue for details. > > Testing: > - [x] gc/logging/TestUnifiedLoggingSwitchStress.java -XX:+UseParallelGC > - [x] tier1 -XX:+UseParallelGC > - [ ] tier2 -XX:+UseParallelGC > - [ ] hotspot_gc Roman Kennke has updated the pull request incrementally with one add

Re: RFR: 8319376: ParallelGC: Forwarded objects found during heap inspection [v5]

2023-11-07 Thread Roman Kennke
> See JBS issue for details. > > Testing: > - [x] gc/logging/TestUnifiedLoggingSwitchStress.java -XX:+UseParallelGC > - [x] tier1 -XX:+UseParallelGC > - [ ] tier2 -XX:+UseParallelGC > - [ ] hotspot_gc Roman Kennke has updated the pull request incrementally with one add

Re: RFR: 8319376: ParallelGC: Forwarded objects found during heap inspection [v4]

2023-11-07 Thread Roman Kennke
> See JBS issue for details. > > Testing: > - [x] gc/logging/TestUnifiedLoggingSwitchStress.java -XX:+UseParallelGC > - [x] tier1 -XX:+UseParallelGC > - [ ] tier2 -XX:+UseParallelGC > - [ ] hotspot_gc Roman Kennke has updated the pull request incrementally with one add

Re: RFR: 8319376: ParallelGC: Forwarded objects found during heap inspection [v3]

2023-11-07 Thread Roman Kennke
On Tue, 7 Nov 2023 10:02:04 GMT, Albert Mingkun Yang wrote: > > Would the failed-promotion slide directly into full-GC which repairs it? > > No, promotion-fail objects are specially handled, as documented in > `PSPromotionManager::oop_promotion_failed`. Other successfully forwarded > objects

Re: RFR: 8319376: ParallelGC: Forwarded objects found during heap inspection [v3]

2023-11-06 Thread Roman Kennke
On Mon, 6 Nov 2023 18:15:00 GMT, Roman Kennke wrote: >> See JBS issue for details. >> >> Testing: >> - [x] gc/logging/TestUnifiedLoggingSwitchStress.java -XX:+UseParallelGC >> - [x] tier1 -XX:+UseParallelGC >> - [ ] tier2 -XX:+UseParallelGC >> - [

Re: RFR: 8319376: ParallelGC: Forwarded objects found during heap inspection [v3]

2023-11-06 Thread Roman Kennke
> See JBS issue for details. > > Testing: > - [x] gc/logging/TestUnifiedLoggingSwitchStress.java -XX:+UseParallelGC > - [x] tier1 -XX:+UseParallelGC > - [ ] tier2 -XX:+UseParallelGC > - [ ] hotspot_gc Roman Kennke has updated the pull request incrementally with one add

Re: RFR: 8319376: ParallelGC: Forwarded objects found during heap inspection [v2]

2023-11-06 Thread Roman Kennke
> See JBS issue for details. > > Testing: > - [x] gc/logging/TestUnifiedLoggingSwitchStress.java -XX:+UseParallelGC > - [x] tier1 -XX:+UseParallelGC > - [ ] tier2 -XX:+UseParallelGC > - [ ] hotspot_gc Roman Kennke has updated the pull request incrementally with one add

Re: RFR: 8319376: ParallelGC: Forwarded objects found during heap inspection

2023-11-06 Thread Roman Kennke
On Fri, 3 Nov 2023 12:42:46 GMT, Roman Kennke wrote: > See JBS issue for details. > > Testing: > - [x] gc/logging/TestUnifiedLoggingSwitchStress.java -XX:+UseParallelGC > - [x] tier1 -XX:+UseParallelGC > - [ ] tier2 -XX:+UseParallelGC > - [ ] hotspo

RFR: 8319376: Parallel: Forwarded objects during heap inspection

2023-11-03 Thread Roman Kennke
See JBS issue for details. Testing: - [x] gc/logging/TestUnifiedLoggingSwitchStress.java -XX:+UseParallelGC - [ ] tier1 -XX:+UseParallelGC - [ ] tier2 -XX:+UseParallelGC - [ ] hotspot_gc - Commit messages: - 8319376: Parallel: Forwarded objects during heap inspection Changes:

Re: RFR: 8315880: change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT

2023-10-05 Thread Roman Kennke
On Thu, 5 Oct 2023 10:09:33 GMT, Julian Waters wrote: > I think this may have broken JDK-8288293  > > Is there any compiler specific implementation involved with the new > lightweight locking? Just a quick question, I can figure out the rest on my > own Not that I am aware of. AFAIK, it

Re: RFR: 8309599: WeakHandle and OopHandle release should clear obj pointer

2023-09-29 Thread Roman Kennke
On Fri, 29 Sep 2023 02:56:07 GMT, David Holmes wrote: > > > Hmmm okay - it seems fragile to have a psuedo-destructor in release(). > > > > > > I don't know what this comment means. > > Object lifetimes should be well managed such that you can't use an object > after it has been "destroyed".

Integrated: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

2023-09-29 Thread Roman Kennke
On Mon, 25 Sep 2023 16:16:51 GMT, Roman Kennke wrote: > The SA can run concurrently with Java threads, SA code that inspects locking > state should be able to deal with that. On the other hand, the particular > code is only used in printing routine and is not expected to be prec

Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock" [v3]

2023-09-29 Thread Roman Kennke
On Thu, 28 Sep 2023 09:11:12 GMT, Roman Kennke wrote: >> The SA can run concurrently with Java threads, SA code that inspects locking >> state should be able to deal with that. On the other hand, the particular >> code is only used in printing routine and is not expe

Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock" [v3]

2023-09-28 Thread Roman Kennke
one, because Java threads may > already have moved on. Instead of crashing with a stacktrace, we should > gracefully return null here. > > Testing: > - [x] sun/tools/jhsdb/JStackStressTest.java > - [x] sun/tools/jhsdb > - [x] serviceability/sa Roman Kennke has updat

Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock" [v2]

2023-09-27 Thread Roman Kennke
one, because Java threads may > already have moved on. Instead of crashing with a stacktrace, we should > gracefully return null here. > > Testing: > - [x] sun/tools/jhsdb/JStackStressTest.java > - [x] sun/tools/jhsdb > - [x] serviceability/sa Roman Kennke has updat

Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

2023-09-27 Thread Roman Kennke
On Wed, 27 Sep 2023 15:42:51 GMT, Chris Plummer wrote: >> I think you are right @plummercj - I'm adding details to the JBS issue. > > I think given this, issuing a warning is the appropriate thing to do. The > warning might want to mention that the failure is likely because we are in > the

Re: RFR: 8309599: WeakHandle and OopHandle release should clear obj pointer

2023-09-26 Thread Roman Kennke
On Tue, 26 Sep 2023 12:47:42 GMT, Coleen Phillimore wrote: > This change makes WeakHandle and OopHandle release null out the obj pointer, > at the cost of making the release function non-const and some changes that > propagated from that. This enables ObjectMonitor code to test for null to >

Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

2023-09-25 Thread Roman Kennke
On Tue, 26 Sep 2023 05:03:13 GMT, Chris Plummer wrote: >> @rkennke the "snapshot" is atomic - the target VM is suspended. > > Atomicity means guaranteeing that a 2 or more operations are executed as if > they are single operation from the viewpoint of other threads. There's no > such concept

Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

2023-09-25 Thread Roman Kennke
On Tue, 26 Sep 2023 03:07:14 GMT, Chris Plummer wrote: >> And I shouldn't have said "cache". I was confusing this PR with another >> dealing with the Monitor Cache. > > ...although that is a pretty small window and we are seeing this bug quite a > lot. Seems if the code in question was the

Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

2023-09-25 Thread Roman Kennke
On Mon, 25 Sep 2023 19:18:38 GMT, Chris Plummer wrote: >> Yes. But unless we run this at a safepoint, there is no consistent state >> when we race with locking. I don't think we want to spam users with warnings >> whenever we run into anonymous owners (which is not too infrequent). >>

Re: RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

2023-09-25 Thread Roman Kennke
On Mon, 25 Sep 2023 17:44:56 GMT, Chris Plummer wrote: >> The SA can run concurrently with Java threads, SA code that inspects locking >> state should be able to deal with that. On the other hand, the particular >> code is only used in printing routine and is not expected to be precise. >>

RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

2023-09-25 Thread Roman Kennke
The SA can run concurrently with Java threads, SA code that inspects locking state should be able to deal with that. On the other hand, the particular code is only used in printing routine and is not expected to be precise. When resolving an anonymous owner, we may not find one, because Java

Re: RFR: 8315880: change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT

2023-09-22 Thread Roman Kennke
On Mon, 18 Sep 2023 20:47:13 GMT, Daniel D. Daugherty wrote: > Change the default of LockingMode to LM_LIGHTWEIGHT from LM_LEGACY. > > This fix has been tested with 3 Mach5 Tier[1-8] runs and a 4th is in process. BTW: would that mess with JVMCI/Graal? AFAIK, Graal does not implement support

Re: RFR: 8315880: change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT

2023-09-18 Thread Roman Kennke
On Mon, 18 Sep 2023 20:47:13 GMT, Daniel D. Daugherty wrote: > Change the default of LockingMode to LM_LIGHTWEIGHT from LM_LEGACY. > > This fix has been tested with 3 Mach5 Tier[1-8] runs and a 4th is in process. Looks good to me, thank you! - Marked as reviewed by rkennke

Re: RFR: JDK-8311870: Split CompressedKlassPointers from compressedOops.hpp

2023-07-12 Thread Roman Kennke
On Tue, 11 Jul 2023 11:20:19 GMT, Thomas Stuefe wrote: > In preparation for some Lilliput-related changes, I'd like to get some purely > mechanical code moves out of the way. It would also improve separation of > concerns and reduces include header bloat. > > In particular, this patch does: >

Re: RFR: 8305895: Implementation: JEP 450: Compact Object Headers (Experimental)

2023-05-12 Thread Roman Kennke
On Fri, 12 May 2023 18:03:13 GMT, Coleen Phillimore wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All >> changes in this PR are protected by this flag. >> - The

RFR: 8305895: Implementation: JEP 450: Compact Object Headers (Experimental)

2023-05-12 Thread Roman Kennke
This is the main body of the JEP 450: Compact Object Headers (Experimental). Main changes: - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. - The compressed Klass* can now be stored in the mark-word of objects. In order to

Integrated: 8291555: Implement alternative fast-locking scheme

2023-05-08 Thread Roman Kennke
On Fri, 28 Oct 2022 20:17:37 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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v78]

2023-05-08 Thread Roman Kennke
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 avo

Re: RFR: 8291555: Implement alternative fast-locking scheme [v70]

2023-05-08 Thread Roman Kennke
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 lo

Re: RFR: 8291555: Implement alternative fast-locking scheme [v78]

2023-05-08 Thread Roman Kennke
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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v78]

2023-05-05 Thread Roman Kennke
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)

Re: RFR: 8291555: Implement alternative fast-locking scheme [v77]

2023-05-05 Thread Roman Kennke
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 avo

Re: RFR: 8291555: Implement alternative fast-locking scheme [v78]

2023-05-05 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > FinagleC

Re: RFR: 8291555: Implement alternative fast-locking scheme [v75]

2023-05-05 Thread Roman Kennke
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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v77]

2023-05-05 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Finagl

Re: RFR: 8291555: Implement alternative fast-locking scheme [v73]

2023-05-05 Thread Roman Kennke
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/hotsp

Re: RFR: 8291555: Implement alternative fast-locking scheme [v76]

2023-05-05 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Finagle

Re: RFR: 8291555: Implement alternative fast-locking scheme [v75]

2023-05-05 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Finagl

Re: RFR: 8291555: Implement alternative fast-locking scheme [v74]

2023-05-05 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% >

Re: RFR: 8291555: Implement alternative fast-locking scheme [v73]

2023-05-05 Thread Roman Kennke
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:

Re: RFR: 8291555: Implement alternative fast-locking scheme [v72]

2023-05-04 Thread Roman Kennke
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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579239 *sigh* This looks relatively harmless, though.

Re: RFR: 8291555: Implement alternative fast-locking scheme [v73]

2023-05-04 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > FinagleCh

Re: RFR: 8291555: Implement alternative fast-locking scheme [v72]

2023-05-04 Thread Roman Kennke
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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v72]

2023-05-04 Thread Roman Kennke
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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v66]

2023-05-04 Thread Roman Kennke
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: >> >>

Re: RFR: 8291555: Implement alternative fast-locking scheme [v72]

2023-05-04 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% &

Re: RFR: 8291555: Implement alternative fast-locking scheme [v71]

2023-05-04 Thread Roman Kennke
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/lockStac

Re: RFR: 8291555: Implement alternative fast-locking scheme [v71]

2023-05-04 Thread Roman Kennke
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(); >&

Re: RFR: 8291555: Implement alternative fast-locking scheme [v71]

2023-05-04 Thread Roman Kennke
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_MacroAssembl

Re: RFR: 8291555: Implement alternative fast-locking scheme [v71]

2023-05-03 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% >

Re: RFR: 8291555: Implement alternative fast-locking scheme [v70]

2023-05-03 Thread Roman Kennke
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: > &g

Re: RFR: 8291555: Implement alternative fast-locking scheme [v70]

2023-05-02 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Finagle

Re: RFR: 8291555: Implement alternative fast-locking scheme [v69]

2023-05-02 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > FinagleC

Re: RFR: 8291555: Implement alternative fast-locking scheme [v68]

2023-05-02 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Finagle

Re: RFR: 8291555: Implement alternative fast-locking scheme [v67]

2023-04-28 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Finagle

Re: RFR: 8291555: Implement alternative fast-locking scheme [v66]

2023-04-28 Thread Roman Kennke
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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v66]

2023-04-28 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Finagl

Re: RFR: 8291555: Implement alternative fast-locking scheme [v65]

2023-04-28 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Finag

Re: RFR: 8291555: Implement alternative fast-locking scheme [v64]

2023-04-27 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > FinagleC

Re: RFR: 8291555: Implement alternative fast-locking scheme [v62]

2023-04-26 Thread Roman Kennke
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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v60]

2023-04-26 Thread Roman Kennke
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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v63]

2023-04-26 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > FinagleCh

Re: RFR: 8291555: Implement alternative fast-locking scheme [v62]

2023-04-26 Thread Roman Kennke
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 69

Re: RFR: 8291555: Implement alternative fast-locking scheme [v62]

2023-04-26 Thread Roman Kennke
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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v60]

2023-04-24 Thread Roman Kennke
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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v62]

2023-04-20 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > FinagleCh

Re: RFR: 8291555: Implement alternative fast-locking scheme [v61]

2023-04-17 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97

Re: RFR: 8291555: Implement alternative fast-locking scheme [v60]

2023-04-17 Thread Roman Kennke
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 avo

Re: RFR: 8291555: Implement alternative fast-locking scheme [v60]

2023-04-14 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Fi

Re: RFR: 8291555: Implement alternative fast-locking scheme [v59]

2023-04-13 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% &g

Re: RFR: 8291555: Implement alternative fast-locking scheme [v58]

2023-04-12 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Fina

Re: RFR: 8291555: Implement alternative fast-locking scheme [v57]

2023-04-12 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > FinagleC

Re: RFR: 8291555: Implement alternative fast-locking scheme [v56]

2023-04-11 Thread Roman Kennke
On Tue, 11 Apr 2023 19:35:36 GMT, Dean Long wrote: >> Given that the race with new lightweight locking is virtually the same as >> the race >> with legacy stack locking, please do not put back the 'LockingMode == 2' >> check >> which would make `jmm_GetThreadInfo()` calls slower with new

Re: RFR: 8291555: Implement alternative fast-locking scheme [v56]

2023-04-11 Thread Roman Kennke
On Tue, 11 Apr 2023 12:15:07 GMT, Stefan Karlsson wrote: >> The NativeAccess is a left-over from an earlier attempt, and yes I think the >> start_processing() is the actual barrier. There is a single call-path where >> we inspect another thread's lock-stack outside of a safepoint (from >>

Re: RFR: 8291555: Implement alternative fast-locking scheme [v56]

2023-04-11 Thread Roman Kennke
On Tue, 11 Apr 2023 11:36:10 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional >> commit since the last revision: >> >> RISCV update > > src/hotspot/share/runtime/lockStack.inline.hpp line 111: >

Re: RFR: 8291555: Implement alternative fast-locking scheme [v55]

2023-04-06 Thread Roman Kennke
On Thu, 6 Apr 2023 07:27:27 GMT, Fei Yang wrote: > Some update for riscv to reflect the latest changes: > [riscv-update.txt](https://github.com/openjdk/jdk/files/11167462/riscv-update.txt) Thank you! The patch did apply with fuzz - I pushed it as it is, can you check if it's still ok? Thanks,

Re: RFR: 8291555: Implement alternative fast-locking scheme [v56]

2023-04-06 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > Finag

Re: RFR: 8291555: Implement alternative fast-locking scheme [v55]

2023-04-05 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > FinagleCh

Re: RFR: 8291555: Implement alternative fast-locking scheme [v54]

2023-04-05 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > FinagleCh

Re: RFR: 8291555: Implement alternative fast-locking scheme [v52]

2023-04-04 Thread Roman Kennke
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().eq

Re: RFR: 8291555: Implement alternative fast-locking scheme [v53]

2023-04-04 Thread Roman Kennke
3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% |   | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% |   | 1088.182 | 1092.266 | > -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% |   | 12017.964 | 11902.559 | > 0.97% > FinagleC

  1   2   3   >