> This is the implementation task for `JEP 490: ZGC: Remove the
> Non-Generational Mode`. See the JEP for details.
> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
Axel Boldt-Christmas has updated the pull request incrementally with six
additional commits since the last
This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational
Mode`. See the JEP for details.
[JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
-
Commit messages:
- Remove XCollectedHeap from HSDB
- Fix typo in TestZUncommitEvent.java
- Add missing probl
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
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
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:
>
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>> -
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
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-
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
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
>> -
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
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
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:
>
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
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));
>>
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
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
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
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
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
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
>> -
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
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
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
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
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
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
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
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
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
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:
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.
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
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
> 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:
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
76 matches
Mail list logo