RFR: 8310187: Improve Generational ZGC jtreg testing

2023-06-16 Thread Axel Boldt-Christmas
The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. So they get missed in Github Actions and for developers running jtreg loc

Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]

2023-06-16 Thread Axel Boldt-Christmas
a different > max heap size for ZGenerational, but it is not the intent to dispatch the > test to both G1 and generational ZGC if Generational ZGC is not specified. > > `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed > to not filter but instead disp

Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]

2023-06-18 Thread Axel Boldt-Christmas
a different > max heap size for ZGenerational, but it is not the intent to dispatch the > test to both G1 and generational ZGC if Generational ZGC is not specified. > > `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed > to not filter but instead disp

Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]

2023-06-19 Thread Axel Boldt-Christmas
On Sat, 17 Jun 2023 13:24:24 GMT, Alan Bateman wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix wrong ZGenerational flag in VectorRebracket128Test.java > > test/jdk/j

Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]

2023-06-19 Thread Axel Boldt-Christmas
On Fri, 16 Jun 2023 20:31:28 GMT, Daniel D. Daugherty wrote: > Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you > might want to fix the PR description. What part are you worried about? When would `vm.gc.ZSingelgen` be invalid? Also what part of the PR requires fix

Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]

2023-06-20 Thread Axel Boldt-Christmas
On Mon, 19 Jun 2023 09:04:17 GMT, Thomas Stuefe wrote: > How much time do we spend now in GHAs on the additional Zgenerational tests? > In any case, this makes sense. This adds around 40 more tests per platform. The runtime of GHA seems to have a lot of run to run variance. Most new tests are

Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]

2023-06-20 Thread Axel Boldt-Christmas
On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas wrote: >> The current implementation for testing generational ZGC with jtreg is >> implemented with a filter on the mode flag `ZGenerational`. Because of this >> only environments which set this flag explicitly will run

Integrated: 8310187: Improve Generational ZGC jtreg testing

2023-06-20 Thread Axel Boldt-Christmas
On Fri, 16 Jun 2023 09:14:10 GMT, Axel Boldt-Christmas wrote: > The current implementation for testing generational ZGC with jtreg is > implemented with a filter on the mode flag `ZGenerational`. Because of this > only environments which set this flag explicitly will run most of

[jdk21] RFR: 8310187: Improve Generational ZGC jtreg testing

2023-06-20 Thread Axel Boldt-Christmas
Hi all, This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023

[jdk21] Integrated: 8310187: Improve Generational ZGC jtreg testing

2023-06-22 Thread Axel Boldt-Christmas
On Tue, 20 Jun 2023 11:17:40 GMT, Axel Boldt-Christmas wrote: > Hi all, > > This pull request contains a backport of commit > [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repos

RFR: 8332495: java/util/logging/LoggingDeadlock2.java fails with AssertionError: Some tests failed

2024-05-19 Thread Axel Boldt-Christmas
Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option. - Commit messages: - 8332495: java/util/logging/LoggingDeadlock2.java fails with AssertionError: Some tests fail

RFR: 8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing from stderr

2024-05-19 Thread Axel Boldt-Christmas
Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring deprecated warnings. Testing non-generational ZGC requires the use of a deprecated option. - Commit messages: - 8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing

Re: RFR: 8332495: java/util/logging/LoggingDeadlock2.java fails with AssertionError: Some tests failed [v2]

2024-05-20 Thread Axel Boldt-Christmas
> Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by ignoring > deprecated warnings. Testing non-generational ZGC requires the use of a > deprecated option. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]

2024-05-20 Thread Axel Boldt-Christmas
> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring > deprecated warnings. Testing non-generational ZGC requires the use of a > deprecated option. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]

2024-05-20 Thread Axel Boldt-Christmas
On Mon, 20 May 2024 10:11:26 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update copyright year > > test/lib/jdk/test/lib/process/OutputAna

Re: RFR: 8332495: java/util/logging/LoggingDeadlock2.java fails with AssertionError: Some tests failed [v2]

2024-05-20 Thread Axel Boldt-Christmas
On Mon, 20 May 2024 07:25:12 GMT, Axel Boldt-Christmas wrote: >> Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by >> ignoring deprecated warnings. Testing non-generational ZGC requires the use >> of a deprecated option. > > Axel Boldt-Christmas has

Integrated: 8332495: java/util/logging/LoggingDeadlock2.java fails with AssertionError: Some tests failed

2024-05-20 Thread Axel Boldt-Christmas
On Mon, 20 May 2024 06:42:19 GMT, Axel Boldt-Christmas wrote: > Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by ignoring > deprecated warnings. Testing non-generational ZGC requires the use of a > deprecated option. This pull request has now been integrated.

Re: RFR: 8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]

2024-05-20 Thread Axel Boldt-Christmas
On Mon, 20 May 2024 07:27:19 GMT, Axel Boldt-Christmas wrote: >> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring >> deprecated warnings. Testing non-generational ZGC requires the use of a >> deprecated option. > > Axel Boldt-Christmas has

Integrated: 8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing from stderr

2024-05-20 Thread Axel Boldt-Christmas
On Mon, 20 May 2024 06:41:45 GMT, Axel Boldt-Christmas wrote: > Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring > deprecated warnings. Testing non-generational ZGC requires the use of a > deprecated option. This pull request has now been integrated. Changeset:

Re: Integrated: 8318964: Fix build failures caused by 8315097

2023-10-27 Thread Axel Boldt-Christmas
On Fri, 27 Oct 2023 09:48:00 GMT, Leo Korinth wrote: > Update method name after huge renaming conflict Marked as reviewed by aboldtch (Reviewer). Trivial fix. - PR Review: https://git.openjdk.org/jdk/pull/16395#pullrequestreview-1701406738 PR Comment: https://git.openjdk.org/jdk/p

RFR: 8315884: New Object to ObjectMonitor mapping

2024-07-08 Thread Axel Boldt-Christmas
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 looser semantics to use this displaced data. In Lilliput this data also contai

Re: RFR: 8315884: New Object to ObjectMonitor mapping

2024-07-08 Thread Axel Boldt-Christmas
On Mon, 8 Jul 2024 09:39:32 GMT, Thomas Wuerthinger wrote: > Is this change expected to require JVMCI and/or Graal JIT changes? Support for `UseObjectMonitorTable` would require changes to Graal JIT. (`UseObjectMonitorTable` is off by default). Minimal support would be to call into the VM for

Re: RFR: 8315884: New Object to ObjectMonitor mapping

2024-07-08 Thread Axel Boldt-Christmas
On Mon, 8 Jul 2024 10:58:29 GMT, Thomas Wuerthinger wrote: > OK. Will there be a CSR or JEP for this? There is no plan for this, nor should it be required. It’s an internal implementation. > When do you approximately expect this to land in main line? ASAP. Compatibility for the field name i

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

2024-07-08 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-07-08 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-07-10 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-07-10 Thread Axel Boldt-Christmas
On Tue, 9 Jul 2024 20:44:58 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 op

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

2024-07-10 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-07-11 Thread Axel Boldt-Christmas
On Thu, 11 Jul 2024 09:25:52 GMT, Yudi Zheng wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with four >> additional commits since the last revision: >> >> - Add extra comments in LightweightSynchronizer::inflate_fast_locked_object >> -

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

2024-07-11 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-07-12 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-07-12 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 09:32:44 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/cpu/aarch64/c2_MacroAssembler_aarch64.cp

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

2024-07-12 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 09:53:11 GMT, Roman Kennke wrote: > When you say 'This patch has been evaluated to be performance neutral when > UseObjectMonitorTable is turned off (the default).' - what does the > performance look like with +UOMT? How does it compare to -UOMT? Most benchmarks are unaffec

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

2024-07-12 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-07-12 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 12:06:05 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: >> >>> 341: const Register t3_owner = t3; >>> 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0 >>> : checked_cast(markWord::monitor_value)); >>

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

2024-07-14 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-07-14 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 11:09:35 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/oops/instanceKlass.cpp line 1090: >

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

2024-08-12 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 13:20:27 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 77: >> >>> 75: using ConcurrentTable = ConcurrentHashTable>> MEMFLAGS::mtObjectMonitor>; >>> 76: >>> 77: ConcurrentTable* _table; >> >> So you have a class ObjectMonitor

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

2024-08-12 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-12 Thread Axel Boldt-Christmas
On Wed, 17 Jul 2024 06:48:03 GMT, David Holmes 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 [v6]

2024-08-12 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 16:44:06 GMT, Coleen Phillimore wrote: >> I wanted to avoid having to add `NoSafepointVerifier` implementation details >> in the synchroniser code. I guess `ContinuationWrapper` already does this. >> >> Simply creating a `NoSafepointVerifier` when you expect no safepoint is

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

2024-08-12 Thread Axel Boldt-Christmas
On Mon, 15 Jul 2024 00:45:25 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 477: >> >>> 475: if (obj->mark_acquire().has_monitor()) { >>> 476: if (_length > 0 && _contended_oops[_length-

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

2024-08-12 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 16 Jul 2024 12:36:08 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 [v12]

2024-08-13 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-13 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 15:32:45 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/lightweightSynchronizer

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

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 20:21:05 GMT, Coleen Phillimore wrote: >> Only legacy locking uses the displaced header, I believe, which isn't clear >> in this code at all. This seems like a fix. We should probably assert that >> only legacy locking uses this field as a displaced header. > > Update: yes

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

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 13:19:02 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 62: >> >>> 60: class ObjectMonitorWorld : public CHeapObj { >>> 61: struct Config { >>> 62: using Value = ObjectMonitor*; >> >> Does this alias really help? We don't st

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

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 16:36:18 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 102: >> >>> 100: assert(*value != nullptr, "must be"); >>> 101: return (*value)->object_is_cleared(); >>> 102: } >> >> The `is_dead` functions seem oddly plac

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

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 14:27:34 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 105: >> >>> 103: }; >>> 104: >>> 105: class LookupMonitor : public StackObj { >> >> I'm not understanding why we need this little wrapper class. > > It's a two way looku

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

2024-08-13 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-13 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-13 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-13 Thread Axel Boldt-Christmas
On Mon, 12 Aug 2024 18:55:41 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Missing DEBUG_ONLY > > src/hotspot/share/runtime/lightweightSynchr

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

2024-08-13 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-13 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-13 Thread Axel Boldt-Christmas
On Mon, 12 Aug 2024 22:40:06 GMT, Daniel D. Daugherty wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Missing DEBUG_ONLY > > src/hotspot/share/interpreter/zero/bytecodeInter

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

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 13 Aug 2024 16:34:17 GMT, Daniel D. Daugherty wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Remove the last OMWorld references >> - Rename omworldtable_wor

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

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 13 Aug 2024 17:05:38 GMT, Daniel D. Daugherty wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Remove the last OMWorld references >> - Rename omworldtable_wor

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

2024-08-14 Thread Axel Boldt-Christmas
On Tue, 13 Aug 2024 18:13:30 GMT, Daniel D. Daugherty wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Remove the last OMWorld references >> - Rename omworldtable_wor

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

2024-08-14 Thread Axel Boldt-Christmas
On Tue, 13 Aug 2024 21:05:29 GMT, Daniel D. Daugherty wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Remove the last OMWorld references >> - Rename omworldtable_wor

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

2024-08-14 Thread Axel Boldt-Christmas
On Tue, 13 Aug 2024 21:45:57 GMT, Daniel D. Daugherty wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Whitespace and nits > > src/hotspot/share/runtime/synchron

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

2024-08-14 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-14 Thread Axel Boldt-Christmas
On Wed, 14 Aug 2024 05:45:27 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Whitespace and nits > > src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp l

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

2024-08-14 Thread Axel Boldt-Christmas
On Tue, 13 Aug 2024 16:03:16 GMT, Roman Kennke wrote: >> I tried the following (see diff below) and it shows about a 5-10% regression >> in most the `LockUnlock.testInflated*` micros. Also tried with just >> `num_unrolled = 1` saw the same regression. Maybe there was some other >> pattern you

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

2024-08-14 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-14 Thread Axel Boldt-Christmas
On Tue, 13 Aug 2024 21:56:29 GMT, Daniel D. Daugherty wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Whitespace and nits > > src/hotspot/share/runtime/vframe.cpp lin

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

2024-08-14 Thread Axel Boldt-Christmas
On Wed, 14 Aug 2024 20:58:24 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 341: >> >>> 339: >>> 340: ObjectMonitor* >>> LightweightSynchronizer::get_or_insert_monitor_from_table(oop object, >>> JavaThread* current, bool* inserted) { >>> 341:

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

2024-08-14 Thread Axel Boldt-Christmas
owing section as a comment in > the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to > avoid inflating by spinning

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

2024-08-14 Thread Axel Boldt-Christmas
On Wed, 14 Aug 2024 21:02:47 GMT, Daniel D. Daugherty wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Use jdk.test.lib.Utils.getRandomInstance() > > src/hotspot/share/run

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

2024-08-15 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 10:12:32 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update arguments.cpp > > Is there a plan to get rid of the UseObjectMonitorTab

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

2024-08-15 Thread Axel Boldt-Christmas
On Thu, 15 Aug 2024 13:45:11 GMT, Yudi Zheng wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove newline > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 677: >

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

2024-08-15 Thread Axel Boldt-Christmas
On Thu, 15 Aug 2024 06:12:22 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 n

Integrated: 8315884: New Object to ObjectMonitor mapping

2024-08-15 Thread Axel Boldt-Christmas
On Mon, 8 Jul 2024 08:18:42 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