From duke at openjdk.org  Thu Jul  6 23:35:09 2023
From: duke at openjdk.org (duke)
Date: Thu, 6 Jul 2023 23:35:09 GMT
Subject: jmx-dev Withdrawn: 8301991: Convert l10n properties resource
 bundles to UTF-8 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <uaRK1W4uoY8WriKgYieJVUIGwgh0EMcgfXRicbKTmg4=.e68ef291-6589-493a-b7e9-8086097fb392@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From phh at openjdk.org  Tue Jul 25 21:56:01 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 25 Jul 2023 21:56:01 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074
Message-ID: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>

MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.

I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.

-------------

Commit messages:
 - 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

Changes: https://git.openjdk.org/jdk/pull/15028/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15028&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313081
  Stats: 16 lines in 2 files changed: 11 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15028/head:pull/15028

PR: https://git.openjdk.org/jdk/pull/15028

From dholmes at openjdk.org  Wed Jul 26 05:33:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Jul 2023 05:33:52 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074
In-Reply-To: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
Message-ID: <RP23PTtBCgINE7gx19O33WP4cO61qjXMceKoVVykLDA=.d63aec34-5a25-47f8-a19c-ec0651e17f63@github.com>

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
> 
> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.

Looks good.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15028#pullrequestreview-1546852702

From sspitsyn at openjdk.org  Wed Jul 26 09:11:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Jul 2023 09:11:54 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074
In-Reply-To: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
Message-ID: <lzlZJPvvv76xYJ6vNEkDD3jA9qStvOvHbRCnIhYVwh4=.4bfd5612-9527-45bf-af73-3984ce0b4c00@github.com>

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
> 
> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15028#pullrequestreview-1547201944

From shade at openjdk.org  Wed Jul 26 10:31:39 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Jul 2023 10:31:39 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074
In-Reply-To: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
Message-ID: <6ke2n3KeAZUJ4XyACdxgfwobjh7vDOzwZAYFuF0YP94=.433f1788-b975-4b23-8bf1-dfa8f759802a@github.com>

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
> 
> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15028#pullrequestreview-1547407222

From shade at openjdk.org  Wed Jul 26 10:47:42 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Jul 2023 10:47:42 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074
In-Reply-To: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
Message-ID: <KjLfE3NuUGr5IPEQA95KRFtiS97aTKh71JyKCH4QgMc=.77aac383-ac67-4bac-8486-78372cf12360@github.com>

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
> 
> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.

So... this does not visibly break right now, because the `MutexLocker` in `jmm_GetTotalThreadAllocatedMemory` silently accepts `nullptr` as the lock? I think we should `assert(MonitoringSupport_lock != nullptr)` there. This should also turn the new `UseSerialGC` test config into proper regression test: the test should fail on that assert without this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15028#issuecomment-1651533398

From kevinw at openjdk.org  Wed Jul 26 11:30:15 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Jul 2023 11:30:15 GMT
Subject: jmx-dev RFR: 8313174: Create fewer predictable port clashes in
 management tests
Message-ID: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>

Specifically noticed on linux-aarch64, detection of port clashes by LocateRegistry.createRegistry(port) appears "racy".

Predictable port clashes can be avoided, tests that are likely to run at the same time should not choose the same port.

Why now?  The RMI related parts are obviously fairly stable these days, as are the tests themselves.
Our OS version/host mix for testing may have changed.  The problems I looked into were on ol8-aarch64.

It doesn't seem necessary to add complexities to the tests, or change LocateRegistry much at this point, when a simple change to the tests can avoid asking for so many port clashes.



test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java:            int port = 5800;  	// 5801 to 5820
test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java:            int port = 5800;	// 5821 to 5840
test/jdk/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java:            int port = 5800;	// 5841 to 5860
test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java:            int port = 5800;	// 5861 to 5880
test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java:            int port = 5800;	// 5881 to 5900
test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java:            int port = 5800;	// 5901 to 5920

-------------

Commit messages:
 - update
 - 8313174: Create fewer predictable port clashes in management tests

Changes: https://git.openjdk.org/jdk/pull/15039/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15039&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313174
  Stats: 16 lines in 6 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/15039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15039/head:pull/15039

PR: https://git.openjdk.org/jdk/pull/15039

From phh at openjdk.org  Wed Jul 26 13:30:50 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 26 Jul 2023 13:30:50 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074
In-Reply-To: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
Message-ID: <PXLAwCLPFvdg4H9NkWgcQF9meBSNFGSN5mhGlzl_o6s=.9d9dc3c9-bd96-490a-b539-1d10d6d4310b@github.com>

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
> 
> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.

windows-aarch64 pre-submit build failure is due to an unrelated aarch64-specific issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15028#issuecomment-1651808313

From phh at openjdk.org  Wed Jul 26 15:01:51 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 26 Jul 2023 15:01:51 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074
In-Reply-To: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
Message-ID: <blfYnunQfgdU9W5a1jv8OUKyfJnCnEv9sQtl_Z1SOls=.fa3b668c-c044-49d4-bf3d-13875889c7ad@github.com>

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
> 
> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.

Aleksey, no, it doesn't break now because (1) we don't appear to test on non-server class machines, and (2) FLAG_SET_ERGO_IF_DEFAULT sets UseG1GC unconditionally regardless of which GC is specified on the command line because it (UseG1GC) hasn't also been specified on the command line. So, the assert will have no effect.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15028#issuecomment-1651986014

From phh at openjdk.org  Wed Jul 26 15:19:02 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 26 Jul 2023 15:19:02 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074 [v2]
In-Reply-To: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
Message-ID: <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>

> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
> 
> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.

Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:

  8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15028/files
  - new: https://git.openjdk.org/jdk/pull/15028/files/e84cb69c..f83eccf7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15028&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15028&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15028/head:pull/15028

PR: https://git.openjdk.org/jdk/pull/15028

From shade at openjdk.org  Wed Jul 26 15:29:40 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Jul 2023 15:29:40 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074 [v2]
In-Reply-To: <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
 <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
Message-ID: <AnOXnnLQM-Sf4lirpglyeSctkxbG2D85gvEgmN6f3D4=.c649713d-f411-4d82-81bd-5e4791a1993a@github.com>

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
>> 
>> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

Looks good! I reverted the `mutexLocker.cpp` hunk locally, and the test fails on assert, as expected.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15028#pullrequestreview-1548033607

From phh at openjdk.org  Wed Jul 26 15:32:49 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 26 Jul 2023 15:32:49 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074 [v2]
In-Reply-To: <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
 <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
Message-ID: <0j2eEgtVyUe9jakYD3SdM_RiCAHZBU6GrVm_xvb3qbA=.f85944d9-d5cc-439a-b111-07c5928c6b3b@github.com>

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
>> 
>> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

Thanks, Aleksey. Will push once pre-submit tests finish.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15028#issuecomment-1652050296

From phh at openjdk.org  Wed Jul 26 16:11:46 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 26 Jul 2023 16:11:46 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074 [v2]
In-Reply-To: <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
 <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
Message-ID: <6-6w1yzxbPOsuWdrC1t7GVM6FHWqhY9sxlJ8p_7Ybp4=.51038924-d152-4336-a4a5-510b392badad@github.com>

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
>> 
>> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

I filed [JDK-8313200](https://bugs.openjdk.org/browse/JDK-8313200) to track the windows-aarch64 build issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15028#issuecomment-1652116355

From shade at openjdk.org  Wed Jul 26 16:48:53 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Jul 2023 16:48:53 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074 [v2]
In-Reply-To: <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
 <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
Message-ID: <95MEBJOjTIVFNaGO46GCAcokwwvxufrPN_QlFyaf88M=.2f6db4a4-6472-4082-bae3-fbc126f83010@github.com>

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
>> 
>> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

...and I filed [JDK-8313202](https://bugs.openjdk.org/browse/JDK-8313202) to deal with `MutexLocker` accepting `nullptrs` more generically :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15028#issuecomment-1652166807

From cjplummer at openjdk.org  Wed Jul 26 17:51:54 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Jul 2023 17:51:54 GMT
Subject: jmx-dev RFR: 8313174: Create fewer predictable port clashes in
 management tests
In-Reply-To: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>
References: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>
Message-ID: <LJoPEb1VwyG6liYy9txJm7kv-JWY2dxoJgGnZF7bqXA=.cceabb33-dfbf-483c-a414-2f65e2bed8de@github.com>

On Wed, 26 Jul 2023 10:50:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Specifically noticed on linux-aarch64, detection of port clashes by LocateRegistry.createRegistry(port) appears "racy".
> 
> Predictable port clashes can be avoided, tests that are likely to run at the same time should not choose the same port.
> 
> Why now?  The RMI related parts are obviously fairly stable these days, as are the tests themselves.
> Our OS version/host mix for testing may have changed.  The problems I looked into were on ol8-aarch64.
> 
> It doesn't seem necessary to add complexities to the tests, or change LocateRegistry much at this point, when a simple change to the tests can avoid asking for so many port clashes.
> 
> 
> 
> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java:            int port = 5800;  	// 5801 to 5820
> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java:            int port = 5800;	// 5821 to 5840
> test/jdk/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java:            int port = 5800;	// 5841 to 5860
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java:            int port = 5800;	// 5861 to 5880
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java:            int port = 5800;	// 5881 to 5900
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java:            int port = 5800;	// 5901 to 5920

Changes requested by cjplummer (Reviewer).

test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java line 76:

> 74:             Registry reg = null;
> 75:             int port = 5880;
> 76:             while (port++ < 6000) {

Does the loop need to terminate on 5900 instead of 6000?

-------------

PR Review: https://git.openjdk.org/jdk/pull/15039#pullrequestreview-1548296441
PR Review Comment: https://git.openjdk.org/jdk/pull/15039#discussion_r1275303419

From phh at openjdk.org  Wed Jul 26 17:55:50 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 26 Jul 2023 17:55:50 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074 [v2]
In-Reply-To: <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
 <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
Message-ID: <PwDuy8sllzgA7EWudTq9xOeuw7PFa8kIhvKG9uR6BYA=.bf82a9c1-d8c5-4a49-ba19-07df954521b8@github.com>

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
>> 
>> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

linux-x86 langtools/tools/javac/varargs/warning/Warn4.java presubmit test failure is a crash in G1ConcurrentMark.cpp which appears unrelated. Rerun on my test box succeeded.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15028#issuecomment-1652255976

From kevinw at openjdk.org  Wed Jul 26 18:06:56 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Jul 2023 18:06:56 GMT
Subject: jmx-dev RFR: 8313174: Create fewer predictable port clashes in
 management tests [v2]
In-Reply-To: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>
References: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>
Message-ID: <q3wx-WEmxSleca2EVCFP8_diu3ATkQ2fUBuUvxN1WRk=.777b7635-5b2e-4ea6-9f17-438a93ef1231@github.com>

> Specifically noticed on linux-aarch64, detection of port clashes by LocateRegistry.createRegistry(port) appears "racy".
> 
> Predictable port clashes can be avoided, tests that are likely to run at the same time should not choose the same port.
> 
> Why now?  The RMI related parts are obviously fairly stable these days, as are the tests themselves.
> Our OS version/host mix for testing may have changed.  The problems I looked into were on ol8-aarch64.
> 
> It doesn't seem necessary to add complexities to the tests, or change LocateRegistry much at this point, when a simple change to the tests can avoid asking for so many port clashes.
> 
> 
> 
> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java:            int port = 5800;  	// 5801 to 5820
> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java:            int port = 5800;	// 5821 to 5840
> test/jdk/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java:            int port = 5800;	// 5841 to 5860
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java:            int port = 5800;	// 5861 to 5880
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java:            int port = 5800;	// 5881 to 5900
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java:            int port = 5800;	// 5901 to 5920

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  port range fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15039/files
  - new: https://git.openjdk.org/jdk/pull/15039/files/6093573c..29b345b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15039&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15039&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15039/head:pull/15039

PR: https://git.openjdk.org/jdk/pull/15039

From kevinw at openjdk.org  Wed Jul 26 18:06:59 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Jul 2023 18:06:59 GMT
Subject: jmx-dev RFR: 8313174: Create fewer predictable port clashes in
 management tests [v2]
In-Reply-To: <LJoPEb1VwyG6liYy9txJm7kv-JWY2dxoJgGnZF7bqXA=.cceabb33-dfbf-483c-a414-2f65e2bed8de@github.com>
References: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>
 <LJoPEb1VwyG6liYy9txJm7kv-JWY2dxoJgGnZF7bqXA=.cceabb33-dfbf-483c-a414-2f65e2bed8de@github.com>
Message-ID: <MYxl3MThb5qUXwS_LVhTo2xc2Hoz6AKgcrEFdgKSRcs=.1f58053d-023b-4ef0-9965-1d9dacf1bf23@github.com>

On Wed, 26 Jul 2023 17:48:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   port range fix
>
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java line 76:
> 
>> 74:             Registry reg = null;
>> 75:             int port = 5880;
>> 76:             while (port++ < 6000) {
> 
> Does the loop need to terminate on 5900 instead of 6000?

Quite right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15039#discussion_r1275316510

From cjplummer at openjdk.org  Wed Jul 26 18:32:41 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Jul 2023 18:32:41 GMT
Subject: jmx-dev RFR: 8313174: Create fewer predictable port clashes in
 management tests [v2]
In-Reply-To: <q3wx-WEmxSleca2EVCFP8_diu3ATkQ2fUBuUvxN1WRk=.777b7635-5b2e-4ea6-9f17-438a93ef1231@github.com>
References: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>
 <q3wx-WEmxSleca2EVCFP8_diu3ATkQ2fUBuUvxN1WRk=.777b7635-5b2e-4ea6-9f17-438a93ef1231@github.com>
Message-ID: <pBu5m1UlOQVA__SKbq7fUCWVkhCm-kWJbmGI_lBdl4s=.ab66f425-bf84-4626-9004-6295038ac392@github.com>

On Wed, 26 Jul 2023 18:06:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Specifically noticed on linux-aarch64, detection of port clashes by LocateRegistry.createRegistry(port) appears "racy".
>> 
>> Predictable port clashes can be avoided, tests that are likely to run at the same time should not choose the same port.
>> 
>> Why now?  The RMI related parts are obviously fairly stable these days, as are the tests themselves.
>> Our OS version/host mix for testing may have changed.  The problems I looked into were on ol8-aarch64.
>> 
>> It doesn't seem necessary to add complexities to the tests, or change LocateRegistry much at this point, when a simple change to the tests can avoid asking for so many port clashes.
>> 
>> 
>> 
>> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java:            int port = 5800;  	// 5801 to 5820
>> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java:            int port = 5800;	// 5821 to 5840
>> test/jdk/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java:            int port = 5800;	// 5841 to 5860
>> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java:            int port = 5800;	// 5861 to 5880
>> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java:            int port = 5800;	// 5881 to 5900
>> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java:            int port = 5800;	// 5901 to 5920
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   port range fix

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15039#pullrequestreview-1548364525

From phh at openjdk.org  Wed Jul 26 19:33:49 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 26 Jul 2023 19:33:49 GMT
Subject: jmx-dev Integrated: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074
In-Reply-To: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
Message-ID: <94S7MWreF1CwP5D1GT0I8uWKBicTbYzjMooiYetFf5s=.3104053f-c9fc-4ca6-8a29-5492d36ff91b@github.com>

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
> 
> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.

This pull request has now been integrated.

Changeset: a9d21c61
Author:    Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9d21c61fb12a11e18c6bb8aa903e5a8e42473f1
Stats:     17 lines in 3 files changed: 12 ins; 2 del; 3 mod

8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

Reviewed-by: dholmes, sspitsyn, shade

-------------

PR: https://git.openjdk.org/jdk/pull/15028

From amenkov at openjdk.org  Wed Jul 26 21:23:52 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 26 Jul 2023 21:23:52 GMT
Subject: jmx-dev RFR: 8313174: Create fewer predictable port clashes in
 management tests [v2]
In-Reply-To: <q3wx-WEmxSleca2EVCFP8_diu3ATkQ2fUBuUvxN1WRk=.777b7635-5b2e-4ea6-9f17-438a93ef1231@github.com>
References: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>
 <q3wx-WEmxSleca2EVCFP8_diu3ATkQ2fUBuUvxN1WRk=.777b7635-5b2e-4ea6-9f17-438a93ef1231@github.com>
Message-ID: <2ESR6vDjjzufAzft71EgGFGaY1Bqf0vjRUpqI86PNgQ=.950d2710-367f-4d8e-9b41-cc8cfbd96528@github.com>

On Wed, 26 Jul 2023 18:06:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Specifically noticed on linux-aarch64, detection of port clashes by LocateRegistry.createRegistry(port) appears "racy".
>> 
>> Predictable port clashes can be avoided, tests that are likely to run at the same time should not choose the same port.
>> 
>> Why now?  The RMI related parts are obviously fairly stable these days, as are the tests themselves.
>> Our OS version/host mix for testing may have changed.  The problems I looked into were on ol8-aarch64.
>> 
>> It doesn't seem necessary to add complexities to the tests, or change LocateRegistry much at this point, when a simple change to the tests can avoid asking for so many port clashes.
>> 
>> 
>> 
>> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java:            int port = 5800;  	// 5801 to 5820
>> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java:            int port = 5800;	// 5821 to 5840
>> test/jdk/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java:            int port = 5800;	// 5841 to 5860
>> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java:            int port = 5800;	// 5861 to 5880
>> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java:            int port = 5800;	// 5881 to 5900
>> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java:            int port = 5800;	// 5901 to 5920
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   port range fix

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15039#pullrequestreview-1548612980

From dholmes at openjdk.org  Thu Jul 27 07:14:56 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Jul 2023 07:14:56 GMT
Subject: jmx-dev RFR: 8313081: MonitoringSupport_lock should be
 unconditionally initialized after 8304074 [v2]
In-Reply-To: <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
References: <FiieD6-VskFEDc2MlllO38p--CqWguwgVz5teUyBuTU=.d3ade134-0f8d-4c11-a54a-be216a390cc1@github.com>
 <eCF2jBbK89daT8gqJnh55ISqMXnYwJlSEfp5Gn3k0mk=.f9260e4d-eec2-4f2c-9119-eae21a9ff607@github.com>
Message-ID: <qJo-9mQWvlngwl6M3FszE1zdeO5_0ii93kn7ZeI9qNc=.0a518f46-67ed-46d9-ba30-55f4045f2559@github.com>

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is specified, see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't included in the Hotspot build or Hotspot is not running on a server class machine (unlikely these days), the lock will not be initialized. The lock's initialization should be unconditional.
>> 
>> I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial collectors.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

src/hotspot/share/services/management.cpp line 2119:

> 2117: 
> 2118:     {
> 2119:       assert(MonitoringSupport_lock != nullptr, "Must be");

This was unnecessary. If you have this here you would have one before every single use of mutex that is expected to be non-null.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15028#discussion_r1275828276

From kevinw at openjdk.org  Thu Jul 27 15:43:03 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Jul 2023 15:43:03 GMT
Subject: jmx-dev RFR: 8313174: Create fewer predictable port clashes in
 management tests [v2]
In-Reply-To: <q3wx-WEmxSleca2EVCFP8_diu3ATkQ2fUBuUvxN1WRk=.777b7635-5b2e-4ea6-9f17-438a93ef1231@github.com>
References: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>
 <q3wx-WEmxSleca2EVCFP8_diu3ATkQ2fUBuUvxN1WRk=.777b7635-5b2e-4ea6-9f17-438a93ef1231@github.com>
Message-ID: <knruB8FxTxNNmvJ7EloiQ_4QxgvX0fZMvUaXziIsVGY=.c724d7cb-4523-4aee-aa2b-740a44001e14@github.com>

On Wed, 26 Jul 2023 18:06:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Specifically noticed on linux-aarch64, detection of port clashes by LocateRegistry.createRegistry(port) appears "racy".
>> 
>> Predictable port clashes can be avoided, tests that are likely to run at the same time should not choose the same port.
>> 
>> Why now?  The RMI related parts are obviously fairly stable these days, as are the tests themselves.
>> Our OS version/host mix for testing may have changed.  The problems I looked into were on ol8-aarch64.
>> 
>> It doesn't seem necessary to add complexities to the tests, or change LocateRegistry much at this point, when a simple change to the tests can avoid asking for so many port clashes.
>> 
>> 
>> 
>> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java:            int port = 5800;  	// 5801 to 5820
>> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java:            int port = 5800;	// 5821 to 5840
>> test/jdk/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java:            int port = 5800;	// 5841 to 5860
>> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java:            int port = 5800;	// 5861 to 5880
>> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java:            int port = 5800;	// 5881 to 5900
>> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java:            int port = 5800;	// 5901 to 5920
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   port range fix

Thanks Chris, thanks Alex!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15039#issuecomment-1653870034

From kevinw at openjdk.org  Thu Jul 27 15:43:05 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Jul 2023 15:43:05 GMT
Subject: jmx-dev Integrated: 8313174: Create fewer predictable port clashes
 in management tests
In-Reply-To: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>
References: <Iz0E-hxEY0r_dvklE6UsFP6MJCN7XoGd_JstrWQhlqY=.bb303b0a-b941-4726-9265-517fc02d4b1a@github.com>
Message-ID: <mSrptrYMjeSboMx0du_M3wT6_WYQ0mfDJxRg3n3XfAk=.63ff9d47-ebdd-4828-97c6-b0912bf7a948@github.com>

On Wed, 26 Jul 2023 10:50:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Specifically noticed on linux-aarch64, detection of port clashes by LocateRegistry.createRegistry(port) appears "racy".
> 
> Predictable port clashes can be avoided, tests that are likely to run at the same time should not choose the same port.
> 
> Why now?  The RMI related parts are obviously fairly stable these days, as are the tests themselves.
> Our OS version/host mix for testing may have changed.  The problems I looked into were on ol8-aarch64.
> 
> It doesn't seem necessary to add complexities to the tests, or change LocateRegistry much at this point, when a simple change to the tests can avoid asking for so many port clashes.
> 
> 
> 
> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java:            int port = 5800;  	// 5801 to 5820
> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java:            int port = 5800;	// 5821 to 5840
> test/jdk/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java:            int port = 5800;	// 5841 to 5860
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java:            int port = 5800;	// 5861 to 5880
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java:            int port = 5800;	// 5881 to 5900
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java:            int port = 5800;	// 5901 to 5920

This pull request has now been integrated.

Changeset: 169b6e3c
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/169b6e3cff8f9e0e09cdd5145c2dfe73a88519d1
Stats:     17 lines in 6 files changed: 0 ins; 0 del; 17 mod

8313174: Create fewer predictable port clashes in management tests

Reviewed-by: cjplummer, amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/15039