Re: Integrated: 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all
On Wed, 25 Sep 2024 17:11:23 GMT, Chen Liang wrote: >> A trivial fix to ProblemList 4 java/nio/channels/DatagramChannel tests on >> macosx-all. > > These failures happen extremely often on macosx indeed. @liach, @AlanBateman, @jddarcy and @dfuch - Thanks for the lightning fast reviews! - PR Comment: https://git.openjdk.org/jdk/pull/21188#issuecomment-2374701024
Integrated: 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all
On Wed, 25 Sep 2024 17:07:57 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList 4 java/nio/channels/DatagramChannel tests on > macosx-all. This pull request has now been integrated. Changeset: 1b2d40ad Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/1b2d40addfc5e32229418d29ae90fb440720479e Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all Reviewed-by: liach, alanb, darcy, dfuchs - PR: https://git.openjdk.org/jdk/pull/21188
Integrated: 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all
A trivial fix to ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all. - Commit messages: - 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all Changes: https://git.openjdk.org/jdk/pull/21188/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21188&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340956 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21188/head:pull/21188 PR: https://git.openjdk.org/jdk/pull/21188
Re: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
On Tue, 13 Aug 2024 17:24:19 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_work to object_monitor_table_work
>
> 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: assert(LockingMode == LM_LIGHTWEIGHT, "must be");
>
> Do you want to assert: `inserted != nullptr`?
What was the resolution? I don't see a reply or a change here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1717543005
Re: RFR: 8315884: New Object to ObjectMonitor mapping [v19]
On Wed, 14 Aug 2024 09:24:34 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 >> looser semantics to use this displaced data. In Lilliput this data also >> contains the klass forcing this to be something that the GC has to take into >> account everywhere. >> >> This patch introduces an alternative solution where locking only uses the >> lock bits of the `markWord` and inflation does not override and displace the >> `markWord`. This is done by keeping associations between objects and >> `ObjectMonitor*` in an external hash table. Different caching techniques are >> used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is >> only supported in combination with the LM_LIGHTWEIGHT locking mode (the >> default). >> >> This patch has been evaluated to be performance neutral when >> `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` >> and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a >> `ObjectMonitorContentionMark` witness object has been introduced to the >> signatures. Which signals that the contentions reference counter is being >> held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact >> more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to >> create a more understandable and enforceable API. There are a handful of >> invariants / assumptions which are not always explicitly asserted which >> could be trivially abstracted and verified by the type system by using >> similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following 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 a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one > additional commit since the last revision: > > Use jdk.test.lib.Utils.getRandomInstance() Just a couple of comments this time. I originally reviewed v10 and this time I reviewed v10..v18. src/hotspot/share/runtime/synchronizer.hpp line 126: > 124: > 125: static bool quick_notify(oopDesc* obj, JavaThread* current, bool All); > 126: Why add the extra blank line? - Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2239178344 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1717549253
Re: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
On Wed, 14 Aug 2024 09:35:10 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/vframe.cpp line 252:
>>
>>> 250: if (mark.has_monitor()) {
>>> 251: ObjectMonitor* mon =
>>> ObjectSynchronizer::read_monitor(current, monitor->owner(), mark);
>>> 252: if (// if the monitor is null we must be in the process of
>>> locking
>>
>> nit - please add a space after `(`
>
> Should I align the rest of the lines? Adding the extra space here looks
> strange to me. But the inlined comments looks strange as well. This is all
> pre-existing code that just moved around a bit.
I'm just not fond of a `// comment` butting right against code.
Your call on whether to leave it alone or how to reformat it.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1717114224
Re: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
On Tue, 13 Aug 2024 16:30:12 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
>> looser semantics to use this displaced data. In Lilliput this data also
>> contains the klass forcing this to be something that the GC has to take into
>> account everywhere.
>>
>> This patch introduces an alternative solution where locking only uses the
>> lock bits of the `markWord` and inflation does not override and displace the
>> `markWord`. This is done by keeping associations between objects and
>> `ObjectMonitor*` in an external hash table. Different caching techniques are
>> used to speedup lookups from compiled code.
>>
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is
>> only supported in combination with the LM_LIGHTWEIGHT locking mode (the
>> default).
>>
>> This patch has been evaluated to be performance neutral when
>> `UseObjectMonitorTable` is turned off (the default).
>>
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT`
>> and `UseObjectMonitorTable` works.
>>
>> # Cleanups
>>
>> Cleaned up displaced header usage for:
>> * BasicLock
>> * Contains some Zero changes
>> * Renames one exported JVMCI field
>> * ObjectMonitor
>> * Updates comments and tests consistencies
>>
>> # Refactoring
>>
>> `ObjectMonitor::enter` has been refactored an a
>> `ObjectMonitorContentionMark` witness object has been introduced to the
>> signatures. Which signals that the contentions reference counter is being
>> held. More details are given below in the section about deflation.
>>
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact
>> more seamlessly with the `ObjectMonitor::enter` code.
>>
>> _There is even more `ObjectMonitor` refactoring which can be done here to
>> create a more understandable and enforceable API. There are a handful of
>> invariants / assumptions which are not always explicitly asserted which
>> could be trivially abstracted and verified by the type system by using
>> similar witness objects._
>>
>> # LightweightSynchronizer
>>
>> Working on adapting and incorporating the following 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 a bit.
>>
>> If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Whitespace and nits
Just for clarity, I think this is the one real bug that I found:
src/hotspot/share/runtime/lightweightSynchronizer.cpp line 126:
> 124:
> 125: static void dec_items_count() {
> 126: Atomic::inc(&_items_count);
Shouldn't this be `Atomic::dec`?
-
PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2287237680
Re: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
On Tue, 13 Aug 2024 16:49:42 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_work to object_monitor_table_work
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 86:
>
>> 84: uintx get_hash() const {
>> 85: uintx hash = _obj->mark().hash();
>> 86: assert(hash != 0, "should have a hash");
>
> Hmmm... I can remember seeing hash values of zero in some
> of my older legacy inflation stress runs. Is a hash value of zero
> not a thing with lightweight locking?
Update: My memory was wrong. When zero is encountered as a
hash value, it is replaced with `0xBAD`.
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 414:
>
>> 412:
>> 413: intptr_t hash = obj->mark().hash();
>> 414: assert(hash != 0, "must be set when claiming the object monitor");
>
> Hmmm... I can remember seeing hash values of zero in some
> of my older legacy inflation stress runs. Is a hash value of zero
> not a thing with lightweight locking?
Update: My memory was wrong. When zero is encountered as a
hash value, it is replaced with `0xBAD`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715952007
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715952460
Re: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
On Tue, 13 Aug 2024 16:30:12 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
>> looser semantics to use this displaced data. In Lilliput this data also
>> contains the klass forcing this to be something that the GC has to take into
>> account everywhere.
>>
>> This patch introduces an alternative solution where locking only uses the
>> lock bits of the `markWord` and inflation does not override and displace the
>> `markWord`. This is done by keeping associations between objects and
>> `ObjectMonitor*` in an external hash table. Different caching techniques are
>> used to speedup lookups from compiled code.
>>
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is
>> only supported in combination with the LM_LIGHTWEIGHT locking mode (the
>> default).
>>
>> This patch has been evaluated to be performance neutral when
>> `UseObjectMonitorTable` is turned off (the default).
>>
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT`
>> and `UseObjectMonitorTable` works.
>>
>> # Cleanups
>>
>> Cleaned up displaced header usage for:
>> * BasicLock
>> * Contains some Zero changes
>> * Renames one exported JVMCI field
>> * ObjectMonitor
>> * Updates comments and tests consistencies
>>
>> # Refactoring
>>
>> `ObjectMonitor::enter` has been refactored an a
>> `ObjectMonitorContentionMark` witness object has been introduced to the
>> signatures. Which signals that the contentions reference counter is being
>> held. More details are given below in the section about deflation.
>>
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact
>> more seamlessly with the `ObjectMonitor::enter` code.
>>
>> _There is even more `ObjectMonitor` refactoring which can be done here to
>> create a more understandable and enforceable API. There are a handful of
>> invariants / assumptions which are not always explicitly asserted which
>> could be trivially abstracted and verified by the type system by using
>> similar witness objects._
>>
>> # LightweightSynchronizer
>>
>> Working on adapting and incorporating the following 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 a bit.
>>
>> If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Whitespace and nits
I finished my first pass crawl thru on these changes. I need to mull
on these changes a bit before I make another pass. I think there's
only one real bug buried in all of my comments.
src/hotspot/share/runtime/objectMonitor.cpp line 377:
> 375:
> 376: if (cur == current) {
> 377: // TODO-FIXME: check for integer overflow! BUGID 6557169.
Thanks for removing this comment. JDK-6557169 was closed as
"Will Not FIx" in 2017.
src/hotspot/share/runtime/synchronizer.cpp line 970:
> 968: if (value == 0) value = 0xBAD;
> 969: assert(value != markWord::no_hash, "invariant");
> 970: return value;
In the elided part above this line, we have:
if (value == 0) value = 0xBAD;
assert(value != markWord::no_hash, "invariant");
so my memory about zero being returnable as a hash value is wrong.
src/hotspot/share/runtime/synchronizer.cpp line 977:
> 975:
> 976: markWord mark = obj->mark_acquire();
> 977: for(;;) {
nit - please insert space before `(`
src/hotspot/share/runtime/synchronizer.cpp line 997:
> 995: // Since the monitor isn't in the object header, it can simply be
> installed.
> 996: if (UseObjectMonitorTable) {
> 997: return install_hash_code(current, obj);
Perhaps:
if (UseObjectMonitorTable) {
// Since the monitor isn't in the object header, the hash can simply be
// installed in the object header.
return install_hash_code(current, obj);
src/hotspot/share/runtime/synchronizer.cpp line 1271:
> 1269: _no_progress_cnt >= NoAsyncDeflationProgressMax) {
> 1270: double remainder = (100.0 - MonitorUsedDeflationThreshold) / 100.0;
> 1271: size_t new_ceiling = ceiling / remainder + 1;
Why was the `new_ceiling` calculation changed?
I think the `new_ceiling` value is going to lower than the old ceiling value.
src/hotspot/share/runtime/synchronizer.inline.hpp line 83:
> 81:
> 82:
> 83: #endif // SHARE_RUNTIME_SYNCHRONIZER_INLINE_HPP
nit - please delete one of the blank lines.
src/hotspot/share/runtime/vframe.cpp line 252:
> 250: if (mark.has_monitor()) {
> 251: ObjectMonitor* mon =
> ObjectSynchronizer::read_monitor(current, mon
Re: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
On Tue, 13 Aug 2024 14:56:32 GMT, Coleen Phillimore 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_work to object_monitor_table_work
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 172:
>
>> 170: static void create() {
>> 171: _table = new ConcurrentTable(initial_log_size(),
>> 172: max_log_size(),
>
> nit, can you line up these parameters?
Or put them all on L171 if that doesn't make it too long...
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715648059
Re: RFR: 8315884: New Object to ObjectMonitor mapping [v6]
On Mon, 15 Jul 2024 00:45:10 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 401:
>>
>>> 399:
>>> 400: if (inserted) {
>>> 401: // Hopefully the performance counters are allocated on distinct
>>
>> It doesn't look like the counters are on distinct cache lines (see
>> objectMonitor.hpp, lines 212ff). If this is a concern, file a bug to
>> investigate it later? The comment here is a bit misplaced, IMO.
>
> It originates from
> https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/runtime/synchronizer.cpp#L1543
>
>
> I think we just kept it and did not think more about it.
>
> Not sure what it is referring to. Maybe @dcubed-ojdk knows more, they
> originated from him (9 years old comment).
I don't think we ever got around to experimenting with putting the perf counters
on distinct cache lines. We've always had bigger fish to fry.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715669185
Re: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
On Tue, 13 Aug 2024 14:52:03 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
>> looser semantics to use this displaced data. In Lilliput this data also
>> contains the klass forcing this to be something that the GC has to take into
>> account everywhere.
>>
>> This patch introduces an alternative solution where locking only uses the
>> lock bits of the `markWord` and inflation does not override and displace the
>> `markWord`. This is done by keeping associations between objects and
>> `ObjectMonitor*` in an external hash table. Different caching techniques are
>> used to speedup lookups from compiled code.
>>
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is
>> only supported in combination with the LM_LIGHTWEIGHT locking mode (the
>> default).
>>
>> This patch has been evaluated to be performance neutral when
>> `UseObjectMonitorTable` is turned off (the default).
>>
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT`
>> and `UseObjectMonitorTable` works.
>>
>> # Cleanups
>>
>> Cleaned up displaced header usage for:
>> * BasicLock
>> * Contains some Zero changes
>> * Renames one exported JVMCI field
>> * ObjectMonitor
>> * Updates comments and tests consistencies
>>
>> # Refactoring
>>
>> `ObjectMonitor::enter` has been refactored an a
>> `ObjectMonitorContentionMark` witness object has been introduced to the
>> signatures. Which signals that the contentions reference counter is being
>> held. More details are given below in the section about deflation.
>>
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact
>> more seamlessly with the `ObjectMonitor::enter` code.
>>
>> _There is even more `ObjectMonitor` refactoring which can be done here to
>> create a more understandable and enforceable API. There are a handful of
>> invariants / assumptions which are not always explicitly asserted which
>> could be trivially abstracted and verified by the type system by using
>> similar witness objects._
>>
>> # LightweightSynchronizer
>>
>> Working on adapting and incorporating the following 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 a bit.
>>
>> If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - Remove the last OMWorld references
> - Rename omworldtable_work to object_monitor_table_work
src/hotspot/share/runtime/basicLock.inline.hpp line 45:
> 43: return reinterpret_cast(get_metadata());
> 44: #else
> 45: // Other platforms does not make use of the cache yet,
nit typo: s/does not/do not/
src/hotspot/share/runtime/basicLock.inline.hpp line 54:
> 52: inline void BasicLock::clear_object_monitor_cache() {
> 53: assert(UseObjectMonitorTable, "must be");
> 54: set_metadata(0);
Should this be a literal `0` or should it be `nullptr`?
Update: The metadata field is of type `unintptr_t`. Got it.
src/hotspot/share/runtime/deoptimization.cpp line 1650:
> 1648: mon_info->lock()->set_bad_metadata_deopt();
> 1649: }
> 1650: #endif
I like this!
src/hotspot/share/runtime/globals.hpp line 1964:
> 1962:
> \
> 1963: product(int, LightweightFastLockingSpins, 13, DIAGNOSTIC,
> \
> 1964: "Specifies the number of time lightweight fast locking will "
> \
nit typo: s/number of time/number of times/
src/hotspot/share/runtime/lightweightSynchronizer.cpp line 34:
> 32: #include "oops/oop.inline.hpp"
> 33: #include "runtime/atomic.hpp"
> 34: #include "memory/allStatic.hpp"
nit: this include is out of order.
src/hotspot/share/runtime/lightweightSynchronizer.cpp line 43:
> 41: #include "runtime/mutexLocker.hpp"
> 42: #include "runtime/objectMonitor.hpp"
> 43: #include "runtime/objectMonitor.inline.hpp"
Shouldn't have both includes here.
src/hotspot/share/runtime/lightweightSynchronizer.cpp line 81:
> 79: oop _obj;
> 80:
> 81: public:
nit - please indent by one more space.
src/hotspot/share/runtime/lightweightSynchronizer.cpp line 86:
> 84: uintx get_hash() const {
> 85: uintx hash = _obj->mark().hash();
> 86: assert(hash != 0, "should have a hash");
Hmmm... I can remember seeing hash values of zero in some
of my older legacy inflation stress runs. Is a hash value of zero
not a thing with lightweight locking?
src/hotspot/share/runtime/lightweightSynchronizer.c
Re: RFR: 8315884: New Object to ObjectMonitor mapping [v11]
On Mon, 12 Aug 2024 15:58:14 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
>> looser semantics to use this displaced data. In Lilliput this data also
>> contains the klass forcing this to be something that the GC has to take into
>> account everywhere.
>>
>> This patch introduces an alternative solution where locking only uses the
>> lock bits of the `markWord` and inflation does not override and displace the
>> `markWord`. This is done by keeping associations between objects and
>> `ObjectMonitor*` in an external hash table. Different caching techniques are
>> used to speedup lookups from compiled code.
>>
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is
>> only supported in combination with the LM_LIGHTWEIGHT locking mode (the
>> default).
>>
>> This patch has been evaluated to be performance neutral when
>> `UseObjectMonitorTable` is turned off (the default).
>>
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT`
>> and `UseObjectMonitorTable` works.
>>
>> # Cleanups
>>
>> Cleaned up displaced header usage for:
>> * BasicLock
>> * Contains some Zero changes
>> * Renames one exported JVMCI field
>> * ObjectMonitor
>> * Updates comments and tests consistencies
>>
>> # Refactoring
>>
>> `ObjectMonitor::enter` has been refactored an a
>> `ObjectMonitorContentionMark` witness object has been introduced to the
>> signatures. Which signals that the contentions reference counter is being
>> held. More details are given below in the section about deflation.
>>
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact
>> more seamlessly with the `ObjectMonitor::enter` code.
>>
>> _There is even more `ObjectMonitor` refactoring which can be done here to
>> create a more understandable and enforceable API. There are a handful of
>> invariants / assumptions which are not always explicitly asserted which
>> could be trivially abstracted and verified by the type system by using
>> similar witness objects._
>>
>> # LightweightSynchronizer
>>
>> Working on adapting and incorporating the following 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 a bit.
>>
>> If 0b10 (Inflated) is observed or there is to...
>
> 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/bytecodeInterpreter.cpp line 632:
> 630: bool success = false;
> 631: if (LockingMode == LM_LEGACY) {
> 632:// Traditional lightweight locking.
The if-statement is for legacy locking so the comment about lightweight
locking seems wrong.
src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 736:
> 734: bool success = false;
> 735: if (LockingMode == LM_LEGACY) {
> 736: // traditional lightweight locking
The if-statement is for legacy locking so the comment about lightweight
locking seems wrong.
src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1671:
> 1669: bool success = false;
> 1670: if (LockingMode == LM_LEGACY) {
> 1671: // traditional lightweight locking
The if-statement is for legacy locking so the comment about lightweight
locking seems wrong.
src/hotspot/share/prims/jvmtiEnvBase.cpp line 1503:
> 1501:
> 1502: if (mon != nullptr) {
> 1503: assert(mon != nullptr, "must have monitor");
With the new if-statement on L1502, the assert is not needed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1714439929
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1714440641
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1714441506
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1714448544
Integrated: 8326062: ProblemList jcstress tests that are failing due to JDK-8325984
On Fri, 16 Feb 2024 15:54:27 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jcstress tests that are failing due to > JDK-8325984. This pull request has now been integrated. Changeset: 00b5c707 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/00b5c70750737855b29b125de6a0c806677c118c Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8326062: ProblemList jcstress tests that are failing due to JDK-8325984 Reviewed-by: azvegint, jvernee - PR: https://git.openjdk.org/jdk/pull/17890
Re: RFR: 8326062: ProblemList jcstress tests that are failing due to JDK-8325984
On Fri, 16 Feb 2024 15:56:41 GMT, Alexander Zvegintsev wrote: >> A trivial fix to ProblemList jcstress tests that are failing due to >> JDK-8325984. > > Marked as reviewed by azvegint (Reviewer). @azvegint - Thanks for the fast review! - PR Comment: https://git.openjdk.org/jdk/pull/17890#issuecomment-1948735042
RFR: 8326062: ProblemList jcstress tests that are failing due to JDK-8325984
A trivial fix to ProblemList jcstress tests that are failing due to JDK-8325984. - Commit messages: - 8326062: ProblemList jcstress tests that are failing due to JDK-8325984 Changes: https://git.openjdk.org/jdk/pull/17890/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17890&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326062 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17890.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17890/head:pull/17890 PR: https://git.openjdk.org/jdk/pull/17890
Re: Integrated: 8324786: validate-source fails after JDK-8042981
On Fri, 26 Jan 2024 21:52:37 GMT, Joe Darcy wrote: >> A trivial fix for validate-source. > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the lightning fast review! - PR Comment: https://git.openjdk.org/jdk/pull/17599#issuecomment-1912744650
Integrated: 8324786: validate-source fails after JDK-8042981
On Fri, 26 Jan 2024 21:51:04 GMT, Daniel D. Daugherty wrote: > A trivial fix for validate-source. This pull request has now been integrated. Changeset: 70f4a4e1 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/70f4a4e18e257110f45565ba0d708f1fa48aed76 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8324786: validate-source fails after JDK-8042981 Reviewed-by: darcy - PR: https://git.openjdk.org/jdk/pull/17599
Integrated: 8324786: validate-source fails after JDK-8042981
A trivial fix for validate-source. - Commit messages: - 8324786: validate-source fails after JDK-8042981 Changes: https://git.openjdk.org/jdk/pull/17599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17599&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324786 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17599.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17599/head:pull/17599 PR: https://git.openjdk.org/jdk/pull/17599
Integrated: 8324161: validate-source fails after JDK-8275338
On Thu, 18 Jan 2024 17:39:47 GMT, Daniel D. Daugherty wrote: > A trivial fix to the copyright line in > test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java. This pull request has now been integrated. Changeset: 5c874c19 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/5c874c19cb08e5c10204a7ad47fb3075f65633db Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8324161: validate-source fails after JDK-8275338 Reviewed-by: darcy - PR: https://git.openjdk.org/jdk/pull/17490
Re: Integrated: 8324161: validate-source fails after JDK-8275338
On Thu, 18 Jan 2024 17:41:04 GMT, Joe Darcy wrote: >> A trivial fix to the copyright line in >> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java. > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the lightning fast review! - PR Comment: https://git.openjdk.org/jdk/pull/17490#issuecomment-1898936525
Integrated: 8324161: validate-source fails after JDK-8275338
A trivial fix to the copyright line in test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java. - Commit messages: - 8324161: validate-source fails after JDK-8275338 Changes: https://git.openjdk.org/jdk/pull/17490/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17490&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324161 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17490/head:pull/17490 PR: https://git.openjdk.org/jdk/pull/17490
Re: [jdk22] RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file
On Thu, 18 Jan 2024 15:36:07 GMT, Albert Mingkun Yang wrote: >> A trivial fix to disable core file generation in >> java/foreign/critical/TestCriticalUpcall.java. > > Marked as reviewed by ayang (Reviewer). @albertnetymk - Thanks for the fast review! - PR Comment: https://git.openjdk.org/jdk22/pull/90#issuecomment-1898718533
[jdk22] Integrated: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file
On Thu, 18 Jan 2024 15:20:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to disable core file generation in > java/foreign/critical/TestCriticalUpcall.java. This pull request has now been integrated. Changeset: b1788944 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk22/commit/b17889442385752929f4cbf77f34a79678dc492a Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file Reviewed-by: ayang Backport-of: a22ae909bc53344afd9bb6b1f08ff06858c10820 - PR: https://git.openjdk.org/jdk22/pull/90
[jdk22] RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file
A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java. - Commit messages: - Backport a22ae909bc53344afd9bb6b1f08ff06858c10820 Changes: https://git.openjdk.org/jdk22/pull/90/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=90&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321938 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk22/pull/90.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/90/head:pull/90 PR: https://git.openjdk.org/jdk22/pull/90
Integrated: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file
On Thu, 18 Jan 2024 00:58:49 GMT, Daniel D. Daugherty wrote: > A trivial fix to disable core file generation in > java/foreign/critical/TestCriticalUpcall.java. This pull request has now been integrated. Changeset: a22ae909 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/a22ae909bc53344afd9bb6b1f08ff06858c10820 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file Reviewed-by: dholmes - PR: https://git.openjdk.org/jdk/pull/17476
Re: RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file [v2]
On Thu, 18 Jan 2024 07:47:54 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update copyright year. > > Good and trivial. > > Copyright year needs updating. > > Thanks @dholmes-ora - Thanks for the review. Copyright year updated. - PR Comment: https://git.openjdk.org/jdk/pull/17476#issuecomment-1898458868
Re: RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file [v2]
> A trivial fix to disable core file generation in > java/foreign/critical/TestCriticalUpcall.java. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Update copyright year. - Changes: - all: https://git.openjdk.org/jdk/pull/17476/files - new: https://git.openjdk.org/jdk/pull/17476/files/44ddcbb8..1982e5bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17476&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17476&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17476/head:pull/17476 PR: https://git.openjdk.org/jdk/pull/17476
RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file
A trivial fix to disable core file generation in java/foreign/critical/TestCriticalUpcall.java. - Commit messages: - 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file Changes: https://git.openjdk.org/jdk/pull/17476/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321938 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17476/head:pull/17476 PR: https://git.openjdk.org/jdk/pull/17476
Re: Integrated: 8322963: ProblemList java/io/BufferedInputStream/TransferTo.java
On Wed, 3 Jan 2024 17:14:42 GMT, Brian Burkhalter wrote: >> A trivial fix to ProblemList java/io/BufferedInputStream/TransferTo.java. > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the lightning fast review! - PR Comment: https://git.openjdk.org/jdk/pull/17249#issuecomment-1875706401
Integrated: 8322963: ProblemList java/io/BufferedInputStream/TransferTo.java
On Wed, 3 Jan 2024 17:13:02 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/io/BufferedInputStream/TransferTo.java. This pull request has now been integrated. Changeset: cc9ab5f1 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/cc9ab5f1976486f0a4a681e01b1a8ac36e7c6f29 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8322963: ProblemList java/io/BufferedInputStream/TransferTo.java Reviewed-by: bpb - PR: https://git.openjdk.org/jdk/pull/17249
Integrated: 8322963: ProblemList java/io/BufferedInputStream/TransferTo.java
A trivial fix to ProblemList java/io/BufferedInputStream/TransferTo.java. - Commit messages: - 8322963: ProblemList java/io/BufferedInputStream/TransferTo.java Changes: https://git.openjdk.org/jdk/pull/17249/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17249&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322963 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17249.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17249/head:pull/17249 PR: https://git.openjdk.org/jdk/pull/17249
Re: RFR: 8322868: java/io/BufferedInputStream/TransferToTrusted.java has bad copyright header
On Tue, 2 Jan 2024 20:27:29 GMT, Brian Burkhalter wrote: > Add missing comma after 2024. Thumbs up. This is a trivial fix. - Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17228#pullrequestreview-1800974980
Integrated: 8321127: ProblemList java/util/stream/GatherersTest.java
On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/stream/GatherersTest.java. This pull request has now been integrated. Changeset: c6a82783 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/c6a827836277f753652815ce6a6bedd426468b87 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8321127: ProblemList java/util/stream/GatherersTest.java Reviewed-by: shade, alanb - PR: https://git.openjdk.org/jdk/pull/16909
Re: Integrated: 8321127: ProblemList java/util/stream/GatherersTest.java
On Thu, 30 Nov 2023 16:12:04 GMT, Aleksey Shipilev wrote: >> A trivial fix to ProblemList java/util/stream/GatherersTest.java. > > All right! Hope it would be fixed soon. Trivial. @shipilev and @AlanBateman - Thanks for the fast reviews. - PR Comment: https://git.openjdk.org/jdk/pull/16909#issuecomment-1834087312
Integrated: 8321127: ProblemList java/util/stream/GatherersTest.java
A trivial fix to ProblemList java/util/stream/GatherersTest.java. - Commit messages: - 8321127: ProblemList java/util/stream/GatherersTest.java Changes: https://git.openjdk.org/jdk/pull/16909/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321127 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16909.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16909/head:pull/16909 PR: https://git.openjdk.org/jdk/pull/16909
Re: RFR: 8318776: Require supports_cx8 to always be true [v5]
On Wed, 22 Nov 2023 21:41:50 GMT, Aleksey Shipilev wrote: >> @shipilev - Do you have a particular legacy x86 in mind? > > My point is that it is such an easy thing to do: leave the "cx8" flag sensing > code in, and keep setting up `_supports_cx8` based on it for `!_LP64` paths. > This both provides more safety by failing cleanly on non-CX8 platform, and > gives other platforms some guidance: if you can check something is supported, > check it. I think we are generally trying to fail cleanly on unsupported > configs, if that is easy to achieve. > > But now that you nerd-sniped me into this... I think non-CX8 platforms would > probably predate Pentium. The oldest real machine my lab has is Z530, which > already has CX8. But it was easy to also go to my QEMU-driven build-test > server, ask for `i486` as platform there, and et voila, no `cx8` in CPU flags: > > > buildworker-debian12-32:~$ lscpu > Architecture:i486 > CPU op-mode(s):32-bit > Address sizes: 36 bits physical, 32 bits virtual > Byte Order:Little Endian > CPU(s): 4 > On-line CPU(s) list: 0-3 > Vendor ID: GenuineIntel > Model name:486 DX/4 > CPU family: 4 > Model: 8 > Thread(s) per core: 4 > Core(s) per socket: 1 > Socket(s): 1 > Stepping:0 > BogoMIPS:5699.99 > Flags: fpu vme pse apic ht cpuid tsc_known_freq x2apic > hypervisor cpuid_fault > > > And mainline JDK even starts there! (with interpreter, there are some asserts > firing in compiler code, having to do with odd instruction selection on some > paths): > > > $ jdk/bin/java -Xint -version > openjdk version "22-testing" 2024-03-19 > OpenJDK Runtime Environment (fastdebug build > 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121) > OpenJDK Server VM (fastdebug build > 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121, interpreted mode, > sharing) Nice spelunking... I was wondering if it was something that old. I wasn't trying to nerd-snipe... I was in the dev lab at Intel when Xenix on the i386 first came up and sent its "Hello World!" email... I left Intel for Sun in 1987 while i486 was still in development, but I still had periodic lunches with folks that worked on those teams. Life was simpler back then... - PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402748121
Re: RFR: 8318776: Require supports_cx8 to always be true [v5]
On Wed, 22 Nov 2023 08:48:09 GMT, Aleksey Shipilev wrote:
>> David Holmes has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains seven additional
>> commits since the last revision:
>>
>> - Merge with master and update Zero code accordingly
>> - Merge branch 'master' into 8318776-supports_cx8
>> - Remove unnecessary includes of vm_version.hpp.
>>Fix copyright years.
>> - Remove cx8 comment as no longer relevant (the spinlock is used regardless
>> of cx8)
>> - Remove suports_cx8() checks from gtest
>> - Remove test for VMSupportsCX8
>> - 8318776: Require supports_cx8 to always be true
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 819:
>
>> 817: }
>> 818:
>> 819: _supports_cx8 = supports_cmpxchg8();
>
> I think we should leave the runtime check here (under `ifndef`, like in
> ARM?). This covers the remaining case of running on legacy x86 without CX8
> implemented: the init guarantee would then fire and prevent any other
> surprises at runtime. Sure, it would be hard to come up with such a platform
> today, but it would be safer to refuse to run there right away on the
> off-chance someone actually has it :)
@shipilev - Do you have a particular legacy x86 in mind?
> src/hotspot/share/runtime/vm_version.cpp line 33:
>
>> 31: void VM_Version_init() {
>> 32: VM_Version::initialize();
>> 33: guarantee(VM_Version::supports_cx8(), "Support for 64-bit atomic
>> operations in required in this release");
>
> Typo: "in required in". Also, no need to mention "this release" at all?
> Suggestion for message: "JVM requires platform support for 64-bit atomic
> operations"
Or the simpler change:
s/in required/is required/
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402515036
PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402528045
Re: RFR: 8318776: Require supports_cx8 to always be true [v5]
On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes wrote: >> As discussed in JBS all platforms (some tweaks to Zero are in progress) >> actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip >> out the locked-based alternatives to using it and just add a guarantee that >> it is true at runtime. And all platforms except some ARM variants set >> `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: >> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not >> defined >> - Assertions for `supports_cx8()` are removed >> - Compiler predicates requiring `supports_cx8()` are removed >> - Access backend is greatly simplified without the need for lock-based >> alternative >> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the >> need for a lock-based alternative >> >> I did consider moving all the ARM `kuser_helper` related code to be only >> defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a >> theoretical risk this could change the behaviour if ARMv7 binaries were run >> on other ARM CPU's. I added a note to that effect in >> vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up >> further if desired. >> >> Testing: >> - All Oracle tiers 1-5 builds (which includes an ARMv7 build) >> - GHA builds/tests >> - Oracle tiers 1-3 sanity testing >> >> Zero changes coming in via >> [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged >> when they arrive. >> >> Thanks. > > David Holmes has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains seven additional > commits since the last revision: > > - Merge with master and update Zero code accordingly > - Merge branch 'master' into 8318776-supports_cx8 > - Remove unnecessary includes of vm_version.hpp. >Fix copyright years. > - Remove cx8 comment as no longer relevant (the spinlock is used regardless > of cx8) > - Remove suports_cx8() checks from gtest > - Remove test for VMSupportsCX8 > - 8318776: Require supports_cx8 to always be true Wow! This PR is much larger than I expected. Thumbs up! - Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16625#pullrequestreview-1745089631
Integrated: 8318038: ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms
On Thu, 12 Oct 2023 19:26:10 GMT, Daniel D. Daugherty wrote: > Trivial ProblemListing for some tests: > > [JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList > runtime/CompressedOops/CompressedClassPointers.java on two platforms > [JDK-8318040](https://bugs.openjdk.org/browse/JDK-8318040) ProblemList > vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java > on macosx-aarch64 > [JDK-8318042](https://bugs.openjdk.org/browse/JDK-8318042) ProblemList > java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC This pull request has now been integrated. Changeset: 0983b548 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/0983b54866d7118bb54c87fa3b2260c863376a92 Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod 8318038: ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms 8318040: ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java on macosx-aarch64 8318042: ProblemList java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC Reviewed-by: rriggs, azvegint - PR: https://git.openjdk.org/jdk/pull/16172
Re: RFR: 8318038: ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms
On Thu, 12 Oct 2023 19:54:17 GMT, Roger Riggs wrote: >> Trivial ProblemListing for some tests: >> >> [JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList >> runtime/CompressedOops/CompressedClassPointers.java on two platforms >> [JDK-8318040](https://bugs.openjdk.org/browse/JDK-8318040) ProblemList >> vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java >> on macosx-aarch64 >> [JDK-8318042](https://bugs.openjdk.org/browse/JDK-8318042) ProblemList >> java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs and @azvegint - Thanks for the fast reviews! - PR Comment: https://git.openjdk.org/jdk/pull/16172#issuecomment-1760285310
RFR: 8318038: ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms
Trivial ProblemListing for some tests: [JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms [JDK-8318040](https://bugs.openjdk.org/browse/JDK-8318040) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java on macosx-aarch64 [JDK-8318042](https://bugs.openjdk.org/browse/JDK-8318042) ProblemList java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC - Commit messages: - 8318042: ProblemList java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC - 8318040: ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java on macosx-aarch64 - 8318038: ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms Changes: https://git.openjdk.org/jdk/pull/16172/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16172&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318038 Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16172.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16172/head:pull/16172 PR: https://git.openjdk.org/jdk/pull/16172
Re: RFR: 8315869: UseHeavyMonitors not used [v2]
On Wed, 20 Sep 2023 18:00:40 GMT, Coleen Phillimore wrote: >> Please review this trivial change to remove the UseHeavyMonitors develop >> option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) >> option. Tested with tier1 locally. > > Coleen Phillimore has updated the pull request incrementally with one > additional commit since the last revision: > > Update option comment. Yes, I agree that this is a trivial fix. (Sorry I missed that earlier.) - PR Comment: https://git.openjdk.org/jdk/pull/15845#issuecomment-1728278222
Re: RFR: 8315869: UseHeavyMonitors not used [v2]
On Wed, 20 Sep 2023 18:00:40 GMT, Coleen Phillimore wrote: >> Please review this trivial change to remove the UseHeavyMonitors develop >> option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) >> option. Tested with tier1 locally. > > Coleen Phillimore has updated the pull request incrementally with one > additional commit since the last revision: > > Update option comment. Thumbs up. - Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15845#pullrequestreview-1636241551
Re: RFR: 8315869: UseHeavyMonitors not used
On Wed, 20 Sep 2023 17:36:06 GMT, Coleen Phillimore wrote: > Please review this trivial change to remove the UseHeavyMonitors develop > option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) > option. Tested with tier1 locally. Changes requested by dcubed (Reviewer). src/hotspot/share/runtime/globals.hpp line 1064: > 1062: develop(bool, VerifyHeavyMonitors, false, > \ > 1063: "Checks that no stack locking happens when using " > \ > 1064: "-XX:LockingMode=LM_MONITOR") > \ s/LM_MONITOR/0/ I don't think you can specify the `LM_MONITOR` value on the actual cmd line. - PR Review: https://git.openjdk.org/jdk/pull/15845#pullrequestreview-1636204262 PR Review Comment: https://git.openjdk.org/jdk/pull/15845#discussion_r1331988698
Re: RFR: 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" [v2]
On Fri, 8 Sep 2023 10:52:06 GMT, Maurizio Cimadamore wrote: >> This PR adds a privileged block surrounding the request to load the fallback >> linker library in LibFallback. >> The lack of this block is causing test failures when platforms using the >> fallback linker are tested using a security manager. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Fix library name @mcimadamore - are you planning to integrate this fix soon? This failure happens in every Tier5. - PR Comment: https://git.openjdk.org/jdk/pull/15633#issuecomment-1711922411
Re: [jdk21] Integrated: 8313208: ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms
On Wed, 26 Jul 2023 19:24:33 GMT, Joe Darcy wrote: >> A trivial fix to ProblemList java/util/concurrent/tck/JSR166TestCase.java on >> select platforms. > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the lightning fast review! - PR Comment: https://git.openjdk.org/jdk21/pull/145#issuecomment-1652365817
[jdk21] Integrated: 8313208: ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms
A trivial fix to ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms. - Commit messages: - 8313208: ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms Changes: https://git.openjdk.org/jdk21/pull/145/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=145&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313208 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk21/pull/145.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/145/head:pull/145 PR: https://git.openjdk.org/jdk21/pull/145
Re: [jdk21] RFR: 8313193: ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64
On Wed, 26 Jul 2023 15:47:48 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList > java/util/concurrent/SynchronousQueue/Fairness.java on X64. They are (so far), but the fix that Doug Lea integrated did not seem to be specific to ZGC or -Xcomp so I went wider... I'm hoping that Doug's fix gets backported to JDK21u. He integrated his fix for 8300663 with a much larger fix for another bug so I thought that the odds of that changeset being backported to JDK21 was low (especially since it is a P3). - PR Comment: https://git.openjdk.org/jdk21/pull/144#issuecomment-1652373120
[jdk21] Integrated: 8313208: ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms
On Wed, 26 Jul 2023 19:22:08 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/concurrent/tck/JSR166TestCase.java on > select platforms. This pull request has now been integrated. Changeset: a10dbcec Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk21/commit/a10dbcecdba59d0ddabec2d37e62b5fb82138dae Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8313208: ProblemList java/util/concurrent/tck/JSR166TestCase.java on select platforms Reviewed-by: darcy - PR: https://git.openjdk.org/jdk21/pull/145
[jdk21] Integrated: 8313193: ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64
On Wed, 26 Jul 2023 15:47:48 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList > java/util/concurrent/SynchronousQueue/Fairness.java on X64. This pull request has now been integrated. Changeset: f666e606 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk21/commit/f666e606810a0a32864c1dbd8ea493da7e980d8a Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8313193: ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64 Reviewed-by: rriggs - PR: https://git.openjdk.org/jdk21/pull/144
Re: [jdk21] RFR: 8313193: ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64
On Wed, 26 Jul 2023 16:44:56 GMT, Roger Riggs wrote: >> A trivial fix to ProblemList >> java/util/concurrent/SynchronousQueue/Fairness.java on X64. > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs - Thanks for the review! - PR Comment: https://git.openjdk.org/jdk21/pull/144#issuecomment-1652170819
[jdk21] RFR: 8313193: ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64
A trivial fix to ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64. - Commit messages: - 8313193: ProblemList java/util/concurrent/SynchronousQueue/Fairness.java on X64 Changes: https://git.openjdk.org/jdk21/pull/144/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=144&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313193 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk21/pull/144.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/144/head:pull/144 PR: https://git.openjdk.org/jdk21/pull/144
Re: RFR: 8311043: Remove trailing blank lines in source files
On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the > files are "dirty" to begin with. This fix will make more files "clean". I > also considered adding a check for this in jcheck for Skara, however it seems > jcheck code handling hunks does not track end-of-files. Thus I will only > clean the files. > > The fix removes trailing lines matching ^[[:space:]]*$ in > > - *.java > - *.cpp > - *.hpp > - *.c > - *.h > > I have applied the following bash script to each file: > > file="$1" > > while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do > truncate -s -1 "$file" > done > > `git diff --ignore-space-change --ignore-blank-lines master` displays no > changes > `git diff --ignore-blank-lines master` displays one change Ending the file with a blank line? I would not have expected that at all. I expect a single EOL at the end of the file; from a visual POV, the last line of non-blank text ends with an EOL. No more, no less. - PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1614806396
Re: Integrated: JDK-8310922: java/lang/Class/forName/ForNameNames.java fails after being added by JDK-8310242
On Mon, 26 Jun 2023 21:21:41 GMT, Mandy Chung wrote: > A trivial fix to correct the expected result to be `Inner[].class`. I > missed the rerun of the test to verify the last-minute edit to the test by > JDK-8310242. Thumbs up. This is a trivial fix. - PR Comment: https://git.openjdk.org/jdk/pull/14667#issuecomment-1608283430
[jdk21] Integrated: 8310822: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64
On Fri, 23 Jun 2023 19:30:56 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java > on generic-x64. This pull request has now been integrated. Changeset: af3a56e5 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk21/commit/af3a56e56901a1ec1e532c8f04c573cff77c5ed0 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8310822: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64 Reviewed-by: iris, lmesnik - PR: https://git.openjdk.org/jdk21/pull/60
Re: [jdk21] RFR: 8310822: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64
On Fri, 23 Jun 2023 19:44:50 GMT, Iris Clark wrote: >> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java >> on generic-x64. > > Marked as reviewed by iris (Reviewer). @irisclark and @lmesnik - Thanks for the fast reviews! - PR Comment: https://git.openjdk.org/jdk21/pull/60#issuecomment-1604810661
Re: [jdk21] RFR: 8310822: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64
On Fri, 23 Jun 2023 19:45:19 GMT, Leonid Mesnik wrote: >> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java >> on generic-x64. > > test/jdk/ProblemList-Xcomp.txt line 31: > >> 29: >> 30: java/lang/invoke/MethodHandles/CatchExceptionTest.java 8146623 >> generic-all >> 31: java/lang/ScopedValue/StressStackOverflow.java 8308609 generic-x64 > > java/lang/ScopedValue/StressStackOverflow.java#no-vmcontinuations ? Nope. This is the JDK21 version of the test and not the JDK22 version of the test. - PR Review Comment: https://git.openjdk.org/jdk21/pull/60#discussion_r1240258561
[jdk21] RFR: 8310822: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64
A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64. - Commit messages: - 8310822: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64 Changes: https://git.openjdk.org/jdk21/pull/60/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=60&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310822 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk21/pull/60.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/60/head:pull/60 PR: https://git.openjdk.org/jdk21/pull/60
Re: Integrated: 8310586: ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all
On Wed, 21 Jun 2023 21:05:11 GMT, Mikael Vidstedt wrote: >> A trivial fix to ProblemList >> java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads >> on linux-all > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for your review also. - PR Comment: https://git.openjdk.org/jdk/pull/14606#issuecomment-1601686797
Re: Integrated: 8310586: ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all
On Wed, 21 Jun 2023 21:02:58 GMT, David Holmes wrote: >> A trivial fix to ProblemList >> java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads >> on linux-all > > Marked as reviewed by dholmes (Reviewer). @dholmes-ora - Thanks for the lightning fast review! - PR Comment: https://git.openjdk.org/jdk/pull/14606#issuecomment-1601676432
Integrated: 8310586: ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all
On Wed, 21 Jun 2023 20:59:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList > java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads > on linux-all This pull request has now been integrated. Changeset: ac44ef19 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/ac44ef19d5a129c41a8e89e667a28cff38acdd42 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8310586: ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all Reviewed-by: dholmes, mikael - PR: https://git.openjdk.org/jdk/pull/14606
Integrated: 8310586: ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all
A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all - Commit messages: - 8310586: ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all Changes: https://git.openjdk.org/jdk/pull/14606/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14606&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310586 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14606.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14606/head:pull/14606 PR: https://git.openjdk.org/jdk/pull/14606
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries
On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou wrote: > 8307858: [REDO] JDK-8307194 Add make target for optionally building a > complete set of all JDK and hotspot libjvm static libraries GHA is failing on windows; is this related to this PR or something else? @erikj - You did a round of Mach5 testing on the JDK22 version of this fix. Do you have plans to redo that testing for the JDK21 backport? - PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595371284 PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595373061
Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
On Fri, 16 Jun 2023 11:41:14 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 the tests.
>> So they get missed in Github Actions and for developers running jtreg
>> locally without supplying the `ZGenerational` flag.
>>
>> The proposed change here is to introduce two new jtreg requirement
>> properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will
>> effectively behave the same as the existing `vm.gc.` flags but also take
>> the specific ZGC mode in account.
>>
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build
>> includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>>
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and
>> `vm.gc.ZSingelgen` will also be true.
>>
>> If `-XX:{+,-}ZGenerational` is supplied then either `vm.gc.ZGenerational`
>> or `vm.gc.ZSingelgen` be true depending on the flags value.
>>
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`
>> will be false.
>>
>> This change also splits the relevant tests into two distinct runs for the
>> two modes. And the respective test ids are set to `ZGenerational` or
>> `ZSinglegen` to make it easier to distinguish the runs.
>>
>> This also solves the issue that some compiler tests will never run with
>> generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the
>> current filter `vm.opt.final.ZGenerational` requires the flag to be
>> explicit, but these compiler tests uses `vm.flagless`.
>>
>> The introduction of `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes
>> the way you specify generational / single gen ZGC test with the way it is
>> done for other gcs with `vm.gc.`
>>
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag`
>> to enable checking if `ZGenerational` is default or not.
>>
>> `vm.opt.final.ZGenerational` is still kept because we still have some
>> reasons to filter based on the supplied flags.
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when
>> running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with 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 dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fix wrong ZGenerational flag in VectorRebracket128Test.java
Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you
might
want to fix the PR description.
-
PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1595274922
Re: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails with "-XX:-VMContinuations" [v6]
On Wed, 14 Jun 2023 16:54:55 GMT, Andrew Haley wrote: >> The implementation changes look good. >> >> The update to test looks okay too although I would like to see if we can do >> better in SVC and STS when there is a SO. In passing, I think all usages of >> tlr should be replaced with ThreadLocalRandom.current(). > >> The implementation changes look good. >> >> The update to test looks okay too although I would like to see if we can do >> better in SVC and STS when there is a SO. > > That would be nice, but it's something of a can of worms. > >> In passing, I think all usages of tlr should be replaced with >> ThreadLocalRandom.current(). > > OK. @theRealAph - So the GHA results for this PR show that serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03 failed. Why wasn't this addressed prior to integration? We saw 5 instances of this failure mode in every Mach5 Tier1 and 20 instances in every Mach5 Tier3 after this PR was integrated. This was not an intermittent failure. I've applied the fix that @AlanBateman proposed in [JDK-8310211](https://bugs.openjdk.org/browse/JDK-8310211) and that appears to have solved the issue for Mach5 Tier1. I'll have to wait for the fix to reach Mach5 Tier3 before I can declare that one is also good. - PR Comment: https://git.openjdk.org/jdk/pull/14399#issuecomment-1595049357
Integrated: 8310211: serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing
On Fri, 16 Jun 2023 17:10:08 GMT, Daniel D. Daugherty wrote: > A trivia fix for > serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java > failing. This pull request has now been integrated. Changeset: 16134f44 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/16134f44221e46f71d91fdba08e30705b0e1f92f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8310211: serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing Co-authored-by: Alan Bateman Reviewed-by: mikael - PR: https://git.openjdk.org/jdk/pull/14524
Re: Integrated: 8310211: serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing
On Fri, 16 Jun 2023 17:26:38 GMT, Mikael Vidstedt wrote: >> A trivia fix for >> serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java >> failing. > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the review! It appears that the bots are running very, very slow since my various pull request commands have not yet all been processed... It's not being a quiet Friday at all... - PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595015175
Re: Integrated: 8310211: serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing
On Fri, 16 Jun 2023 17:10:08 GMT, Daniel D. Daugherty wrote: > A trivia fix for > serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java > failing. This fix is being tested with an urgent Mach5 Tier1. macosx-aarch64-debug has passed the test when it failed before. linux-x64-debug has passed the test where it failed before... windows-x64-debug has passed the test where it failed before... linux-aarch64-debug has passed the test where it failed before... - PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595004554 PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595005744 PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595016095 PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595020596 PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595022380
Integrated: 8310211: serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing
A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing. - Commit messages: - 8310211: serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing Changes: https://git.openjdk.org/jdk/pull/14524/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14524&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310211 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14524/head:pull/14524 PR: https://git.openjdk.org/jdk/pull/14524
Integrated: 8309236: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again
On Wed, 31 May 2023 20:34:07 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java > with ZGC and Generational ZGC again This pull request has now been integrated. Changeset: e42a4b65 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/e42a4b659a78721567e4e882a26fe2972975bc80 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod 8309236: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again Reviewed-by: bpb, azvegint - PR: https://git.openjdk.org/jdk/pull/14253
Re: Integrated: 8309236: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again
On Wed, 31 May 2023 20:38:23 GMT, Brian Burkhalter wrote: >> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java >> with ZGC and Generational ZGC again > > Marked as reviewed by bpb (Reviewer). @bplb and @azvegint - Thanks for the fast reviews! - PR Comment: https://git.openjdk.org/jdk/pull/14253#issuecomment-1570917645
Integrated: 8309236: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again
A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again - Commit messages: - 8309236: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again Changes: https://git.openjdk.org/jdk/pull/14253/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14253&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309236 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14253.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14253/head:pull/14253 PR: https://git.openjdk.org/jdk/pull/14253
Integrated: 8309230: ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64
On Wed, 31 May 2023 16:40:54 GMT, Daniel D. Daugherty wrote: > A couple of trivial ProblemListings: > [JDK-8309230](https://bugs.openjdk.org/browse/JDK-8309230) ProblemList > jdk/incubator/vector/Float64VectorTests.java on aarch64 > [JDK-8309231](https://bugs.openjdk.org/browse/JDK-8309231) ProblemList > vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java This pull request has now been integrated. Changeset: 45473ef2 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/45473ef23520271954fa7196a5be588f88337aaf Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod 8309230: ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64 8309231: ProblemList vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java Reviewed-by: darcy - PR: https://git.openjdk.org/jdk/pull/14250
Integrated: 8309230: ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64
A couple of trivial ProblemListings: [JDK-8309230](https://bugs.openjdk.org/browse/JDK-8309230) ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64 [JDK-8309231](https://bugs.openjdk.org/browse/JDK-8309231) ProblemList vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java - Commit messages: - 8309231: ProblemList vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java - 8309230: ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64 Changes: https://git.openjdk.org/jdk/pull/14250/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14250&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309230 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14250.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14250/head:pull/14250 PR: https://git.openjdk.org/jdk/pull/14250
Re: Integrated: 8309230: ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64
On Wed, 31 May 2023 16:48:06 GMT, Joe Darcy wrote: >> A couple of trivial ProblemListings: >> [JDK-8309230](https://bugs.openjdk.org/browse/JDK-8309230) ProblemList >> jdk/incubator/vector/Float64VectorTests.java on aarch64 >> [JDK-8309231](https://bugs.openjdk.org/browse/JDK-8309231) ProblemList >> vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the fast review! - PR Comment: https://git.openjdk.org/jdk/pull/14250#issuecomment-1570578322
Integrated: 8307966: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java > on linux-x64. This pull request has now been integrated. Changeset: 9a7b4431 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/9a7b4431ecde03f37d9f1c1b06dab6ef8d60a94c Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8307966: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64 Reviewed-by: naoto, lmesnik - PR: https://git.openjdk.org/jdk/pull/13946
Re: RFR: 8307966: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java > on linux-x64. I've switched to using 'linux-all' instead of enumeration of the platforms. - PR Comment: https://git.openjdk.org/jdk/pull/13946#issuecomment-1544945743
Re: RFR: 8307966: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64 [v2]
> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java > on linux-x64. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: plummercj CR - use linux-all instead - Changes: - all: https://git.openjdk.org/jdk/pull/13946/files - new: https://git.openjdk.org/jdk/pull/13946/files/94bad01c..35501c98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13946&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13946&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13946/head:pull/13946 PR: https://git.openjdk.org/jdk/pull/13946
Re: RFR: 8307966: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
On Fri, 12 May 2023 00:15:25 GMT, Leonid Mesnik wrote: >> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java >> on linux-x64. > > Might be this failure is platform agnostic and should be generic all. We just > don't run this combination on macosx so often. ( @lmesnik - Thanks for the review. Folks, I'm only going with the sightings that I've seen. - PR Comment: https://git.openjdk.org/jdk/pull/13946#issuecomment-1544925144
Re: RFR: 8307966: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
On Fri, 12 May 2023 00:09:12 GMT, Chris Plummer wrote: >> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java >> on linux-x64. > > Maybe linux-all would be better. @plummercj - Thanks for the review. 'linux-all' would make it apply to linux versions that we don't have. I've only seen this issue on the three platforms that I'm targeting. @naotoj - Thanks for the review. - PR Comment: https://git.openjdk.org/jdk/pull/13946#issuecomment-1544921538
RFR: 8307966: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64. - Commit messages: - 8307966: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64 Changes: https://git.openjdk.org/jdk/pull/13946/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13946&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307966 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13946/head:pull/13946 PR: https://git.openjdk.org/jdk/pull/13946
Integrated: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
On Thu, 4 May 2023 20:49:26 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a few tests: > - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList > jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 > - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList > sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 > - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList > sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 This pull request has now been integrated. Changeset: 111858f3 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/111858f3ff86a15666537df515375fa04ffef048 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 8307490: ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 8307491: ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 Reviewed-by: darcy - PR: https://git.openjdk.org/jdk/pull/13816
Re: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
On Thu, 4 May 2023 21:21:38 GMT, Joe Darcy wrote: >> Trivial fixes to ProblemList a few tests: >> - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList >> jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 >> - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList >> sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 >> - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList >> sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the review! - PR Comment: https://git.openjdk.org/jdk/pull/13816#issuecomment-1535438955
RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
Trivial fixes to ProblemList a few tests: - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 - Commit messages: - get rid of extra blank line. - 8307491: ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 - 8307490: ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 - 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 Changes: https://git.openjdk.org/jdk/pull/13816/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13816&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307489 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13816.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13816/head:pull/13816 PR: https://git.openjdk.org/jdk/pull/13816
Re: RFR: 8306946: jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with "wrong number of lines in OutputAnalyzer output" [v3]
On Thu, 27 Apr 2023 16:35:59 GMT, Leonid Mesnik wrote: >> The ProcessTools.startProcess (...) has been updated to completely read >> streams after process has been completed. >> The test was updated to run 5 times with different number of lines and line >> sizes. > > Leonid Mesnik has updated the pull request incrementally with one additional > commit since the last revision: > > move buffers registration before pumping start point What Mach5 testing has been done with this fix? - PR Comment: https://git.openjdk.org/jdk/pull/13683#issuecomment-1526034233
Re: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time
On Tue, 25 Apr 2023 04:05:05 GMT, Leonid Mesnik wrote:
>> test/lib/jdk/test/lib/process/ProcessTools.java line 792:
>>
>>> 790: @Override
>>> 791: public InputStream getInputStream() {
>>> 792: return out;
>>
>> This is a little bit confusing that the `getInputStream()` returns `out`
>> stream.
>> Just wanted to double-check if it is intentional and was not needed for
>> `getOutputStream()` instead.
>
> Agree, it is confusing, even in standard j.l.Process API . The `InputStream
> java.lang.Process.getInputStream()`" returns **output** stream of started
> process. So for our implementation ProcessImpl the 'out' and 'err' mean
> output and error streams. However they are returned as InputStreams so users
> could read them.
Right. From the API caller's POV, it is asking for InputStreams that it can use
to read the process' stdout or stderr streams.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1176718448
Integrated: 8306780: ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp
On Mon, 24 Apr 2023 19:28:41 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in > Xcomp. This pull request has now been integrated. Changeset: 328e512d Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/328e512d12f6fd1d37cf1778ba68fa7b8ff1b8e3 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8306780: ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp Reviewed-by: darcy - PR: https://git.openjdk.org/jdk/pull/13627
Re: Integrated: 8306780: ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp
On Mon, 24 Apr 2023 19:34:01 GMT, Joe Darcy wrote: >> A trivial fix to ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in >> Xcomp. > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the fast review! - PR Comment: https://git.openjdk.org/jdk/pull/13627#issuecomment-1520719825
Integrated: 8306780: ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp
A trivial fix to ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp. - Commit messages: - 8306780: ProblemList java/lang/Thread/virtual/HoldsLock.java#id0 in Xcomp Changes: https://git.openjdk.org/jdk/pull/13627/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13627&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306780 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13627/head:pull/13627 PR: https://git.openjdk.org/jdk/pull/13627
Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
On Wed, 5 Apr 2023 21:12:14 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a couple of tests: > [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList > serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp > [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList > java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC This pull request has now been integrated. Changeset: b5d204c3 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/b5d204c3a4274c2e4604390eba436d42b5f5e9c9 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp 8305679: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC Reviewed-by: mikael - PR: https://git.openjdk.org/jdk/pull/13365
Re: Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
On Wed, 5 Apr 2023 21:18:28 GMT, Mikael Vidstedt wrote: >> Trivial fixes to ProblemList a couple of tests: >> [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList >> serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp >> [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList >> java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the fast review! - PR Comment: https://git.openjdk.org/jdk/pull/13365#issuecomment-1498180191
Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
Trivial fixes to ProblemList a couple of tests: [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC - Commit messages: - 8305679: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC - 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp Changes: https://git.openjdk.org/jdk/pull/13365/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13365&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305678 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13365/head:pull/13365 PR: https://git.openjdk.org/jdk/pull/13365
Re: Integrated: 8305602: ProblemList java/lang/invoke/lambda/LogGeneratedClassesTest.java
On Tue, 4 Apr 2023 18:58:12 GMT, Mandy Chung wrote: > This gives time to investigate JDK-8305600 and understand why the test didn't > fail on my testing before the push. Thumbs up. This is a trivial fix. - Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13334#pullrequestreview-1371612964
Re: RFR: JDK-8304163: Move jdk.internal.module.ModuleInfoWriter to the test library [v2]
On Sat, 18 Mar 2023 19:14:09 GMT, Mandy Chung wrote: >> `ModuleInfoWriter` is not used by the runtime. Move it to the test library >> as `jdk.test.lib.util.ModuleInfoWriter`. The tests are updated to use the >> test library instead. `ModuleInfoWriter` depends on `jdk.internal.module` >> types and the Classfile API. Hence `@modules >> java.base/jdk.internal.classfile` and other classfile subpackages are added. > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > move @library after @modules per the recommended ordering Sigh... And again we have the situation where some folks are adding `@build` directives and other folks are removing `@build` directives. Another recent PR removed library build directives: https://github.com/openjdk/jdk/pull/13030 and that made the related tests stop failing with NoClassDefFoundErrors. This mess is related to: [CODETOOLS-7902847](https://bugs.openjdk.org/browse/CODETOOLS-7902847) Class directory of a test case should not be used to compile a library and these problems show up when doing parallel execution of tests where more than one test uses the "offending" library. We really, really need @jonathan-gibbons to chime in on review threads like these. - PR Comment: https://git.openjdk.org/jdk/pull/13085#issuecomment-1476684779
Re: RFR: 8303133: Update ProcessTols.startProcess(...) to exit early if process exit before linePredicate is printed.
On Fri, 24 Feb 2023 22:15:18 GMT, Leonid Mesnik wrote: > The solution proposed by Stefan K > > The startProcess() might wait forever for the expected line if the process > exits (failed to start). It makes sense to just fail earlier in such cases. > > The fix also move > 'output = new OutputAnalyzer(this.process);' > in method xrun() to be able to try to print them in waitFor is > failed/interrupted. I fixed a typo in the bug's synopsis line so you'll need to update the PR's title. Use "/issue JDK-8303133" as the quickest way to set it. - PR: https://git.openjdk.org/jdk/pull/12751
Re: RFR: 8301306: java/net/httpclient/* fail with -Xcomp: java.io.IOException: HTTP/1.1 header parser received no bytes
On Mon, 30 Jan 2023 07:16:17 GMT, SUN Guoyun wrote: > Hi all, > I think `BackgroundCompilation` should not be set to false when `-Xcomp` be > used, which causes the java thread to block for longer, then causing the > following tests failed frequently on the AArch64 and LoongArch64 architecture. > > java/net/httpclient/ByteArrayPublishers.java （fastdebug -Xcomp） > java/net/httpclient/ManyRequestsLegacy.java （fastdebug -Xcomp） > java/net/httpclient/HttpClientLocalAddrTest.java （fastdebug -Xcomp） > jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java > （fastdebug -Xcomp） > java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java （release > -Xcomp） > > This PR delete BackgroundCompilation be setted, Above tests can be passed. > Please help review it. > > Thanks. This is not the right fix for this kind of problem. src/hotspot/share/runtime/arguments.cpp line 1440: > 1438: case _comp: > 1439: UseInterpreter = false; > 1440: BackgroundCompilation= false; Disabling `BackgroundCompilation` when -Xcomp is specified is not the right answer here. When `-Xcomp` is specified, `-Xbatch` needs to be turned off and I believe that's what old L1440 is doing. - Changes requested by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/12282
[jdk20] Integrated: 8300141: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
On Fri, 13 Jan 2023 21:25:54 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList some tests: > [JDK-8300141](https://bugs.openjdk.org/browse/JDK-8300141) ProblemList > java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC > [JDK-8300144](https://bugs.openjdk.org/browse/JDK-8300144) ProblemList > vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC > [JDK-8300147](https://bugs.openjdk.org/browse/JDK-8300147) ProblemList > vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java > in Xcomp This pull request has now been integrated. Changeset: bc498f87 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk20/commit/bc498f87f7037c37ad9c2a101fee5e39ae6bfda1 Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod 8300141: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC 8300144: ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC 8300147: ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp Reviewed-by: mikael - PR: https://git.openjdk.org/jdk20/pull/103
Re: [jdk20] Integrated: 8300141: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
On Fri, 13 Jan 2023 22:43:09 GMT, Mikael Vidstedt wrote: >> Trivial fixes to ProblemList some tests: >> [JDK-8300141](https://bugs.openjdk.org/browse/JDK-8300141) ProblemList >> java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC >> [JDK-8300144](https://bugs.openjdk.org/browse/JDK-8300144) ProblemList >> vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC >> [JDK-8300147](https://bugs.openjdk.org/browse/JDK-8300147) ProblemList >> vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java >> in Xcomp > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the fast review! - PR: https://git.openjdk.org/jdk20/pull/103
[jdk20] Integrated: 8300141: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC
Trivial fixes to ProblemList some tests: [JDK-8300141](https://bugs.openjdk.org/browse/JDK-8300141) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC [JDK-8300144](https://bugs.openjdk.org/browse/JDK-8300144) ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC [JDK-8300147](https://bugs.openjdk.org/browse/JDK-8300147) ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp - Commit messages: - 8300147: ProblemList vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java in Xcomp - 8300144: ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java with ZGC - 8300141: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC Changes: https://git.openjdk.org/jdk20/pull/103/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=103&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300141 Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk20/pull/103.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/103/head:pull/103 PR: https://git.openjdk.org/jdk20/pull/103
