From dholmes at openjdk.org  Tue Jan  2 05:57:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Jan 2024 05:57:05 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated
Message-ID: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>

Please review these missing updates to the `jcmd` manpage - see JBS issue for details.

I also fixed the sub-command ordering in a few places and a couple of minor formatting fixes.

Thanks to @tstuefe for collating the initial information on what was missing. I used to `jcmd help <cmd>` option to compare the help text with the manpage text and adjusted the manpage accordingly (and found a few more omissions - some of which will be fixed by follow up RFE by the respective owners).

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

Commit messages:
 - 8319948: jcmd man page needs to be updated

Changes: https://git.openjdk.org/jdk/pull/17213/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17213&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319948
  Stats: 262 lines in 1 file changed: 175 ins; 56 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/17213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17213/head:pull/17213

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

From kevinw at openjdk.org  Tue Jan  2 13:17:46 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 2 Jan 2024 13:17:46 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated
In-Reply-To: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
Message-ID: <1qdF5nx16Z34Do7b2kX8LPJrIwlhiMZsgBpXtccDqFg=.60daa558-e999-406a-a556-e85f680947f7@github.com>

On Tue, 2 Jan 2024 05:51:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these missing updates to the `jcmd` manpage - see JBS issue for details.
> 
> I also fixed the sub-command ordering in a few places and a couple of minor formatting fixes.
> 
> Thanks to @tstuefe for collating the initial information on what was missing. I used to `jcmd help <cmd>` option to compare the help text with the manpage text and adjusted the manpage accordingly (and found a few more omissions - some of which will be fixed by follow up RFE by the respective owners).

Looks good.

Trivially can note that here in jcmd.1 VM.flags says "Prints the VM flag..." while diagnosticCommand.hpp says: "Print VM flag...".  
We could make it consistent, but not important.
"Print" maybe in the minority compared to "Prints", but we have some of each. 8-)

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17213#pullrequestreview-1800411408

From alanb at openjdk.org  Tue Jan  2 15:22:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Jan 2024 15:22:05 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
Message-ID: <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>

> A lot of test changes have accumulated in the loom repo, this includes both new tests and updates to existing tests. Some of these updates can be brought to the main line. This update brings over:
> 
> - The existing tests for pinning use synchronized blocks. In preparation for changes to allow carrier thread be released when a virtual thread parks holding a monitor or blocks on monitorenter, these tests are changed to pin by having a native frame on the stack. This part includes test infrastructure to make it easy to add more tests that do operations while pinned. The tests still test what they were originally created to test of course.
> 
> - The test for the JFR jdk.VirtualThreadPinned event is refactored to allow for additional cases where the event may be reported.
> 
> - ThreadAPI is expanded to cover test for uncaught exception handling.
> 
> - GetStackTraceWhenRunnable is refactored to not use a Selector, otherwise this test will be invalidated when blocking selection operations release the carrier.
> 
> - StressStackOverflow is dialed down to run for 1m instead of 2mins.
> 
> - The use of CountDownLatch in a number of tests that poll thread state has been dropped to keep the tests as simple as possible.

Alan Bateman 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 four additional commits since the last revision:

 - Revert changes to TracePinnedThreads.java
 - Sync up from loom repo
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17136/files
  - new: https://git.openjdk.org/jdk/pull/17136/files/b7abfc0a..fe255921

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

  Stats: 3108 lines in 165 files changed: 1976 ins; 659 del; 473 mod
  Patch: https://git.openjdk.org/jdk/pull/17136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17136/head:pull/17136

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

From stefank at openjdk.org  Tue Jan  2 15:36:07 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Jan 2024 15:36:07 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v4]
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <yEDcAV7XwAPsBX5Z4vPBDDUowP57us2a3WIW5bJ6vyk=.d55a077c-b8c9-4050-ad9d-08337753fbae@github.com>

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

Stefan Karlsson 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 four additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Test cleanup
 - Fix impl and add test
 - 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17049/files
  - new: https://git.openjdk.org/jdk/pull/17049/files/5d488f42..486dc6d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=02-03

  Stats: 5249 lines in 348 files changed: 3069 ins; 973 del; 1207 mod
  Patch: https://git.openjdk.org/jdk/pull/17049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049

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

From stefank at openjdk.org  Tue Jan  2 15:36:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Jan 2024 15:36:10 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v3]
In-Reply-To: <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
 <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>
Message-ID: <yDnkf3CvvXwTidrzaz6lrvS6XZVKBLVbJEOqBXwPi6M=.e4ddf28f-f03d-4c37-b831-a7206a202755@github.com>

On Mon, 11 Dec 2023 14:06:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
>> 
>> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
>> 
>> With these functions it is common to see the following pattern in tests:
>> 
>> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
>> OutputAnalyzer output = executeProcess(pb);
>> 
>> 
>> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
>> 
>> OutputAnalyzer output = ProcessTools.executeTestJvm();
>> 
>> 
>> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test cleanup

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17049#issuecomment-1874176578

From kevinw at openjdk.org  Tue Jan  2 15:54:08 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 2 Jan 2024 15:54:08 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX) Management
 Applet (m-let) feature
Message-ID: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>

Remove the MLet feature and its tests.

Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
test/jdk/javax/management/MBeanServer/PostExceptionTest.java
test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

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

Commit messages:
 - remote old commented-out code
 - Merge remote-tracking branch 'upstream/master' into 8318707_MLet_Remove
 - (C) updates
 - Remove MLet from additional tests
 - Further test updates
 - Addtional test updates
 - Remove PrivateMLet from ClassleakTest, retain stated purpose of test
 - Merge remote-tracking branch 'upstream/master' into 8318707_MLet_Remove
 - Test update
 - remove LibraryLoader MLet test
 - ... and 5 more: https://git.openjdk.org/jdk/compare/a5cf4210...cc6e0d28

Changes: https://git.openjdk.org/jdk/pull/16363/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16363&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318707
  Stats: 3532 lines in 39 files changed: 41 ins; 3429 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/16363.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16363/head:pull/16363

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

From kevinw at openjdk.org  Tue Jan  2 15:54:08 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 2 Jan 2024 15:54:08 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <FDIAgcrRrmE3ZN0gssl8kzyOuFcnej2T3cgcaXZWxWQ=.b8092c13-b802-4bf3-8dd4-db95d1dc9ffe@github.com>

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

Additional test updates, a few more to come...

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

PR Comment: https://git.openjdk.org/jdk/pull/16363#issuecomment-1866081811

From mikael at openjdk.org  Tue Jan  2 21:51:03 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 2 Jan 2024 21:51:03 GMT
Subject: RFR: 8322873: Duplicate -ljava -ljvm options for libinstrument
Message-ID: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>

The libinstrument library is linked against libjava and libjvm, twice. This is mostly harmless but Xcode 15.x generates a warning:

Creating support/modules_libs/java.instrument/libinstrument.dylib from 12 file(s)
ld: warning: ignoring duplicate libraries: '-ljava', '-ljvm'

In particular, note that the `JDKLIB_LIBS` variable passed in to `LIBS` already contains the -ljava -ljvm options. Digging through the history it seems like this issue was introduced with [JDK-8141290](https://bugs.openjdk.org/browse/JDK-8141290).

Testing: tier1,builds-tier[2-5] (in progress)

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

Commit messages:
 - 8322873: Duplicate -ljava -ljvm options for libinstrument

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

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

From dholmes at openjdk.org  Tue Jan  2 21:51:57 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Jan 2024 21:51:57 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated [v2]
In-Reply-To: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
Message-ID: <RxiQ0MT2uZy3XzMD4-V7v98HKSV7NEqU_Pxo0l3frGk=.5965e917-145d-4cc6-bd5b-897f03eaeaaa@github.com>

> Please review these missing updates to the `jcmd` manpage - see JBS issue for details.
> 
> I also fixed the sub-command ordering in a few places and a couple of minor formatting fixes.
> 
> Thanks to @tstuefe for collating the initial information on what was missing. I used to `jcmd help <cmd>` option to compare the help text with the manpage text and adjusted the manpage accordingly (and found a few more omissions - some of which will be fixed by follow up RFE by the respective owners).

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fix two formatting errors and make VM.flags consistent with help text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17213/files
  - new: https://git.openjdk.org/jdk/pull/17213/files/9e47816e..c410c17f

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

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

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

From dholmes at openjdk.org  Tue Jan  2 22:01:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Jan 2024 22:01:11 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated [v3]
In-Reply-To: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
Message-ID: <JIqj1o15_fvY5F7cKDvzOmVPN4JLorm7HlRWU2_y3VI=.9a978c84-3468-4641-acc7-a3e2667eea59@github.com>

> Please review these missing updates to the `jcmd` manpage - see JBS issue for details.
> 
> I also fixed the sub-command ordering in a few places and a couple of minor formatting fixes.
> 
> Thanks to @tstuefe for collating the initial information on what was missing. I used to `jcmd help <cmd>` option to compare the help text with the manpage text and adjusted the manpage accordingly (and found a few more omissions - some of which will be fixed by follow up RFE by the respective owners).

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Consistency pass to match manpage text with help text for VM subcommands

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17213/files
  - new: https://git.openjdk.org/jdk/pull/17213/files/c410c17f..39cbf52a

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

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

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

From dholmes at openjdk.org  Tue Jan  2 22:01:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Jan 2024 22:01:11 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated [v3]
In-Reply-To: <1qdF5nx16Z34Do7b2kX8LPJrIwlhiMZsgBpXtccDqFg=.60daa558-e999-406a-a556-e85f680947f7@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
 <1qdF5nx16Z34Do7b2kX8LPJrIwlhiMZsgBpXtccDqFg=.60daa558-e999-406a-a556-e85f680947f7@github.com>
Message-ID: <hNW_Jt3wzVFy7m3yxNqDXrRR3IdaC9N1ly9jBnDFYCk=.cda98398-238d-4edd-a0f2-ca280bb9bc09@github.com>

On Tue, 2 Jan 2024 13:15:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Consistency pass to match manpage text with help text for VM subcommands
>
> Looks good.
> 
> Trivially can note that here in jcmd.1 VM.flags says "Prints the VM flag..." while diagnosticCommand.hpp says: "Print VM flag...".  
> We could make it consistent, but not important.
> "Print" maybe in the minority compared to "Prints", but we have some of each. 8-)

Thanks for the review @kevinjwalls . I did a consistency sweep over the VM subcommands and changed a lot of `Prints` to `Print` so the manpage matches the help text. Which form is better grammatically I'm not sure, but if we want to change things we should do that for the help text and manpage at the same time.

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

PR Comment: https://git.openjdk.org/jdk/pull/17213#issuecomment-1874615668

From dholmes at openjdk.org  Wed Jan  3 02:18:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Jan 2024 02:18:37 GMT
Subject: RFR: 8322873: Duplicate -ljava -ljvm options for libinstrument
In-Reply-To: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>
References: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>
Message-ID: <UT4s2fvIKGXuvJw_jyd8800DaoaIeB8vlNAlHphWaMU=.67d263ca-ea27-4937-b8e2-59bc7525db3d@github.com>

On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The libinstrument library is linked against libjava and libjvm, twice. This is mostly harmless but Xcode 15.x generates a warning:
> 
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12 file(s)
> ld: warning: ignoring duplicate libraries: '-ljava', '-ljvm'
> 
> In particular, note that the `JDKLIB_LIBS` variable passed in to `LIBS` already contains the -ljava -ljvm options. Digging through the history it seems like this issue was introduced with [JDK-8141290](https://bugs.openjdk.org/browse/JDK-8141290).
> 
> Testing: tier1,builds-tier[2-5]

LGTM.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17230#pullrequestreview-1801291647

From alanb at openjdk.org  Wed Jan  3 07:13:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 07:13:48 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated [v3]
In-Reply-To: <JIqj1o15_fvY5F7cKDvzOmVPN4JLorm7HlRWU2_y3VI=.9a978c84-3468-4641-acc7-a3e2667eea59@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
 <JIqj1o15_fvY5F7cKDvzOmVPN4JLorm7HlRWU2_y3VI=.9a978c84-3468-4641-acc7-a3e2667eea59@github.com>
Message-ID: <OYYZBevZEinKAYP_hm7nFQa8MAHAT06flL39g4-f1X4=.bc1cf38d-35bf-4864-adc4-8d6db06b67a1@github.com>

On Tue, 2 Jan 2024 22:01:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review these missing updates to the `jcmd` manpage - see JBS issue for details.
>> 
>> I also fixed the sub-command ordering in a few places and a couple of minor formatting fixes.
>> 
>> Thanks to @tstuefe for collating the initial information on what was missing. I used to `jcmd help <cmd>` option to compare the help text with the manpage text and adjusted the manpage accordingly (and found a few more omissions - some of which will be fixed by follow up RFE by the respective owners).
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Consistency pass to match manpage text with help text for VM subcommands

src/jdk.jcmd/share/man/jcmd.1 line 199:

> 197: .TP
> 198: \f[V]Compiler.directives_add\f[R] \f[I]filename\f[R] \f[I]arguments\f[R]
> 199: Adds compiler directives from a file.

I might be misreading this one, it looks like there are two arguments but the the help output shows just one, maybe check that one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17213#discussion_r1440134308

From dholmes at openjdk.org  Wed Jan  3 07:19:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Jan 2024 07:19:03 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated [v4]
In-Reply-To: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
Message-ID: <uJbqiLtUCfJ5ZGwQ_hQn8pzKnpHp5p2qMdEWWQK8SuA=.d3729a56-95e2-4932-a447-9f42cf8f0965@github.com>

> Please review these missing updates to the `jcmd` manpage - see JBS issue for details.
> 
> I also fixed the sub-command ordering in a few places and a couple of minor formatting fixes.
> 
> Thanks to @tstuefe for collating the initial information on what was missing. I used to `jcmd help <cmd>` option to compare the help text with the manpage text and adjusted the manpage accordingly (and found a few more omissions - some of which will be fixed by follow up RFE by the respective owners).

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fixed Compiler.directives_add

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17213/files
  - new: https://git.openjdk.org/jdk/pull/17213/files/39cbf52a..6ac454de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17213&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17213&range=02-03

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

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

From dholmes at openjdk.org  Wed Jan  3 07:19:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Jan 2024 07:19:05 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated [v3]
In-Reply-To: <OYYZBevZEinKAYP_hm7nFQa8MAHAT06flL39g4-f1X4=.bc1cf38d-35bf-4864-adc4-8d6db06b67a1@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
 <JIqj1o15_fvY5F7cKDvzOmVPN4JLorm7HlRWU2_y3VI=.9a978c84-3468-4641-acc7-a3e2667eea59@github.com>
 <OYYZBevZEinKAYP_hm7nFQa8MAHAT06flL39g4-f1X4=.bc1cf38d-35bf-4864-adc4-8d6db06b67a1@github.com>
Message-ID: <Q9dEOeWLUbyiJDF18TZeaa3qa9i2ZFy0xSS37RiEXAI=.de9be521-dbd2-4ff0-8a32-753a7ceec8d8@github.com>

On Wed, 3 Jan 2024 07:11:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Consistency pass to match manpage text with help text for VM subcommands
>
> src/jdk.jcmd/share/man/jcmd.1 line 199:
> 
>> 197: .TP
>> 198: \f[V]Compiler.directives_add\f[R] \f[I]filename\f[R] \f[I]arguments\f[R]
>> 199: Adds compiler directives from a file.
> 
> I might be misreading this one, it looks like there are two arguments but the the help output shows just one, maybe check that one.

Thanks for catching that!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17213#discussion_r1440136676

From alanb at openjdk.org  Wed Jan  3 07:23:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 07:23:38 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated [v4]
In-Reply-To: <uJbqiLtUCfJ5ZGwQ_hQn8pzKnpHp5p2qMdEWWQK8SuA=.d3729a56-95e2-4932-a447-9f42cf8f0965@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
 <uJbqiLtUCfJ5ZGwQ_hQn8pzKnpHp5p2qMdEWWQK8SuA=.d3729a56-95e2-4932-a447-9f42cf8f0965@github.com>
Message-ID: <vPYcMwcN890iL2lBnVN1sI5Q7mOJu3oX1eSLlu7gAlY=.fea3ee50-9640-4caf-b13b-e77195774850@github.com>

On Wed, 3 Jan 2024 07:19:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review these missing updates to the `jcmd` manpage - see JBS issue for details.
>> 
>> I also fixed the sub-command ordering in a few places and a couple of minor formatting fixes.
>> 
>> Thanks to @tstuefe for collating the initial information on what was missing. I used to `jcmd help <cmd>` option to compare the help text with the manpage text and adjusted the manpage accordingly (and found a few more omissions - some of which will be fixed by follow up RFE by the respective owners).
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed Compiler.directives_add

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17213#pullrequestreview-1801482143

From alanb at openjdk.org  Wed Jan  3 07:23:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 07:23:41 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated [v3]
In-Reply-To: <Q9dEOeWLUbyiJDF18TZeaa3qa9i2ZFy0xSS37RiEXAI=.de9be521-dbd2-4ff0-8a32-753a7ceec8d8@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
 <JIqj1o15_fvY5F7cKDvzOmVPN4JLorm7HlRWU2_y3VI=.9a978c84-3468-4641-acc7-a3e2667eea59@github.com>
 <OYYZBevZEinKAYP_hm7nFQa8MAHAT06flL39g4-f1X4=.bc1cf38d-35bf-4864-adc4-8d6db06b67a1@github.com>
 <Q9dEOeWLUbyiJDF18TZeaa3qa9i2ZFy0xSS37RiEXAI=.de9be521-dbd2-4ff0-8a32-753a7ceec8d8@github.com>
Message-ID: <ONKhl-IXUxtIIeiZ5BQVbtQJQC0chUfVUwOqBtvU8ec=.9043112d-d401-4a36-828d-31014e155cea@github.com>

On Wed, 3 Jan 2024 07:15:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/jdk.jcmd/share/man/jcmd.1 line 199:
>> 
>>> 197: .TP
>>> 198: \f[V]Compiler.directives_add\f[R] \f[I]filename\f[R] \f[I]arguments\f[R]
>>> 199: Adds compiler directives from a file.
>> 
>> I might be misreading this one, it looks like there are two arguments but the the help output shows just one, maybe check that one.
>
> Thanks for catching that!

I didn't spot anything else, the update looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17213#discussion_r1440139492

From dholmes at openjdk.org  Wed Jan  3 07:30:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Jan 2024 07:30:47 GMT
Subject: RFR: 8319948: jcmd man page needs to be updated [v4]
In-Reply-To: <vPYcMwcN890iL2lBnVN1sI5Q7mOJu3oX1eSLlu7gAlY=.fea3ee50-9640-4caf-b13b-e77195774850@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
 <uJbqiLtUCfJ5ZGwQ_hQn8pzKnpHp5p2qMdEWWQK8SuA=.d3729a56-95e2-4932-a447-9f42cf8f0965@github.com>
 <vPYcMwcN890iL2lBnVN1sI5Q7mOJu3oX1eSLlu7gAlY=.fea3ee50-9640-4caf-b13b-e77195774850@github.com>
Message-ID: <aemckj09oKF_az4PgORAVeydbOQf5ZsRH1isQr6IEuA=.1f7afed4-06b5-4a71-a964-1bd2d0f6d43e@github.com>

On Wed, 3 Jan 2024 07:21:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed Compiler.directives_add
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the review @AlanBateman !

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

PR Comment: https://git.openjdk.org/jdk/pull/17213#issuecomment-1874947985

From stefank at openjdk.org  Wed Jan  3 07:55:12 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Jan 2024 07:55:12 GMT
Subject: RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v5]
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <GpEb2qpnxJqXX5Ogimr2sbaXPOyFbB7wh06f0a47vc8=.96bd91bf-8487-49e0-8112-77843e7e3b15@github.com>

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

Stefan Karlsson 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 five additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Test cleanup
 - Fix impl and add test
 - 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17049/files
  - new: https://git.openjdk.org/jdk/pull/17049/files/486dc6d5..755d925d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=03-04

  Stats: 875 lines in 70 files changed: 577 ins; 58 del; 240 mod
  Patch: https://git.openjdk.org/jdk/pull/17049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049

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

From jwaters at openjdk.org  Wed Jan  3 08:54:47 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 3 Jan 2024 08:54:47 GMT
Subject: RFR: 8322873: Duplicate -ljava -ljvm options for libinstrument
In-Reply-To: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>
References: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>
Message-ID: <0OJOIbmNMM_cMydNcuKvspMGa9b-tO6uuDJH0DVkb5s=.b7d012e0-939f-40d0-a550-c22d86d011e3@github.com>

On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The libinstrument library is linked against libjava and libjvm, twice. This is mostly harmless but Xcode 15.x generates a warning:
> 
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12 file(s)
> ld: warning: ignoring duplicate libraries: '-ljava', '-ljvm'
> 
> In particular, note that the `JDKLIB_LIBS` variable passed in to `LIBS` already contains the -ljava -ljvm options. Digging through the history it seems like this issue was introduced with [JDK-8141290](https://bugs.openjdk.org/browse/JDK-8141290).
> 
> Testing: tier1,builds-tier[2-5]

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17230#pullrequestreview-1801585544

From stefank at openjdk.org  Wed Jan  3 08:55:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Jan 2024 08:55:54 GMT
Subject: Integrated: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <97p3loy_9ZZnMenWO0FMfeACOTWUjesg8dVD6fmYCzs=.160baa3e-3709-4ece-a3aa-986206b73148@github.com>

On Mon, 11 Dec 2023 09:15:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

This pull request has now been integrated.

Changeset: cbe329b9
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbe329b90ac1488836d4852fead79aa26c082114
Stats:     262 lines in 89 files changed: 73 ins; 1 del; 188 mod

8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

Reviewed-by: lkorinth, lmesnik

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

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

From jpai at openjdk.org  Wed Jan  3 11:41:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Jan 2024 11:41:39 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
Message-ID: <Hbsfs9dPWgHu126XKgqXt003NLlSO-paxlg4KpHfIwU=.c9b04105-cf0d-4458-9c85-05f75a307543@github.com>

On Tue, 2 Jan 2024 15:22:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A lot of test changes have accumulated in the loom repo, this includes both new tests and updates to existing tests. Some of these updates can be brought to the main line. This update brings over:
>> 
>> - The existing tests for pinning use synchronized blocks. In preparation for changes to allow carrier thread be released when a virtual thread parks holding a monitor or blocks on monitorenter, these tests are changed to pin by having a native frame on the stack. This part includes test infrastructure to make it easy to add more tests that do operations while pinned. The tests still test what they were originally created to test of course.
>> 
>> - The test for the JFR jdk.VirtualThreadPinned event is refactored to allow for additional cases where the event may be reported.
>> 
>> - ThreadAPI is expanded to cover test for uncaught exception handling.
>> 
>> - GetStackTraceWhenRunnable is refactored to not use a Selector, otherwise this test will be invalidated when blocking selection operations release the carrier.
>> 
>> - StressStackOverflow is dialed down to run for 1m instead of 2mins.
>> 
>> - The use of CountDownLatch in a number of tests that poll thread state has been dropped to keep the tests as simple as possible.
>
> Alan Bateman 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 four additional commits since the last revision:
> 
>  - Revert changes to TracePinnedThreads.java
>  - Sync up from loom repo
>  - Merge
>  - Initial commit

test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 29:

> 27:  * @requires vm.continuations
> 28:  * @requires !vm.debug | vm.gc != "Z"
> 29:  * @run main/othervm/timeout=300 -Xmx1500m Skynet

Are these heap sizing changes to reduce the resource usage of this test or is it to try and trigger any potential issue that this test verifies?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17136#discussion_r1440354141

From mbaesken at openjdk.org  Wed Jan  3 11:47:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 11:47:54 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified class
 name "java.util.Arrays"
Message-ID: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>

In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

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

Commit messages:
 - JDK-8322782

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

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

From jpai at openjdk.org  Wed Jan  3 11:56:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Jan 2024 11:56:38 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
Message-ID: <k36AHGzZN2KBYXDtnAc8eqIld_VHXKG3-sP_gkjbgIU=.6f08593b-a9df-42de-a288-9ba584446921@github.com>

On Tue, 2 Jan 2024 15:22:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A lot of test changes have accumulated in the loom repo, this includes both new tests and updates to existing tests. Some of these updates can be brought to the main line. This update brings over:
>> 
>> - The existing tests for pinning use synchronized blocks. In preparation for changes to allow carrier thread be released when a virtual thread parks holding a monitor or blocks on monitorenter, these tests are changed to pin by having a native frame on the stack. This part includes test infrastructure to make it easy to add more tests that do operations while pinned. The tests still test what they were originally created to test of course.
>> 
>> - The test for the JFR jdk.VirtualThreadPinned event is refactored to allow for additional cases where the event may be reported.
>> 
>> - ThreadAPI is expanded to cover test for uncaught exception handling.
>> 
>> - GetStackTraceWhenRunnable is refactored to not use a Selector, otherwise this test will be invalidated when blocking selection operations release the carrier.
>> 
>> - StressStackOverflow is dialed down to run for 1m instead of 2mins.
>> 
>> - The use of CountDownLatch in a number of tests that poll thread state has been dropped to keep the tests as simple as possible.
>
> Alan Bateman 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 four additional commits since the last revision:
> 
>  - Revert changes to TracePinnedThreads.java
>  - Sync up from loom repo
>  - Merge
>  - Initial commit

Overall these changes look OK to me. I haven't paid much attention to the jvmti test change, but I've looked at others and they seem fine.
The `StressStackOverflow` test has its duration reduced by half which appears intentional and then there's a new test library helper class to allow pinning tasks in tests.

Just one question - doesn't the use of a new native code in the test library (the `libVThreadPinner.c`) require any build changes (I'm not too familiar with that part)?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17136#pullrequestreview-1801861084

From alanb at openjdk.org  Wed Jan  3 11:56:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 11:56:41 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <Hbsfs9dPWgHu126XKgqXt003NLlSO-paxlg4KpHfIwU=.c9b04105-cf0d-4458-9c85-05f75a307543@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
 <Hbsfs9dPWgHu126XKgqXt003NLlSO-paxlg4KpHfIwU=.c9b04105-cf0d-4458-9c85-05f75a307543@github.com>
Message-ID: <M-kwswRy4ECQvr0Orv5j28k_yRbpWmeJir4XWXBrJK0=.49c21927-f991-45c6-9a62-97982bc8fe11@github.com>

On Wed, 3 Jan 2024 11:39:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Are these heap sizing changes to reduce the resource usage of this test or is it to try and trigger any potential issue that this test verifies?

The heap usage for this one can vary quite a bit, some of the lower optimization modes lead to more contention so there are are more FJP submissions. See JDK-8303635 for one example. It's been bumped to 1.5g in the loom repo for some time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17136#discussion_r1440368527

From alanb at openjdk.org  Wed Jan  3 11:59:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 11:59:46 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <k36AHGzZN2KBYXDtnAc8eqIld_VHXKG3-sP_gkjbgIU=.6f08593b-a9df-42de-a288-9ba584446921@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
 <k36AHGzZN2KBYXDtnAc8eqIld_VHXKG3-sP_gkjbgIU=.6f08593b-a9df-42de-a288-9ba584446921@github.com>
Message-ID: <BmDx2DMZiHb_29Mt5yVe0CpqTr_EVVAQ_8PQcscW0fo=.8312ce73-b057-4f7c-a626-0dbba592c3dc@github.com>

On Wed, 3 Jan 2024 11:53:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Just one question - doesn't the use of a new native code in the test library (the `libVThreadPinner.c`) require any build changes (I'm not too familiar with that part)?

Magnus did some work in the make files some time ago to build native libs in the test/lib tree.

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

PR Comment: https://git.openjdk.org/jdk/pull/17136#issuecomment-1875259504

From jpai at openjdk.org  Wed Jan  3 11:59:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Jan 2024 11:59:48 GMT
Subject: RFR: 8320707: Virtual thread test updates [v2]
In-Reply-To: <M-kwswRy4ECQvr0Orv5j28k_yRbpWmeJir4XWXBrJK0=.49c21927-f991-45c6-9a62-97982bc8fe11@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
 <Ll6tp3-YjPbPyD8sT_dOdI5DQPCvjZ5SaBUhGdm_H9o=.581cb368-8de4-4a1c-a2b2-368e953993f9@github.com>
 <Hbsfs9dPWgHu126XKgqXt003NLlSO-paxlg4KpHfIwU=.c9b04105-cf0d-4458-9c85-05f75a307543@github.com>
 <M-kwswRy4ECQvr0Orv5j28k_yRbpWmeJir4XWXBrJK0=.49c21927-f991-45c6-9a62-97982bc8fe11@github.com>
Message-ID: <KMutveIAyJKU8xcIlkS9Q_UlcD8KInHaij7q198VUWI=.2ecb7c51-6410-4b16-a161-0a31c0ad92d7@github.com>

On Wed, 3 Jan 2024 11:53:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>  It's been bumped to 1.5g in the loom repo for some time.

Ah, I misread that change previously as reducing it from `1g` to `150m`, while infact this change is increasing it to `1500m`. Given your reference to JDK-8303635, the change looks OK to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17136#discussion_r1440371281

From alanb at openjdk.org  Wed Jan  3 13:32:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 13:32:38 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays"
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <9oRf6_NeT3KKnkiZNAwUlcK6kBs13ahenPR1iWFfcb8=.ed953023-01bb-45d0-858e-daf5d4d52093@github.com>

On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

Looks fine, surprised to see so many. I assume you'll bump the copyright date on all the files before integrating.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17241#pullrequestreview-1802064657

From erikj at openjdk.org  Wed Jan  3 13:47:45 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 Jan 2024 13:47:45 GMT
Subject: RFR: 8322873: Duplicate -ljava -ljvm options for libinstrument
In-Reply-To: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>
References: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>
Message-ID: <7-cZ9UH5eOc4fbb6u3lhKczNH7Bd5nU_BFZH0GOIfcY=.b56e71c9-c0ae-4876-aa80-32fe10398c3d@github.com>

On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The libinstrument library is linked against libjava and libjvm, twice. This is mostly harmless but Xcode 15.x generates a warning:
> 
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12 file(s)
> ld: warning: ignoring duplicate libraries: '-ljava', '-ljvm'
> 
> In particular, note that the `JDKLIB_LIBS` variable passed in to `LIBS` already contains the -ljava -ljvm options. Digging through the history it seems like this issue was introduced with [JDK-8141290](https://bugs.openjdk.org/browse/JDK-8141290).
> 
> Testing: tier1,builds-tier[2-5]

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17230#pullrequestreview-1802105849

From mbaesken at openjdk.org  Wed Jan  3 13:51:03 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 13:51:03 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v2]
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <7MyzckmpbHdkVKO-GM7_sEkpOtRCN7wf2dBe50P7ptE=.8764e79c-d68b-4737-a906-31dadf47c140@github.com>

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17241/files
  - new: https://git.openjdk.org/jdk/pull/17241/files/af1c0375..c06f35b5

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

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17241.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17241/head:pull/17241

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

From duke at openjdk.org  Wed Jan  3 13:57:59 2024
From: duke at openjdk.org (Thomas Wuerthinger)
Date: Wed, 3 Jan 2024 13:57:59 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]
In-Reply-To: <KwtMPcY1e45DC5i0xJ1DFGtVz2rVJsIBvgTA6w6UsLs=.3621cd02-67d2-4bb3-844b-7383cbdc78d9@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <EwkIDbTs7wG5q6lcikgo0ycMFRpu5VXxvMbR3tOPAM8=.40c169b6-57df-4dc7-8726-fd6d8439c541@github.com>
 <m3pEt7BjebAgGp1zZpD1LPyYKivqVkSuHGr-D6f-sVo=.f1ce13c8-c470-4ac1-882d-d9786a1a3f85@github.com>
 <l9ccGru-LPBEE-BVjVM-buQI78OiaXupEfDRfCBA4ao=.e8ae4d5e-0eef-4868-a028-238ab101b32e@github.com>
 <KwtMPcY1e45DC5i0xJ1DFGtVz2rVJsIBvgTA6w6UsLs=.3621cd02-67d2-4bb3-844b-7383cbdc78d9@github.com>
Message-ID: <zQ-YIzVMo-KlUmRNeMx-L7qd-kdXhDnX5PlSBUssJcM=.053967c3-f4b4-4b13-937c-51380e901399@github.com>

On Wed, 20 Dec 2023 10:40:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> You can't do this! The Java code knows nothing about JVM TI being enabled/disabled and will call this function unconditionally.
>> 
>> Indeed. I wonder if anyone is testing minimal builds to catch issues like this.
>
> Good catch, David!
> Filed a cleanup bug: https://bugs.openjdk.org/browse/JDK-8322538

Are these new compiler intrinsics required or an optional performance optimization? This PR creates issues for us when updating the JDK build for Graal. CC @davleopo

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1440478960

From mbaesken at openjdk.org  Wed Jan  3 13:55:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 13:55:22 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust Invokers.java too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17241/files
  - new: https://git.openjdk.org/jdk/pull/17241/files/c06f35b5..eac9ca69

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

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

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

From mbaesken at openjdk.org  Wed Jan  3 14:04:48 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Jan 2024 14:04:48 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
 <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
Message-ID: <DT_MWVwT-RJ-7yBvvVC7b1g5Ydzaieys5v3KReYzyI4=.ba3f0f55-faf2-4988-bb39-4d8539ca075a@github.com>

On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Invokers.java too

Hi Alan, thanks for the review !
I adjust the copyright year info and also some more places in Invokers.java .

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

PR Comment: https://git.openjdk.org/jdk/pull/17241#issuecomment-1875416193

From alanb at openjdk.org  Wed Jan  3 14:06:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 14:06:53 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]
In-Reply-To: <zQ-YIzVMo-KlUmRNeMx-L7qd-kdXhDnX5PlSBUssJcM=.053967c3-f4b4-4b13-937c-51380e901399@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <EwkIDbTs7wG5q6lcikgo0ycMFRpu5VXxvMbR3tOPAM8=.40c169b6-57df-4dc7-8726-fd6d8439c541@github.com>
 <m3pEt7BjebAgGp1zZpD1LPyYKivqVkSuHGr-D6f-sVo=.f1ce13c8-c470-4ac1-882d-d9786a1a3f85@github.com>
 <l9ccGru-LPBEE-BVjVM-buQI78OiaXupEfDRfCBA4ao=.e8ae4d5e-0eef-4868-a028-238ab101b32e@github.com>
 <KwtMPcY1e45DC5i0xJ1DFGtVz2rVJsIBvgTA6w6UsLs=.3621cd02-67d2-4bb3-844b-7383cbdc78d9@github.com>
 <zQ-YIzVMo-KlUmRNeMx-L7qd-kdXhDnX5PlSBUssJcM=.053967c3-f4b4-4b13-937c-51380e901399@github.com>
Message-ID: <av4HwfBaHRjBgTfIRw6riJEcMcqGY3R5wOYwNyEmbpI=.975ca00d-050d-4855-a4d3-85e9b39f1a5f@github.com>

On Wed, 3 Jan 2024 13:55:24 GMT, Thomas Wuerthinger <duke at openjdk.org> wrote:

> Are these new compiler intrinsics required or an optional performance optimization? 

Performance. If the intrinsic isn't there then some methods executed on virtual threads, or on a virtual thread as the target for some op, will have to call into the VM.  The main concern was Thread.interrupted() as it gets called very frequently in locking and concurrency code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17011#discussion_r1440487675

From alanb at openjdk.org  Wed Jan  3 15:01:50 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Jan 2024 15:01:50 GMT
Subject: Integrated: 8320707: Virtual thread test updates
In-Reply-To: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
References: <rNS3FjC-lrCkDaS7D4upOdiVZcqXrtHhzc41R2pOXgM=.8240aa70-7226-4c88-8234-fe7e54a088bf@github.com>
Message-ID: <MXBZKESEZF9KtNaei_9342CBwUfRTVqc5JBp1qGSfxM=.93062578-7619-4ceb-8f7c-79464251bd5f@github.com>

On Sat, 16 Dec 2023 17:25:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A lot of test changes have accumulated in the loom repo, this includes both new tests and updates to existing tests. Some of these updates can be brought to the main line. This update brings over:
> 
> - The existing tests for pinning use synchronized blocks. In preparation for changes to allow carrier thread be released when a virtual thread parks holding a monitor or blocks on monitorenter, these tests are changed to pin by having a native frame on the stack. This part includes test infrastructure to make it easy to add more tests that do operations while pinned. The tests still test what they were originally created to test of course.
> 
> - The test for the JFR jdk.VirtualThreadPinned event is refactored to allow for additional cases where the event may be reported.
> 
> - ThreadAPI is expanded to cover test for uncaught exception handling.
> 
> - GetStackTraceWhenRunnable is refactored to not use a Selector, otherwise this test will be invalidated when blocking selection operations release the carrier.
> 
> - StressStackOverflow is dialed down to run for 1m instead of 2mins.
> 
> - The use of CountDownLatch in a number of tests that poll thread state has been dropped to keep the tests as simple as possible.

This pull request has now been integrated.

Changeset: b67b71cd
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b67b71cd87c62f15d5b73f923c300d0f77c988f5
Stats:     981 lines in 16 files changed: 618 ins; 213 del; 150 mod

8320707: Virtual thread test updates

Reviewed-by: jpai

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

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

From aivanov at openjdk.org  Wed Jan  3 16:53:47 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 3 Jan 2024 16:53:47 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
 <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
Message-ID: <B4b8hcwJuDZ13_YT-Z3AmKful6e8fkxL1GkjF33HcuA=.0923da91-b9f8-4f70-8261-408d7db28edc@github.com>

On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Invokers.java too

Looks good to me.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17241#pullrequestreview-1802684965

From mikael at openjdk.org  Wed Jan  3 19:26:31 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 3 Jan 2024 19:26:31 GMT
Subject: Integrated: 8322873: Duplicate -ljava -ljvm options for libinstrument
In-Reply-To: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>
References: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>
Message-ID: <lNzNv-r19wRVU3TRX5eAtVV90w6uebzTjYHY1ATXnPI=.7338a5bc-a541-4012-bf84-f75743b32824@github.com>

On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The libinstrument library is linked against libjava and libjvm, twice. This is mostly harmless but Xcode 15.x generates a warning:
> 
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12 file(s)
> ld: warning: ignoring duplicate libraries: '-ljava', '-ljvm'
> 
> In particular, note that the `JDKLIB_LIBS` variable passed in to `LIBS` already contains the -ljava -ljvm options. Digging through the history it seems like this issue was introduced with [JDK-8141290](https://bugs.openjdk.org/browse/JDK-8141290).
> 
> Testing: tier1,builds-tier[2-5]

This pull request has now been integrated.

Changeset: 296c5b64
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/296c5b645a2ecd8293a02233962c4a316a506c52
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8322873: Duplicate -ljava -ljvm options for libinstrument

Reviewed-by: dholmes, jwaters, erikj

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

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

From mikael at openjdk.org  Wed Jan  3 19:26:30 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 3 Jan 2024 19:26:30 GMT
Subject: RFR: 8322873: Duplicate -ljava -ljvm options for libinstrument
In-Reply-To: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>
References: <ePJPhFyykoM6FUroz1rmLxmODDHVf9N2A8JrgvLLBPA=.a0784503-e041-484d-ac62-d983d62a2d5d@github.com>
Message-ID: <onZ1cCWqO5HPs84ScKIbLqtOTqlA--IrwvA7JZG6nPs=.2abcda70-fb81-4088-8a99-fedcdfb90253@github.com>

On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The libinstrument library is linked against libjava and libjvm, twice. This is mostly harmless but Xcode 15.x generates a warning:
> 
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12 file(s)
> ld: warning: ignoring duplicate libraries: '-ljava', '-ljvm'
> 
> In particular, note that the `JDKLIB_LIBS` variable passed in to `LIBS` already contains the -ljava -ljvm options. Digging through the history it seems like this issue was introduced with [JDK-8141290](https://bugs.openjdk.org/browse/JDK-8141290).
> 
> Testing: tier1,builds-tier[2-5]

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17230#issuecomment-1875852891

From dholmes at openjdk.org  Wed Jan  3 22:33:30 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Jan 2024 22:33:30 GMT
Subject: Integrated: 8319948: jcmd man page needs to be updated
In-Reply-To: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
References: <HfFssS3MDTcCqrUpqMDqWQead8oQ2ERVnxoRjexfH8Q=.88e4f77b-412b-45a7-841c-95f1e6f9e1b4@github.com>
Message-ID: <Fpc9Ysvbx_BOcGTzytRsw06X0SBr-8tKGFW2iHeYyOk=.bba46021-cd62-45d8-8b44-68530a85a15c@github.com>

On Tue, 2 Jan 2024 05:51:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these missing updates to the `jcmd` manpage - see JBS issue for details.
> 
> I also fixed the sub-command ordering in a few places and a couple of minor formatting fixes.
> 
> Thanks to @tstuefe for collating the initial information on what was missing. I used to `jcmd help <cmd>` option to compare the help text with the manpage text and adjusted the manpage accordingly (and found a few more omissions - some of which will be fixed by follow up RFE by the respective owners).

This pull request has now been integrated.

Changeset: 028ec7e7
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/028ec7e744f06cd8429b7b74d7b6f7020133aa94
Stats:     269 lines in 1 file changed: 171 ins; 52 del; 46 mod

8319948: jcmd man page needs to be updated

Co-authored-by: Thomas Stuefe <stuefe at openjdk.org>
Reviewed-by: kevinw, alanb

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

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

From dholmes at openjdk.org  Thu Jan  4 01:38:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Jan 2024 01:38:41 GMT
Subject: [jdk22] RFR: 8319948: jcmd man page needs to be updated
Message-ID: <vm0p2X67PO2ws-FwJKwITnNxHHrqAla9cJazrbWIdqg=.6c8e43f9-c60c-4182-9615-94a153444fd8@github.com>

Hi all,

This pull request contains a backport of commit [028ec7e](https://github.com/openjdk/jdk/commit/028ec7e744f06cd8429b7b74d7b6f7020133aa94) from the [jdk](https://github.com/openjdk/jdk/) repository.

The commit being backported was authored by @dholmes-ora on 3 Jan 2024 and was reviewed by @kevinjwalls and @alanbateman

Thanks!

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

Commit messages:
 - Backport 028ec7e744f06cd8429b7b74d7b6f7020133aa94

Changes: https://git.openjdk.org/jdk22/pull/27/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=27&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319948
  Stats: 264 lines in 1 file changed: 175 ins; 46 del; 43 mod
  Patch: https://git.openjdk.org/jdk22/pull/27.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/27/head:pull/27

PR: https://git.openjdk.org/jdk22/pull/27

From dholmes at openjdk.org  Thu Jan  4 01:52:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Jan 2024 01:52:44 GMT
Subject: [jdk22] RFR: 8319948: jcmd man page needs to be updated [v2]
In-Reply-To: <vm0p2X67PO2ws-FwJKwITnNxHHrqAla9cJazrbWIdqg=.6c8e43f9-c60c-4182-9615-94a153444fd8@github.com>
References: <vm0p2X67PO2ws-FwJKwITnNxHHrqAla9cJazrbWIdqg=.6c8e43f9-c60c-4182-9615-94a153444fd8@github.com>
Message-ID: <NHvOOHQwk1DeWjnb2U-3x8wQwEZtjs0ZmRCzNd0eJoQ=.95fe633c-7fce-416e-a21e-de830f856f3a@github.com>

> Hi all,
> 
> This pull request contains a backport of commit [028ec7e](https://github.com/openjdk/jdk/commit/028ec7e744f06cd8429b7b74d7b6f7020133aa94) from the [jdk](https://github.com/openjdk/jdk/) repository.
> 
> The commit being backported was authored by @dholmes-ora on 3 Jan 2024 and was reviewed by @kevinjwalls and @alanbateman
> 
> The backport is not clean as a JDK23 specific change to Compiler.perfmap had to be removed.
> 
> Thanks!

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Removed JDK23 specific change to Compilerp[erfmap

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

Changes:
  - all: https://git.openjdk.org/jdk22/pull/27/files
  - new: https://git.openjdk.org/jdk22/pull/27/files/06920aa7..b10de178

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

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk22/pull/27.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/27/head:pull/27

PR: https://git.openjdk.org/jdk22/pull/27

From cjplummer at openjdk.org  Thu Jan  4 02:07:47 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Jan 2024 02:07:47 GMT
Subject: RFR: 8322981: Fix 2 locations in JDI that throw IOException without
 using the "Caused by" exception
Message-ID: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>

Use "cause" argument when rethrowing an exception. See CR for details on how this helps.

Tested with all of tier1, and also ran tier2 and tier4 svc tests.

I'd like to push this as a trivial change.

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

Commit messages:
 - Use "cause" argument when rethrowing an exception

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

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

From sspitsyn at openjdk.org  Thu Jan  4 02:00:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Jan 2024 02:00:27 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <utsjnNggROZ6z0Omk8QMGg-lsxIRyqGij3r6s3cXHss=.2b0580cb-19bb-463b-b661-b3f817d2fe6b@github.com>

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

test/jdk/javax/management/Introspector/ClassLeakTest.java line 53:

> 51: 
> 52:         MBeanServer mbs = MBeanServerFactory.createMBeanServer();
> 53:         ObjectName testName = new ObjectName("x:name=Test");

Q: I'd just like to understand why it is `x:name=Test` instead of `x:type=Test` as it was before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441189776

From cjplummer at openjdk.org  Thu Jan  4 02:14:48 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Jan 2024 02:14:48 GMT
Subject: RFR: 8322980: Debug agent's dumpThread() API should update thread's
 name before printing it
Message-ID: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>

In threadControl.c, at build time you can decide to keep track of thread names by compiling with "#define DEBUG_THREADNAME". If this is also a debug build, some extra debugging functions are included in the build, including "dumpThread(ThreadNode *node)". These are intended to be called from gdb, or possibly from somewhere in the debug agent implementation, to aid with debugging. When dumpThread() prints the thread's name, it just uses the name that was stored when the thread was created. However, the thread name can change, so dumpThread() should really fetch the current thread name and print it. 

I also added some commented out code to print other useful fields of the ThreadNode, including the ThreadState. These can be enabled by the user as needed.

Tested with all of tier1, and also ran tier2 and tier4 svc tests.

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

Commit messages:
 - Minor code cleanup.
 - Undo change to not print out suspendCount by default.
 - Set get/set the thread's current name when dumping threads

Changes: https://git.openjdk.org/jdk/pull/17259/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17259&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322980
  Stats: 45 lines in 1 file changed: 43 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17259.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17259/head:pull/17259

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

From sspitsyn at openjdk.org  Thu Jan  4 02:16:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Jan 2024 02:16:22 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <3faU2Mez2ng8Kjo4d5xFHmLVehM6bZNBG8uY6SsB6co=.e633d63b-08fc-4362-9adc-23750f948bbe@github.com>

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

test/jdk/javax/management/remote/mandatory/connection/IdleTimeoutTest.java line 214:

> 212:                                        +"]: starting at " +
> 213:                                        elapsed + "ms");
> 214:                     final String name = ":name=Test_instance_" + i;

Q: The same question, why it is not started with the `d:type=` as it was before?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441198526

From cjplummer at openjdk.org  Thu Jan  4 02:22:38 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Jan 2024 02:22:38 GMT
Subject: RFR: 8322978: Remove debug agent debugMonitorTimedWait() function. It
 is no longer used.
Message-ID: <s_TGXjglxb-esA8Uw5aid_biJzeeFOWXLwNz-wMANFU=.6a20d536-05e5-4055-8c57-ed57597d2376@github.com>

Remove unused debugMonitorTimedWait() function.

Tested with all of tier1, and also ran tier2 and tier4 svc tests.

I'd like to push this as a trivial change.

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

Commit messages:
 - Remove unused debugMonitorTimedWait() function.

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

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

From duke at openjdk.org  Thu Jan  4 02:42:22 2024
From: duke at openjdk.org (Bernd)
Date: Thu, 4 Jan 2024 02:42:22 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <FtIYhiTB1ZPbi1YFS7RsIHNKjx9Bz25RMk4vGL2P5FA=.e35d03aa-a9ff-420b-928d-29cafde147e4@github.com>

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

src/java.management/share/classes/javax/management/loading/MLet.java line 68:

> 66: import javax.management.ReflectionException;
> 67: 
> 68: import static com.sun.jmx.defaults.JmxProperties.MLET_LIB_DIR;

Do those 2 statics in JmxProperties also need to be removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441216307

From ddong at openjdk.org  Thu Jan  4 03:22:32 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 4 Jan 2024 03:22:32 GMT
Subject: RFR: 8321404: Limit the number of heap dumps triggered by
 HeapDumpBeforeFullGC/AfterFullGC [v3]
In-Reply-To: <8GGPQMjfU6YWa1i0yjk7SvrJ-lnZu6TxG8zPcbWN3jE=.1a4bb16e-dfc6-46ed-84e1-f2ed3d911699@github.com>
References: <0q_yL6Q90R3L0R2-m94w1cCdbkOwapo0hLn_x_QAIVc=.f7a3b73f-9015-485f-9e9c-b4585ca84dd9@github.com>
 <8GGPQMjfU6YWa1i0yjk7SvrJ-lnZu6TxG8zPcbWN3jE=.1a4bb16e-dfc6-46ed-84e1-f2ed3d911699@github.com>
Message-ID: <dj1JUhVjpC9MeBAdxWi_0UPTOdPg77G-ooVo7tH4JXQ=.ab5f8426-bf57-4fbf-a01d-27f724df3e64@github.com>

On Sat, 16 Dec 2023 04:36:57 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this patch?
>> 
>> In the current implementation, HeapDumpBeforeFullGC/AfterFullGC will generate dumps for every FGC, increasing the risk of disk full.
>> 
>> This patch introduces a new option 'FullGCHeapDumpLimit' to limit the number of dumps triggered by HeapDumpBeforeFullGC/AfterFullGC to enhance production-friendliness.
>> 
>> Best,
>> Denghui
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine description

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/16976#issuecomment-1876254452

From ddong at openjdk.org  Thu Jan  4 03:22:34 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 4 Jan 2024 03:22:34 GMT
Subject: Integrated: 8321404: Limit the number of heap dumps triggered by
 HeapDumpBeforeFullGC/AfterFullGC
In-Reply-To: <0q_yL6Q90R3L0R2-m94w1cCdbkOwapo0hLn_x_QAIVc=.f7a3b73f-9015-485f-9e9c-b4585ca84dd9@github.com>
References: <0q_yL6Q90R3L0R2-m94w1cCdbkOwapo0hLn_x_QAIVc=.f7a3b73f-9015-485f-9e9c-b4585ca84dd9@github.com>
Message-ID: <YMqfmEz5h6swSeM1enmLjiACFvelRJIMul-NYI9Uu_k=.be49f0ee-248e-4ebb-a810-38ed56205725@github.com>

On Tue, 5 Dec 2023 16:31:24 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of this patch?
> 
> In the current implementation, HeapDumpBeforeFullGC/AfterFullGC will generate dumps for every FGC, increasing the risk of disk full.
> 
> This patch introduces a new option 'FullGCHeapDumpLimit' to limit the number of dumps triggered by HeapDumpBeforeFullGC/AfterFullGC to enhance production-friendliness.
> 
> Best,
> Denghui

This pull request has now been integrated.

Changeset: 1cf9335b
Author:    Denghui Dong <ddong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1cf9335b24639938aa64250d6862d9636f8605f8
Stats:     57 lines in 3 files changed: 53 ins; 0 del; 4 mod

8321404: Limit the number of heap dumps triggered by HeapDumpBeforeFullGC/AfterFullGC

Reviewed-by: dholmes, cjplummer

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

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

From dholmes at openjdk.org  Thu Jan  4 06:04:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Jan 2024 06:04:28 GMT
Subject: RFR: 8321404: Limit the number of heap dumps triggered by
 HeapDumpBeforeFullGC/AfterFullGC [v3]
In-Reply-To: <dj1JUhVjpC9MeBAdxWi_0UPTOdPg77G-ooVo7tH4JXQ=.ab5f8426-bf57-4fbf-a01d-27f724df3e64@github.com>
References: <0q_yL6Q90R3L0R2-m94w1cCdbkOwapo0hLn_x_QAIVc=.f7a3b73f-9015-485f-9e9c-b4585ca84dd9@github.com>
 <8GGPQMjfU6YWa1i0yjk7SvrJ-lnZu6TxG8zPcbWN3jE=.1a4bb16e-dfc6-46ed-84e1-f2ed3d911699@github.com>
 <dj1JUhVjpC9MeBAdxWi_0UPTOdPg77G-ooVo7tH4JXQ=.ab5f8426-bf57-4fbf-a01d-27f724df3e64@github.com>
Message-ID: <Lw8NpN_eiesMFKs5a6Upup2_dCGG58sUTbduFkWobJ8=.e553457c-ea99-4b23-b163-335b71e7a959@github.com>

On Thu, 4 Jan 2024 03:19:17 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refine description
>
> Thanks for the review.

@D-D-H  the new test is failing in our CI in tier3 on all platforms:

Error occurred during initialization of VM
Multiple garbage collectors selected

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

PR Comment: https://git.openjdk.org/jdk/pull/16976#issuecomment-1876414177

From dholmes at openjdk.org  Thu Jan  4 06:13:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Jan 2024 06:13:38 GMT
Subject: RFR: 8321404: Limit the number of heap dumps triggered by
 HeapDumpBeforeFullGC/AfterFullGC [v3]
In-Reply-To: <8GGPQMjfU6YWa1i0yjk7SvrJ-lnZu6TxG8zPcbWN3jE=.1a4bb16e-dfc6-46ed-84e1-f2ed3d911699@github.com>
References: <0q_yL6Q90R3L0R2-m94w1cCdbkOwapo0hLn_x_QAIVc=.f7a3b73f-9015-485f-9e9c-b4585ca84dd9@github.com>
 <8GGPQMjfU6YWa1i0yjk7SvrJ-lnZu6TxG8zPcbWN3jE=.1a4bb16e-dfc6-46ed-84e1-f2ed3d911699@github.com>
Message-ID: <v_SPGwdJVKi8pKIbTnL_K0gOM48hiBoh75VqqXvpZCs=.b0f4e2a6-21d1-4d29-ad57-e2178cacc473@github.com>

On Sat, 16 Dec 2023 04:36:57 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this patch?
>> 
>> In the current implementation, HeapDumpBeforeFullGC/AfterFullGC will generate dumps for every FGC, increasing the risk of disk full.
>> 
>> This patch introduces a new option 'FullGCHeapDumpLimit' to limit the number of dumps triggered by HeapDumpBeforeFullGC/AfterFullGC to enhance production-friendliness.
>> 
>> Best,
>> Denghui
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine description

Filed JDK-8322989

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

PR Comment: https://git.openjdk.org/jdk/pull/16976#issuecomment-1876432026

From dholmes at openjdk.org  Thu Jan  4 06:33:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Jan 2024 06:33:21 GMT
Subject: RFR: 8322978: Remove debug agent debugMonitorTimedWait() function.
 It is no longer used.
In-Reply-To: <s_TGXjglxb-esA8Uw5aid_biJzeeFOWXLwNz-wMANFU=.6a20d536-05e5-4055-8c57-ed57597d2376@github.com>
References: <s_TGXjglxb-esA8Uw5aid_biJzeeFOWXLwNz-wMANFU=.6a20d536-05e5-4055-8c57-ed57597d2376@github.com>
Message-ID: <CRSeMcf1LWOTQbPrhfdGd-UXpjY3vJlfOj5W8SnmFN8=.48eb8da6-e765-4684-9489-a984371419fb@github.com>

On Thu, 4 Jan 2024 02:18:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Remove unused debugMonitorTimedWait() function.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
> 
> I'd like to push this as a trivial change.

Seems fine and trivial.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17260#pullrequestreview-1803569347

From dholmes at openjdk.org  Thu Jan  4 06:59:20 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Jan 2024 06:59:20 GMT
Subject: RFR: 8322981: Fix 2 locations in JDI that throw IOException
 without using the "Caused by" exception
In-Reply-To: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
References: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
Message-ID: <1k0kRwAFcEekS6XxACN6ozaGQZ5NSbi6H1k3Tg8FgAU=.3f4fc8f8-3c00-4fa2-aa5e-f87aa53d0d27@github.com>

On Thu, 4 Jan 2024 02:00:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Use "cause" argument when rethrowing an exception. See CR for details on how this helps.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
> 
> I'd like to push this as a trivial change.

Setting the cause is good, but do you not also want an informative message?

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

PR Review: https://git.openjdk.org/jdk/pull/17258#pullrequestreview-1803590345

From alanb at openjdk.org  Thu Jan  4 07:20:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Jan 2024 07:20:25 GMT
Subject: [jdk22] RFR: 8319948: jcmd man page needs to be updated [v2]
In-Reply-To: <NHvOOHQwk1DeWjnb2U-3x8wQwEZtjs0ZmRCzNd0eJoQ=.95fe633c-7fce-416e-a21e-de830f856f3a@github.com>
References: <vm0p2X67PO2ws-FwJKwITnNxHHrqAla9cJazrbWIdqg=.6c8e43f9-c60c-4182-9615-94a153444fd8@github.com>
 <NHvOOHQwk1DeWjnb2U-3x8wQwEZtjs0ZmRCzNd0eJoQ=.95fe633c-7fce-416e-a21e-de830f856f3a@github.com>
Message-ID: <eFXExkTwszkqGg-snCCeB2eM2Kk5IepKvkr1zo1bdEI=.12ae0976-2d97-405f-89c1-7554a075c3dd@github.com>

On Thu, 4 Jan 2024 01:52:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [028ec7e](https://github.com/openjdk/jdk/commit/028ec7e744f06cd8429b7b74d7b6f7020133aa94) from the [jdk](https://github.com/openjdk/jdk/) repository.
>> 
>> The commit being backported was authored by @dholmes-ora on 3 Jan 2024 and was reviewed by @kevinjwalls and @alanbateman
>> 
>> The backport is not clean as a JDK23 specific change to Compiler.perfmap had to be removed.
>> 
>> Thanks!
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed JDK23 specific change to Compilerp[erfmap

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/27#pullrequestreview-1803611996

From ddong at openjdk.org  Thu Jan  4 07:32:32 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 4 Jan 2024 07:32:32 GMT
Subject: RFR: 8321404: Limit the number of heap dumps triggered by
 HeapDumpBeforeFullGC/AfterFullGC [v3]
In-Reply-To: <dj1JUhVjpC9MeBAdxWi_0UPTOdPg77G-ooVo7tH4JXQ=.ab5f8426-bf57-4fbf-a01d-27f724df3e64@github.com>
References: <0q_yL6Q90R3L0R2-m94w1cCdbkOwapo0hLn_x_QAIVc=.f7a3b73f-9015-485f-9e9c-b4585ca84dd9@github.com>
 <8GGPQMjfU6YWa1i0yjk7SvrJ-lnZu6TxG8zPcbWN3jE=.1a4bb16e-dfc6-46ed-84e1-f2ed3d911699@github.com>
 <dj1JUhVjpC9MeBAdxWi_0UPTOdPg77G-ooVo7tH4JXQ=.ab5f8426-bf57-4fbf-a01d-27f724df3e64@github.com>
Message-ID: <OY2r2x0fgy_kntDWhUM5BG-LfP1rH0hOwMSnVXBXPA8=.094d4d75-f783-4f45-8304-4c926df02410@github.com>

On Thu, 4 Jan 2024 03:19:17 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refine description
>
> Thanks for the review.

> @D-D-H the new test is failing in our CI in tier3 on all platforms:
> 
> Error occurred during initialization of VM Multiple garbage collectors selected

Sorry for that, I'll take a look at it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16976#issuecomment-1876600685

From ddong at openjdk.org  Thu Jan  4 08:07:30 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 4 Jan 2024 08:07:30 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails
Message-ID: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>

Hi,

Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.

Thanks.

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

Commit messages:
 - 8322989: New test serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails

Changes: https://git.openjdk.org/jdk/pull/17263/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17263&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322989
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17263.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17263/head:pull/17263

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

From mbaesken at openjdk.org  Thu Jan  4 08:09:32 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 4 Jan 2024 08:09:32 GMT
Subject: RFR: JDK-8322782: Clean up usages of unnecessary fully qualified
 class name "java.util.Arrays" [v3]
In-Reply-To: <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
 <8dn2hPVVlVQ8b4XuM9pvc1ycDWuzzP6xWMGFf6ubW88=.c26e8fb7-1c7c-4604-8b06-6dc16adc681d@github.com>
Message-ID: <h5_ZKH7cVAf9LLYbYwTqfoD5L_UE2_KUlZZuDRQzckA=.3901c22a-ffc3-4a4b-9c93-059565a42682@github.com>

On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Invokers.java too

Hi Alexey, thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/17241#issuecomment-1876673066

From mbaesken at openjdk.org  Thu Jan  4 08:09:34 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 4 Jan 2024 08:09:34 GMT
Subject: Integrated: JDK-8322782: Clean up usages of unnecessary fully
 qualified class name "java.util.Arrays"
In-Reply-To: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
References: <M6EUVBshiC84-7Y0EvTN8xSH9rSlzq21NklrMpakBeM=.7af1af64-c9c8-4b9e-ab60-81d96954b525@github.com>
Message-ID: <3omokFt2Z2o6tspIqc14e1qKWtD9FygYKsoXsHjHnI0=.f649ef22-6972-4008-8df0-f5e0dec1038a@github.com>

On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar cleanup has been proposed before (and was done in the change). But there are a number of other places in the codebase where the import is done and still the unneeded fully qualified class name "java.util.Arrays" is used so more cleanups can be done.

This pull request has now been integrated.

Changeset: 1369c545
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1369c545ac51d7b5ff623d486e28c939869fecb8
Stats:     29 lines in 9 files changed: 0 ins; 0 del; 29 mod

8322782: Clean up usages of unnecessary fully qualified class name "java.util.Arrays"

Reviewed-by: alanb, aivanov

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

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

From kevinw at openjdk.org  Thu Jan  4 09:30:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 09:30:29 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature
In-Reply-To: <FtIYhiTB1ZPbi1YFS7RsIHNKjx9Bz25RMk4vGL2P5FA=.e35d03aa-a9ff-420b-928d-29cafde147e4@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <FtIYhiTB1ZPbi1YFS7RsIHNKjx9Bz25RMk4vGL2P5FA=.e35d03aa-a9ff-420b-928d-29cafde147e4@github.com>
Message-ID: <fCpcTLcHhBY7lGj01GJEiw1ea9Zz7bY3B-yS5tchg94=.61e3c194-feaf-444e-bc15-8a44aa8b8ee3@github.com>

On Thu, 4 Jan 2024 02:39:17 GMT, Bernd <duke at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> src/java.management/share/classes/javax/management/loading/MLet.java line 68:
> 
>> 66: import javax.management.ReflectionException;
>> 67: 
>> 68: import static com.sun.jmx.defaults.JmxProperties.MLET_LIB_DIR;
> 
> Do those 2 statics in JmxProperties also need to be removed?

Yes good question - there are a couple of other definitions, they will be removed later if not now.

I was hesitant and was thinking maybe they should be removed later.  But looking again I find no other references to these, they are not part of the documented interface, so I should update this to remove them now.


src/java.management/share/classes/com/sun/jmx/defaults/JmxProperties.java
MLET_LIB_DIR only used by MLet.java
MLET_LOGGER_NAME used in same file to define MLET_LOGGER 
MLET_LOGGER used by MLet.java and MLetParser.java

JMX_INITIAL_BUILDER defined above MLET_LIB_DIR has an incorrect name in the comment.


src/java.management/share/classes/com/sun/jmx/defaults/ServiceName.java
public static final String MLET = "type=MLet"; only used by MLet.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441521876

From kevinw at openjdk.org  Thu Jan  4 10:05:27 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 10:05:27 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature
In-Reply-To: <utsjnNggROZ6z0Omk8QMGg-lsxIRyqGij3r6s3cXHss=.2b0580cb-19bb-463b-b661-b3f817d2fe6b@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <utsjnNggROZ6z0Omk8QMGg-lsxIRyqGij3r6s3cXHss=.2b0580cb-19bb-463b-b661-b3f817d2fe6b@github.com>
Message-ID: <bRIUzbJe7aG1idSpsM239YAptmweGq4W7OM6ZgtT_aw=.728a3041-a29e-4535-b77f-a25d2ecade0b@github.com>

On Thu, 4 Jan 2024 01:57:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> test/jdk/javax/management/Introspector/ClassLeakTest.java line 53:
> 
>> 51: 
>> 52:         MBeanServer mbs = MBeanServerFactory.createMBeanServer();
>> 53:         ObjectName testName = new ObjectName("x:name=Test");
> 
> Q: I'd just like to understand why it is `x:name=Test` instead of `x:type=Test` as it was before.

These ObjectName patterns (domain:key=value) don't matter very much for these test mbeans.
We just need an ObjectName to pass when registering the MBean, and also to use when querying, e.g. calling getMBeanInfo.

The domain part was "x" but could be empty, but it must also define at least one key=value.
The "type=mlet" might still work (I just tested: it does 8-) ), but I wanted to remove it as it would be misleading.
So we need to add some key=value and just giving a name is enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441557767

From stefank at openjdk.org  Thu Jan  4 10:04:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Jan 2024 10:04:21 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails
In-Reply-To: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
Message-ID: <ScedhP-gmKnchR8922JvTtUwTfXbz77qe5N4lwApE5U=.9532921e-d864-4bf4-a81c-78882bd9ae7a@github.com>

On Thu, 4 Jan 2024 08:01:57 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
> 
> Thanks.

I prefer if we stay away from using `@requires vm.flagless` if possible. For this test I think we can just add `@requires vm.gc.Serial`? Could you try that instead?

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17263#pullrequestreview-1803844916

From kevinw at openjdk.org  Thu Jan  4 10:25:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 10:25:26 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature
In-Reply-To: <bRIUzbJe7aG1idSpsM239YAptmweGq4W7OM6ZgtT_aw=.728a3041-a29e-4535-b77f-a25d2ecade0b@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <utsjnNggROZ6z0Omk8QMGg-lsxIRyqGij3r6s3cXHss=.2b0580cb-19bb-463b-b661-b3f817d2fe6b@github.com>
 <bRIUzbJe7aG1idSpsM239YAptmweGq4W7OM6ZgtT_aw=.728a3041-a29e-4535-b77f-a25d2ecade0b@github.com>
Message-ID: <shG_MRYCUwSwCKWqTzwtePTktHnNbI6I2WAjb4a2Bos=.2bc1b528-4940-4a56-8b26-670f4b60e356@github.com>

On Thu, 4 Jan 2024 10:02:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/javax/management/Introspector/ClassLeakTest.java line 53:
>> 
>>> 51: 
>>> 52:         MBeanServer mbs = MBeanServerFactory.createMBeanServer();
>>> 53:         ObjectName testName = new ObjectName("x:name=Test");
>> 
>> Q: I'd just like to understand why it is `x:name=Test` instead of `x:type=Test` as it was before.
>
> These ObjectName patterns (domain:key=value) don't matter very much for these test mbeans.
> We just need an ObjectName to pass when registering the MBean, and also to use when querying, e.g. calling getMBeanInfo.
> 
> The domain part was "x" but could be empty, but it must also define at least one key=value.
> The "type=mlet" might still work (I just tested: it does 8-) ), but I wanted to remove it as it would be misleading.
> So we need to add some key=value and just giving a name is enough.

In ClassLeakTest.java, it was creating two MBeans, but now only creates one.
It was creating a PrivateMLet (which it registers using type=mlet) and comparing classloader with another MBean.  The second MBean is created using the m-let name as the "loader name" parameter to mbs.createMBean().  This doesn't make sense without MLets, which are classloaders.  

The test retains is stated goal of checking a reference to the MBean class is not retained after it is unloaded.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441576425

From kevinw at openjdk.org  Thu Jan  4 10:33:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 10:33:29 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature
In-Reply-To: <3faU2Mez2ng8Kjo4d5xFHmLVehM6bZNBG8uY6SsB6co=.e633d63b-08fc-4362-9adc-23750f948bbe@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <3faU2Mez2ng8Kjo4d5xFHmLVehM6bZNBG8uY6SsB6co=.e633d63b-08fc-4362-9adc-23750f948bbe@github.com>
Message-ID: <xcxSTB4E34lQiRVYz1ZeOY5LmFdcqv7yUWVhNtH6a4Q=.96cc6153-2b80-4afc-b5cd-d47688f5bf04@github.com>

On Thu, 4 Jan 2024 02:13:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> test/jdk/javax/management/remote/mandatory/connection/IdleTimeoutTest.java line 214:
> 
>> 212:                                        +"]: starting at " +
>> 213:                                        elapsed + "ms");
>> 214:                     final String name = ":name=Test_instance_" + i;
> 
> Q: The same question, why it is not started with the `d:type=` as it was before?

Yes, just an identifier, the content is not very important.
type=mlet should be removed to clarify it's not an m-let, but would not stop it from working.
I could leave this one unchanged other than removing "type=mlet".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1441585077

From kevinw at openjdk.org  Thu Jan  4 10:36:43 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 10:36:43 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v2]
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <lix2RuvTrcsGSc_ZTB9VGebvjsEnwwEqmZY1Npwgr5c=.c8d41ea5-12a8-4a6e-926c-5c0af4cc49b1@github.com>

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

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

  IdleTimeoutTest ObjectName more like original

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16363/files
  - new: https://git.openjdk.org/jdk/pull/16363/files/cc6e0d28..ec9f5390

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

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

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

From kevinw at openjdk.org  Thu Jan  4 10:48:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 10:48:38 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

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

  Remove unnecessary MLET_ Properties

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16363/files
  - new: https://git.openjdk.org/jdk/pull/16363/files/ec9f5390..29ec31f2

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

  Stats: 35 lines in 2 files changed: 0 ins; 30 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16363.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16363/head:pull/16363

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

From dholmes at openjdk.org  Thu Jan  4 11:59:20 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Jan 2024 11:59:20 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails
In-Reply-To: <ScedhP-gmKnchR8922JvTtUwTfXbz77qe5N4lwApE5U=.9532921e-d864-4bf4-a81c-78882bd9ae7a@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <ScedhP-gmKnchR8922JvTtUwTfXbz77qe5N4lwApE5U=.9532921e-d864-4bf4-a81c-78882bd9ae7a@github.com>
Message-ID: <GlyVxcSL9zuePWJt-KEVYK8kKwr2jbavboV49yC6lgY=.b42f423f-d656-49dd-9cc5-8869e0cc1692@github.com>

On Thu, 4 Jan 2024 10:01:41 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> For this test I think we can just add @requires vm.gc.Serial

@stefank but it doesn't require that, it explicitly sets that. The test requires that no specific GC has been requested.

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1876977003

From sspitsyn at openjdk.org  Thu Jan  4 12:38:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Jan 2024 12:38:21 GMT
Subject: RFR: 8322978: Remove debug agent debugMonitorTimedWait() function.
 It is no longer used.
In-Reply-To: <s_TGXjglxb-esA8Uw5aid_biJzeeFOWXLwNz-wMANFU=.6a20d536-05e5-4055-8c57-ed57597d2376@github.com>
References: <s_TGXjglxb-esA8Uw5aid_biJzeeFOWXLwNz-wMANFU=.6a20d536-05e5-4055-8c57-ed57597d2376@github.com>
Message-ID: <Ytg5K4okOta8JAK0UUBaQneAwxJyj3QkGwmnYH1P6do=.a027243c-70f6-4a10-942a-c0e74b786296@github.com>

On Thu, 4 Jan 2024 02:18:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Remove unused debugMonitorTimedWait() function.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
> 
> I'd like to push this as a trivial change.

Looks okay.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17260#pullrequestreview-1804079022

From dchuyko at openjdk.org  Thu Jan  4 13:26:33 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 4 Jan 2024 13:26:33 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v20]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <UqpVESKHo9HFeS9FhYJzg4DKRjXtrbKofq9w482qRoA=.cd9a5f07-4f94-4e74-8ad4-b2124b84cb3d@github.com>

> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
> 
> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
> 
> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods).
> 
> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter.
> 
> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them.
> 
> In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ...

Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:

 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Deopt osr, cleanups
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - ... and 28 more: https://git.openjdk.org/jdk/compare/27d5f5c2...691ea329

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

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=19
  Stats: 381 lines in 15 files changed: 348 ins; 3 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/14111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111

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

From ddong at openjdk.org  Thu Jan  4 14:45:22 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 4 Jan 2024 14:45:22 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails
In-Reply-To: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
Message-ID: <gvpILSIPRPLQWkVXkPO8QtCkvBurlE0PVJrX14yrLAM=.f20d1dbf-6796-494c-9262-c0d326d4a8b4@github.com>

On Thu, 4 Jan 2024 08:01:57 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
> 
> Thanks.

I found other tests that set -XX:+UseSerialGC explicitly have `@requires vm.gc.Serial` or  `vm.gc == "Serial" | vm.gc == "null"`

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1877208345

From ddong at openjdk.org  Thu Jan  4 14:48:21 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 4 Jan 2024 14:48:21 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails
In-Reply-To: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
Message-ID: <GrNqLzvsh9wUBXeFQE4BpkN5J8vU66ixj6fumVz-gs4=.1390b529-adca-4db6-bb84-b89b8b6dda90@github.com>

On Thu, 4 Jan 2024 08:01:57 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
> 
> Thanks.

And for this test, I think `@requires vm.opt.DisableExplicitGC != "true"` is also needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1877213165

From ddong at openjdk.org  Thu Jan  4 15:22:36 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 4 Jan 2024 15:22:36 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v2]
In-Reply-To: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
Message-ID: <4SEIfK-jErnMkyGrSbHYGYD7nJ1fanb6pQj_Q32kA5M=.88490eea-c904-47a1-a812-98f88361951d@github.com>

> Hi,
> 
> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
> 
> Thanks.

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17263/files
  - new: https://git.openjdk.org/jdk/pull/17263/files/737a3d79..1eabda7e

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

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

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

From ddong at openjdk.org  Thu Jan  4 15:37:33 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 4 Jan 2024 15:37:33 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v3]
In-Reply-To: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
Message-ID: <rr8G_Sx1maCFQBx2dOL8YKW8fCCsk_6fZldQF3wNkso=.3ac5c7d3-a366-4b3d-927f-ff6bc49327e1@github.com>

> Hi,
> 
> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
> 
> Thanks.

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17263/files
  - new: https://git.openjdk.org/jdk/pull/17263/files/1eabda7e..47519b1a

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

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

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

From stefank at openjdk.org  Thu Jan  4 15:57:20 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Jan 2024 15:57:20 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v3]
In-Reply-To: <GlyVxcSL9zuePWJt-KEVYK8kKwr2jbavboV49yC6lgY=.b42f423f-d656-49dd-9cc5-8869e0cc1692@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <ScedhP-gmKnchR8922JvTtUwTfXbz77qe5N4lwApE5U=.9532921e-d864-4bf4-a81c-78882bd9ae7a@github.com>
 <GlyVxcSL9zuePWJt-KEVYK8kKwr2jbavboV49yC6lgY=.b42f423f-d656-49dd-9cc5-8869e0cc1692@github.com>
Message-ID: <6tDoJuv4y7KX6axgCjYkSDBFNftSmPCnrkpJKGEfnuk=.cd5bf578-b878-4d49-9f18-a0cf89424585@github.com>

On Thu, 4 Jan 2024 11:56:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > For this test I think we can just add @requires vm.gc.Serial
> 
> @stefank but it doesn't require that, it explicitly sets that. The test requires that no specific GC has been requested.

@dholmes-ora `@requires vm.gc.Serial` doesn't mean that it requires Serial to be set. It's more subtle than that. It means that either Serial is set (and available) or it can be set (because no other GC has been selected). It is the correct requires line to use when you explicitly set the GC in the test. Look at our other GC tests.

For example:
test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java

Without selecting a GC, the test is run:

$ make -C ../build/fastdebug test TEST=test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java JTREG="JAVA_OPTIONS=-Xmx128m"
...
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:open/test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java
                                                         1     1     0     0  


With Serial as the selected GC, the test is run:

$ make -C ../build/fastdebug test TEST=test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java JTREG="JAVA_OPTIONS=-Xmx128m -XX:+UseSerialGC"
...
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:open/test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java
                                                         1     1     0     0   


With G1 as the selected GC, the test is excluded:

$ make -C ../build/fastdebug test TEST=test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java JTREG="JAVA_OPTIONS=-Xmx128m -XX:+UseG1GC"
...
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:open/test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java
                                                         0     0     0     0

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1877333642

From dcubed at openjdk.org  Thu Jan  4 16:09:21 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 Jan 2024 16:09:21 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v3]
In-Reply-To: <rr8G_Sx1maCFQBx2dOL8YKW8fCCsk_6fZldQF3wNkso=.3ac5c7d3-a366-4b3d-927f-ff6bc49327e1@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <rr8G_Sx1maCFQBx2dOL8YKW8fCCsk_6fZldQF3wNkso=.3ac5c7d3-a366-4b3d-927f-ff6bc49327e1@github.com>
Message-ID: <dOQi_k9vK4pElo6wzfVxYGGwzkuixOqQ22gX7WXWp1M=.1bc4fa52-8b9e-4199-b16e-32ee34bf6532@github.com>

On Thu, 4 Jan 2024 15:37:33 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>> 
>> Thanks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

We're up to 48 test failures so far (8 x 6 Tier3 buildIDs) which is very, very noisy.
Since it looks like this PR is still being discussed, I'm going to ProblemList this
test in order to get the noise level back down.

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1877355597

From ddong at openjdk.org  Thu Jan  4 16:12:20 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 4 Jan 2024 16:12:20 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v3]
In-Reply-To: <dOQi_k9vK4pElo6wzfVxYGGwzkuixOqQ22gX7WXWp1M=.1bc4fa52-8b9e-4199-b16e-32ee34bf6532@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <rr8G_Sx1maCFQBx2dOL8YKW8fCCsk_6fZldQF3wNkso=.3ac5c7d3-a366-4b3d-927f-ff6bc49327e1@github.com>
 <dOQi_k9vK4pElo6wzfVxYGGwzkuixOqQ22gX7WXWp1M=.1bc4fa52-8b9e-4199-b16e-32ee34bf6532@github.com>
Message-ID: <Go0zmDm236h5ToeBFaYidNG0vHpoEeLCOaeA8xWMKzo=.2ff77bfe-2832-4b0f-bf38-2ac26f5f9cb1@github.com>

On Thu, 4 Jan 2024 16:06:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> We're up to 48 test failures so far (8 x 6 Tier3 buildIDs) which is very, very noisy. Since it looks like this PR is still being discussed, I'm going to ProblemList this test in order to get the noise level back down.

sorry for that :-(

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1877361239

From ctornqvi at openjdk.org  Thu Jan  4 16:31:40 2024
From: ctornqvi at openjdk.org (Christian Tornqvist)
Date: Thu, 4 Jan 2024 16:31:40 GMT
Subject: Integrated: 8323011: ProblemList
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java
In-Reply-To: <Ew-jT7fJpRjwoAEHXm6H1aSu9dwa-24TcYRrFPuq9-o=.07c10612-0215-4d1e-ae15-160598dbbf51@github.com>
References: <Ew-jT7fJpRjwoAEHXm6H1aSu9dwa-24TcYRrFPuq9-o=.07c10612-0215-4d1e-ae15-160598dbbf51@github.com>
Message-ID: <lhi9nM-ajfU4QYh6lgsu_SNWUUfy3LmnyLgyyf0Vxn0=.0739eace-175f-4337-be73-c582eca7b180@github.com>

On Thu, 4 Jan 2024 16:24:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to  ProblemList serviceability/HeapDump/FullGCHeapDumpLimitTest.java
> on all platforms.
> 
> We're already up to 54 failures in Tier3 and Tier5.

Marked as reviewed by ctornqvi (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17269#pullrequestreview-1804540865

From dcubed at openjdk.org  Thu Jan  4 16:31:42 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 Jan 2024 16:31:42 GMT
Subject: Integrated: 8323011: ProblemList
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java
In-Reply-To: <Ew-jT7fJpRjwoAEHXm6H1aSu9dwa-24TcYRrFPuq9-o=.07c10612-0215-4d1e-ae15-160598dbbf51@github.com>
References: <Ew-jT7fJpRjwoAEHXm6H1aSu9dwa-24TcYRrFPuq9-o=.07c10612-0215-4d1e-ae15-160598dbbf51@github.com>
Message-ID: <Af0cviiCDsyUyUY8Bdr-9ZS2ui97xk72bS1vx3Mp8ZA=.944c3adb-058a-4788-8ecd-9e2230c140a0@github.com>

On Thu, 4 Jan 2024 16:24:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to  ProblemList serviceability/HeapDump/FullGCHeapDumpLimitTest.java
> on all platforms.
> 
> We're already up to 54 failures in Tier3 and Tier5.

This pull request has now been integrated.

Changeset: ea19e9c6
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea19e9c6aa86034055a39c8780156ae4c569de5b
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8323011: ProblemList serviceability/HeapDump/FullGCHeapDumpLimitTest.java

Reviewed-by: azvegint, ctornqvi

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

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

From dcubed at openjdk.org  Thu Jan  4 16:31:39 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 Jan 2024 16:31:39 GMT
Subject: Integrated: 8323011: ProblemList
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java
Message-ID: <Ew-jT7fJpRjwoAEHXm6H1aSu9dwa-24TcYRrFPuq9-o=.07c10612-0215-4d1e-ae15-160598dbbf51@github.com>

A trivial fix to  ProblemList serviceability/HeapDump/FullGCHeapDumpLimitTest.java
on all platforms.

We're already up to 54 failures in Tier3 and Tier5.

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

Commit messages:
 - 8323011: ProblemList serviceability/HeapDump/FullGCHeapDumpLimitTest.java

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

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

From dcubed at openjdk.org  Thu Jan  4 16:31:41 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 Jan 2024 16:31:41 GMT
Subject: Integrated: 8323011: ProblemList
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java
In-Reply-To: <hjXlNXk8MznrkFACfNVXW0bSRBjAHXQ4zfzeDs7oZRA=.60f1b9cd-8399-4e8f-9a31-dece8bac1bc3@github.com>
References: <Ew-jT7fJpRjwoAEHXm6H1aSu9dwa-24TcYRrFPuq9-o=.07c10612-0215-4d1e-ae15-160598dbbf51@github.com>
 <hjXlNXk8MznrkFACfNVXW0bSRBjAHXQ4zfzeDs7oZRA=.60f1b9cd-8399-4e8f-9a31-dece8bac1bc3@github.com>
Message-ID: <SOQUTYQh6lAL5FBhBi4MiAxhaLFfJnC0N_QwDDkfrBM=.c2d02e43-8f95-4edf-85f3-481d8dad4383@github.com>

On Thu, 4 Jan 2024 16:27:05 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> A trivial fix to  ProblemList serviceability/HeapDump/FullGCHeapDumpLimitTest.java
>> on all platforms.
>> 
>> We're already up to 54 failures in Tier3 and Tier5.
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint and @ctornqvi - Thanks for the lightning fast reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17269#issuecomment-1877394481

From azvegint at openjdk.org  Thu Jan  4 16:31:40 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 4 Jan 2024 16:31:40 GMT
Subject: Integrated: 8323011: ProblemList
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java
In-Reply-To: <Ew-jT7fJpRjwoAEHXm6H1aSu9dwa-24TcYRrFPuq9-o=.07c10612-0215-4d1e-ae15-160598dbbf51@github.com>
References: <Ew-jT7fJpRjwoAEHXm6H1aSu9dwa-24TcYRrFPuq9-o=.07c10612-0215-4d1e-ae15-160598dbbf51@github.com>
Message-ID: <hjXlNXk8MznrkFACfNVXW0bSRBjAHXQ4zfzeDs7oZRA=.60f1b9cd-8399-4e8f-9a31-dece8bac1bc3@github.com>

On Thu, 4 Jan 2024 16:24:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to  ProblemList serviceability/HeapDump/FullGCHeapDumpLimitTest.java
> on all platforms.
> 
> We're already up to 54 failures in Tier3 and Tier5.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17269#pullrequestreview-1804540855

From dcubed at openjdk.org  Thu Jan  4 16:33:23 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 Jan 2024 16:33:23 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v3]
In-Reply-To: <rr8G_Sx1maCFQBx2dOL8YKW8fCCsk_6fZldQF3wNkso=.3ac5c7d3-a366-4b3d-927f-ff6bc49327e1@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <rr8G_Sx1maCFQBx2dOL8YKW8fCCsk_6fZldQF3wNkso=.3ac5c7d3-a366-4b3d-927f-ff6bc49327e1@github.com>
Message-ID: <_3S4IRXU-i82TWZmQo0VZbQ0bhj5wG3MUfY33go_fAE=.291691c5-7f54-49ef-8ee1-f16844bc8efa@github.com>

On Thu, 4 Jan 2024 15:37:33 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>> 
>> Thanks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

ProblemListing PR has been approved and should integrate shortly:
https://github.com/openjdk/jdk/pull/17269
Please update your repo to include that fix so that you can remove the
test from the ProblemList.txt file in your PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1877400820

From kevinw at openjdk.org  Thu Jan  4 17:03:23 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Jan 2024 17:03:23 GMT
Subject: RFR: 8322980: Debug agent's dumpThread() API should update
 thread's name before printing it
In-Reply-To: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
References: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
Message-ID: <63l2t5lhDYm_kp0CHcR5T7I7dVAY4YiLQ6DAF9aIDj4=.7d7bf12f-3568-469b-a690-b79d0e5fe465@github.com>

On Thu, 4 Jan 2024 02:06:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In threadControl.c, at build time you can decide to keep track of thread names by compiling with "#define DEBUG_THREADNAME". If this is also a debug build, some extra debugging functions are included in the build, including "dumpThread(ThreadNode *node)". These are intended to be called from gdb, or possibly from somewhere in the debug agent implementation, to aid with debugging. When dumpThread() prints the thread's name, it just uses the name that was stored when the thread was created. However, the thread name can change, so dumpThread() should really fetch the current thread name and print it. 
> 
> I also added some commented out code to print other useful fields of the ThreadNode, including the ThreadState. These can be enabled by the user as needed.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.

Looks good I think.

A future idea could be to have these ifdefs active in the debug JDK build.  I wouldn't normally run the debugger from the debug build, but if you wanted this extra info it would be more convenient if it was in the debug JDK bundle.

(The changed output might fool some tests so would need checking, but might be worth considering.)

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17259#pullrequestreview-1804619393

From cjplummer at openjdk.org  Thu Jan  4 17:17:21 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Jan 2024 17:17:21 GMT
Subject: RFR: 8322981: Fix 2 locations in JDI that throw IOException
 without using the "Caused by" exception
In-Reply-To: <1k0kRwAFcEekS6XxACN6ozaGQZ5NSbi6H1k3Tg8FgAU=.3f4fc8f8-3c00-4fa2-aa5e-f87aa53d0d27@github.com>
References: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
 <1k0kRwAFcEekS6XxACN6ozaGQZ5NSbi6H1k3Tg8FgAU=.3f4fc8f8-3c00-4fa2-aa5e-f87aa53d0d27@github.com>
Message-ID: <RQdjJh4CvhFkJA-SevN4i-iIy0VhC4W-kcp79TQcj-E=.73cc932d-c601-41df-8ea5-6de627202ec3@github.com>

On Thu, 4 Jan 2024 06:56:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Setting the cause is good, but do you not also want an informative message?

Not necessary.

public class Test {
    public static void main(String[] args) {
        try {
            try {
                throw new Throwable("hello");
            } catch (Throwable t) {
                throw new Throwable(t);
            }
        } catch (Throwable t) {
            t.printStackTrace(System.out);
        }
    }
}

produces:

java.lang.Throwable: java.lang.Throwable: hello
	at Test.main(Test.java:7)
Caused by: java.lang.Throwable: hello
	at Test.main(Test.java:5)

If I change the second throw to:

                throw new Throwable(t,"goodbye");

You get:

java.lang.Throwable: goodbye
	at Test.main(Test.java:7)
Caused by: java.lang.Throwable: hello
	at Test.main(Test.java:5)

So it appears that for the first line of the prinstStackTrace() output, it prints the exception name and then the message if there is one. If there is no message then it instead prints the cause exception name, and its message if it has one.

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

PR Comment: https://git.openjdk.org/jdk/pull/17258#issuecomment-1877474604

From cjplummer at openjdk.org  Thu Jan  4 17:24:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Jan 2024 17:24:23 GMT
Subject: RFR: 8322980: Debug agent's dumpThread() API should update
 thread's name before printing it
In-Reply-To: <63l2t5lhDYm_kp0CHcR5T7I7dVAY4YiLQ6DAF9aIDj4=.7d7bf12f-3568-469b-a690-b79d0e5fe465@github.com>
References: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
 <63l2t5lhDYm_kp0CHcR5T7I7dVAY4YiLQ6DAF9aIDj4=.7d7bf12f-3568-469b-a690-b79d0e5fe465@github.com>
Message-ID: <oaoXhOFSzlXkTXEhbhptbDB6bT1C_wzOzR0fPLOd6NM=.9eba3d72-bc53-43c4-8aa9-80c6e4b6150b@github.com>

On Thu, 4 Jan 2024 17:00:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> A future idea could be to have these ifdefs active in the debug JDK build. I wouldn't normally run the debugger from the debug build, but if you wanted this extra info it would be more convenient if it was in the debug JDK bundle.

Possibly DEBUG_THREADNAME should be enabled in debug builds, but I opted not to long ago because of the potential footprint and performance cost. For the `#if 0` code, generally speaking it results in too much output and is really just meant as examples of other things you might want to include in the output, but most cases you would prefer not to have all of it. A possible solution would be to have each line of output controlled by a global variable (either a bitwise flag or a global per line), and then the user could enable additional output at runtime (from within gdb), but I don't feel this is worth the effort.

There aren't any test output concern unless you introduce calls to these API, in which case they are a concern whether or not all the `#if 0` stuff is included.

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

PR Comment: https://git.openjdk.org/jdk/pull/17259#issuecomment-1877483546

From cjplummer at openjdk.org  Thu Jan  4 17:25:29 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Jan 2024 17:25:29 GMT
Subject: RFR: 8322978: Remove debug agent debugMonitorTimedWait() function.
 It is no longer used.
In-Reply-To: <s_TGXjglxb-esA8Uw5aid_biJzeeFOWXLwNz-wMANFU=.6a20d536-05e5-4055-8c57-ed57597d2376@github.com>
References: <s_TGXjglxb-esA8Uw5aid_biJzeeFOWXLwNz-wMANFU=.6a20d536-05e5-4055-8c57-ed57597d2376@github.com>
Message-ID: <0NRjnvuGbNssa-BZAoRBPEOIqiu8_UDfYSqxLB-q5Vc=.66df2387-6974-4860-a91d-b5ecec94cbad@github.com>

On Thu, 4 Jan 2024 02:18:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Remove unused debugMonitorTimedWait() function.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
> 
> I'd like to push this as a trivial change.

Thanks for the reviews David and Serguei.

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

PR Comment: https://git.openjdk.org/jdk/pull/17260#issuecomment-1877484995

From cjplummer at openjdk.org  Thu Jan  4 17:25:30 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 Jan 2024 17:25:30 GMT
Subject: Integrated: 8322978: Remove debug agent debugMonitorTimedWait()
 function. It is no longer used.
In-Reply-To: <s_TGXjglxb-esA8Uw5aid_biJzeeFOWXLwNz-wMANFU=.6a20d536-05e5-4055-8c57-ed57597d2376@github.com>
References: <s_TGXjglxb-esA8Uw5aid_biJzeeFOWXLwNz-wMANFU=.6a20d536-05e5-4055-8c57-ed57597d2376@github.com>
Message-ID: <OuHsyP1aZYAAI3c5d5qB_aCUgLq3vjfp_TrSlAHRJe8=.1510c236-e860-4cd6-8057-633265d50bc9@github.com>

On Thu, 4 Jan 2024 02:18:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Remove unused debugMonitorTimedWait() function.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
> 
> I'd like to push this as a trivial change.

This pull request has now been integrated.

Changeset: 3fbccb01
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3fbccb01dcffe9eb48a08d99aab0e9aa311a18cf
Stats:     20 lines in 2 files changed: 0 ins; 18 del; 2 mod

8322978: Remove debug agent debugMonitorTimedWait() function. It is no longer used.

Reviewed-by: dholmes, sspitsyn

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

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

From dholmes at openjdk.org  Thu Jan  4 20:40:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Jan 2024 20:40:24 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v3]
In-Reply-To: <6tDoJuv4y7KX6axgCjYkSDBFNftSmPCnrkpJKGEfnuk=.cd5bf578-b878-4d49-9f18-a0cf89424585@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <ScedhP-gmKnchR8922JvTtUwTfXbz77qe5N4lwApE5U=.9532921e-d864-4bf4-a81c-78882bd9ae7a@github.com>
 <GlyVxcSL9zuePWJt-KEVYK8kKwr2jbavboV49yC6lgY=.b42f423f-d656-49dd-9cc5-8869e0cc1692@github.com>
 <6tDoJuv4y7KX6axgCjYkSDBFNftSmPCnrkpJKGEfnuk=.cd5bf578-b878-4d49-9f18-a0cf89424585@github.com>
Message-ID: <uvojOmAhkGg-Tjo6PvWdiUYNh9ZxgHNqCbhnNQ-YQk8=.585a5ae1-04f9-4dd0-9577-3ce019302dff@github.com>

On Thu, 4 Jan 2024 15:54:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> It means that either Serial is set (and available) or it can be set 

@stefank that is subtle - and unintuitive. Thanks for explaining.

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1877728970

From dholmes at openjdk.org  Thu Jan  4 22:52:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Jan 2024 22:52:21 GMT
Subject: RFR: 8322981: Fix 2 locations in JDI that throw IOException
 without using the "Caused by" exception
In-Reply-To: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
References: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
Message-ID: <0cxVfy_b-0_6ZMJXfq-wAZNReiTp9BeH6DcEhvo8SIE=.28b90575-9ceb-4fb7-98a7-f23e1b05b538@github.com>

On Thu, 4 Jan 2024 02:00:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Use "cause" argument when rethrowing an exception. See CR for details on how this helps.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
> 
> I'd like to push this as a trivial change.

Okay - thanks. Change is trivial.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17258#pullrequestreview-1805084395

From ddong at openjdk.org  Fri Jan  5 00:47:48 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Fri, 5 Jan 2024 00:47:48 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v4]
In-Reply-To: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
Message-ID: <qjcpTBlXh-eAQypzIf7-xnn_HVJwKYHV6__rmL9mBpA=.69c845e2-4995-47b8-b509-97476d493548@github.com>

> Hi,
> 
> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
> 
> Thanks.

Denghui Dong 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 five additional commits since the last revision:

 - update
 - Merge remote-tracking branch 'origin/master' into JDK-8322989
 - update
 - update
 - 8322989: New test serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17263/files
  - new: https://git.openjdk.org/jdk/pull/17263/files/47519b1a..734f1d7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17263&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17263&range=02-03

  Stats: 369 lines in 54 files changed: 191 ins; 57 del; 121 mod
  Patch: https://git.openjdk.org/jdk/pull/17263.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17263/head:pull/17263

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

From ddong at openjdk.org  Fri Jan  5 01:56:29 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Fri, 5 Jan 2024 01:56:29 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v4]
In-Reply-To: <qjcpTBlXh-eAQypzIf7-xnn_HVJwKYHV6__rmL9mBpA=.69c845e2-4995-47b8-b509-97476d493548@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <qjcpTBlXh-eAQypzIf7-xnn_HVJwKYHV6__rmL9mBpA=.69c845e2-4995-47b8-b509-97476d493548@github.com>
Message-ID: <F0ngDUYDNA5vX19aJgn0JyNvIEdKhHXemLNpK3bFcYs=.c08134d3-f729-46ec-a063-eae0b194a984@github.com>

On Fri, 5 Jan 2024 00:47:48 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>> 
>> Thanks.
>
> Denghui Dong 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 five additional commits since the last revision:
> 
>  - update
>  - Merge remote-tracking branch 'origin/master' into JDK-8322989
>  - update
>  - update
>  - 8322989: New test serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails

> ProblemListing PR has been approved and should integrate shortly: #17269 Please update your repo to include that fix so that you can remove the test from the ProblemList.txt file in your PR.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1878003544

From dholmes at openjdk.org  Fri Jan  5 02:11:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Jan 2024 02:11:26 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v4]
In-Reply-To: <qjcpTBlXh-eAQypzIf7-xnn_HVJwKYHV6__rmL9mBpA=.69c845e2-4995-47b8-b509-97476d493548@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <qjcpTBlXh-eAQypzIf7-xnn_HVJwKYHV6__rmL9mBpA=.69c845e2-4995-47b8-b509-97476d493548@github.com>
Message-ID: <pO1Q8qlu8gIeeRroWSapSU2GgfJX31SDXLvkLnR7ijY=.03af484b-c4f7-43b9-b2f6-ef8a499417a3@github.com>

On Fri, 5 Jan 2024 00:47:48 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>> 
>> Thanks.
>
> Denghui Dong 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 five additional commits since the last revision:
> 
>  - update
>  - Merge remote-tracking branch 'origin/master' into JDK-8322989
>  - update
>  - update
>  - 8322989: New test serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails

Seems reasonable based on previous discussions.

You may need to update the Alibaba copyright header now it is 2024 (depends on their rules, whatever they may be).

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17263#pullrequestreview-1805253887

From ddong at openjdk.org  Fri Jan  5 02:22:45 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Fri, 5 Jan 2024 02:22:45 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v5]
In-Reply-To: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
Message-ID: <PyXP2juvlGaRxfwqKzL4zJPnYs3h8fvJHeaz0k4MxvA=.9c9a6e20-4c14-4cde-b4e1-6e4bf212f27a@github.com>

> Hi,
> 
> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
> 
> Thanks.

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17263/files
  - new: https://git.openjdk.org/jdk/pull/17263/files/734f1d7e..696f51e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17263&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17263&range=03-04

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

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

From ddong at openjdk.org  Fri Jan  5 02:27:27 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Fri, 5 Jan 2024 02:27:27 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v5]
In-Reply-To: <uvojOmAhkGg-Tjo6PvWdiUYNh9ZxgHNqCbhnNQ-YQk8=.585a5ae1-04f9-4dd0-9577-3ce019302dff@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <ScedhP-gmKnchR8922JvTtUwTfXbz77qe5N4lwApE5U=.9532921e-d864-4bf4-a81c-78882bd9ae7a@github.com>
 <GlyVxcSL9zuePWJt-KEVYK8kKwr2jbavboV49yC6lgY=.b42f423f-d656-49dd-9cc5-8869e0cc1692@github.com>
 <6tDoJuv4y7KX6axgCjYkSDBFNftSmPCnrkpJKGEfnuk=.cd5bf578-b878-4d49-9f18-a0cf89424585@github.com>
 <uvojOmAhkGg-Tjo6PvWdiUYNh9ZxgHNqCbhnNQ-YQk8=.585a5ae1-04f9-4dd0-9577-3ce019302dff@github.com>
Message-ID: <eHdEHTql6Pa1aYmADs7RT9QoS4qn8e7zPmZBpbiZ9Pg=.5b8caccc-f38a-43a6-833e-8c1ddf8493c2@github.com>

On Thu, 4 Jan 2024 20:37:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> > For this test I think we can just add @requires vm.gc.Serial
>>> 
>>> @stefank but it doesn't require that, it explicitly sets that. The test requires that no specific GC has been requested.
>> 
>> @dholmes-ora `@requires vm.gc.Serial` doesn't mean that it requires Serial to be set. It's more subtle than that. It means that either Serial is set (and available) or it can be set (because no other GC has been selected). It is the correct requires line to use when you explicitly set the GC in the test. Look at our other GC tests.
>> 
>> For example:
>> test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java
>> 
>> Without selecting a GC, the test is run:
>> 
>> $ make -C ../build/fastdebug test TEST=test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java JTREG="JAVA_OPTIONS=-Xmx128m"
>> ...
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:open/test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java
>>                                                          1     1     0     0  
>> 
>> 
>> With Serial as the selected GC, the test is run:
>> 
>> $ make -C ../build/fastdebug test TEST=test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java JTREG="JAVA_OPTIONS=-Xmx128m -XX:+UseSerialGC"
>> ...
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:open/test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java
>>                                                          1     1     0     0   
>> 
>> 
>> With G1 as the selected GC, the test is excluded:
>> 
>> $ make -C ../build/fastdebug test TEST=test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java JTREG="JAVA_OPTIONS=-Xmx128m -XX:+UseG1GC"
>> ...
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:open/test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java
>>                                                          0     0     0     0
>
>> It means that either Serial is set (and available) or it can be set 
> 
> @stefank that is subtle - and unintuitive. Thanks for explaining.

@dholmes-ora Thanks for the review.

This change only involves the test part. Do I need a second review?

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1878035550

From dholmes at openjdk.org  Fri Jan  5 03:01:23 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Jan 2024 03:01:23 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v5]
In-Reply-To: <eHdEHTql6Pa1aYmADs7RT9QoS4qn8e7zPmZBpbiZ9Pg=.5b8caccc-f38a-43a6-833e-8c1ddf8493c2@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <ScedhP-gmKnchR8922JvTtUwTfXbz77qe5N4lwApE5U=.9532921e-d864-4bf4-a81c-78882bd9ae7a@github.com>
 <GlyVxcSL9zuePWJt-KEVYK8kKwr2jbavboV49yC6lgY=.b42f423f-d656-49dd-9cc5-8869e0cc1692@github.com>
 <6tDoJuv4y7KX6axgCjYkSDBFNftSmPCnrkpJKGEfnuk=.cd5bf578-b878-4d49-9f18-a0cf89424585@github.com>
 <uvojOmAhkGg-Tjo6PvWdiUYNh9ZxgHNqCbhnNQ-YQk8=.585a5ae1-04f9-4dd0-9577-3ce019302dff@github.com>
 <eHdEHTql6Pa1aYmADs7RT9QoS4qn8e7zPmZBpbiZ9Pg=.5b8caccc-f38a-43a6-833e-8c1ddf8493c2@github.com>
Message-ID: <q8ibjdeREomNonRMG9CmcZMiLSUspSQ5xETfHW22LeM=.bfea3ac2-0e39-4959-92c3-561fe6267e56@github.com>

On Fri, 5 Jan 2024 02:24:44 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>>> It means that either Serial is set (and available) or it can be set 
>> 
>> @stefank that is subtle - and unintuitive. Thanks for explaining.
>
> @dholmes-ora Thanks for the review.
> 
> This change only involves the test part. Do I need a second review?

@D-D-H given the discussion it would be best if @stefank also approved it. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1878056447

From lmesnik at openjdk.org  Fri Jan  5 07:03:21 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 5 Jan 2024 07:03:21 GMT
Subject: RFR: 8322981: Fix 2 locations in JDI that throw IOException
 without using the "Caused by" exception
In-Reply-To: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
References: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
Message-ID: <WFUXtMkw9D-o8DYMjS4tiQGrFrHm0HxjqhenaEesL2E=.0eb518b8-e67a-4caa-88ea-88d326b91d7b@github.com>

On Thu, 4 Jan 2024 02:00:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Use "cause" argument when rethrowing an exception. See CR for details on how this helps.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
> 
> I'd like to push this as a trivial change.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17258#pullrequestreview-1805439839

From sroy at openjdk.org  Fri Jan  5 08:55:28 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 5 Jan 2024 08:55:28 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v7]
In-Reply-To: <2sMyJ8mZ6EIULC67tK1IcI4uNnJMvpCzw1BKEDUaIms=.c90f1101-236e-4a80-869c-feca6abd3dc3@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <QnORwi8c5OCcUV51-xB91wPbXS-rGeJPEI4BxNMsBxc=.ac951d81-1db2-4549-abe0-025b99a1de4e@github.com>
 <_WrW-iHHdU-IgC7Z1b6oe_Qh0dkC6P3KJAdl7J2S1Do=.712dd065-6207-4632-a82f-8e12ad023cd5@github.com>
 <2sMyJ8mZ6EIULC67tK1IcI4uNnJMvpCzw1BKEDUaIms=.c90f1101-236e-4a80-869c-feca6abd3dc3@github.com>
Message-ID: <wGOj88IqIx_nTIbnPSqK69z-qz2CBJTFEDqFvmhRlvM=.93dd348f-d41e-4a3d-b699-9dd833e7d436@github.com>

On Thu, 21 Dec 2023 10:01:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> > > What happens if we accidentally attempt to load a "real" static library, which is also named *.a? Would dlopen() then crash? What would happen?
>>> 
>>> > I don't think the problem is with *.a . They would load as the default behaviour of the dlopen. It is only when the dlopen fails for *.so , we give another chance to check for .a file with the same name.
>>> 
>>> No, what I meant, and what must be clarified before going forward with this solution, is the following:
>>> 
>>> * is _every_ `*.a` object on AIX loadable with `dlopen`, and will the result be the same as when loading a `*.so` object
>>> * or, if we present arbitrary `*.a` files to dlopen, is there a chance for dlopen to crash or misbehave.
>>> 
>>> Reason is that I was under the impression that *.a libraries are static libraries and cannot be loaded dynamically. This is what you now try to do.
>>> If we cannot safely answer this question, I would opt for a more narrow solution by hard-wiring known alternative names. So, do the second *.a attempt only for your `ibm_16_am.a` which you know works. That could also be done in a reasonably maintainable manner.
>>> 
>> In AIX, both static and dynamic libraries have *.a extension. And AIX also supports *.so files.Bascially shared objects in AIX have both *.a and *.so extension.  Hence we need to implement this logic.
>> If we try loading a static archive specifically ,how the dlopen would behave , that is something probably @JoKern65  can answer ? 
>> 
>> 
>>> > > Does this really have to be handled in the OpenJDK? What does J9 on AIX do? Could this be done in a simpler way outside OpenJDK, e.g. by providing an *.so variant of the library in question? Where does this library come from?
>>> 
>>> > I am not sure how J9 handles this. I would have to consult .
>>> 
>>> J9 is Open Source, can't you just look? :)
>> 
>> I did try comparing the file structures, and i do not see a similar file structure over there. 
>> I am unable to find the jvmTiAgent code and also os_aix file. So i am not sure which functions over there are doing the same functionality. You have any suggestion on how i can check and correlate ?  
>>> 
>>> > However as per current observation, this issue does not show up on Semuru. This issue is only happening on Adoptium. The team that release these file has always released *.a files which work fine for Semuru.
>>> 
>>> I don't know what Semuru is. What is the context, is that a different VM? Also OpenJDK? J9 derived? 
>> 
>> 
>> Semuru is J9 derived.
>
>> > > > What happens if we accidentally attempt to load a "real" static library, which is also named *.a? Would dlopen() then crash? What would happen?
>> > 
>> > 
>> > > I don't think the problem is with *.a . They would load as the default behaviour of the dlopen. It is only when the dlopen fails for *.so , we give another chance to check for .a file with the same name.
>> > 
>> > 
>> > No, what I meant, and what must be clarified before going forward with this solution, is the following:
>> > 
>> > * is _every_ `*.a` object on AIX loadable with `dlopen`, and will the result be the same as when loading a `*.so` object
>> > * or, if we present arbitrary `*.a` files to dlopen, is there a chance for dlopen to crash or misbehave.
>> > 
>> > Reason is that I was under the impression that *.a libraries are static libraries and cannot be loaded dynamically. This is what you now try to do.
>> > If we cannot safely answer this question, I would opt for a more narrow solution by hard-wiring known alternative names. So, do the second *.a attempt only for your `ibm_16_am.a` which you know works. That could also be done in a reasonably maintainable manner.
>> 
>> In AIX, both static and dynamic libraries have *.a extension. And AIX also supports *.so files.Bascially shared objects in AIX have both *.a and *.so extension. Hence we need to implement this logic. If we try loading a static archive specifically ,how the dlopen would behave , that is something probably @JoKern65 can answer ?
> 
> Rather, this is a question you have to ask your collegues at IBM that develop the AIX libc.
> 
> Since AIX libc is not open source, we cannot look for ourselves, nor can Joachim (her works at SAP).
> 
>> 
>> > > > Does this really have to be handled in the OpenJDK? What does J9 on AIX do? Could this be done in a simpler way outside OpenJDK, e.g. by providing an *.so variant of the library in question? Where does this library come from?
>> > 
>> > 
>> > > I am not sure how J9 handles this. I would have to consult .
>> > 
>> > 
>> > J9 is Open Source, can't you just look? :)
>> 
>> I did try comparing the file structures, and i do not see a similar file structure over there. I am unable to find the jvmTiAgent code and also os_aix file. So i am not sure which functions over there are doing the same functionality. You have any suggestion on how i can check and correlate ?
> 
> Someone must implement LoadLibrary. Try looking for places where dlopen() is called.
> 
>> 
>> > > However as per current observation, this issue does ...

Hi @tstuefe Clarifications on your questions.



> Hi,
> 
> some requests and questions:
> 

> * Does this really have to be handled in the OpenJDK? What does J9 on AIX do? Could this be done in a simpler way outside OpenJDK, e.g. by providing an *.so variant of the library in question? Where does this library come from?

In J9, there was syshelp native file that did the appending of .a to the filename till java 14. Post that the appending is handled in the JavaClassLoader . However, when I tried to do the same on OpenJDK, it didn't work. So I had to trace into the hotspot code. 
This change will affect some Panama changes too. I think @TheRealMDoerr  has faced issues with respect to another library as well.  Long term, providing a .so variant may not be feasible as it will be continuous process imo.
 



> * What happens if we accidentally attempt to load a "real" static library, which is also named *.a? Would dlopen() then crash? What would happen?

I enquired on this. The dlopen exits with an error .The program does not crash when trying to load a static library. 

> * What happens if the original path handed to os::dll_load is already a *.a file? Should the logic then be reversed?

Already explained above.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1878327576

From stefank at openjdk.org  Fri Jan  5 09:00:25 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Jan 2024 09:00:25 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v5]
In-Reply-To: <PyXP2juvlGaRxfwqKzL4zJPnYs3h8fvJHeaz0k4MxvA=.9c9a6e20-4c14-4cde-b4e1-6e4bf212f27a@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <PyXP2juvlGaRxfwqKzL4zJPnYs3h8fvJHeaz0k4MxvA=.9c9a6e20-4c14-4cde-b4e1-6e4bf212f27a@github.com>
Message-ID: <SnWl6pHdp1iyjBBFfuGpWlwk30gE9SxhSrIqMKT3JYw=.8e2434a7-e01a-44c2-b077-1ea1c6b78566@github.com>

On Fri, 5 Jan 2024 02:22:45 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>> 
>> Thanks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17263#pullrequestreview-1805569410

From ddong at openjdk.org  Fri Jan  5 09:26:33 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Fri, 5 Jan 2024 09:26:33 GMT
Subject: RFR: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails [v5]
In-Reply-To: <PyXP2juvlGaRxfwqKzL4zJPnYs3h8fvJHeaz0k4MxvA=.9c9a6e20-4c14-4cde-b4e1-6e4bf212f27a@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
 <PyXP2juvlGaRxfwqKzL4zJPnYs3h8fvJHeaz0k4MxvA=.9c9a6e20-4c14-4cde-b4e1-6e4bf212f27a@github.com>
Message-ID: <5GMEpQ8xsDGLmmHoIdhRdhHflv1gnq1-n5SwgR3Xabk=.f38bc270-8721-4254-853a-beff01edaa18@github.com>

On Fri, 5 Jan 2024 02:22:45 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>> 
>> Thanks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17263#issuecomment-1878363017

From ddong at openjdk.org  Fri Jan  5 09:26:34 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Fri, 5 Jan 2024 09:26:34 GMT
Subject: Integrated: 8322989: New test
 serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails
In-Reply-To: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
References: <F3S50Z10YWmfqVLxremO6wW8gohGqJd5B5fx4F4S6F8=.9e81ada3-2274-41b6-808e-1aef02607fa6@github.com>
Message-ID: <VormeCc_UH2N-93n1VoFfI9CatxVDYF6vNtZcpxxjcY=.e19cc630-269d-48f6-b053-7ee08d4d3339@github.com>

On Thu, 4 Jan 2024 08:01:57 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Please help review this patch that fixes the failures of FullGCHeapDumpLimitTest.java caused by passing other gc flags.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 3dc4bd85
Author:    Denghui Dong <ddong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3dc4bd858139f133f5e5b17e7bd3082dd6766d02
Stats:     4 lines in 2 files changed: 1 ins; 2 del; 1 mod

8322989: New test serviceability/HeapDump/FullGCHeapDumpLimitTest.java fails

Reviewed-by: stefank, dholmes

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

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

From mdoerr at openjdk.org  Fri Jan  5 12:13:27 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 5 Jan 2024 12:13:27 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v7]
In-Reply-To: <QnORwi8c5OCcUV51-xB91wPbXS-rGeJPEI4BxNMsBxc=.ac951d81-1db2-4549-abe0-025b99a1de4e@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <QnORwi8c5OCcUV51-xB91wPbXS-rGeJPEI4BxNMsBxc=.ac951d81-1db2-4549-abe0-025b99a1de4e@github.com>
Message-ID: <hX5s13YzFiPxFoyjZwvyq-prh2xRP8r-f5Rv_ZCFTyA=.a09e4c89-e74f-4f2e-88a7-6b967ce342a3@github.com>

On Wed, 20 Dec 2023 11:16:03 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spaces fix

I have tried to build jextract (https://github.com/openjdk/jextract/tree/jdk22) with LLVM (https://github.com/llvm/llvm-project/releases/download/llvmorg-16.0.4/clang+llvm-16.0.4-powerpc64-ibm-aix-7.2.tar.xz). I noticed that llvm mainly consists of .a files. So, I think we need to support that for FFI compatibility with other libraries and open source projects.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1878570142

From cjplummer at openjdk.org  Fri Jan  5 17:55:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Jan 2024 17:55:22 GMT
Subject: RFR: 8322980: Debug agent's dumpThread() API should update
 thread's name before printing it
In-Reply-To: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
References: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
Message-ID: <RqOa4lC-pUPCDu0jeLYXpZrBHxFBwuotmAmSQ8Bo7tk=.a95062b4-8859-422b-871a-a1249be858a6@github.com>

On Thu, 4 Jan 2024 02:06:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In threadControl.c, at build time you can decide to keep track of thread names by compiling with "#define DEBUG_THREADNAME". If this is also a debug build, some extra debugging functions are included in the build, including "dumpThread(ThreadNode *node)". These are intended to be called from gdb, or possibly from somewhere in the debug agent implementation, to aid with debugging. When dumpThread() prints the thread's name, it just uses the name that was stored when the thread was created. However, the thread name can change, so dumpThread() should really fetch the current thread name and print it. 
> 
> I also added some commented out code to print other useful fields of the ThreadNode, including the ThreadState. These can be enabled by the user as needed.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.

Could I get one more review please.

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

PR Comment: https://git.openjdk.org/jdk/pull/17259#issuecomment-1879051184

From cjplummer at openjdk.org  Fri Jan  5 17:56:26 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Jan 2024 17:56:26 GMT
Subject: RFR: 8322981: Fix 2 locations in JDI that throw IOException
 without using the "Caused by" exception
In-Reply-To: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
References: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
Message-ID: <iDhrhzFaij70bHxjtAnyrIoya6tqtYpdBcFoMBezn1U=.16d86a08-9aec-4860-a9e4-f9560f743ab1@github.com>

On Thu, 4 Jan 2024 02:00:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Use "cause" argument when rethrowing an exception. See CR for details on how this helps.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
> 
> I'd like to push this as a trivial change.

Thanks for the reviews David and Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/17258#issuecomment-1879050024

From cjplummer at openjdk.org  Fri Jan  5 17:56:27 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Jan 2024 17:56:27 GMT
Subject: Integrated: 8322981: Fix 2 locations in JDI that throw IOException
 without using the "Caused by" exception
In-Reply-To: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
References: <BV-JilZwEebIZb1D3EVwHS6_mKF1M8aVjYkSJJxbFGo=.16969956-022d-4492-9e90-8516296526a6@github.com>
Message-ID: <Psd6NyMffsAZ0siZn-45_TkbMrs8sdGeI9arFIHgNgM=.1a9cb8ff-fba4-4b2d-87b4-3aeaa7886180@github.com>

On Thu, 4 Jan 2024 02:00:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Use "cause" argument when rethrowing an exception. See CR for details on how this helps.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
> 
> I'd like to push this as a trivial change.

This pull request has now been integrated.

Changeset: 46965a09
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46965a096ce74d9375df36a3a66107e9295cc180
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8322981: Fix 2 locations in JDI that throw IOException without using the "Caused by" exception

Reviewed-by: dholmes, lmesnik

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

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

From sspitsyn at openjdk.org  Fri Jan  5 18:39:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 5 Jan 2024 18:39:22 GMT
Subject: RFR: 8322980: Debug agent's dumpThread() API should update
 thread's name before printing it
In-Reply-To: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
References: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
Message-ID: <u_2kLAiGSMV1elf_uNucr9L1pUXllAGgpEjNt0EYU3Q=.98f9f315-a972-4fad-8c49-7a6d3120e812@github.com>

On Thu, 4 Jan 2024 02:06:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In threadControl.c, at build time you can decide to keep track of thread names by compiling with "#define DEBUG_THREADNAME". If this is also a debug build, some extra debugging functions are included in the build, including "dumpThread(ThreadNode *node)". These are intended to be called from gdb, or possibly from somewhere in the debug agent implementation, to aid with debugging. When dumpThread() prints the thread's name, it just uses the name that was stored when the thread was created. However, the thread name can change, so dumpThread() should really fetch the current thread name and print it. 
> 
> I also added some commented out code to print other useful fields of the ThreadNode, including the ThreadState. These can be enabled by the user as needed.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2654:

> 2652:   jvmtiError error = FUNC_PTR(gdata->jvmti,GetThreadState)
> 2653:     (gdata->jvmti, node->thread, &state);
> 2654:   return state;

Nit: The indent in this file is 4, not 2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17259#discussion_r1443245407

From sspitsyn at openjdk.org  Fri Jan  5 18:42:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 5 Jan 2024 18:42:21 GMT
Subject: RFR: 8322980: Debug agent's dumpThread() API should update
 thread's name before printing it
In-Reply-To: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
References: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
Message-ID: <Ql4SybRvL1iNf9bqz50cjNcqsxnKNwxVmR_F2DtgsZw=.6572e60e-b681-4c21-9b8f-636c76649283@github.com>

On Thu, 4 Jan 2024 02:06:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In threadControl.c, at build time you can decide to keep track of thread names by compiling with "#define DEBUG_THREADNAME". If this is also a debug build, some extra debugging functions are included in the build, including "dumpThread(ThreadNode *node)". These are intended to be called from gdb, or possibly from somewhere in the debug agent implementation, to aid with debugging. When dumpThread() prints the thread's name, it just uses the name that was stored when the thread was created. However, the thread name can change, so dumpThread() should really fetch the current thread name and print it. 
> 
> I also added some commented out code to print other useful fields of the ThreadNode, including the ThreadState. These can be enabled by the user as needed.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.

Looks good.
Q: Do you want to keep the debugging code under `#ifdef ... #endif`?

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17259#pullrequestreview-1806638897

From cjplummer at openjdk.org  Fri Jan  5 19:06:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Jan 2024 19:06:36 GMT
Subject: RFR: 8322980: Debug agent's dumpThread() API should update
 thread's name before printing it [v2]
In-Reply-To: <Ql4SybRvL1iNf9bqz50cjNcqsxnKNwxVmR_F2DtgsZw=.6572e60e-b681-4c21-9b8f-636c76649283@github.com>
References: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
 <Ql4SybRvL1iNf9bqz50cjNcqsxnKNwxVmR_F2DtgsZw=.6572e60e-b681-4c21-9b8f-636c76649283@github.com>
Message-ID: <oguXQYEIvIeplX-ooqkDv6i-1geF-Rzu12HI7uYYomQ=.bba0c4ce-f19c-4ea6-9d94-5753b628d96d@github.com>

On Fri, 5 Jan 2024 18:39:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Looks good. Q: Do you want to keep the debugging code under `#ifdef ... #endif`?

Yes. The "#ifdef DEBUG_THREADNAME" is something that I want the user to have to manually enable at build time to avoid the memory and performance impact. Also, "#if 0" code generates extra output that normally you don't want, but I wanted to leave the code there as examples and so it can be easily enabled when needed."

> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2654:
> 
>> 2652:   jvmtiError error = FUNC_PTR(gdata->jvmti,GetThreadState)
>> 2653:     (gdata->jvmti, node->thread, &state);
>> 2654:   return state;
> 
> Nit: The indent in this file is 4, not 2.

Fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17259#issuecomment-1879132891
PR Review Comment: https://git.openjdk.org/jdk/pull/17259#discussion_r1443277177

From cjplummer at openjdk.org  Fri Jan  5 19:06:34 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 5 Jan 2024 19:06:34 GMT
Subject: RFR: 8322980: Debug agent's dumpThread() API should update
 thread's name before printing it [v2]
In-Reply-To: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
References: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
Message-ID: <klYRO05inVaDUqJqafeSoeOV79DjENxJan82PiTareo=.d9a62738-ba6b-4790-9a45-3abc14c0daa7@github.com>

> In threadControl.c, at build time you can decide to keep track of thread names by compiling with "#define DEBUG_THREADNAME". If this is also a debug build, some extra debugging functions are included in the build, including "dumpThread(ThreadNode *node)". These are intended to be called from gdb, or possibly from somewhere in the debug agent implementation, to aid with debugging. When dumpThread() prints the thread's name, it just uses the name that was stored when the thread was created. However, the thread name can change, so dumpThread() should really fetch the current thread name and print it. 
> 
> I also added some commented out code to print other useful fields of the ThreadNode, including the ThreadState. These can be enabled by the user as needed.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17259/files
  - new: https://git.openjdk.org/jdk/pull/17259/files/eb318d81..fbbd07e5

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

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

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

From sspitsyn at openjdk.org  Fri Jan  5 21:03:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 5 Jan 2024 21:03:22 GMT
Subject: RFR: 8322980: Debug agent's dumpThread() API should update
 thread's name before printing it [v2]
In-Reply-To: <klYRO05inVaDUqJqafeSoeOV79DjENxJan82PiTareo=.d9a62738-ba6b-4790-9a45-3abc14c0daa7@github.com>
References: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
 <klYRO05inVaDUqJqafeSoeOV79DjENxJan82PiTareo=.d9a62738-ba6b-4790-9a45-3abc14c0daa7@github.com>
Message-ID: <EXGBwNHtl067Cm8eC59QNtbtlJS-PWiJzLHjxgG8nn4=.eb3032c4-01ec-488a-a781-3f4e901378e5@github.com>

On Fri, 5 Jan 2024 19:06:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> In threadControl.c, at build time you can decide to keep track of thread names by compiling with "#define DEBUG_THREADNAME". If this is also a debug build, some extra debugging functions are included in the build, including "dumpThread(ThreadNode *node)". These are intended to be called from gdb, or possibly from somewhere in the debug agent implementation, to aid with debugging. When dumpThread() prints the thread's name, it just uses the name that was stored when the thread was created. However, the thread name can change, so dumpThread() should really fetch the current thread name and print it. 
>> 
>> I also added some commented out code to print other useful fields of the ThreadNode, including the ThreadState. These can be enabled by the user as needed.
>> 
>> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17259#pullrequestreview-1806840976

From dholmes at openjdk.org  Fri Jan  5 21:05:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Jan 2024 21:05:25 GMT
Subject: [jdk22] RFR: 8319948: jcmd man page needs to be updated [v2]
In-Reply-To: <eFXExkTwszkqGg-snCCeB2eM2Kk5IepKvkr1zo1bdEI=.12ae0976-2d97-405f-89c1-7554a075c3dd@github.com>
References: <vm0p2X67PO2ws-FwJKwITnNxHHrqAla9cJazrbWIdqg=.6c8e43f9-c60c-4182-9615-94a153444fd8@github.com>
 <NHvOOHQwk1DeWjnb2U-3x8wQwEZtjs0ZmRCzNd0eJoQ=.95fe633c-7fce-416e-a21e-de830f856f3a@github.com>
 <eFXExkTwszkqGg-snCCeB2eM2Kk5IepKvkr1zo1bdEI=.12ae0976-2d97-405f-89c1-7554a075c3dd@github.com>
Message-ID: <7wBGhF-xyZWoS99XSjbRww3LMX2Wyq41-llJ5hC4R-w=.99853a69-64cc-483f-840f-e11dcbd75c08@github.com>

On Thu, 4 Jan 2024 07:17:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed JDK23 specific change to Compilerp[erfmap
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the review @AlanBateman

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

PR Comment: https://git.openjdk.org/jdk22/pull/27#issuecomment-1879252175

From dholmes at openjdk.org  Fri Jan  5 21:05:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Jan 2024 21:05:26 GMT
Subject: [jdk22] Integrated: 8319948: jcmd man page needs to be updated
In-Reply-To: <vm0p2X67PO2ws-FwJKwITnNxHHrqAla9cJazrbWIdqg=.6c8e43f9-c60c-4182-9615-94a153444fd8@github.com>
References: <vm0p2X67PO2ws-FwJKwITnNxHHrqAla9cJazrbWIdqg=.6c8e43f9-c60c-4182-9615-94a153444fd8@github.com>
Message-ID: <XSDRNVSLA-hLENv7k8YuTYOHFWiT16KBpyRm7MaJESs=.316feb10-af48-439d-a0a5-1879a0b04c83@github.com>

On Thu, 4 Jan 2024 01:31:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [028ec7e](https://github.com/openjdk/jdk/commit/028ec7e744f06cd8429b7b74d7b6f7020133aa94) from the [jdk](https://github.com/openjdk/jdk/) repository.
> 
> The commit being backported was authored by @dholmes-ora on 3 Jan 2024 and was reviewed by @kevinjwalls and @alanbateman
> 
> The backport is not clean as a JDK23 specific change to Compiler.perfmap had to be removed.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 6aace181
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/6aace1819c7473db1c9dc6a79a825cc20e7df11d
Stats:     259 lines in 1 file changed: 170 ins; 46 del; 43 mod

8319948: jcmd man page needs to be updated

Reviewed-by: alanb
Backport-of: 028ec7e744f06cd8429b7b74d7b6f7020133aa94

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

PR: https://git.openjdk.org/jdk22/pull/27

From cjplummer at openjdk.org  Mon Jan  8 16:59:33 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Jan 2024 16:59:33 GMT
Subject: RFR: 8322980: Debug agent's dumpThread() API should update
 thread's name before printing it [v2]
In-Reply-To: <klYRO05inVaDUqJqafeSoeOV79DjENxJan82PiTareo=.d9a62738-ba6b-4790-9a45-3abc14c0daa7@github.com>
References: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
 <klYRO05inVaDUqJqafeSoeOV79DjENxJan82PiTareo=.d9a62738-ba6b-4790-9a45-3abc14c0daa7@github.com>
Message-ID: <QNisJu0BpaXU0shTJFiOdPIMesmezTKvpG1AMuDkxBU=.e0eb99e0-f356-4e20-8c12-2cb95897eba5@github.com>

On Fri, 5 Jan 2024 19:06:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> In threadControl.c, at build time you can decide to keep track of thread names by compiling with "#define DEBUG_THREADNAME". If this is also a debug build, some extra debugging functions are included in the build, including "dumpThread(ThreadNode *node)". These are intended to be called from gdb, or possibly from somewhere in the debug agent implementation, to aid with debugging. When dumpThread() prints the thread's name, it just uses the name that was stored when the thread was created. However, the thread name can change, so dumpThread() should really fetch the current thread name and print it. 
>> 
>> I also added some commented out code to print other useful fields of the ThreadNode, including the ThreadState. These can be enabled by the user as needed.
>> 
>> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation

Thank you for the reviews Kevin and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/17259#issuecomment-1881466760

From cjplummer at openjdk.org  Mon Jan  8 16:59:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Jan 2024 16:59:35 GMT
Subject: Integrated: 8322980: Debug agent's dumpThread() API should update
 thread's name before printing it
In-Reply-To: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
References: <mq6iN_xCiQzNd-u3xM6BQIcLQVwoPdiMD6Y6lu9my2U=.a742596e-54ef-442d-b21f-889f90c9df85@github.com>
Message-ID: <Md5vsJWqKyUc3xOOLuVxTr4uGzZJgTV6sSPF6LoEhrU=.b25e72cf-d99c-40ad-a7cd-d16ee04175f8@github.com>

On Thu, 4 Jan 2024 02:06:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In threadControl.c, at build time you can decide to keep track of thread names by compiling with "#define DEBUG_THREADNAME". If this is also a debug build, some extra debugging functions are included in the build, including "dumpThread(ThreadNode *node)". These are intended to be called from gdb, or possibly from somewhere in the debug agent implementation, to aid with debugging. When dumpThread() prints the thread's name, it just uses the name that was stored when the thread was created. However, the thread name can change, so dumpThread() should really fetch the current thread name and print it. 
> 
> I also added some commented out code to print other useful fields of the ThreadNode, including the ThreadState. These can be enabled by the user as needed.
> 
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.

This pull request has now been integrated.

Changeset: 387828a3
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/387828a3f7e4ec5b26954747e756aac212d579ae
Stats:     45 lines in 1 file changed: 43 ins; 0 del; 2 mod

8322980: Debug agent's dumpThread() API should update thread's name before printing it

Reviewed-by: kevinw, sspitsyn

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

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

From sspitsyn at openjdk.org  Mon Jan  8 18:52:25 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 8 Jan 2024 18:52:25 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
Message-ID: <vZzXwv2j3EYB2f0X9PxJySG34wlUU16RRvHG_Y9p-us=.03086cf0-16f5-4a9d-9b0f-b1344b7d0cc3@github.com>

On Thu, 4 Jan 2024 10:48:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary MLET_ Properties

Kevin, thank you for the answers! Looks okay to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16363#pullrequestreview-1809788070

From cjplummer at openjdk.org  Mon Jan  8 20:22:31 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 8 Jan 2024 20:22:31 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
Message-ID: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>

Fix some broken links and other minor cleanups:

 There are a few broken links in the javadoc for ObjectReference.java. For example:


     * Not all target VMs support this operation. See
     * VirtualMachine#canGetMonitorInfo to determine if the
     * operation is supported.


Which should be:


     * Not all target VMs support this operation. See
     * {@link VirtualMachine#canGetMonitorInfo} to determine if the
     * operation is supported.



The following does not need to include the link text:

`     * {@link VirtualMachine#canGetInstanceInfo() canGetInstanceInfo()}`

Instead just use:

`     * {@link VirtualMachine#canGetInstanceInfo()}`


There are many places where we embed a "see" rather than use @see. The formatting convention is:

`     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}.`

However, there are a few places that are missing a space before the "see":


     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
     * -see {@link VirtualMachine#canBeModified()}.

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

Commit messages:
 - Minor cleanup of some javadocs

Changes: https://git.openjdk.org/jdk/pull/17311/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17311&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323213
  Stats: 14 lines in 2 files changed: 1 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/17311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17311/head:pull/17311

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

From dholmes at openjdk.org  Tue Jan  9 02:35:29 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Jan 2024 02:35:29 GMT
Subject: RFR: 8323241: jcmd manpage should use lists for argument lists
Message-ID: <4u5tmz1xty7FQZYG9aAF9QChI7Xkg3JISFNNQPJDHN0=.49e46b13-5866-4b23-bcb3-c6b4e8adb5fa@github.com>

Trivial fix to the formatting of "argument" lists for a few sub-commands.
Thanks

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

Commit messages:
 - 8323241: jcmd manpage should use lists for argument lists

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

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

From sspitsyn at openjdk.org  Tue Jan  9 07:28:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 9 Jan 2024 07:28:23 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
In-Reply-To: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
Message-ID: <JGeZiT4CTuZIV4wZl8X7g3Y8EAY_D-Zmr98BVDeLqsM=.3f1d748e-fc24-4467-8c75-560b4cd752be@github.com>

On Mon, 8 Jan 2024 20:16:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix some broken links and other minor cleanups:
> 
>  There are a few broken links in the javadoc for ObjectReference.java. For example:
> 
> 
>      * Not all target VMs support this operation. See
>      * VirtualMachine#canGetMonitorInfo to determine if the
>      * operation is supported.
> 
> 
> Which should be:
> 
> 
>      * Not all target VMs support this operation. See
>      * {@link VirtualMachine#canGetMonitorInfo} to determine if the
>      * operation is supported.
> 
> 
> 
> The following does not need to include the link text:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo() canGetInstanceInfo()}`
> 
> Instead just use:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo()}`
> 
> 
> There are many places where we embed a "see" rather than use @see. The formatting convention is:
> 
> `     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}.`
> 
> However, there are a few places that are missing a space before the "see":
> 
> 
>      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>      * -see {@link VirtualMachine#canBeModified()}.

Looks good to me.

src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java line 681:

> 679:      * class prepare events by source name.
> 680:      *
> 681:      * @see ClassPrepareRequest#addSourceNameFilter

It is not clear why the link has been removed. There are some other similar places with links but others without links, so it is not clear how to achieve consistency here. Just want to understand your logic.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17311#pullrequestreview-1810539818
PR Review Comment: https://git.openjdk.org/jdk/pull/17311#discussion_r1445712962

From alanb at openjdk.org  Tue Jan  9 08:13:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Jan 2024 08:13:22 GMT
Subject: RFR: 8323241: jcmd manpage should use lists for argument lists
In-Reply-To: <4u5tmz1xty7FQZYG9aAF9QChI7Xkg3JISFNNQPJDHN0=.49e46b13-5866-4b23-bcb3-c6b4e8adb5fa@github.com>
References: <4u5tmz1xty7FQZYG9aAF9QChI7Xkg3JISFNNQPJDHN0=.49e46b13-5866-4b23-bcb3-c6b4e8adb5fa@github.com>
Message-ID: <xF_60TInbIiY7GHkT1zGOXzLH2svgIO2S8jUZGziU5s=.df0e60e5-b94e-47fd-baf1-301a94e02981@github.com>

On Tue, 9 Jan 2024 02:30:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Trivial fix to the formatting of "argument" lists for a few sub-commands.
> Thanks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17318#pullrequestreview-1810601092

From dholmes at openjdk.org  Tue Jan  9 08:22:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Jan 2024 08:22:28 GMT
Subject: RFR: 8323241: jcmd manpage should use lists for argument lists
In-Reply-To: <xF_60TInbIiY7GHkT1zGOXzLH2svgIO2S8jUZGziU5s=.df0e60e5-b94e-47fd-baf1-301a94e02981@github.com>
References: <4u5tmz1xty7FQZYG9aAF9QChI7Xkg3JISFNNQPJDHN0=.49e46b13-5866-4b23-bcb3-c6b4e8adb5fa@github.com>
 <xF_60TInbIiY7GHkT1zGOXzLH2svgIO2S8jUZGziU5s=.df0e60e5-b94e-47fd-baf1-301a94e02981@github.com>
Message-ID: <ruuhPZWTqbOvpJff8DuI3EAQ7l-SJdITjG0nceCNppg=.ab4c5df3-1a15-486c-9b89-8133be955ed0@github.com>

On Tue, 9 Jan 2024 08:10:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Trivial fix to the formatting of "argument" lists for a few sub-commands.
>> Thanks
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the review @AlanBateman !

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

PR Comment: https://git.openjdk.org/jdk/pull/17318#issuecomment-1882594833

From dholmes at openjdk.org  Tue Jan  9 08:22:30 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Jan 2024 08:22:30 GMT
Subject: Integrated: 8323241: jcmd manpage should use lists for argument lists
In-Reply-To: <4u5tmz1xty7FQZYG9aAF9QChI7Xkg3JISFNNQPJDHN0=.49e46b13-5866-4b23-bcb3-c6b4e8adb5fa@github.com>
References: <4u5tmz1xty7FQZYG9aAF9QChI7Xkg3JISFNNQPJDHN0=.49e46b13-5866-4b23-bcb3-c6b4e8adb5fa@github.com>
Message-ID: <3y2DqtPWdUTBSeyjoaOyFBvWdxIiiP7KLaIyl7ZJLyY=.435d4e18-35d1-4c62-a09c-7e86033c663d@github.com>

On Tue, 9 Jan 2024 02:30:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Trivial fix to the formatting of "argument" lists for a few sub-commands.
> Thanks

This pull request has now been integrated.

Changeset: 075fed91
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/075fed91bd144d94328e198b41ea2946961940e9
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8323241: jcmd manpage should use lists for argument lists

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Tue Jan  9 18:46:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Jan 2024 18:46:22 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
In-Reply-To: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
Message-ID: <qAotM7eiXSMREdRFSIvgSbc52Syixcysci13DhQO55U=.e383967a-580a-493b-861b-4e5dbd533751@github.com>

On Mon, 8 Jan 2024 20:16:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix some broken links and other minor cleanups:
> 
>  There are a few broken links in the javadoc for ObjectReference.java. For example:
> 
> 
>      * Not all target VMs support this operation. See
>      * VirtualMachine#canGetMonitorInfo to determine if the
>      * operation is supported.
> 
> 
> Which should be:
> 
> 
>      * Not all target VMs support this operation. See
>      * {@link VirtualMachine#canGetMonitorInfo} to determine if the
>      * operation is supported.
> 
> 
> 
> The following does not need to include the link text:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo() canGetInstanceInfo()}`
> 
> Instead just use:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo()}`
> 
> 
> There are many places where we embed a "see" rather than use @see. The formatting convention is:
> 
> `     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}.`
> 
> However, there are a few places that are missing a space before the "see":
> 
> 
>      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>      * -see {@link VirtualMachine#canBeModified()}.

src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java line 331:

> 329:      * <code>false</code> otherwise.
> 330:      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
> 331:      * - see {@link VirtualMachine#canBeModified()}.

The alternative would be drop the "- see <link>" and add  `@see VirtualMachine#canBeModified()` on a new line so that it shows up in the "See also" list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17311#discussion_r1446472512

From cjplummer at openjdk.org  Tue Jan  9 19:12:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 9 Jan 2024 19:12:23 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
In-Reply-To: <qAotM7eiXSMREdRFSIvgSbc52Syixcysci13DhQO55U=.e383967a-580a-493b-861b-4e5dbd533751@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
 <qAotM7eiXSMREdRFSIvgSbc52Syixcysci13DhQO55U=.e383967a-580a-493b-861b-4e5dbd533751@github.com>
Message-ID: <SjBSJtxz8NLOlu3ZFnLdbsm2M7GXU6Vyc9C4YWUQvqY=.c5eae3b0-3872-4cb6-81cb-685a7062cf68@github.com>

On Tue, 9 Jan 2024 18:44:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Fix some broken links and other minor cleanups:
>> 
>>  There are a few broken links in the javadoc for ObjectReference.java. For example:
>> 
>> 
>>      * Not all target VMs support this operation. See
>>      * VirtualMachine#canGetMonitorInfo to determine if the
>>      * operation is supported.
>> 
>> 
>> Which should be:
>> 
>> 
>>      * Not all target VMs support this operation. See
>>      * {@link VirtualMachine#canGetMonitorInfo} to determine if the
>>      * operation is supported.
>> 
>> 
>> 
>> The following does not need to include the link text:
>> 
>> `     * {@link VirtualMachine#canGetInstanceInfo() canGetInstanceInfo()}`
>> 
>> Instead just use:
>> 
>> `     * {@link VirtualMachine#canGetInstanceInfo()}`
>> 
>> 
>> There are many places where we embed a "see" rather than use @see. The formatting convention is:
>> 
>> `     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}.`
>> 
>> However, there are a few places that are missing a space before the "see":
>> 
>> 
>>      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>>      * -see {@link VirtualMachine#canBeModified()}.
>
> src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java line 331:
> 
>> 329:      * <code>false</code> otherwise.
>> 330:      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>> 331:      * - see {@link VirtualMachine#canBeModified()}.
> 
> The alternative would be drop the "- see <link>" and add  `@see VirtualMachine#canBeModified()` on a new line so that it shows up in the "See also" list.

There are a lot of places where we use `see` in this manner, because it applies specifically to the text that proceeds it. These 3 were different in that the space was missing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17311#discussion_r1446495608

From cjplummer at openjdk.org  Tue Jan  9 19:12:25 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 9 Jan 2024 19:12:25 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
In-Reply-To: <JGeZiT4CTuZIV4wZl8X7g3Y8EAY_D-Zmr98BVDeLqsM=.3f1d748e-fc24-4467-8c75-560b4cd752be@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
 <JGeZiT4CTuZIV4wZl8X7g3Y8EAY_D-Zmr98BVDeLqsM=.3f1d748e-fc24-4467-8c75-560b4cd752be@github.com>
Message-ID: <2i9Rna418LEX615MaXy9ArC2X8kZUxHWDfHGCFid1mk=.276a7e95-f1cd-407b-9912-de8ce1be7dc0@github.com>

On Tue, 9 Jan 2024 07:24:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Fix some broken links and other minor cleanups:
>> 
>>  There are a few broken links in the javadoc for ObjectReference.java. For example:
>> 
>> 
>>      * Not all target VMs support this operation. See
>>      * VirtualMachine#canGetMonitorInfo to determine if the
>>      * operation is supported.
>> 
>> 
>> Which should be:
>> 
>> 
>>      * Not all target VMs support this operation. See
>>      * {@link VirtualMachine#canGetMonitorInfo} to determine if the
>>      * operation is supported.
>> 
>> 
>> 
>> The following does not need to include the link text:
>> 
>> `     * {@link VirtualMachine#canGetInstanceInfo() canGetInstanceInfo()}`
>> 
>> Instead just use:
>> 
>> `     * {@link VirtualMachine#canGetInstanceInfo()}`
>> 
>> 
>> There are many places where we embed a "see" rather than use @see. The formatting convention is:
>> 
>> `     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}.`
>> 
>> However, there are a few places that are missing a space before the "see":
>> 
>> 
>>      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>>      * -see {@link VirtualMachine#canBeModified()}.
>
> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java line 681:
> 
>> 679:      * class prepare events by source name.
>> 680:      *
>> 681:      * @see ClassPrepareRequest#addSourceNameFilter
> 
> It is not clear why the link has been removed. There are some other similar places with links but others without links, so it is not clear how to achieve consistency here. Just want to understand your logic.

`@see` doesn't require using `@link`. It is implied. The text ends up in the `See Also:` section of the javadoc. The `See Also:` is just a list of links.

You may also see something like the following:

     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
     * - see {@link VirtualMachine#canBeModified()}.

In this case this is not something that ends up in the `See Also:` section. The text is simply part of the `@throw` description, and there is nothing special about the word `see`. Thus the `@link` is needed.

For this particular case you are commenting on, it seemed more appropriate to put this in the `See Also:` section rather than inlined with the descriptive text since it did not seem to be an extension of the sentence that preceded it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17311#discussion_r1446494377

From amenkov at openjdk.org  Tue Jan  9 19:33:33 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 9 Jan 2024 19:33:33 GMT
Subject: Integrated: JDK-8322237: Heap dump contains duplicate thread records
 for mounted virtual threads
In-Reply-To: <8erTsH14ewZCVLtTZe0AZjGljqpum_VxBQQq2Shn-EE=.da5df507-2878-4775-bc07-f6d642283b19@github.com>
References: <8erTsH14ewZCVLtTZe0AZjGljqpum_VxBQQq2Shn-EE=.da5df507-2878-4775-bc07-f6d642283b19@github.com>
Message-ID: <wI9pYnflZAg9T20V9aFQ472-jW6tI3gljFjN2d_h7_E=.54992564-10ab-46a2-b8d9-4bd552f32063@github.com>

On Sat, 16 Dec 2023 02:15:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> HeapDumper dumps virtual threads in 2 places:
> - dumping platform threads (mounted virtual threads are dumped as separate thread object);
> - dumping heap objects when the object is `java.lang.VirtualThread`.
> 
> In the 2nd case mounted virtual threads should be skipped (as they are already dumped with correct stack traces/stack references)
> Check that a virtual thread is mounted is non-trivial, method from JvmtiEnvBase was used for this.
> 
> Testing: tier1..3, heapdump-related tests: open/test/hotspot/jtreg/serviceability,open/test/hotspot/jtreg/runtime/ErrorHandling,open/test/hotspot/jtreg/gc/epsilon,open/test/jdk/sun/tools/jhsdb

This pull request has now been integrated.

Changeset: dd8ae616
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd8ae616437398f957f9b4f09cf2c7f1d0bd0938
Stats:     35 lines in 2 files changed: 33 ins; 0 del; 2 mod

8322237: Heap dump contains duplicate thread records for mounted virtual threads

Reviewed-by: dholmes, sspitsyn

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

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

From alanb at openjdk.org  Tue Jan  9 20:03:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Jan 2024 20:03:25 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
In-Reply-To: <SjBSJtxz8NLOlu3ZFnLdbsm2M7GXU6Vyc9C4YWUQvqY=.c5eae3b0-3872-4cb6-81cb-685a7062cf68@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
 <qAotM7eiXSMREdRFSIvgSbc52Syixcysci13DhQO55U=.e383967a-580a-493b-861b-4e5dbd533751@github.com>
 <SjBSJtxz8NLOlu3ZFnLdbsm2M7GXU6Vyc9C4YWUQvqY=.c5eae3b0-3872-4cb6-81cb-685a7062cf68@github.com>
Message-ID: <a25ebw8DDBvxJkdMj9cw_pIWiRJhmWxKuV2XeZ4JZW8=.24074819-983a-40d8-a62f-4d05a801a64d@github.com>

On Tue, 9 Jan 2024 19:09:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/jdi/ObjectReference.java line 331:
>> 
>>> 329:      * <code>false</code> otherwise.
>>> 330:      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>>> 331:      * - see {@link VirtualMachine#canBeModified()}.
>> 
>> The alternative would be drop the "- see <link>" and add  `@see VirtualMachine#canBeModified()` on a new line so that it shows up in the "See also" list.
>
> There are a lot of places where we use `see` in this manner, because it applies specifically to the text that proceeds it. These 3 were different in that the space was missing.

I personally would not use this style, instead I would limit the `@throws` to just the simple sentence and then use `@see` for related methods, just as we do in the core APIs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17311#discussion_r1446541382

From cjplummer at openjdk.org  Tue Jan  9 20:20:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 9 Jan 2024 20:20:22 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
In-Reply-To: <a25ebw8DDBvxJkdMj9cw_pIWiRJhmWxKuV2XeZ4JZW8=.24074819-983a-40d8-a62f-4d05a801a64d@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
 <qAotM7eiXSMREdRFSIvgSbc52Syixcysci13DhQO55U=.e383967a-580a-493b-861b-4e5dbd533751@github.com>
 <SjBSJtxz8NLOlu3ZFnLdbsm2M7GXU6Vyc9C4YWUQvqY=.c5eae3b0-3872-4cb6-81cb-685a7062cf68@github.com>
 <a25ebw8DDBvxJkdMj9cw_pIWiRJhmWxKuV2XeZ4JZW8=.24074819-983a-40d8-a62f-4d05a801a64d@github.com>
Message-ID: <fJF0W82-LKPbCVKxEPA__DTBN3eOAyQC8hAFWMtB9uE=.cd02bfa7-83a6-45dc-a199-7b197a68f38b@github.com>

On Tue, 9 Jan 2024 20:00:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There are a lot of places where we use `see` in this manner, because it applies specifically to the text that proceeds it. These 3 were different in that the space was missing.
>
> Personally I wouldn't not use this style, instead I would limit the `@throws` to just the simple sentence and then use `@see` for related methods, just as we do in the core APIs.

We have 33 instances of using `see` like this in JDI. I rather not get into changing them for this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17311#discussion_r1446555486

From amenkov at openjdk.org  Tue Jan  9 22:28:21 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 9 Jan 2024 22:28:21 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field
In-Reply-To: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
Message-ID: <rmnLxrowm3lnS2N2NU09G6jWviKxSMtMKeWGLP3dnZ8=.463a3ffb-29b1-4797-bf19-4a7e93a9fff8@github.com>

On Wed, 13 Dec 2023 21:32:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate class fields in the reverse order and use field indexes to access instead of forward iteration. This is performance ineffective (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> The change introduces new class FilteredJavaFieldStream as a replacement for FilteredFieldStream.
> It uses the same FilteredField/FilteredFieldsMap stuff as FilteredJavaFieldStream does.
> 
> FieldStream/FilteredFieldStream are still used by heap walking API, will be cleaned by [JDK-8317636](https://bugs.openjdk.org/browse/JDK-8317636)
> 
> Testing:
> - tier1..3
> - all tests which calls GetClassFields: open/test/hotspot/jtreg/serviceability/jvmti,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic
> including
>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java - tests that GetClassFields returns fields in correct order;
>   - test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/FilteredFieldsTest.java - test that GetClassFields filters out field like reflection.

Ping. Could I get review please.

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

PR Comment: https://git.openjdk.org/jdk/pull/17094#issuecomment-1883898569

From sspitsyn at openjdk.org  Tue Jan  9 23:06:24 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 9 Jan 2024 23:06:24 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
In-Reply-To: <2i9Rna418LEX615MaXy9ArC2X8kZUxHWDfHGCFid1mk=.276a7e95-f1cd-407b-9912-de8ce1be7dc0@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
 <JGeZiT4CTuZIV4wZl8X7g3Y8EAY_D-Zmr98BVDeLqsM=.3f1d748e-fc24-4467-8c75-560b4cd752be@github.com>
 <2i9Rna418LEX615MaXy9ArC2X8kZUxHWDfHGCFid1mk=.276a7e95-f1cd-407b-9912-de8ce1be7dc0@github.com>
Message-ID: <7YcjhTN2xI24C4m5kawyov7nuTms03X86NxvObFidbI=.a7710dc8-83bd-490e-b996-d001c2e3cf86@github.com>

On Tue, 9 Jan 2024 19:08:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java line 681:
>> 
>>> 679:      * class prepare events by source name.
>>> 680:      *
>>> 681:      * @see ClassPrepareRequest#addSourceNameFilter
>> 
>> It is not clear why the link has been removed. There are some other similar places with links but others without links, so it is not clear how to achieve consistency here. Just want to understand your logic.
>
> `@see` doesn't require using `@link`. It is implied. The text ends up in the `See Also:` section of the javadoc. The `See Also:` is just a list of links.
> 
> You may also see something like the following:
> 
>      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>      * - see {@link VirtualMachine#canBeModified()}.
> 
> In this case this is not something that ends up in the `See Also:` section. The text is simply part of the `@throw` description, and there is nothing special about the word `see`. Thus the `@link` is needed.
> 
> For this particular case you are commenting on, it seemed more appropriate to put this in the `See Also:` section rather than inlined with the descriptive text since it did not seem to be an extension of the sentence that preceded it.

Okay, thanks! Reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17311#discussion_r1446709471

From sspitsyn at openjdk.org  Tue Jan  9 23:20:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 9 Jan 2024 23:20:21 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field
In-Reply-To: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
Message-ID: <pY92sHbQfo8j48YnyakWe00h5T2dFf3AFn2vuYBB62c=.508c52e2-2d08-4968-b111-47212e949ced@github.com>

On Wed, 13 Dec 2023 21:32:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate class fields in the reverse order and use field indexes to access instead of forward iteration. This is performance ineffective (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> The change introduces new class FilteredJavaFieldStream as a replacement for FilteredFieldStream.
> It uses the same FilteredField/FilteredFieldsMap stuff as FilteredJavaFieldStream does.
> 
> FieldStream/FilteredFieldStream are still used by heap walking API, will be cleaned by [JDK-8317636](https://bugs.openjdk.org/browse/JDK-8317636)
> 
> Testing:
> - tier1..3
> - all tests which calls GetClassFields: open/test/hotspot/jtreg/serviceability/jvmti,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic
> including
>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java - tests that GetClassFields returns fields in correct order;
>   - test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/FilteredFieldsTest.java - test that GetClassFields filters out field like reflection.

Looks good!
The copyright headers need to be updated.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17094#pullrequestreview-1812171240

From sspitsyn at openjdk.org  Tue Jan  9 23:29:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 9 Jan 2024 23:29:22 GMT
Subject: [jdk22] RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
In-Reply-To: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
References: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
Message-ID: <cWJUikQsPhbJ98Oa25FYcTkizSxUhLXMTMChsrNm5BE=.5452e37b-2db7-4bcf-9ba0-9dd12d4f4959@github.com>

On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Serguei Spitsyn on 19 Dec 2023 and was reviewed by Leonid Mesnik and Alan Bateman.
> 
> Thanks!

Ping! Need, at list, one review for this 22 backport, please.

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

PR Comment: https://git.openjdk.org/jdk22/pull/23#issuecomment-1883954123

From sspitsyn at openjdk.org  Tue Jan  9 23:53:30 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 9 Jan 2024 23:53:30 GMT
Subject: RFR: 8321685: Missing ResourceMark in code called from
 JvmtiEnvBase::get_vthread_jvf
Message-ID: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>

This fix adds a ResourceMark missing in the `SetFramePopClosure::do_thread` and `SetFramePopClosure::do_vthread`.

Testing:
 - TBD to submit tiers: 1-5

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

Commit messages:
 - 8321685: Missing ResourceMark in code called from JvmtiEnvBase::get_vthread_jvf

Changes: https://git.openjdk.org/jdk/pull/17332/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17332&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321685
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17332/head:pull/17332

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

From amenkov at openjdk.org  Wed Jan 10 01:58:30 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Jan 2024 01:58:30 GMT
Subject: RFR: JDK-8317804: com/sun/jdi/JdwpAllowTest.java fails on Alpine 3.17
 / 3.18
Message-ID: <Ps8O8saJt-LVLuzAgW115r-UGs4sKZc1qxIg1ktsKdY=.0cb836b6-d586-4a15-a326-6495e1e4481f@github.com>

The change fixes workaround introduced by JDK-8250630.
Submitter confirmed that the fix resolved the issue.

Testing: tier1, all JDI-related tests (test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdb, test/jdk/com/sun/jdi)

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

Commit messages:
 - workaround fix

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

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

From dholmes at openjdk.org  Wed Jan 10 01:59:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Jan 2024 01:59:47 GMT
Subject: [jdk22] RFR: 8323241: jcmd manpage should use lists for argument lists
Message-ID: <7Y5uo2glNqXtdPzCMx4_A_2C_nfLctnMwvbWFc24sU4=.6e59f041-927b-41f6-9fce-784ab4df0f87@github.com>

Backport of https://github.com/openjdk/jdk/commit/075fed91bd144d94328e198b41ea2946961940e9 which was reviewed by Alan Bateman.

The backport is not clean as one item in mainline does not exist in JDK 22.

Thanks.

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

Commit messages:
 - Backport 075fed91bd144d94328e198b41ea2946961940e9

Changes: https://git.openjdk.org/jdk22/pull/48/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=48&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323241
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk22/pull/48.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/48/head:pull/48

PR: https://git.openjdk.org/jdk22/pull/48

From amenkov at openjdk.org  Wed Jan 10 02:06:19 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Jan 2024 02:06:19 GMT
Subject: RFR: 8321685: Missing ResourceMark in code called from
 JvmtiEnvBase::get_vthread_jvf
In-Reply-To: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>
References: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>
Message-ID: <STo5rU7eppjWF2xHAI6kV_4xlgc5Gb7fSbRdstD6J-k=.ffab7305-0b1f-47bb-b68c-e14eb38def59@github.com>

On Tue, 9 Jan 2024 23:48:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fix adds a ResourceMark missing in the `SetFramePopClosure::do_thread` and `SetFramePopClosure::do_vthread`.
> 
> Testing:
>  - TBD to submit tiers: 1-5

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17332#pullrequestreview-1812295888

From cjplummer at openjdk.org  Wed Jan 10 02:37:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 02:37:23 GMT
Subject: RFR: 8321685: Missing ResourceMark in code called from
 JvmtiEnvBase::get_vthread_jvf
In-Reply-To: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>
References: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>
Message-ID: <fBYGRfhlLjRnc2zR2YdphAPJjjEUlLn6jel8IrpeLQ8=.1139788b-ca1a-494b-970f-0090f59ebe68@github.com>

On Tue, 9 Jan 2024 23:48:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fix adds a ResourceMark missing in the `SetFramePopClosure::do_thread` and `SetFramePopClosure::do_vthread`.
> 
> Testing:
>  - TBD to submit tiers: 1-5

Looks good. Note, it would be good if the jvmti code added comments explaining why a ResourceMark is needed. For these two cases I had to search around until I stumbled across the following in some unrelated code:

  // vframes are resource allocated
  Thread* current_thread = Thread::current();
  ResourceMark rm(current_thread);

This looks very much like the code you are updating, except the updated code is lacking the comment.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17332#pullrequestreview-1812314880

From amenkov at openjdk.org  Wed Jan 10 02:39:33 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Jan 2024 02:39:33 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v2]
In-Reply-To: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
Message-ID: <JGe8Yc3R083BQxr7SLFnUQb_IB5BpYU0gffnLiaT6Ts=.5ca86311-3021-498d-a516-e40d746dd682@github.com>

> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate class fields in the reverse order and use field indexes to access instead of forward iteration. This is performance ineffective (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> The change introduces new class FilteredJavaFieldStream as a replacement for FilteredFieldStream.
> It uses the same FilteredField/FilteredFieldsMap stuff as FilteredJavaFieldStream does.
> 
> FieldStream/FilteredFieldStream are still used by heap walking API, will be cleaned by [JDK-8317636](https://bugs.openjdk.org/browse/JDK-8317636)
> 
> Testing:
> - tier1..3
> - all tests which calls GetClassFields: open/test/hotspot/jtreg/serviceability/jvmti,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic
> including
>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java - tests that GetClassFields returns fields in correct order;
>   - test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/FilteredFieldsTest.java - test that GetClassFields filters out field like reflection.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  copyright headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17094/files
  - new: https://git.openjdk.org/jdk/pull/17094/files/7a790887..76df939f

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17094.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17094/head:pull/17094

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

From cjplummer at openjdk.org  Wed Jan 10 02:43:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 02:43:22 GMT
Subject: [jdk22] RFR: 8323241: jcmd manpage should use lists for argument
 lists
In-Reply-To: <7Y5uo2glNqXtdPzCMx4_A_2C_nfLctnMwvbWFc24sU4=.6e59f041-927b-41f6-9fce-784ab4df0f87@github.com>
References: <7Y5uo2glNqXtdPzCMx4_A_2C_nfLctnMwvbWFc24sU4=.6e59f041-927b-41f6-9fce-784ab4df0f87@github.com>
Message-ID: <Js3F116TEnhjc70TVtegzHCklE_2WHffVTXsgqIc5yY=.4aea2da7-c355-4ef0-8aed-112cc35a15fe@github.com>

On Wed, 10 Jan 2024 01:53:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/075fed91bd144d94328e198b41ea2946961940e9 which was reviewed by Alan Bateman.
> 
> The backport is not clean as one item in mainline does not exist in JDK 22.
> 
> Thanks.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/48#pullrequestreview-1812318827

From cjplummer at openjdk.org  Wed Jan 10 02:46:20 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 02:46:20 GMT
Subject: RFR: JDK-8317804: com/sun/jdi/JdwpAllowTest.java fails on Alpine
 3.17 / 3.18
In-Reply-To: <Ps8O8saJt-LVLuzAgW115r-UGs4sKZc1qxIg1ktsKdY=.0cb836b6-d586-4a15-a326-6495e1e4481f@github.com>
References: <Ps8O8saJt-LVLuzAgW115r-UGs4sKZc1qxIg1ktsKdY=.0cb836b6-d586-4a15-a326-6495e1e4481f@github.com>
Message-ID: <DJRMHC-z_JL8qCmuAe43uEFJfvL9go7fcNPvWBIzyxs=.07004620-d8e4-48f0-b88c-22d9a6ce57ea@github.com>

On Wed, 10 Jan 2024 01:53:02 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes workaround introduced by JDK-8250630.
> Submitter confirmed that the fix resolved the issue.
> 
> Testing: tier1, all JDI-related tests (test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdb, test/jdk/com/sun/jdi)

There's no explanation here of the root cause and how the fix solves it, and the CR has too much discussion to wade through.

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

PR Comment: https://git.openjdk.org/jdk/pull/17334#issuecomment-1884102814

From amenkov at openjdk.org  Wed Jan 10 04:00:20 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Jan 2024 04:00:20 GMT
Subject: RFR: JDK-8317804: com/sun/jdi/JdwpAllowTest.java fails on Alpine
 3.17 / 3.18
In-Reply-To: <DJRMHC-z_JL8qCmuAe43uEFJfvL9go7fcNPvWBIzyxs=.07004620-d8e4-48f0-b88c-22d9a6ce57ea@github.com>
References: <Ps8O8saJt-LVLuzAgW115r-UGs4sKZc1qxIg1ktsKdY=.0cb836b6-d586-4a15-a326-6495e1e4481f@github.com>
 <DJRMHC-z_JL8qCmuAe43uEFJfvL9go7fcNPvWBIzyxs=.07004620-d8e4-48f0-b88c-22d9a6ce57ea@github.com>
Message-ID: <Jg52rEUa3cxyscqE8FiRd6Zo9pBm35gnxQ9C8K8fAzc=.c57abb05-76ec-411d-af8d-43822f06439f@github.com>

On Wed, 10 Jan 2024 02:43:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There's no explanation here of the root cause and how the fix solves it, and the CR has too much discussion to wade through.

Sorry, my fault. Without explanation the fix may look not as simple as it is.
It's a typo in the code - need to take a closer look at the cycle.
I added more details to the description.

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

PR Comment: https://git.openjdk.org/jdk/pull/17334#issuecomment-1884153702

From dholmes at openjdk.org  Wed Jan 10 04:32:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Jan 2024 04:32:28 GMT
Subject: [jdk22] RFR: 8323241: jcmd manpage should use lists for argument
 lists
In-Reply-To: <Js3F116TEnhjc70TVtegzHCklE_2WHffVTXsgqIc5yY=.4aea2da7-c355-4ef0-8aed-112cc35a15fe@github.com>
References: <7Y5uo2glNqXtdPzCMx4_A_2C_nfLctnMwvbWFc24sU4=.6e59f041-927b-41f6-9fce-784ab4df0f87@github.com>
 <Js3F116TEnhjc70TVtegzHCklE_2WHffVTXsgqIc5yY=.4aea2da7-c355-4ef0-8aed-112cc35a15fe@github.com>
Message-ID: <OA1VEFQpgOg5sQpG3tpkKBjSzmxpuSs8p8SeOIOaqrQ=.bbdb43f2-f17f-441b-ad15-38edac1af735@github.com>

On Wed, 10 Jan 2024 02:40:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Backport of https://github.com/openjdk/jdk/commit/075fed91bd144d94328e198b41ea2946961940e9 which was reviewed by Alan Bateman.
>> 
>> The backport is not clean as one item in mainline does not exist in JDK 22.
>> 
>> Thanks.
>
> Looks good.

Thanks for the review @plummercj .

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

PR Comment: https://git.openjdk.org/jdk22/pull/48#issuecomment-1884172778

From dholmes at openjdk.org  Wed Jan 10 04:32:30 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Jan 2024 04:32:30 GMT
Subject: [jdk22] Integrated: 8323241: jcmd manpage should use lists for
 argument lists
In-Reply-To: <7Y5uo2glNqXtdPzCMx4_A_2C_nfLctnMwvbWFc24sU4=.6e59f041-927b-41f6-9fce-784ab4df0f87@github.com>
References: <7Y5uo2glNqXtdPzCMx4_A_2C_nfLctnMwvbWFc24sU4=.6e59f041-927b-41f6-9fce-784ab4df0f87@github.com>
Message-ID: <3YBVQOq-qeuU8X5qDUegIUsFNPN0pRFUNVrM-_3X8_w=.5261cdf0-1b26-4d40-b478-cad39bc44c40@github.com>

On Wed, 10 Jan 2024 01:53:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/075fed91bd144d94328e198b41ea2946961940e9 which was reviewed by Alan Bateman.
> 
> The backport is not clean as one item in mainline does not exist in JDK 22.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 6b79e792
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/6b79e792ac410cc26400431d66851c89f05c2a78
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8323241: jcmd manpage should use lists for argument lists

Reviewed-by: cjplummer
Backport-of: 075fed91bd144d94328e198b41ea2946961940e9

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

PR: https://git.openjdk.org/jdk22/pull/48

From cjplummer at openjdk.org  Wed Jan 10 05:04:21 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 05:04:21 GMT
Subject: RFR: JDK-8317804: com/sun/jdi/JdwpAllowTest.java fails on Alpine
 3.17 / 3.18
In-Reply-To: <Ps8O8saJt-LVLuzAgW115r-UGs4sKZc1qxIg1ktsKdY=.0cb836b6-d586-4a15-a326-6495e1e4481f@github.com>
References: <Ps8O8saJt-LVLuzAgW115r-UGs4sKZc1qxIg1ktsKdY=.0cb836b6-d586-4a15-a326-6495e1e4481f@github.com>
Message-ID: <Plob3CpOAtgHs1-cXVumvAUWiv1XgI4rlpIqnjL87h0=.7c2d1028-a896-4718-a5ba-be9a28258f7c@github.com>

On Wed, 10 Jan 2024 01:53:02 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes workaround introduced by [[JDK-8250630]](https://bugs.openjdk.org/browse/JDK-8250630).
> The root cause of the test failure was identified by JDK-8250630:
> On Apline Linux getaddrinfo function returns 2 entries for "any" address - mapped IPv4 (`::ffff:0.0.0.0`) and IPv6 (`::`) and IPv4 is returned first.
> When JDWP agent listens on mapped IPv4, it accepts only connections from IPv4 addresses, connections from IPv6 addresses fail with "connection refused" error.
> Fix for JDK-8250630 introduced workaround for the case - if we get `::ffff:0.0.0.0` (`mappedAny`) and `::` (`in6addr_any`) is also returned by getaddrinfo, agent uses `in6addr_any` for listening.
> 
> But the fix had a typo - the loop goes through returned addresses (`ai` variable), but checks if `listenAddr` equals `in6addr_any`. This is always false (because `listenAddr` equals `mappedAny`), so the workaround does not work.
> 
> Submitter confirmed that the fix resolves the issue.
> 
> Testing: tier1, all JDI-related tests (test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdb, test/jdk/com/sun/jdi)

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17334#pullrequestreview-1812411933

From cjplummer at openjdk.org  Wed Jan 10 05:07:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 05:07:22 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v2]
In-Reply-To: <JGe8Yc3R083BQxr7SLFnUQb_IB5BpYU0gffnLiaT6Ts=.5ca86311-3021-498d-a516-e40d746dd682@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
 <JGe8Yc3R083BQxr7SLFnUQb_IB5BpYU0gffnLiaT6Ts=.5ca86311-3021-498d-a516-e40d746dd682@github.com>
Message-ID: <ua4Y-5Mg7h3Flz1h6lFUIQ6Aw3cCmqH2kXaIOb2xzlk=.2bf483c9-60c7-45e8-b18c-3ab1982264f7@github.com>

On Wed, 10 Jan 2024 02:39:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate class fields in the reverse order and use field indexes to access instead of forward iteration. This is performance ineffective (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> The change introduces new class FilteredJavaFieldStream as a replacement for FilteredFieldStream.
>> It uses the same FilteredField/FilteredFieldsMap stuff as FilteredJavaFieldStream does.
>> 
>> FieldStream/FilteredFieldStream are still used by heap walking API, will be cleaned by [JDK-8317636](https://bugs.openjdk.org/browse/JDK-8317636)
>> 
>> Testing:
>> - tier1..3
>> - all tests which calls GetClassFields: open/test/hotspot/jtreg/serviceability/jvmti,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic
>> including
>>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java - tests that GetClassFields returns fields in correct order;
>>   - test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/FilteredFieldsTest.java - test that GetClassFields filters out field like reflection.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright headers

The debug agent uses `GetClassFields`. You should make sure all jdi, jdwp, and jdb tests are run.

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

PR Comment: https://git.openjdk.org/jdk/pull/17094#issuecomment-1884197250

From cjplummer at openjdk.org  Wed Jan 10 05:31:24 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 05:31:24 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v2]
In-Reply-To: <JGe8Yc3R083BQxr7SLFnUQb_IB5BpYU0gffnLiaT6Ts=.5ca86311-3021-498d-a516-e40d746dd682@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
 <JGe8Yc3R083BQxr7SLFnUQb_IB5BpYU0gffnLiaT6Ts=.5ca86311-3021-498d-a516-e40d746dd682@github.com>
Message-ID: <Xy8pVQzd6FfN3mMGqIITd1uGynZQ4ikySotLAH0qha0=.a20e12eb-245c-4583-922a-7ad8dada239f@github.com>

On Wed, 10 Jan 2024 02:39:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate class fields in the reverse order and use field indexes to access instead of forward iteration. This is performance ineffective (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> The change introduces new class FilteredJavaFieldStream as a replacement for FilteredFieldStream.
>> It uses the same FilteredField/FilteredFieldsMap stuff as FilteredJavaFieldStream does.
>> 
>> FieldStream/FilteredFieldStream are still used by heap walking API, will be cleaned by [JDK-8317636](https://bugs.openjdk.org/browse/JDK-8317636)
>> 
>> Testing:
>> - tier1..3
>> - all tests which calls GetClassFields: open/test/hotspot/jtreg/serviceability/jvmti,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic
>> including
>>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java - tests that GetClassFields returns fields in correct order;
>>   - test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/FilteredFieldsTest.java - test that GetClassFields filters out field like reflection.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright headers

src/hotspot/share/prims/jvmtiEnv.cpp line 2910:

> 2908:     result_list[i] = jfieldIDWorkaround::to_jfieldID(
> 2909:           ik, flds.offset(),
> 2910:           flds.access_flags().is_static());

I think the indent here should be 4, not 6.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17094#discussion_r1446894480

From cjplummer at openjdk.org  Wed Jan 10 05:31:25 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 05:31:25 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v2]
In-Reply-To: <Xy8pVQzd6FfN3mMGqIITd1uGynZQ4ikySotLAH0qha0=.a20e12eb-245c-4583-922a-7ad8dada239f@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
 <JGe8Yc3R083BQxr7SLFnUQb_IB5BpYU0gffnLiaT6Ts=.5ca86311-3021-498d-a516-e40d746dd682@github.com>
 <Xy8pVQzd6FfN3mMGqIITd1uGynZQ4ikySotLAH0qha0=.a20e12eb-245c-4583-922a-7ad8dada239f@github.com>
Message-ID: <Zf7cXdguxVsKbwqdijnpICV3-v7xtdZKoC3sqP-ybbk=.dbeede3d-d11d-4f32-a2fd-2d28237a1609@github.com>

On Wed, 10 Jan 2024 05:20:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright headers
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 2910:
> 
>> 2908:     result_list[i] = jfieldIDWorkaround::to_jfieldID(
>> 2909:           ik, flds.offset(),
>> 2910:           flds.access_flags().is_static());
> 
> I think the indent here should be 4, not 6.

You said in the description that the order was reversed, but I don't see where that is getting fixed. It seems it was partially fixed by [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692), but it is only preserving the class hierarchy order, but not the order of fields within each class. If that's all you are attempting to do, then please make it clear in the description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17094#discussion_r1446898843

From alanb at openjdk.org  Wed Jan 10 08:03:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Jan 2024 08:03:28 GMT
Subject: [jdk22] RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
In-Reply-To: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
References: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
Message-ID: <jVPfPLpjU62M30gFPhFhehbBcJF5fIzmaQtQRhfXshk=.6afe9c36-4ef0-4ca4-8c31-b2a61c4d6882@github.com>

On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Serguei Spitsyn on 19 Dec 2023 and was reviewed by Leonid Mesnik and Alan Bateman.
> 
> Thanks!

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/23#pullrequestreview-1812613022

From mbaesken at openjdk.org  Wed Jan 10 08:14:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 10 Jan 2024 08:14:22 GMT
Subject: RFR: JDK-8317804: com/sun/jdi/JdwpAllowTest.java fails on Alpine
 3.17 / 3.18
In-Reply-To: <Ps8O8saJt-LVLuzAgW115r-UGs4sKZc1qxIg1ktsKdY=.0cb836b6-d586-4a15-a326-6495e1e4481f@github.com>
References: <Ps8O8saJt-LVLuzAgW115r-UGs4sKZc1qxIg1ktsKdY=.0cb836b6-d586-4a15-a326-6495e1e4481f@github.com>
Message-ID: <7ti6530I9dq9D3OG5EsKXkzjp2dcG7rJr1LWQrrjrVo=.e3f70728-a6c1-490f-af58-a59933a57896@github.com>

On Wed, 10 Jan 2024 01:53:02 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes workaround introduced by [[JDK-8250630]](https://bugs.openjdk.org/browse/JDK-8250630).
> The root cause of the test failure was identified by JDK-8250630:
> On Apline Linux getaddrinfo function returns 2 entries for "any" address - mapped IPv4 (`::ffff:0.0.0.0`) and IPv6 (`::`) and IPv4 is returned first.
> When JDWP agent listens on mapped IPv4, it accepts only connections from IPv4 addresses, connections from IPv6 addresses fail with "connection refused" error.
> Fix for JDK-8250630 introduced workaround for the case - if we get `::ffff:0.0.0.0` (`mappedAny`) and `::` (`in6addr_any`) is also returned by getaddrinfo, agent uses `in6addr_any` for listening.
> 
> But the fix had a typo - the loop goes through returned addresses (`ai` variable), but checks if `listenAddr` equals `in6addr_any`. This is always false (because `listenAddr` equals `mappedAny`), so the workaround does not work.
> 
> Submitter confirmed that the fix resolves the issue.
> 
> Testing: tier1, all JDI-related tests (test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdb, test/jdk/com/sun/jdi)

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17334#pullrequestreview-1812629326

From sspitsyn at openjdk.org  Wed Jan 10 10:11:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Jan 2024 10:11:21 GMT
Subject: RFR: 8321685: Missing ResourceMark in code called from
 JvmtiEnvBase::get_vthread_jvf
In-Reply-To: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>
References: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>
Message-ID: <6t9yEN1Us1HI7IaQGdtU7RSOXSc9KSQuLTbu_JY-Az8=.24b61e44-60b9-4f14-bd54-b0dd765be646@github.com>

On Tue, 9 Jan 2024 23:48:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fix adds a ResourceMark missing in the `SetFramePopClosure::do_thread` and `SetFramePopClosure::do_vthread`.
> 
> Testing:
>  - TBD to submit tiers: 1-5

Alex and Chris, thank you for review!
Chris, I'll add similar comments as you noted. I agree, it will be helpful.

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

PR Comment: https://git.openjdk.org/jdk/pull/17332#issuecomment-1884547925

From hgreule at openjdk.org  Wed Jan 10 10:18:22 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 10 Jan 2024 10:18:22 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v2]
In-Reply-To: <Zf7cXdguxVsKbwqdijnpICV3-v7xtdZKoC3sqP-ybbk=.dbeede3d-d11d-4f32-a2fd-2d28237a1609@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
 <JGe8Yc3R083BQxr7SLFnUQb_IB5BpYU0gffnLiaT6Ts=.5ca86311-3021-498d-a516-e40d746dd682@github.com>
 <Xy8pVQzd6FfN3mMGqIITd1uGynZQ4ikySotLAH0qha0=.a20e12eb-245c-4583-922a-7ad8dada239f@github.com>
 <Zf7cXdguxVsKbwqdijnpICV3-v7xtdZKoC3sqP-ybbk=.dbeede3d-d11d-4f32-a2fd-2d28237a1609@github.com>
Message-ID: <BsgkO5f7PpHAeYlaYUXiYXk8Z8EMyWcf1xCWYaIkRqM=.7ef550ac-d8e7-44dc-a3ef-6dd11aca6a39@github.com>

On Wed, 10 Jan 2024 05:28:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnv.cpp line 2910:
>> 
>>> 2908:     result_list[i] = jfieldIDWorkaround::to_jfieldID(
>>> 2909:           ik, flds.offset(),
>>> 2910:           flds.access_flags().is_static());
>> 
>> I think the indent here should be 4, not 6.
>
> You said in the description that the order was reversed, but I don't see where that is getting fixed. It seems it was partially fixed by [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692), but it is only preserving the class hierarchy order, but not the order of fields within each class. If that's all you are attempting to do, then please make it clear in the description.

FieldStream from reflectionUtils iterates fields in reverse order, so reversing again was previously needed here. JavaFieldStream from fieldStreams (and the new FilteredJavaFieldStream) iterate in the order the fields actually occur, so this double-reversing isn't needed anymore.

It's a bit confusing to have FilteredJavaFieldStream in reflectionUtils; eventually it would probably make sense to move the FilteredFieldsMap and FilteredjavaFieldStream into fieldStreams instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17094#discussion_r1447163822

From sspitsyn at openjdk.org  Wed Jan 10 10:38:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Jan 2024 10:38:27 GMT
Subject: [jdk22] RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
In-Reply-To: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
References: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
Message-ID: <iUenkpGXMqIrdt_jFowJYGOpRoUuMZuBmPpVJzaEL5s=.22d71c49-c5d0-4418-b13c-0621c56c3294@github.com>

On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Serguei Spitsyn on 19 Dec 2023 and was reviewed by Leonid Mesnik and Alan Bateman.
> 
> Thanks!

Alan, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk22/pull/23#issuecomment-1884591260

From sspitsyn at openjdk.org  Wed Jan 10 11:43:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Jan 2024 11:43:51 GMT
Subject: RFR: 8321685: Missing ResourceMark in code called from
 JvmtiEnvBase::get_vthread_jvf [v2]
In-Reply-To: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>
References: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>
Message-ID: <M0uywFVrw7KyMf50_mKPQRzzIHYKCfUKxY4FiDmoJsA=.cef5386f-f79e-4361-bade-f80e775b9365@github.com>

> This fix adds a ResourceMark missing in the `SetFramePopClosure::do_thread` and `SetFramePopClosure::do_vthread`.
> 
> Testing:
>  - TBD to submit tiers: 1-5

Serguei Spitsyn 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 three additional commits since the last revision:

 - Merge
 - review: add comments for ResourceMark
 - 8321685: Missing ResourceMark in code called from JvmtiEnvBase::get_vthread_jvf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17332/files
  - new: https://git.openjdk.org/jdk/pull/17332/files/dd838135..73963e8f

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

  Stats: 13793 lines in 239 files changed: 10265 ins; 2043 del; 1485 mod
  Patch: https://git.openjdk.org/jdk/pull/17332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17332/head:pull/17332

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

From jkern at openjdk.org  Wed Jan 10 11:49:05 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 10 Jan 2024 11:49:05 GMT
Subject: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle
 equality [v12]
In-Reply-To: <gGcrTtnlBgOXOfyZcvnNlUc1MceBrHFxuArZerAeHdU=.b1aaf776-00e3-401c-af8e-ebf0b78df211@github.com>
References: <gGcrTtnlBgOXOfyZcvnNlUc1MceBrHFxuArZerAeHdU=.b1aaf776-00e3-401c-af8e-ebf0b78df211@github.com>
Message-ID: <YoXI4zXroPuOX4fJhdiLOJmJRTeLQOYk_P8nQvl3ORY=.6b0684fc-60cc-4462-9247-b1b511de5e3a@github.com>

> On AIX, repeated calls to dlopen referring to the same shared library may result in different, unique dl handles to be returned from libc. In that it differs from typical libc implementations that cache dl handles.
> 
> This causes problems in the JVM with code that assumes equality of handles. One such problem is in the JVMTI agent handler. That problem was fixed with a local fix to said handler ([JDK-8315706](https://bugs.openjdk.org/browse/JDK-8315706)). However, this fix causes follow-up problems since it assumes that the file name passed to `os::dll_load()` is the file that has been opened. It prevents efficient, os_aix.cpp-local workarounds for other AIX issues like the *.so/*.a duality. See [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005). As such, it is a hack that causes other, more uglier hacks to follow (see discussion of https://github.com/openjdk/jdk/pull/16604).
> 
> We propose a different, cleaner way of handling this:
> 
> - Handle this entirely inside the AIX versions of os::dll_load and os::dll_unload.
> - Cache dl handles; repeated opening of a library should return the cached handle.
> - Increase handle-local ref counter on open, Decrease it on close
> - Make sure calls to os::dll_load are matched to os::dll_unload (See [JDK-8320830](https://bugs.openjdk.org/browse/JDK-8320830)).
> 
> This way we mimic dl handle equality as it is implemented on other platforms, and this works for all callers of os::dll_load.

Joachim Kern has updated the pull request incrementally with two additional commits since the last revision:

 - cosmetic changes
 - cosmetic changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16920/files
  - new: https://git.openjdk.org/jdk/pull/16920/files/acf306d4..d908a969

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16920&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16920&range=10-11

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

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

From jbechberger at openjdk.org  Wed Jan 10 13:55:37 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 10 Jan 2024 13:55:37 GMT
Subject: RFR: JDK-8318736: com/sun/jdi/JdwpOnThrowTest.java failed with
 "transport error 202: bind failed: Address already in use" [v6]
In-Reply-To: <lQrfSexZhT9reirdSWvRyWLBNIQAASQAFlvKn6mfeOs=.9230341f-0276-447d-b18b-70a0017e16ca@github.com>
References: <O3n-DS4caJ5YTGcJYU6BV2jKMtH1wJ4crluS63z-Qo4=.f78665aa-d6f1-42a3-8532-f7c963518b6d@github.com>
 <lQrfSexZhT9reirdSWvRyWLBNIQAASQAFlvKn6mfeOs=.9230341f-0276-447d-b18b-70a0017e16ca@github.com>
Message-ID: <adwMDpuVZk-0cxQNVO5EEGE4CtZ6E2g6J84DlIfVFtA=.9930d766-674b-4f16-bcde-6cf69ac0bca7@github.com>

On Fri, 3 Nov 2023 07:22:26 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Fix race condition in debugger port selection, introduced with [JDK-8317920](https://bugs.openjdk.org/browse/JDK-8317920).
>> 
>> Tested on my Mac M1, but it doesn't contain platform-dependent code.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/com/sun/jdi/lib/jdb/Debuggee.java
>   
>   Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com>

I forgot that I wanted it to backport from 17u-dev.

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

PR Comment: https://git.openjdk.org/jdk/pull/16358#issuecomment-1884891560

From dfuchs at openjdk.org  Wed Jan 10 14:07:29 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Jan 2024 14:07:29 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
Message-ID: <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>

On Thu, 4 Jan 2024 10:48:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary MLET_ Properties

test/jdk/javax/management/Introspector/ClassLeakTest.java line 55:

> 53:         ObjectName testName = new ObjectName("x:name=Test");
> 54:         Test mbean = new Test();
> 55:         mbs.registerMBean(mbean, testName);

I suspect this test should first register an MBean which is a ClassLoader implementing PrivateClassLoader, through which the TestMBean would be loaded in order to preserve the semantics of the test.

In other words, replace the MLet with a regular MBean that extends URLClassLoader and implements PrivateClassLoader and do the same thing than the original test was doing.

test/jdk/javax/management/mxbean/MXBeanLoadingTest1.java line 85:

> 83:             MBeanServer mbs = MBeanServerFactory.createMBeanServer();
> 84:             ObjectName testName = new ObjectName("x:type=test");
> 85:             ObjectInstance mb = mbs.createMBean(Test.class.getName(), testName);

Same remark here - I think we need to first register an MBean which is a ClassLoader and implements PrivateClassLoader to replace the MLet in this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447419444
PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447428031

From sspitsyn at openjdk.org  Wed Jan 10 14:10:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Jan 2024 14:10:32 GMT
Subject: Integrated: 8321685: Missing ResourceMark in code called from
 JvmtiEnvBase::get_vthread_jvf
In-Reply-To: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>
References: <v4qhnp8oYgFUOGHs3r3aOqGyqExkqD6-7cW0okwqnK4=.9a6a28a6-40d0-440e-aa51-c3790d14fd92@github.com>
Message-ID: <mKOgZBIBvCbH3wZvW1ooQq73jqziKwtW9QGNB5t6L9Y=.2898310a-9a94-4b78-b921-f338e836b46a@github.com>

On Tue, 9 Jan 2024 23:48:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fix adds a ResourceMark missing in the `SetFramePopClosure::do_thread` and `SetFramePopClosure::do_vthread`.
> 
> Testing:
>  - TBD to submit tiers: 1-5

This pull request has now been integrated.

Changeset: 2806adee
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2806adee2d8cca6bc215f285888631799bd02eac
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8321685: Missing ResourceMark in code called from JvmtiEnvBase::get_vthread_jvf

Reviewed-by: amenkov, cjplummer

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

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

From kevinw at openjdk.org  Wed Jan 10 15:18:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Jan 2024 15:18:25 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
Message-ID: <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>

On Wed, 10 Jan 2024 13:55:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary MLET_ Properties
>
> test/jdk/javax/management/Introspector/ClassLeakTest.java line 55:
> 
>> 53:         ObjectName testName = new ObjectName("x:name=Test");
>> 54:         Test mbean = new Test();
>> 55:         mbs.registerMBean(mbean, testName);
> 
> I suspect this test should first register an MBean which is a ClassLoader implementing PrivateClassLoader, through which the TestMBean would be loaded in order to preserve the semantics of the test.
> 
> In other words, replace the MLet with a regular MBean that extends URLClassLoader and implements PrivateClassLoader and do the same thing than the original test was doing.

I didn't see great value in it, as we no longer provide an MBean which is a ClassLoader.
Having a test MBean that extends URLClassLoader, and calling its loadClass()... is basically testing URLClassLoader? 8-)
Implementing PrivateClassLoader affects ClassLoaderRepository behaviour, but that's not tested here.
If you think this has value, we can do it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447525897

From dfuchs at openjdk.org  Wed Jan 10 16:16:26 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Jan 2024 16:16:26 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
Message-ID: <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>

On Wed, 10 Jan 2024 15:15:36 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/javax/management/Introspector/ClassLeakTest.java line 55:
>> 
>>> 53:         ObjectName testName = new ObjectName("x:name=Test");
>>> 54:         Test mbean = new Test();
>>> 55:         mbs.registerMBean(mbean, testName);
>> 
>> I suspect this test should first register an MBean which is a ClassLoader implementing PrivateClassLoader, through which the TestMBean would be loaded in order to preserve the semantics of the test.
>> 
>> In other words, replace the MLet with a regular MBean that extends URLClassLoader and implements PrivateClassLoader and do the same thing than the original test was doing.
>
> I didn't see great value in it, as we no longer provide an MBean which is a ClassLoader.
> Having a test MBean that extends URLClassLoader, and calling its loadClass()... is basically testing URLClassLoader? 8-)
> Implementing PrivateClassLoader affects ClassLoaderRepository behaviour, but that's not tested here.
> If you think this has value, we can do it.

My thinking is that this tests for a leak when an MBean is created using a ClassLoader which is also an MBean. MLet was such a ready-to-use ClassLoader. We no longer have MLets, but it's still possible to register an MBean that is a class loader and use that to create another MBean whose concrete class gets loaded by that ClassLoader MBean. We're testing that the Introspector doesn't create a leak in this case. And I believe the fact that the ClassLoader MBean is a PrivateClassLoader may also be of importance in the tested scenario (maybe).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447605593

From kevinw at openjdk.org  Wed Jan 10 16:53:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 Jan 2024 16:53:28 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
 <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
Message-ID: <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>

On Wed, 10 Jan 2024 16:11:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I didn't see great value in it, as we no longer provide an MBean which is a ClassLoader.
>> Having a test MBean that extends URLClassLoader, and calling its loadClass()... is basically testing URLClassLoader? 8-)
>> Implementing PrivateClassLoader affects ClassLoaderRepository behaviour, but that's not tested here.
>> If you think this has value, we can do it.
>
> My thinking is that this tests for a leak when an MBean is created using a ClassLoader which is also an MBean. MLet was such a ready-to-use ClassLoader. We no longer have MLets, but it's still possible to register an MBean that is a class loader and use that to create another MBean whose concrete class gets loaded by that ClassLoader MBean. We're testing that the Introspector doesn't create a leak in this case. And I believe the fact that the ClassLoader MBean is a PrivateClassLoader may also be of importance in the tested scenario (maybe).

Checking on the original problem noted in the test, looks like it wasn't really about ClassLoaders and MLets:
JDK-4909536: Standard MBean introspector keeps reference to last class introspected
This is what the test still tests.
Do we see value in having the MBean be a ClassLoader and checking if such MBeans are held on to...? 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447655672

From dfuchs at openjdk.org  Wed Jan 10 17:09:27 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Jan 2024 17:09:27 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
 <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
 <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>
Message-ID: <LIGvMDYJtJe8VL-DWblKtt2cEg27fkuLVq87WA2qBvI=.14cbf728-596d-4ee2-9e46-f73363598336@github.com>

On Wed, 10 Jan 2024 16:50:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> My thinking is that this tests for a leak when an MBean is created using a ClassLoader which is also an MBean. MLet was such a ready-to-use ClassLoader. We no longer have MLets, but it's still possible to register an MBean that is a class loader and use that to create another MBean whose concrete class gets loaded by that ClassLoader MBean. We're testing that the Introspector doesn't create a leak in this case. And I believe the fact that the ClassLoader MBean is a PrivateClassLoader may also be of importance in the tested scenario (maybe).
>
> Checking on the original problem noted in the test, looks like it wasn't really about ClassLoaders and MLets:
> JDK-4909536: Standard MBean introspector keeps reference to last class introspected
> This is what the test still tests.
> Do we see value in having the MBean be a ClassLoader and checking if such MBeans are held on to...? 8-)

Yes, that's the whole point of the test. Without using an MBean which is a ClassLoader the fix cannot be tested.
1. you need to create an MBean which is an URLClassLoader, and it needs to be a PrivateClassLoader so that it's not added to the ClassLoaderRepository - let's call it  LoaderMBean.
2. you need to use that LoaderMBean to load another MBean - let's call it TestMBean. The concrete class of TestMBean needs to be loaded by the LoaderMBean - that is - LoaderMBean needs to be the defining ClassLoader for that class (the TestMBean class must not be loaded by the System/Application ClassLoader).
3. In the MBeanServer you then end up with two MBeans, one is the LoaderMBean, the other is the TestMBean whose class has been loaded by the LoaderMBean.
4. you then keep a weak reference on the _LoaderMBean_, and unregister both MBeans.
5. at that point - if the Introspector still has a strong reference to the class of the TestMBean, then the _LoaderMBean WeakReference_ will never be enqueued, because the class of the TestMBean will have a strong reference to its ClassLoader, which is _LoaderMBean_.

So you can only test that if you have an MBean which is loaded by a custom ClassLoader, because you want to verify that the Introspector doesn't hold on that ClassLoader (through the TestMBean class).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1447675022

From cjplummer at openjdk.org  Wed Jan 10 17:31:25 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 17:31:25 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v2]
In-Reply-To: <BsgkO5f7PpHAeYlaYUXiYXk8Z8EMyWcf1xCWYaIkRqM=.7ef550ac-d8e7-44dc-a3ef-6dd11aca6a39@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
 <JGe8Yc3R083BQxr7SLFnUQb_IB5BpYU0gffnLiaT6Ts=.5ca86311-3021-498d-a516-e40d746dd682@github.com>
 <Xy8pVQzd6FfN3mMGqIITd1uGynZQ4ikySotLAH0qha0=.a20e12eb-245c-4583-922a-7ad8dada239f@github.com>
 <Zf7cXdguxVsKbwqdijnpICV3-v7xtdZKoC3sqP-ybbk=.dbeede3d-d11d-4f32-a2fd-2d28237a1609@github.com>
 <BsgkO5f7PpHAeYlaYUXiYXk8Z8EMyWcf1xCWYaIkRqM=.7ef550ac-d8e7-44dc-a3ef-6dd11aca6a39@github.com>
Message-ID: <-CbIylmXFWX0z0oN8Ewxs6PH8E5puD_0JF0Kw6xqUFY=.92381e98-6c70-493e-9deb-44e86bdf6a70@github.com>

On Wed, 10 Jan 2024 10:16:01 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> You said in the description that the order was reversed, but I don't see where that is getting fixed. It seems it was partially fixed by [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692), but it is only preserving the class hierarchy order, but not the order of fields within each class. If that's all you are attempting to do, then please make it clear in the description.
>
> FieldStream from reflectionUtils iterates fields in reverse order, so reversing again was previously needed here. JavaFieldStream from fieldStreams (and the new FilteredJavaFieldStream) iterate in the order the fields actually occur, so this double-reversing isn't needed anymore.
> 
> It's a bit confusing to have FilteredJavaFieldStream in reflectionUtils; eventually it would probably make sense to move the FilteredFieldsMap and FilteredjavaFieldStream into fieldStreams instead?

Ok. I see now how the old code was actually reversing the order to undo the reversing that was already done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17094#discussion_r1447702578

From sspitsyn at openjdk.org  Wed Jan 10 18:19:30 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Jan 2024 18:19:30 GMT
Subject: [jdk22] Integrated: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
In-Reply-To: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
References: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>
Message-ID: <vWZGC3_rp__dEhj52NGzKfdnbmev6XfHp2b18sagmCA=.ab386b0c-b8d8-4d4c-a203-bcd59b076f96@github.com>

On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Serguei Spitsyn on 19 Dec 2023 and was reviewed by Leonid Mesnik and Alan Bateman.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 865cf888
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/865cf888efbdf5533ded8ca39ef706de9b48dc15
Stats:     229 lines in 15 files changed: 196 ins; 0 del; 33 mod

8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

Reviewed-by: alanb
Backport-of: 0f8e4e0a81257c678e948c341a241dc0b810494f

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

PR: https://git.openjdk.org/jdk22/pull/23

From mdoerr at openjdk.org  Wed Jan 10 21:26:27 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 Jan 2024 21:26:27 GMT
Subject: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle
 equality [v12]
In-Reply-To: <YoXI4zXroPuOX4fJhdiLOJmJRTeLQOYk_P8nQvl3ORY=.6b0684fc-60cc-4462-9247-b1b511de5e3a@github.com>
References: <gGcrTtnlBgOXOfyZcvnNlUc1MceBrHFxuArZerAeHdU=.b1aaf776-00e3-401c-af8e-ebf0b78df211@github.com>
 <YoXI4zXroPuOX4fJhdiLOJmJRTeLQOYk_P8nQvl3ORY=.6b0684fc-60cc-4462-9247-b1b511de5e3a@github.com>
Message-ID: <KlLQ56b5zUdO6BORhb9R4-4XV_FL1sf9Yad-xjh8Onw=.00e2e9cb-e0c9-48d7-a21a-d81f486eadc3@github.com>

On Wed, 10 Jan 2024 11:49:05 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> On AIX, repeated calls to dlopen referring to the same shared library may result in different, unique dl handles to be returned from libc. In that it differs from typical libc implementations that cache dl handles.
>> 
>> This causes problems in the JVM with code that assumes equality of handles. One such problem is in the JVMTI agent handler. That problem was fixed with a local fix to said handler ([JDK-8315706](https://bugs.openjdk.org/browse/JDK-8315706)). However, this fix causes follow-up problems since it assumes that the file name passed to `os::dll_load()` is the file that has been opened. It prevents efficient, os_aix.cpp-local workarounds for other AIX issues like the *.so/*.a duality. See [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005). As such, it is a hack that causes other, more uglier hacks to follow (see discussion of https://github.com/openjdk/jdk/pull/16604).
>> 
>> We propose a different, cleaner way of handling this:
>> 
>> - Handle this entirely inside the AIX versions of os::dll_load and os::dll_unload.
>> - Cache dl handles; repeated opening of a library should return the cached handle.
>> - Increase handle-local ref counter on open, Decrease it on close
>> - Make sure calls to os::dll_load are matched to os::dll_unload (See [JDK-8320830](https://bugs.openjdk.org/browse/JDK-8320830)).
>> 
>> This way we mimic dl handle equality as it is implemented on other platforms, and this works for all callers of os::dll_load.
>
> Joachim Kern has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cosmetic changes
>  - cosmetic changes

Looks correct to me. I'm not familiar with all AIX details, but they have been reviewed before. Test results look good.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16920#pullrequestreview-1814204628

From cjplummer at openjdk.org  Wed Jan 10 21:46:29 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 21:46:29 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename parameter,
 and other misc related jcmd doc cleanups
Message-ID: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>

The jcmd docs for Compiler.perfmap currently say:

    - *filename*: (Optional) The name of the map file (STRING, no default value)

However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.

VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.

Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:

    *arguments*:

    - *flag name*: The name of the flag that you want to set (STRING, no
        default value)

    - *string value*: (Optional) The value that you want to set (STRING, no
        default value)

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

Commit messages:
 - minor improvements related to Compiler.perfmap filename argument

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

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

From amenkov at openjdk.org  Wed Jan 10 22:34:57 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Jan 2024 22:34:57 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v3]
In-Reply-To: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
Message-ID: <Dk709Zo7e2P78Xgzh-WAF-ujLTDrY72A8KpalRcP1zk=.1bb98e06-8d3c-4d6d-9c6c-0a9eee8d9c5d@github.com>

> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate class fields in the reverse order and use field indexes to access instead of forward iteration. This is performance ineffective (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> The change introduces new class FilteredJavaFieldStream as a replacement for FilteredFieldStream.
> It uses the same FilteredField/FilteredFieldsMap stuff as FilteredJavaFieldStream does.
> 
> FieldStream/FilteredFieldStream are still used by heap walking API, will be cleaned by [JDK-8317636](https://bugs.openjdk.org/browse/JDK-8317636)
> 
> Testing:
> - tier1..3
> - all tests which calls GetClassFields: open/test/hotspot/jtreg/serviceability/jvmti,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic
> including
>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java - tests that GetClassFields returns fields in correct order;
>   - test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/FilteredFieldsTest.java - test that GetClassFields filters out field like reflection.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  indent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17094/files
  - new: https://git.openjdk.org/jdk/pull/17094/files/76df939f..259365d0

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

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

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

From dholmes at openjdk.org  Wed Jan 10 22:49:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Jan 2024 22:49:21 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups
In-Reply-To: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
Message-ID: <BKbAHPPgpOHpNy70OBBOV014iAr91-adSfa7T0e86is=.8ac5b4b1-86b5-4ce3-955f-7127b629404b@github.com>

On Wed, 10 Jan 2024 21:40:08 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The jcmd docs for Compiler.perfmap currently say:
> 
>     - *filename*: (Optional) The name of the map file (STRING, no default value)
> 
> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
> 
> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
> 
> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
> 
>     *arguments*:
> 
>     - *flag name*: The name of the flag that you want to set (STRING, no
>         default value)
> 
>     - *string value*: (Optional) The value that you want to set (STRING, no
>         default value)

@plummercj the manpage output should be consistent with the help output and AFAICS the help does not state that there is a default filename either for `Compiler.perfmap` or `VM.cds`. I think the help text has to be updated as well, in which case the VM.cds change should be split out separately IMO.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17359#pullrequestreview-1814333469

From amenkov at openjdk.org  Wed Jan 10 23:15:22 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Jan 2024 23:15:22 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v2]
In-Reply-To: <-CbIylmXFWX0z0oN8Ewxs6PH8E5puD_0JF0Kw6xqUFY=.92381e98-6c70-493e-9deb-44e86bdf6a70@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
 <JGe8Yc3R083BQxr7SLFnUQb_IB5BpYU0gffnLiaT6Ts=.5ca86311-3021-498d-a516-e40d746dd682@github.com>
 <Xy8pVQzd6FfN3mMGqIITd1uGynZQ4ikySotLAH0qha0=.a20e12eb-245c-4583-922a-7ad8dada239f@github.com>
 <Zf7cXdguxVsKbwqdijnpICV3-v7xtdZKoC3sqP-ybbk=.dbeede3d-d11d-4f32-a2fd-2d28237a1609@github.com>
 <BsgkO5f7PpHAeYlaYUXiYXk8Z8EMyWcf1xCWYaIkRqM=.7ef550ac-d8e7-44dc-a3ef-6dd11aca6a39@github.com>
 <-CbIylmXFWX0z0oN8Ewxs6PH8E5puD_0JF0Kw6xqUFY=.92381e98-6c70-493e-9deb-44e86bdf6a70@github.com>
Message-ID: <MwcmO1qQSq7UD4tKxo9Mypoi0W8VgRoogFZxfruAX1U=.3264ad03-eb35-4285-a408-d97c9c9e8669@github.com>

On Wed, 10 Jan 2024 17:28:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> FieldStream from reflectionUtils iterates fields in reverse order, so reversing again was previously needed here. JavaFieldStream from fieldStreams (and the new FilteredJavaFieldStream) iterate in the order the fields actually occur, so this double-reversing isn't needed anymore.
>> 
>> It's a bit confusing to have FilteredJavaFieldStream in reflectionUtils; eventually it would probably make sense to move the FilteredFieldsMap and FilteredjavaFieldStream into fieldStreams instead?
>
> Ok. I see now how the old code was actually reversing the order to undo the reversing that was already done.

> I think the indent here should be 4, not 6.

I updated indentation to be consistent with other multi-line statements in the file

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17094#discussion_r1448092338

From cjplummer at openjdk.org  Wed Jan 10 23:46:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 23:46:22 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v3]
In-Reply-To: <Dk709Zo7e2P78Xgzh-WAF-ujLTDrY72A8KpalRcP1zk=.1bb98e06-8d3c-4d6d-9c6c-0a9eee8d9c5d@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
 <Dk709Zo7e2P78Xgzh-WAF-ujLTDrY72A8KpalRcP1zk=.1bb98e06-8d3c-4d6d-9c6c-0a9eee8d9c5d@github.com>
Message-ID: <V4C5ctP3BnCIc2LJd22kdgGCxkbHuYEALMoz_gqQETc=.31d35b26-639b-4d04-be77-51d32583895d@github.com>

On Wed, 10 Jan 2024 22:34:57 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate class fields in the reverse order and use field indexes to access instead of forward iteration. This is performance ineffective (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> The change introduces new class FilteredJavaFieldStream as a replacement for FilteredFieldStream.
>> It uses the same FilteredField/FilteredFieldsMap stuff as FilteredJavaFieldStream does.
>> 
>> FieldStream/FilteredFieldStream are still used by heap walking API, will be cleaned by [JDK-8317636](https://bugs.openjdk.org/browse/JDK-8317636)
>> 
>> Testing:
>> - tier1..3
>> - all tests which calls GetClassFields: open/test/hotspot/jtreg/serviceability/jvmti,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic
>> including
>>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java - tests that GetClassFields returns fields in correct order;
>>   - test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/FilteredFieldsTest.java - test that GetClassFields filters out field like reflection.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indent

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17094#pullrequestreview-1814392197

From cjplummer at openjdk.org  Wed Jan 10 23:47:24 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Jan 2024 23:47:24 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups
In-Reply-To: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
Message-ID: <mfo0ZXQGRyoFez6gfPO5542Q1iReLD4CHsU8TO5naNI=.94ac987a-d601-4e4f-9f56-6d27f07094ba@github.com>

On Wed, 10 Jan 2024 21:40:08 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The jcmd docs for Compiler.perfmap currently say:
> 
>     - *filename*: (Optional) The name of the map file (STRING, no default value)
> 
> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
> 
> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
> 
> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
> 
>     *arguments*:
> 
>     - *flag name*: The name of the flag that you want to set (STRING, no
>         default value)
> 
>     - *string value*: (Optional) The value that you want to set (STRING, no
>         default value)

I can update the help text, but I don't see why VM.cds needs to be a separate PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/17359#issuecomment-1885933464

From amenkov at openjdk.org  Thu Jan 11 00:33:22 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 11 Jan 2024 00:33:22 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v2]
In-Reply-To: <MwcmO1qQSq7UD4tKxo9Mypoi0W8VgRoogFZxfruAX1U=.3264ad03-eb35-4285-a408-d97c9c9e8669@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
 <JGe8Yc3R083BQxr7SLFnUQb_IB5BpYU0gffnLiaT6Ts=.5ca86311-3021-498d-a516-e40d746dd682@github.com>
 <Xy8pVQzd6FfN3mMGqIITd1uGynZQ4ikySotLAH0qha0=.a20e12eb-245c-4583-922a-7ad8dada239f@github.com>
 <Zf7cXdguxVsKbwqdijnpICV3-v7xtdZKoC3sqP-ybbk=.dbeede3d-d11d-4f32-a2fd-2d28237a1609@github.com>
 <BsgkO5f7PpHAeYlaYUXiYXk8Z8EMyWcf1xCWYaIkRqM=.7ef550ac-d8e7-44dc-a3ef-6dd11aca6a39@github.com>
 <-CbIylmXFWX0z0oN8Ewxs6PH8E5puD_0JF0Kw6xqUFY=.92381e98-6c70-493e-9deb-44e86bdf6a70@github.com>
 <MwcmO1qQSq7UD4tKxo9Mypoi0W8VgRoogFZxfruAX1U=.3264ad03-eb35-4285-a408-d97c9c9e8669@github.com>
Message-ID: <izIJh4FIEMsYxAn7uSNE2S_mAkY9flYdcsHCxZQU5Hk=.55033238-fda2-4136-9f62-bffaace6d6f3@github.com>

On Wed, 10 Jan 2024 23:12:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Ok. I see now how the old code was actually reversing the order to undo the reversing that was already done.
>
>> I think the indent here should be 4, not 6.
> 
> I updated indentation to be consistent with other multi-line statements in the file

> It's a bit confusing to have FilteredJavaFieldStream in reflectionUtils; eventually it would probably make sense to move the FilteredFieldsMap and FilteredjavaFieldStream into fieldStreams instead?

We have only 2 users of FilteredJavaFieldStream - GetClassFields and heap walking API implementation.
fieldStreams is light-weight (it has only header files) and used in many places, and FilteredFieldsMap would add dependency on several additional headers.
So prefer to keep all this stuff in reflectionUtils (at least for now).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17094#discussion_r1448139416

From amenkov at openjdk.org  Thu Jan 11 00:36:23 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 11 Jan 2024 00:36:23 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v3]
In-Reply-To: <Dk709Zo7e2P78Xgzh-WAF-ujLTDrY72A8KpalRcP1zk=.1bb98e06-8d3c-4d6d-9c6c-0a9eee8d9c5d@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
 <Dk709Zo7e2P78Xgzh-WAF-ujLTDrY72A8KpalRcP1zk=.1bb98e06-8d3c-4d6d-9c6c-0a9eee8d9c5d@github.com>
Message-ID: <rtoiCNdZOTaHyuXgkZDUzvL0dfXKnmDy_dW85cY3vh0=.73a8feb2-f02a-4558-bc86-219a721a6ad9@github.com>

On Wed, 10 Jan 2024 22:34:57 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate class fields in the reverse order and use field indexes to access instead of forward iteration. This is performance ineffective (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> The change introduces new class FilteredJavaFieldStream as a replacement for FilteredFieldStream.
>> It uses the same FilteredField/FilteredFieldsMap stuff as FilteredJavaFieldStream does.
>> 
>> FieldStream/FilteredFieldStream are still used by heap walking API, will be cleaned by [JDK-8317636](https://bugs.openjdk.org/browse/JDK-8317636)
>> 
>> Testing:
>> - tier1..3
>> - all tests which calls GetClassFields: open/test/hotspot/jtreg/serviceability/jvmti,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic
>> including
>>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java - tests that GetClassFields returns fields in correct order;
>>   - test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/FilteredFieldsTest.java - test that GetClassFields filters out field like reflection.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indent

jdi/jdwp/jdb tests passed, tier4..6 are in progress

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

PR Comment: https://git.openjdk.org/jdk/pull/17094#issuecomment-1885986523

From amenkov at openjdk.org  Thu Jan 11 00:39:26 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 11 Jan 2024 00:39:26 GMT
Subject: Integrated: JDK-8317804: com/sun/jdi/JdwpAllowTest.java fails on
 Alpine 3.17 / 3.18
In-Reply-To: <Ps8O8saJt-LVLuzAgW115r-UGs4sKZc1qxIg1ktsKdY=.0cb836b6-d586-4a15-a326-6495e1e4481f@github.com>
References: <Ps8O8saJt-LVLuzAgW115r-UGs4sKZc1qxIg1ktsKdY=.0cb836b6-d586-4a15-a326-6495e1e4481f@github.com>
Message-ID: <i78Acys27EPu4baqNd-bTaNjB3YgCl3CLrlzDgycg08=.6ae7e4a6-6b9d-4aab-9870-df76aeae4420@github.com>

On Wed, 10 Jan 2024 01:53:02 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes workaround introduced by [[JDK-8250630]](https://bugs.openjdk.org/browse/JDK-8250630).
> The root cause of the test failure was identified by JDK-8250630:
> On Apline Linux getaddrinfo function returns 2 entries for "any" address - mapped IPv4 (`::ffff:0.0.0.0`) and IPv6 (`::`) and IPv4 is returned first.
> When JDWP agent listens on mapped IPv4, it accepts only connections from IPv4 addresses, connections from IPv6 addresses fail with "connection refused" error.
> Fix for JDK-8250630 introduced workaround for the case - if we get `::ffff:0.0.0.0` (`mappedAny`) and `::` (`in6addr_any`) is also returned by getaddrinfo, agent uses `in6addr_any` for listening.
> 
> But the fix had a typo - the loop goes through returned addresses (`ai` variable), but checks if `listenAddr` equals `in6addr_any`. This is always false (because `listenAddr` equals `mappedAny`), so the workaround does not work.
> 
> Submitter confirmed that the fix resolves the issue.
> 
> Testing: tier1, all JDI-related tests (test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdb, test/jdk/com/sun/jdi)

This pull request has now been integrated.

Changeset: b530c028
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b530c0281b5082994065b10addeb8366ffa58e2f
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8317804: com/sun/jdi/JdwpAllowTest.java fails on Alpine 3.17 / 3.18

Reviewed-by: cjplummer, mbaesken

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

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

From amenkov at openjdk.org  Thu Jan 11 01:04:47 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 11 Jan 2024 01:04:47 GMT
Subject: [jdk22] RFR: 8322237: Heap dump contains duplicate thread records for
 mounted virtual threads
Message-ID: <qtUJ-g5jaw565DK1xyO12H6rqw7HtMhOWePQy7D07UM=.243a0dc3-34a0-4168-813e-e8dc840ba979@github.com>

Hi all,

This pull request contains a backport of commit [dd8ae616](https://github.com/openjdk/jdk/commit/dd8ae616437398f957f9b4f09cf2c7f1d0bd0938) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Alex Menkov on 9 Jan 2024 and was reviewed by David Holmes and Serguei Spitsyn.

Thanks!

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

Commit messages:
 - Backport dd8ae616437398f957f9b4f09cf2c7f1d0bd0938

Changes: https://git.openjdk.org/jdk22/pull/60/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=60&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322237
  Stats: 35 lines in 2 files changed: 33 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk22/pull/60.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/60/head:pull/60

PR: https://git.openjdk.org/jdk22/pull/60

From cjplummer at openjdk.org  Thu Jan 11 01:14:26 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 11 Jan 2024 01:14:26 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
In-Reply-To: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
Message-ID: <FecYyQs2QSGnoCJPXIBZUXpy6FIU8NoERzT3y3QcK90=.9b4713c6-4c61-40e6-815a-4d52bf3f8329@github.com>

On Mon, 8 Jan 2024 20:16:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix some broken links and other minor cleanups:
> 
>  There are a few broken links in the javadoc for ObjectReference.java. For example:
> 
> 
>      * Not all target VMs support this operation. See
>      * VirtualMachine#canGetMonitorInfo to determine if the
>      * operation is supported.
> 
> 
> Which should be:
> 
> 
>      * Not all target VMs support this operation. See
>      * {@link VirtualMachine#canGetMonitorInfo} to determine if the
>      * operation is supported.
> 
> 
> 
> The following does not need to include the link text:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo() canGetInstanceInfo()}`
> 
> Instead just use:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo()}`
> 
> 
> There are many places where we embed a "see" rather than use @see. The formatting convention is:
> 
> `     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}.`
> 
> However, there are a few places that are missing a space before the "see":
> 
> 
>      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>      * -see {@link VirtualMachine#canBeModified()}.

I could use one more review. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17311#issuecomment-1886029788

From amenkov at openjdk.org  Thu Jan 11 01:26:22 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 11 Jan 2024 01:26:22 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
In-Reply-To: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
Message-ID: <98KH1uRP8_WCKwqnHDw6XHofyv7wrbZVubD2dJbniQo=.0dde845e-6b49-4126-ae80-3dd44e4c1bea@github.com>

On Mon, 8 Jan 2024 20:16:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix some broken links and other minor cleanups:
> 
>  There are a few broken links in the javadoc for ObjectReference.java. For example:
> 
> 
>      * Not all target VMs support this operation. See
>      * VirtualMachine#canGetMonitorInfo to determine if the
>      * operation is supported.
> 
> 
> Which should be:
> 
> 
>      * Not all target VMs support this operation. See
>      * {@link VirtualMachine#canGetMonitorInfo} to determine if the
>      * operation is supported.
> 
> 
> 
> The following does not need to include the link text:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo() canGetInstanceInfo()}`
> 
> Instead just use:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo()}`
> 
> 
> There are many places where we embed a "see" rather than use @see. The formatting convention is:
> 
> `     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}.`
> 
> However, there are a few places that are missing a space before the "see":
> 
> 
>      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>      * -see {@link VirtualMachine#canBeModified()}.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17311#pullrequestreview-1814497335

From kevinw at openjdk.org  Thu Jan 11 11:34:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Jan 2024 11:34:24 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <LIGvMDYJtJe8VL-DWblKtt2cEg27fkuLVq87WA2qBvI=.14cbf728-596d-4ee2-9e46-f73363598336@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
 <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
 <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>
 <LIGvMDYJtJe8VL-DWblKtt2cEg27fkuLVq87WA2qBvI=.14cbf728-596d-4ee2-9e46-f73363598336@github.com>
Message-ID: <4QjIXeDX05m0gHFt-sTe7clN57p7PBsTp7Z13g5Cdq4=.de46bb97-2a22-447b-a3a7-2aac342ff7a5@github.com>

On Wed, 10 Jan 2024 17:06:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Checking on the original problem noted in the test, looks like it wasn't really about ClassLoaders and MLets:
>> JDK-4909536: Standard MBean introspector keeps reference to last class introspected
>> This is what the test still tests.
>> Do we see value in having the MBean be a ClassLoader and checking if such MBeans are held on to...? 8-)
>
> Yes, that's the whole point of the test. Without using an MBean which is a ClassLoader the fix cannot be tested.
> 1. you need to create an MBean which is an URLClassLoader, and it needs to be a PrivateClassLoader so that it's not added to the ClassLoaderRepository - let's call it  LoaderMBean.
> 2. you need to use that LoaderMBean to load another MBean - let's call it TestMBean. The concrete class of TestMBean needs to be loaded by the LoaderMBean - that is - LoaderMBean needs to be the defining ClassLoader for that class (the TestMBean class must not be loaded by the System/Application ClassLoader).
> 3. In the MBeanServer you then end up with two MBeans, one is the LoaderMBean, the other is the TestMBean whose class has been loaded by the LoaderMBean.
> 4. you then keep a weak reference on the _LoaderMBean_, and unregister both MBeans.
> 5. at that point - if the Introspector still has a strong reference to the class of the TestMBean, then the _LoaderMBean WeakReference_ will never be enqueued, because the class of the TestMBean will have a strong reference to its ClassLoader, which is _LoaderMBean_.
> 
> So you can only test that if you have an MBean which is loaded by a custom ClassLoader, because you want to verify that the Introspector doesn't hold on that ClassLoader (through the TestMBean class).

Hi Daniel -
I am missing see how being a ClassLoader relates to the leak where the Introspector holds on to a reference to the most recent MBean.  I didn't locate the jdk5 change, I only read a short synopsis.

I can make this test create an MBean which is a ClassLoader, and the test can do its check that having the loader MBean load a class, creates a distinct class.  I can add that update here.  But it looks like an MLet test which leaked into the Introspector test. 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1448708811

From dfuchs at openjdk.org  Thu Jan 11 12:27:21 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Jan 2024 12:27:21 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <4QjIXeDX05m0gHFt-sTe7clN57p7PBsTp7Z13g5Cdq4=.de46bb97-2a22-447b-a3a7-2aac342ff7a5@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
 <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
 <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>
 <LIGvMDYJtJe8VL-DWblKtt2cEg27fkuLVq87WA2qBvI=.14cbf728-596d-4ee2-9e46-f73363598336@github.com>
 <4QjIXeDX05m0gHFt-sTe7clN57p7PBsTp7Z13g5Cdq4=.de46bb97-2a22-447b-a3a7-2aac342ff7a5@github.com>
Message-ID: <Lo8e1Mrji7teolBaOC90qlICKy-MVbdpBU5RamNa56c=.04c2ddc1-6135-4549-9be9-a59caaf84bfe@github.com>

On Thu, 11 Jan 2024 11:31:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yes, that's the whole point of the test. Without using an MBean which is a ClassLoader the fix cannot be tested.
>> 1. you need to create an MBean which is an URLClassLoader, and it needs to be a PrivateClassLoader so that it's not added to the ClassLoaderRepository - let's call it  LoaderMBean.
>> 2. you need to use that LoaderMBean to load another MBean - let's call it TestMBean. The concrete class of TestMBean needs to be loaded by the LoaderMBean - that is - LoaderMBean needs to be the defining ClassLoader for that class (the TestMBean class must not be loaded by the System/Application ClassLoader).
>> 3. In the MBeanServer you then end up with two MBeans, one is the LoaderMBean, the other is the TestMBean whose class has been loaded by the LoaderMBean.
>> 4. you then keep a weak reference on the _LoaderMBean_, and unregister both MBeans.
>> 5. at that point - if the Introspector still has a strong reference to the class of the TestMBean, then the _LoaderMBean WeakReference_ will never be enqueued, because the class of the TestMBean will have a strong reference to its ClassLoader, which is _LoaderMBean_.
>> 
>> So you can only test that if you have an MBean which is loaded by a custom ClassLoader, because you want to verify that the Introspector doesn't hold on that ClassLoader (through the TestMBean class).
>
> Hi Daniel -
> I am missing see how being a ClassLoader relates to the leak where the Introspector holds on to a reference to the most recent MBean.  I didn't locate the jdk5 change, I only read a short synopsis.
> 
> I can make this test create an MBean which is a ClassLoader, and the test can do its check that having the loader MBean load a class, creates a distinct class.  I can add that update here.  But it looks like an MLet test which leaked into the Introspector test. 8-)

Hi Kevin,

To verify whether the Introspector holds a reference to a *Class Object* you need that class to be loaded by a custom class loader, and verify that the custom class loader that loaded that class can be garbage collected.

If the class loader that loaded that class has not been garbage collected after you released all references to it, then it's because the class it loaded is still referenced somewhere.

The logic of the test is as follows:
You create an MBean L which is a class loader and able to load class C. L must be the defining class loader for C.
You register L in the MBeanServer.
You ask the MBeanServer to create an MBean of class C through L (this is why you must use the variant of createMBean that takes a loader name).
You keep a weak ref to L
You unregister L and the MBean of class C from the MBeanServer and make sure the test doesn't have any strong reference to them (or to class C).
Then you start GC and wait until the weak ref to L is enqueued. If that doesn't happen, it's because the Introspector still hold a reference to class C.

You cannot test that if C has been loaded by the system class loader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1448772336

From sspitsyn at openjdk.org  Thu Jan 11 12:57:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Jan 2024 12:57:27 GMT
Subject: [jdk22] RFR: 8322237: Heap dump contains duplicate thread records
 for mounted virtual threads
In-Reply-To: <qtUJ-g5jaw565DK1xyO12H6rqw7HtMhOWePQy7D07UM=.243a0dc3-34a0-4168-813e-e8dc840ba979@github.com>
References: <qtUJ-g5jaw565DK1xyO12H6rqw7HtMhOWePQy7D07UM=.243a0dc3-34a0-4168-813e-e8dc840ba979@github.com>
Message-ID: <R21Hs1ZE-PehCmCDtdKt80tTSY5sr2iO7Kvqn5X3k-A=.b7aa9474-84b6-4569-9690-2847b280cde7@github.com>

On Thu, 11 Jan 2024 00:59:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [dd8ae616](https://github.com/openjdk/jdk/commit/dd8ae616437398f957f9b4f09cf2c7f1d0bd0938) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Alex Menkov on 9 Jan 2024 and was reviewed by David Holmes and Serguei Spitsyn.
> 
> Thanks!

This backport is clean.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/60#pullrequestreview-1815512921

From sspitsyn at openjdk.org  Thu Jan 11 13:02:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Jan 2024 13:02:22 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups
In-Reply-To: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
Message-ID: <Z2v2vqdqs9hvg7FTfVERN5Owqe6R0e_lGfqxhtNKLHw=.88ef90c7-aae0-47c1-bb42-da84962edd0e@github.com>

On Wed, 10 Jan 2024 21:40:08 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The jcmd docs for Compiler.perfmap currently say:
> 
>     - *filename*: (Optional) The name of the map file (STRING, no default value)
> 
> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
> 
> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
> 
> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
> 
>     *arguments*:
> 
>     - *flag name*: The name of the flag that you want to set (STRING, no
>         default value)
> 
>     - *string value*: (Optional) The value that you want to set (STRING, no
>         default value)

This looks okay to me modulo the comment from David.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17359#pullrequestreview-1815523231

From jkern at openjdk.org  Thu Jan 11 13:15:36 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 11 Jan 2024 13:15:36 GMT
Subject: Integrated: JDK-8320890: [AIX] Find a better way to mimic dl handle
 equality
In-Reply-To: <gGcrTtnlBgOXOfyZcvnNlUc1MceBrHFxuArZerAeHdU=.b1aaf776-00e3-401c-af8e-ebf0b78df211@github.com>
References: <gGcrTtnlBgOXOfyZcvnNlUc1MceBrHFxuArZerAeHdU=.b1aaf776-00e3-401c-af8e-ebf0b78df211@github.com>
Message-ID: <ynRqY6PM29CFLbI9C5oCVmeDysA7mLxQDo0IPzi4B_E=.3b0c1ab4-cddd-4041-a7a3-4e5592e453b2@github.com>

On Fri, 1 Dec 2023 11:33:46 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> On AIX, repeated calls to dlopen referring to the same shared library may result in different, unique dl handles to be returned from libc. In that it differs from typical libc implementations that cache dl handles.
> 
> This causes problems in the JVM with code that assumes equality of handles. One such problem is in the JVMTI agent handler. That problem was fixed with a local fix to said handler ([JDK-8315706](https://bugs.openjdk.org/browse/JDK-8315706)). However, this fix causes follow-up problems since it assumes that the file name passed to `os::dll_load()` is the file that has been opened. It prevents efficient, os_aix.cpp-local workarounds for other AIX issues like the *.so/*.a duality. See [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005). As such, it is a hack that causes other, more uglier hacks to follow (see discussion of https://github.com/openjdk/jdk/pull/16604).
> 
> We propose a different, cleaner way of handling this:
> 
> - Handle this entirely inside the AIX versions of os::dll_load and os::dll_unload.
> - Cache dl handles; repeated opening of a library should return the cached handle.
> - Increase handle-local ref counter on open, Decrease it on close
> - Make sure calls to os::dll_load are matched to os::dll_unload (See [JDK-8320830](https://bugs.openjdk.org/browse/JDK-8320830)).
> 
> This way we mimic dl handle equality as it is implemented on other platforms, and this works for all callers of os::dll_load.

This pull request has now been integrated.

Changeset: b8ae4a8c
Author:    Joachim Kern <jkern at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8ae4a8c0985d1763ac48ba78943d8b992d7be77
Stats:     446 lines in 12 files changed: 332 ins; 108 del; 6 mod

8320890: [AIX] Find a better way to mimic dl handle equality

Reviewed-by: stuefe, mdoerr

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

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

From fparain at openjdk.org  Thu Jan 11 15:45:26 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 11 Jan 2024 15:45:26 GMT
Subject: RFR: JDK-8318563: GetClassFields should not use random access to
 field [v3]
In-Reply-To: <Dk709Zo7e2P78Xgzh-WAF-ujLTDrY72A8KpalRcP1zk=.1bb98e06-8d3c-4d6d-9c6c-0a9eee8d9c5d@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
 <Dk709Zo7e2P78Xgzh-WAF-ujLTDrY72A8KpalRcP1zk=.1bb98e06-8d3c-4d6d-9c6c-0a9eee8d9c5d@github.com>
Message-ID: <B232eZj4ufRWBNRFzv8U4PkyJRv5N1C-_ZBh1kRuqwc=.a6f16f82-8437-4958-806b-bff863e038a0@github.com>

On Wed, 10 Jan 2024 22:34:57 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate class fields in the reverse order and use field indexes to access instead of forward iteration. This is performance ineffective (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> The change introduces new class FilteredJavaFieldStream as a replacement for FilteredFieldStream.
>> It uses the same FilteredField/FilteredFieldsMap stuff as FilteredJavaFieldStream does.
>> 
>> FieldStream/FilteredFieldStream are still used by heap walking API, will be cleaned by [JDK-8317636](https://bugs.openjdk.org/browse/JDK-8317636)
>> 
>> Testing:
>> - tier1..3
>> - all tests which calls GetClassFields: open/test/hotspot/jtreg/serviceability/jvmti,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic
>> including
>>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java - tests that GetClassFields returns fields in correct order;
>>   - test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/FilteredFieldsTest.java - test that GetClassFields filters out field like reflection.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indent

LGTM

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

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17094#pullrequestreview-1815899711

From dchuyko at openjdk.org  Thu Jan 11 15:47:39 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 11 Jan 2024 15:47:39 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v21]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <80-36XIRkWYvc-zxRxsYm-Puip2-Y2Cf6be206LgZpo=.9f7e32ee-f32e-4db5-b964-c400d5470139@github.com>

> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
> 
> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
> 
> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods).
> 
> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter.
> 
> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them.
> 
> In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ...

Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Deopt osr, cleanups
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - ... and 29 more: https://git.openjdk.org/jdk/compare/c2e77e2f...d1aec993

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

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=20
  Stats: 381 lines in 15 files changed: 348 ins; 3 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/14111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111

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

From jkern at openjdk.org  Thu Jan 11 15:52:46 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 11 Jan 2024 15:52:46 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on AIX
 if prefixLen of mask is larger than 32 in IPv6 case
Message-ID: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>

In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.

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

Commit messages:
 - JDK-8319382

Changes: https://git.openjdk.org/jdk/pull/17374/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17374&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319382
  Stats: 30 lines in 1 file changed: 2 ins; 19 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17374/head:pull/17374

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

From mbaesken at openjdk.org  Thu Jan 11 16:03:24 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Jan 2024 16:03:24 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case
In-Reply-To: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
Message-ID: <RQF1MOBDO9oCJPVkv6NPCI5v1Yy1v7BM4Xkv98bZ4r8=.bdfcc792-00fc-4e05-9c5b-4e6dd34e5bff@github.com>

On Thu, 11 Jan 2024 15:46:59 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.

src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c line 428:

> 426:         convertIPv4ToIPv6(&sa, &addr6);
> 427:         *isIPv4 = 1;
> 428:     } else

Better use braces here too in the `else` part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17374#discussion_r1449073666

From jkern at openjdk.org  Thu Jan 11 16:14:39 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 11 Jan 2024 16:14:39 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v2]
In-Reply-To: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
Message-ID: <vCNR3BxIbHKYvMjgThBa-GWaJnHBnCArvQltQ3BvI30=.481491ff-d62f-4646-a45b-f6cfc82ce159@github.com>

> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  cosmetic changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17374/files
  - new: https://git.openjdk.org/jdk/pull/17374/files/cbc56dd4..a5bfdd1a

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

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

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

From jkern at openjdk.org  Thu Jan 11 16:14:41 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 11 Jan 2024 16:14:41 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v2]
In-Reply-To: <RQF1MOBDO9oCJPVkv6NPCI5v1Yy1v7BM4Xkv98bZ4r8=.bdfcc792-00fc-4e05-9c5b-4e6dd34e5bff@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
 <RQF1MOBDO9oCJPVkv6NPCI5v1Yy1v7BM4Xkv98bZ4r8=.bdfcc792-00fc-4e05-9c5b-4e6dd34e5bff@github.com>
Message-ID: <ix1Ji557WoO2xQ6ChCAq6SHAfAzNQOZAcWDuhpxIGyM=.cefd147b-2046-4d35-a1f7-fc35c3664fbe@github.com>

On Thu, 11 Jan 2024 16:00:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cosmetic changes
>
> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c line 428:
> 
>> 426:         convertIPv4ToIPv6(&sa, &addr6);
>> 427:         *isIPv4 = 1;
>> 428:     } else
> 
> Better use braces here too in the `else` part.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17374#discussion_r1449087986

From cjplummer at openjdk.org  Thu Jan 11 16:47:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 11 Jan 2024 16:47:35 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v2]
In-Reply-To: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
Message-ID: <FfhdZL3jrQNavn_fYneW23Smh86u1npZ043GLQkKVy4=.e693f150-8381-4ae2-8546-57ee802f3fc9@github.com>

> The jcmd docs for Compiler.perfmap currently say:
> 
>     - *filename*: (Optional) The name of the map file (STRING, no default value)
> 
> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
> 
> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
> 
> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
> 
>     *arguments*:
> 
>     - *flag name*: The name of the flag that you want to set (STRING, no
>         default value)
> 
>     - *string value*: (Optional) The value that you want to set (STRING, no
>         default value)

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  update jcmd help output to include default filename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17359/files
  - new: https://git.openjdk.org/jdk/pull/17359/files/6a9b43f2..b6819c77

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

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

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

From cjplummer at openjdk.org  Thu Jan 11 18:16:39 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 11 Jan 2024 18:16:39 GMT
Subject: Integrated: 8323213: Fix some javadoc broken links in ObjectReference, 
 and other misc javadoc cleanups
In-Reply-To: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
Message-ID: <n_alWmfe8MNT2k1ihA7hG7rS7xpc3us10j4fun99Vww=.66072da3-9e01-4c0b-91f5-90d39c8708f1@github.com>

On Mon, 8 Jan 2024 20:16:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix some broken links and other minor cleanups:
> 
>  There are a few broken links in the javadoc for ObjectReference.java. For example:
> 
> 
>      * Not all target VMs support this operation. See
>      * VirtualMachine#canGetMonitorInfo to determine if the
>      * operation is supported.
> 
> 
> Which should be:
> 
> 
>      * Not all target VMs support this operation. See
>      * {@link VirtualMachine#canGetMonitorInfo} to determine if the
>      * operation is supported.
> 
> 
> 
> The following does not need to include the link text:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo() canGetInstanceInfo()}`
> 
> Instead just use:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo()}`
> 
> 
> There are many places where we embed a "see" rather than use @see. The formatting convention is:
> 
> `     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}.`
> 
> However, there are a few places that are missing a space before the "see":
> 
> 
>      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>      * -see {@link VirtualMachine#canBeModified()}.

This pull request has now been integrated.

Changeset: 93bedd7a
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/93bedd7abae33f5d5eb909d3d216ee415ad2f8b2
Stats:     14 lines in 2 files changed: 1 ins; 0 del; 13 mod

8323213: Fix some javadoc broken links in ObjectReference, and other misc javadoc cleanups

Reviewed-by: sspitsyn, amenkov

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

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

From cjplummer at openjdk.org  Thu Jan 11 18:16:38 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 11 Jan 2024 18:16:38 GMT
Subject: RFR: 8323213: Fix some javadoc broken links in ObjectReference,
 and other misc javadoc cleanups
In-Reply-To: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
References: <5i0-w6SjGazDLfwCT4xOrcdgnMRRWgI3wJQqPoyrGoc=.8f92cb93-8c1a-4554-a7fd-0b5e359dacd8@github.com>
Message-ID: <rfvTZ2MP1skqNmbw2RCaNqYqYCK169sviqrI_Ay8Jck=.41513a36-d85b-4d4e-aa76-d4ec7d746146@github.com>

On Mon, 8 Jan 2024 20:16:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix some broken links and other minor cleanups:
> 
>  There are a few broken links in the javadoc for ObjectReference.java. For example:
> 
> 
>      * Not all target VMs support this operation. See
>      * VirtualMachine#canGetMonitorInfo to determine if the
>      * operation is supported.
> 
> 
> Which should be:
> 
> 
>      * Not all target VMs support this operation. See
>      * {@link VirtualMachine#canGetMonitorInfo} to determine if the
>      * operation is supported.
> 
> 
> 
> The following does not need to include the link text:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo() canGetInstanceInfo()}`
> 
> Instead just use:
> 
> `     * {@link VirtualMachine#canGetInstanceInfo()}`
> 
> 
> There are many places where we embed a "see" rather than use @see. The formatting convention is:
> 
> `     * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}.`
> 
> However, there are a few places that are missing a space before the "see":
> 
> 
>      * @throws VMCannotBeModifiedException if the VirtualMachine is read-only
>      * -see {@link VirtualMachine#canBeModified()}.

Thanks for the reviews Serguei and Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/17311#issuecomment-1887704991

From amenkov at openjdk.org  Thu Jan 11 20:11:04 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 11 Jan 2024 20:11:04 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v2]
In-Reply-To: <vCNR3BxIbHKYvMjgThBa-GWaJnHBnCArvQltQ3BvI30=.481491ff-d62f-4646-a45b-f6cfc82ce159@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
 <vCNR3BxIbHKYvMjgThBa-GWaJnHBnCArvQltQ3BvI30=.481491ff-d62f-4646-a45b-f6cfc82ce159@github.com>
Message-ID: <WId4Us3KqGzuGfDpRjFPUYewqzqhK-0vqT_5hfVVers=.fc800d49-d3ab-43ae-bd55-f640639a992e@github.com>

On Thu, 11 Jan 2024 16:14:39 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c line 420:

> 418:     struct in_addr addr;
> 419:     struct in6_addr addr6;
> 420:     if (inet_pton (AF_INET6, buffer, &addr6) == 1) {

space is not needed before brace
Suggestion:

    if (inet_pton(AF_INET6, buffer, &addr6) == 1) {

src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c line 422:

> 420:     if (inet_pton (AF_INET6, buffer, &addr6) == 1) {
> 421:         *isIPv4 = 0;
> 422:     } else if (inet_pton (AF_INET, buffer, &addr) == 1) {

Space before brace
Suggestion:

    } else if (inet_pton(AF_INET, buffer, &addr) == 1) {

src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c line 425:

> 423:         // IPv4 address - convert to mapped IPv6
> 424:         struct sockaddr sa;
> 425:         memcpy(&(((struct sockaddr_in*)&sa)->sin_addr), &addr, 4);

Suggestion:

        memcpy(&(((struct sockaddr_in*)&sa)->sin_addr), &addr, sizeof(addr));

src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c line 426:

> 424:         struct sockaddr sa;
> 425:         memcpy(&(((struct sockaddr_in*)&sa)->sin_addr), &addr, 4);
> 426:         convertIPv4ToIPv6(&sa, &addr6);

Comment for convertIPv4ToIPv6 says: "Input is sockaddr just because all clients have it."
Now it's not true.
I suggest to update convertIPv4ToIPv6 function and make 1st argument `const struct in_addr` (need to update other call of the function from isPeerAllowed())

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17374#discussion_r1449312487
PR Review Comment: https://git.openjdk.org/jdk/pull/17374#discussion_r1449312811
PR Review Comment: https://git.openjdk.org/jdk/pull/17374#discussion_r1449314051
PR Review Comment: https://git.openjdk.org/jdk/pull/17374#discussion_r1449329711

From kevinw at openjdk.org  Thu Jan 11 20:59:05 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Jan 2024 20:59:05 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v4]
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <MTxYN1H-yYAS30YtR_QD7TdWAMIniVBAO5zWlZsr6so=.fd202cec-2734-4ba6-bfe8-9f78e9da2e4f@github.com>

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

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

  Test update using URLClassLoader MBeans, more like original tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16363/files
  - new: https://git.openjdk.org/jdk/pull/16363/files/29ec31f2..70092fa4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16363&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16363&range=02-03

  Stats: 83 lines in 2 files changed: 68 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/16363.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16363/head:pull/16363

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

From kevinw at openjdk.org  Thu Jan 11 21:06:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Jan 2024 21:06:26 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <Lo8e1Mrji7teolBaOC90qlICKy-MVbdpBU5RamNa56c=.04c2ddc1-6135-4549-9be9-a59caaf84bfe@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
 <T58iW4oeTwyI3Af7pumtfEuUw-ApCLRBsrKW-Oz7Qk4=.644ea3d7-6a35-4dcd-bf7e-52ece7590f95@github.com>
 <-w3Tt44-Q_pH4h55nebjYR2aU2uldsHPvN5eC2YUd8A=.8dcb1918-80f3-40ef-83c8-49c75d191ca6@github.com>
 <cWS1VWemZN9z01-RC77F99v-GWg1rGd83OMYxSqQOFE=.0fe5ffb8-406b-491c-bde1-fb10e378d0fe@github.com>
 <LIGvMDYJtJe8VL-DWblKtt2cEg27fkuLVq87WA2qBvI=.14cbf728-596d-4ee2-9e46-f73363598336@github.com>
 <4QjIXeDX05m0gHFt-sTe7clN57p7PBsTp7Z13g5Cdq4=.de46bb97-2a22-447b-a3a7-2aac342ff7a5@github.com>
 <Lo8e1Mrji7teolBaOC90qlICKy-MVbdpBU5RamNa56c=.04c2ddc1-6135-4549-9be9-a59caaf84bfe@github.com>
Message-ID: <PJjTJq-s7xffC1OdFTFAXvYP31YWdXTeFlH3EKvscV0=.89d20833-e7a8-496a-85cf-5697d39a27c2@github.com>

On Thu, 11 Jan 2024 12:23:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi Daniel -
>> I am missing see how being a ClassLoader relates to the leak where the Introspector holds on to a reference to the most recent MBean.  I didn't locate the jdk5 change, I only read a short synopsis.
>> 
>> I can make this test create an MBean which is a ClassLoader, and the test can do its check that having the loader MBean load a class, creates a distinct class.  I can add that update here.  But it looks like an MLet test which leaked into the Introspector test. 8-)
>
> Hi Kevin,
> 
> To verify whether the Introspector holds a reference to a *Class Object* you need that class to be loaded by a custom class loader, and verify that the custom class loader that loaded that class can be garbage collected.
> 
> If the class loader that loaded that class has not been garbage collected after you released all references to it, then it's because the class it loaded is still referenced somewhere.
> 
> The logic of the test is as follows:
> You create an MBean L which is a class loader and able to load class C. L must be the defining class loader for C.
> You register L in the MBeanServer.
> You ask the MBeanServer to create an MBean of class C through L (this is why you must use the variant of createMBean that takes a loader name).
> You keep a weak ref to L
> You unregister L and the MBean of class C from the MBeanServer and make sure the test doesn't have any strong reference to them (or to class C).
> Then you start GC and wait until the weak ref to L is enqueued. If that doesn't happen, it's because the Introspector still hold a reference to class C.
> 
> You cannot test that if C has been loaded by the system class loader.

I am updating those two tests.
I read the test as checking that an Object instance is collected, rather than Class Object, so was favouring making it simpler.
But we can use an MBean which is a URLClassLoader, and things will be more similar to the originals.

Some of MXBeanLoadingTest1 is duplicating some of ClassLeakTest, so something for future auditing perhaps...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1449391121

From kevinw at openjdk.org  Thu Jan 11 21:06:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Jan 2024 21:06:29 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v3]
In-Reply-To: <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <CWdczKbWaeezQzjFChOE22AVY1gTgkPihseZcMJ97uQ=.0a0f2d9a-c078-4475-9790-99f6088d0ff2@github.com>
 <mZTaH7ULJbETNhnXUoHMIz3I8fZlknjmYRuJJgO545U=.ff547793-ee1c-482a-9e72-1aaa1e5d0935@github.com>
Message-ID: <oF04jian4Rx1FKNIUBq2q5ybWbl5_HcjGv4dy134K_U=.69ca8040-28d2-47eb-a488-ea681f33605f@github.com>

On Wed, 10 Jan 2024 14:02:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary MLET_ Properties
>
> test/jdk/javax/management/mxbean/MXBeanLoadingTest1.java line 85:
> 
>> 83:             MBeanServer mbs = MBeanServerFactory.createMBeanServer();
>> 84:             ObjectName testName = new ObjectName("x:type=test");
>> 85:             ObjectInstance mb = mbs.createMBean(Test.class.getName(), testName);
> 
> Same remark here - I think we need to first register an MBean which is a ClassLoader and implements PrivateClassLoader to replace the MLet in this test.

Updated!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16363#discussion_r1449391712

From amenkov at openjdk.org  Thu Jan 11 21:15:34 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 11 Jan 2024 21:15:34 GMT
Subject: [jdk22] Integrated: 8322237: Heap dump contains duplicate thread
 records for mounted virtual threads
In-Reply-To: <qtUJ-g5jaw565DK1xyO12H6rqw7HtMhOWePQy7D07UM=.243a0dc3-34a0-4168-813e-e8dc840ba979@github.com>
References: <qtUJ-g5jaw565DK1xyO12H6rqw7HtMhOWePQy7D07UM=.243a0dc3-34a0-4168-813e-e8dc840ba979@github.com>
Message-ID: <C_LFy6CZHLSNQnvJfAeNxSpJQMrMm71_vxzHqdL-Uok=.2dcf9d47-bed0-4856-a322-81fb30db65f2@github.com>

On Thu, 11 Jan 2024 00:59:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [dd8ae616](https://github.com/openjdk/jdk/commit/dd8ae616437398f957f9b4f09cf2c7f1d0bd0938) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Alex Menkov on 9 Jan 2024 and was reviewed by David Holmes and Serguei Spitsyn.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 3984a00e
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/3984a00ea91c2ea77072b5c48adfc9c89689b016
Stats:     35 lines in 2 files changed: 33 ins; 0 del; 2 mod

8322237: Heap dump contains duplicate thread records for mounted virtual threads

Reviewed-by: sspitsyn
Backport-of: dd8ae616437398f957f9b4f09cf2c7f1d0bd0938

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

PR: https://git.openjdk.org/jdk22/pull/60

From cjplummer at openjdk.org  Thu Jan 11 22:11:00 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 11 Jan 2024 22:11:00 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v3]
In-Reply-To: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
Message-ID: <9yth9ex-7IfxdsK765_y37phw_DTVTKTLFVPhkuwV0s=.aec358eb-0059-4c87-8ff7-7088c06df86d@github.com>

> The jcmd docs for Compiler.perfmap currently say:
> 
>     - *filename*: (Optional) The name of the map file (STRING, no default value)
> 
> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
> 
> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
> 
> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
> 
>     *arguments*:
> 
>     - *flag name*: The name of the flag that you want to set (STRING, no
>         default value)
> 
>     - *string value*: (Optional) The value that you want to set (STRING, no
>         default value)

Chris Plummer 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 three additional commits since the last revision:

 - Merge branch 'master' into 8323546_jcmd_doc
   merge
 - update jcmd help output to include default filename
 - minor improvements related to Compiler.perfmap filename argument

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17359/files
  - new: https://git.openjdk.org/jdk/pull/17359/files/b6819c77..16f23147

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

  Stats: 3946 lines in 88 files changed: 2665 ins; 801 del; 480 mod
  Patch: https://git.openjdk.org/jdk/pull/17359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17359/head:pull/17359

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

From cjplummer at openjdk.org  Thu Jan 11 23:38:20 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 11 Jan 2024 23:38:20 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v3]
In-Reply-To: <9yth9ex-7IfxdsK765_y37phw_DTVTKTLFVPhkuwV0s=.aec358eb-0059-4c87-8ff7-7088c06df86d@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <9yth9ex-7IfxdsK765_y37phw_DTVTKTLFVPhkuwV0s=.aec358eb-0059-4c87-8ff7-7088c06df86d@github.com>
Message-ID: <bq1WCyVGrngo-rUB0TpYEv-w3dV8URsYwpcq94s81wo=.ca68e56d-0c5b-4f91-97c9-ddb4965110e3@github.com>

On Thu, 11 Jan 2024 22:11:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The jcmd docs for Compiler.perfmap currently say:
>> 
>>     - *filename*: (Optional) The name of the map file (STRING, no default value)
>> 
>> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
>> 
>> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
>> 
>> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
>> 
>>     *arguments*:
>> 
>>     - *flag name*: The name of the flag that you want to set (STRING, no
>>         default value)
>> 
>>     - *string value*: (Optional) The value that you want to set (STRING, no
>>         default value)
>
> Chris Plummer 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8323546_jcmd_doc
>    merge
>  - update jcmd help output to include default filename
>  - minor improvements related to Compiler.perfmap filename argument

Ignore my last push to update the jcmd help output. It doesn't work because it actually sets the default to the specified value, so in the case of `Compiler.perfmap`, it writes to the file `/tmp/perf-<pid>.map` where `<pid>` is literal and not expanded to the actual pid.

I don't think it is going to be possible to get the help output to display the default value since the default value varies based on the pid, and in the case of VM.cds, also depends on the `subcmd` argument.

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

PR Comment: https://git.openjdk.org/jdk/pull/17359#issuecomment-1888135435

From sspitsyn at openjdk.org  Fri Jan 12 00:54:59 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Jan 2024 00:54:59 GMT
Subject: [jdk22] RFR: 8321685: Missing ResourceMark in code called from
 JvmtiEnvBase::get_vthread_jvf
Message-ID: <VeegSGFyOXk3KAgBCXos1MNvohm3C5pBAPO6xsGyGqQ=.42e66221-3020-4656-a123-93e9c2155353@github.com>

Hi all,

    This pull request contains a clean backport of commit [2806adee](https://github.com/openjdk/jdk/commit/2806adee2d8cca6bc215f285888631799bd02eac) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

    The commit being backported was authored by Serguei Spitsyn on 10 Jan 2024 and was reviewed by Alex Menkov and Chris Plummer.

    Thanks!

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

Commit messages:
 - Backport 2806adee2d8cca6bc215f285888631799bd02eac

Changes: https://git.openjdk.org/jdk22/pull/64/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=64&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321685
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk22/pull/64.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/64/head:pull/64

PR: https://git.openjdk.org/jdk22/pull/64

From cjplummer at openjdk.org  Fri Jan 12 02:07:47 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 12 Jan 2024 02:07:47 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
Message-ID: <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>

> The jcmd docs for Compiler.perfmap currently say:
> 
>     - *filename*: (Optional) The name of the map file (STRING, no default value)
> 
> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
> 
> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
> 
> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
> 
>     *arguments*:
> 
>     - *flag name*: The name of the flag that you want to set (STRING, no
>         default value)
> 
>     - *string value*: (Optional) The value that you want to set (STRING, no
>         default value)

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  fix default filename issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17359/files
  - new: https://git.openjdk.org/jdk/pull/17359/files/16f23147..ba64b6f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17359&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17359&range=02-03

  Stats: 16 lines in 1 file changed: 12 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17359/head:pull/17359

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

From cjplummer at openjdk.org  Fri Jan 12 02:10:21 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 12 Jan 2024 02:10:21 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v3]
In-Reply-To: <9yth9ex-7IfxdsK765_y37phw_DTVTKTLFVPhkuwV0s=.aec358eb-0059-4c87-8ff7-7088c06df86d@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <9yth9ex-7IfxdsK765_y37phw_DTVTKTLFVPhkuwV0s=.aec358eb-0059-4c87-8ff7-7088c06df86d@github.com>
Message-ID: <k-OURlPfEE0aM34vRlEDVeccbJZcd5Z8sZU1yQOZqOg=.450a112e-c4a2-483e-9e18-d80b961df6d3@github.com>

On Thu, 11 Jan 2024 22:11:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The jcmd docs for Compiler.perfmap currently say:
>> 
>>     - *filename*: (Optional) The name of the map file (STRING, no default value)
>> 
>> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
>> 
>> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
>> 
>> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
>> 
>>     *arguments*:
>> 
>>     - *flag name*: The name of the flag that you want to set (STRING, no
>>         default value)
>> 
>>     - *string value*: (Optional) The value that you want to set (STRING, no
>>         default value)
>
> Chris Plummer 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8323546_jcmd_doc
>    merge
>  - update jcmd help output to include default filename
>  - minor improvements related to Compiler.perfmap filename argument

I found a solution. I compare the filename to the default (the descriptive default, not the actual generated default), and if it is the same then the filename is changed to nullptr, which triggers the code that uses it to generate the default file name.

@dholmes-ora @iklam Can you please have a look?

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

PR Comment: https://git.openjdk.org/jdk/pull/17359#issuecomment-1888301313

From amenkov at openjdk.org  Fri Jan 12 02:41:18 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Jan 2024 02:41:18 GMT
Subject: [jdk22] RFR: 8321685: Missing ResourceMark in code called from
 JvmtiEnvBase::get_vthread_jvf
In-Reply-To: <VeegSGFyOXk3KAgBCXos1MNvohm3C5pBAPO6xsGyGqQ=.42e66221-3020-4656-a123-93e9c2155353@github.com>
References: <VeegSGFyOXk3KAgBCXos1MNvohm3C5pBAPO6xsGyGqQ=.42e66221-3020-4656-a123-93e9c2155353@github.com>
Message-ID: <_bJ4O96kz_0gwSbLUYy83QETN6S7XxZo26A11-BlPIE=.57aa9185-637b-46ea-951a-585a1a3b21fd@github.com>

On Fri, 12 Jan 2024 00:47:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit [2806adee](https://github.com/openjdk/jdk/commit/2806adee2d8cca6bc215f285888631799bd02eac) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Serguei Spitsyn on 10 Jan 2024 and was reviewed by Alex Menkov and Chris Plummer.
> 
> Thanks!

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/64#pullrequestreview-1817273736

From duke at openjdk.org  Fri Jan 12 03:37:27 2024
From: duke at openjdk.org (sendaoYan)
Date: Fri, 12 Jan 2024 03:37:27 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
Message-ID: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>

Reviewed-by: Yi Yang

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

Commit messages:
 - 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

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

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

From clanger at openjdk.org  Fri Jan 12 08:41:21 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 12 Jan 2024 08:41:21 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v2]
In-Reply-To: <vCNR3BxIbHKYvMjgThBa-GWaJnHBnCArvQltQ3BvI30=.481491ff-d62f-4646-a45b-f6cfc82ce159@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
 <vCNR3BxIbHKYvMjgThBa-GWaJnHBnCArvQltQ3BvI30=.481491ff-d62f-4646-a45b-f6cfc82ce159@github.com>
Message-ID: <3bZccfWjyLcQYQeasyI1gaBWCuscijV1nmvC0NLgTts=.11ac9f48-d1e3-4f62-a79b-d5c2b2c93e8e@github.com>

On Thu, 11 Jan 2024 16:14:39 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

@MBaesken, I believe with this idea/PR, #16561 could be closed, right?

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

PR Comment: https://git.openjdk.org/jdk/pull/17374#issuecomment-1888660725

From mbaesken at openjdk.org  Fri Jan 12 08:56:33 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 12 Jan 2024 08:56:33 GMT
Subject: Withdrawn: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures
 on AIX if prefixLen of mask is larger than 32 in IPv6 case
In-Reply-To: <c1NBH6_L-_Crc1vchfeaW0xAiGYsMkZXRvkpHUL1ef8=.95ddb69a-152b-4a15-8a44-aeea7ddee642@github.com>
References: <c1NBH6_L-_Crc1vchfeaW0xAiGYsMkZXRvkpHUL1ef8=.95ddb69a-152b-4a15-8a44-aeea7ddee642@github.com>
Message-ID: <TGkDIAmvjgMl6BiUQzGPWx1PbMD8lqQbGOqQrcIwCLU=.169698d6-ce75-4c19-a4bc-3302845b60ea@github.com>

On Wed, 8 Nov 2023 14:37:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In parseAllowedMask (file socketTransport.c) , prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise). This fails on AIX if it is larger than 32, because getaddrinfo seems to often (always ?) detect IPv4 family, even for IPv6 addresses, so we take the wrong maxValue.
> Probably we have to adjust the allowed maxValue on AIX, or adjust the IPv6 check.
> 
> Example:
> images/jdk/bin/java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:0,allow=0:0:0:0:0:0:10:0/106
> Error in allow option: '106'
> ERROR: transport error 103: invalid netmask in allow option
> ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)

This pull request has been closed without being integrated.

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

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

From mbaesken at openjdk.org  Fri Jan 12 08:58:18 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 12 Jan 2024 08:58:18 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v2]
In-Reply-To: <3bZccfWjyLcQYQeasyI1gaBWCuscijV1nmvC0NLgTts=.11ac9f48-d1e3-4f62-a79b-d5c2b2c93e8e@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
 <vCNR3BxIbHKYvMjgThBa-GWaJnHBnCArvQltQ3BvI30=.481491ff-d62f-4646-a45b-f6cfc82ce159@github.com>
 <3bZccfWjyLcQYQeasyI1gaBWCuscijV1nmvC0NLgTts=.11ac9f48-d1e3-4f62-a79b-d5c2b2c93e8e@github.com>
Message-ID: <LUNloDe_guKR7o492mZAwmbPMjyb02HP_sTLd2UYag4=.d899b4a4-ed56-40c8-b8a3-eb1abe423777@github.com>

On Fri, 12 Jan 2024 08:38:48 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> @MBaesken, I believe with this idea/PR, #16561 could be closed, right?

Yes  we want to use inet_pton ; the other one was just a temporary thing (when I think about it , I could have closed this for quite some time ) .

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

PR Comment: https://git.openjdk.org/jdk/pull/17374#issuecomment-1888685686

From sspitsyn at openjdk.org  Fri Jan 12 10:17:19 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Jan 2024 10:17:19 GMT
Subject: [jdk22] RFR: 8321685: Missing ResourceMark in code called from
 JvmtiEnvBase::get_vthread_jvf
In-Reply-To: <VeegSGFyOXk3KAgBCXos1MNvohm3C5pBAPO6xsGyGqQ=.42e66221-3020-4656-a123-93e9c2155353@github.com>
References: <VeegSGFyOXk3KAgBCXos1MNvohm3C5pBAPO6xsGyGqQ=.42e66221-3020-4656-a123-93e9c2155353@github.com>
Message-ID: <cO9VOgC8WvhtgOL_C-CLfCbD5yHbNLakhQvdSfdwyc0=.0c741689-0f7b-4081-ad42-846e74514285@github.com>

On Fri, 12 Jan 2024 00:47:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit [2806adee](https://github.com/openjdk/jdk/commit/2806adee2d8cca6bc215f285888631799bd02eac) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Serguei Spitsyn on 10 Jan 2024 and was reviewed by Alex Menkov and Chris Plummer.
> 
> Thanks!

Alex, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk22/pull/64#issuecomment-1888811987

From sspitsyn at openjdk.org  Fri Jan 12 10:20:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Jan 2024 10:20:22 GMT
Subject: [jdk22] Integrated: 8321685: Missing ResourceMark in code called from
 JvmtiEnvBase::get_vthread_jvf
In-Reply-To: <VeegSGFyOXk3KAgBCXos1MNvohm3C5pBAPO6xsGyGqQ=.42e66221-3020-4656-a123-93e9c2155353@github.com>
References: <VeegSGFyOXk3KAgBCXos1MNvohm3C5pBAPO6xsGyGqQ=.42e66221-3020-4656-a123-93e9c2155353@github.com>
Message-ID: <vez3Rz9imaFsacRQMzjS-0EKxiqxNznru95eggud8Qk=.19197792-17cf-4562-9fdd-501f16e648fc@github.com>

On Fri, 12 Jan 2024 00:47:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a clean backport of commit [2806adee](https://github.com/openjdk/jdk/commit/2806adee2d8cca6bc215f285888631799bd02eac) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Serguei Spitsyn on 10 Jan 2024 and was reviewed by Alex Menkov and Chris Plummer.
> 
> Thanks!

This pull request has now been integrated.

Changeset: d3f18d04
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/d3f18d0469d2eafbcfa527358c2817df24fde2c3
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8321685: Missing ResourceMark in code called from JvmtiEnvBase::get_vthread_jvf

Reviewed-by: amenkov
Backport-of: 2806adee2d8cca6bc215f285888631799bd02eac

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

PR: https://git.openjdk.org/jdk22/pull/64

From sspitsyn at openjdk.org  Fri Jan 12 10:30:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Jan 2024 10:30:23 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
Message-ID: <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>

On Fri, 12 Jan 2024 02:07:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The jcmd docs for Compiler.perfmap currently say:
>> 
>>     - *filename*: (Optional) The name of the map file (STRING, no default value)
>> 
>> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
>> 
>> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
>> 
>> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
>> 
>>     *arguments*:
>> 
>>     - *flag name*: The name of the flag that you want to set (STRING, no
>>         default value)
>> 
>>     - *string value*: (Optional) The value that you want to set (STRING, no
>>         default value)
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix default filename issue

src/hotspot/share/services/diagnosticCommand.cpp line 866:

> 864:   const char* filename = _filename.value();
> 865:   if (strncmp(filename, DEFAULT_PERFMAP_FILENAME, strlen(DEFAULT_PERFMAP_FILENAME)) == 0) {
> 866:       filename = nullptr; // use the default filename based on the pid

Nit: the indent has to be 2, not 4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17359#discussion_r1450203634

From jkern at openjdk.org  Fri Jan 12 11:28:32 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 12 Jan 2024 11:28:32 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v3]
In-Reply-To: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
Message-ID: <5tlqtm3ruUcH8OcrMMbUKBil6873u0uLchtaB-31Ocg=.6ef3aafe-1025-4fa5-8079-e27f51bbe9f1@github.com>

> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  following proposals of alexmenkov

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17374/files
  - new: https://git.openjdk.org/jdk/pull/17374/files/a5bfdd1a..0266dc12

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

  Stats: 11 lines in 1 file changed: 1 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/17374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17374/head:pull/17374

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

From jkern at openjdk.org  Fri Jan 12 11:28:34 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 12 Jan 2024 11:28:34 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v2]
In-Reply-To: <vCNR3BxIbHKYvMjgThBa-GWaJnHBnCArvQltQ3BvI30=.481491ff-d62f-4646-a45b-f6cfc82ce159@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
 <vCNR3BxIbHKYvMjgThBa-GWaJnHBnCArvQltQ3BvI30=.481491ff-d62f-4646-a45b-f6cfc82ce159@github.com>
Message-ID: <DtADSrAGMjG_-zKuS_2awEhwZkN8ErUI7v0dpucdU2U=.b1174f45-a715-41b2-b5d8-6b76bfd60821@github.com>

On Thu, 11 Jan 2024 16:14:39 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

I tried to implement all of Alex proposals.

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

PR Comment: https://git.openjdk.org/jdk/pull/17374#issuecomment-1888922000

From duke at openjdk.org  Fri Jan 12 11:29:43 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 12 Jan 2024 11:29:43 GMT
Subject: RFR: 8240908: RetransformClass does not know about
 MethodParameters attribute [v3]
In-Reply-To: <dMH8fURNEJSUnn5ZmVG8_6YjPVFz0K8uBBISXomQuKI=.8f86026b-770c-489b-8b56-28791643ebaf@github.com>
References: <vnZLq5xcMIEqCPeYZZDVu6mMdfUoIKh0y7UFnfdmagg=.32596479-d407-450a-95a5-88ae0bb12d13@github.com>
 <xSsY8JXChJeaZ0NRjJuaiX1_v-WZBXDXkZ62DL6_7m0=.fb6521db-09d0-4411-8bb9-8023b3de9c69@github.com>
 <dMH8fURNEJSUnn5ZmVG8_6YjPVFz0K8uBBISXomQuKI=.8f86026b-770c-489b-8b56-28791643ebaf@github.com>
Message-ID: <pkphPgvijEtis_d52YcyCJ-2G-EW3KUs79tEdso1p0o=.e78d9f4d-3f55-4f9b-8d20-a965bf91cc2f@github.com>

On Wed, 26 Jan 2022 16:38:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplified the test, added comments
>
> Simplified the test (a lot of code was useful during development/debugging, but now don't have much value).

@alexmenkov We noticed that the patch applies cleanly to JDK 17, but hasn't been backported yet. Our Java fuzzer [Jazzer](https://github.com/CodeIntelligenceTesting/jazzer) relies on class retransformation and, without this patch, is often unable to fuzz Spring applications. 

Would it be possible to backport this patch? If there is anything we can do to help let us know (we don't have contributor access).

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

PR Comment: https://git.openjdk.org/jdk/pull/7180#issuecomment-1888923698

From dfuchs at openjdk.org  Fri Jan 12 13:47:24 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 12 Jan 2024 13:47:24 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v4]
In-Reply-To: <MTxYN1H-yYAS30YtR_QD7TdWAMIniVBAO5zWlZsr6so=.fd202cec-2734-4ba6-bfe8-9f78e9da2e4f@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <MTxYN1H-yYAS30YtR_QD7TdWAMIniVBAO5zWlZsr6so=.fd202cec-2734-4ba6-bfe8-9f78e9da2e4f@github.com>
Message-ID: <WUf6_V4zrjG6EXlJFuaf80a2D_ZLhoD7vg2vZiUr1O0=.94ed694f-a8a3-40db-90f5-753495d1da5d@github.com>

On Thu, 11 Jan 2024 20:59:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update using URLClassLoader MBeans, more like original tests

That looks better. I would have kept the LoaderMBean and the TestMBean separate  - as using the same class for both makes the test harder to understand (it's not obvious that there are two separate copies of the TestMBean class, one loaded by the System ClassLoader, one loaded by the TestMBean itself when acting as a loader), but otherwise looks good.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16363#pullrequestreview-1818296233

From duke at openjdk.org  Fri Jan 12 14:38:47 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Fri, 12 Jan 2024 14:38:47 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation
Message-ID: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>

follow up 8234502.

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

Commit messages:
 - fix header ordering

Changes: https://git.openjdk.org/jdk/pull/17398/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17398&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323660
  Stats: 33 lines in 4 files changed: 15 ins; 18 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17398.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17398/head:pull/17398

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

From ayang at openjdk.org  Fri Jan 12 14:48:19 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 12 Jan 2024 14:48:19 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation
In-Reply-To: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
Message-ID: <k_zHC8ogzBYe1Y17Fxah80h8ucWjGS0Qv7U-z0JsaP0=.3a67e5c4-2ab6-44db-87c2-80719961379f@github.com>

On Fri, 12 Jan 2024 14:31:54 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> follow up 8234502.

Some indentations of arg list are broken, e.g. `SerialHeap::collect_generation`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17398#issuecomment-1889401934

From duke at openjdk.org  Fri Jan 12 15:15:41 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Fri, 12 Jan 2024 15:15:41 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation [v2]
In-Reply-To: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
Message-ID: <08NGH82Pd_FyTqI9e_C1WNiv7MaJ-283j4fO8nlPoo0=.8fcf848e-dd93-4f65-9615-9433a98bf548@github.com>

> follow up 8234502.

Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:

  fix indent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17398/files
  - new: https://git.openjdk.org/jdk/pull/17398/files/6d423eee..5c9a5e96

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

  Stats: 37 lines in 1 file changed: 0 ins; 3 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/17398.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17398/head:pull/17398

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

From ayang at openjdk.org  Fri Jan 12 15:22:24 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 12 Jan 2024 15:22:24 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation [v2]
In-Reply-To: <08NGH82Pd_FyTqI9e_C1WNiv7MaJ-283j4fO8nlPoo0=.8fcf848e-dd93-4f65-9615-9433a98bf548@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
 <08NGH82Pd_FyTqI9e_C1WNiv7MaJ-283j4fO8nlPoo0=.8fcf848e-dd93-4f65-9615-9433a98bf548@github.com>
Message-ID: <DfXa8tsZCLR8WtwD0bkK68nNl7_4WZxpQwgYffCu34Y=.7b09d602-e3f4-4d84-b43e-31d095fe6a4f@github.com>

On Fri, 12 Jan 2024 15:15:41 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8234502.
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indent

src/hotspot/share/gc/serial/serialHeap.cpp line 81:

> 79: #include "utilities/formatBuffer.hpp"
> 80: #include "utilities/macros.hpp"
> 81: #include "services/memoryManager.hpp"

This order seems wrong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17398#discussion_r1450593010

From duke at openjdk.org  Fri Jan 12 15:26:34 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Fri, 12 Jan 2024 15:26:34 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation [v3]
In-Reply-To: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
Message-ID: <t5AFnzelHtihLgqEh3TOW_8TOkbehDAmD3ySbQReLPM=.3ceabfce-eaf6-414c-b650-ff8f6f84eda1@github.com>

> follow up 8234502.

Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:

  fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17398/files
  - new: https://git.openjdk.org/jdk/pull/17398/files/5c9a5e96..ed54e312

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

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

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

From ayang at openjdk.org  Fri Jan 12 15:30:21 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 12 Jan 2024 15:30:21 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation [v3]
In-Reply-To: <t5AFnzelHtihLgqEh3TOW_8TOkbehDAmD3ySbQReLPM=.3ceabfce-eaf6-414c-b650-ff8f6f84eda1@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
 <t5AFnzelHtihLgqEh3TOW_8TOkbehDAmD3ySbQReLPM=.3ceabfce-eaf6-414c-b650-ff8f6f84eda1@github.com>
Message-ID: <k5_PkG4PQWKGFO__19XcixJqJwq9BJIn1w1uOnHqUkc=.4a02335c-61ed-48b9-a0c5-806cff52c78e@github.com>

On Fri, 12 Jan 2024 15:26:34 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8234502.
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17398#pullrequestreview-1818513721

From duke at openjdk.org  Fri Jan 12 15:35:20 2024
From: duke at openjdk.org (sendaoYan)
Date: Fri, 12 Jan 2024 15:35:20 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
References: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
Message-ID: <170e6zHFDiV7S-wjywSB0jTAIwb-OnyTAgtWWwQft4I=.cfb79650-9127-45d3-ab22-89cacf9dec1b@github.com>

On Fri, 12 Jan 2024 03:31:37 GMT, sendaoYan <duke at openjdk.org> wrote:

> Reviewed-by: Yi Yang

The test case before this PR has a maximum heap of 64MB and applies for 8M of memory each time in the for loop. When applying for memory for the sixth time, it was killed by the docker container because of OOM, jdk.internal.platform.Metrics.systemMetrics().getMemoryFailCount( ) interface has no chance to return 1, and the Java process returns exit code 137. The maximum heap is also 64M, The PR is changed to 1KB each time to ensure that the getMemoryFailCount() interface has a chance to return 1 and the test case has a chance to exit the for loop of memory allocation.

## test result before this PR:

![image](https://github.com/openjdk/jdk/assets/24123821/4554dd00-6da5-4529-907a-45e2df5c902b)


## test result after this PR:

![image](https://github.com/openjdk/jdk/assets/24123821/32ea4fc8-aa04-425e-8481-a920265d2b1f)

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

PR Comment: https://git.openjdk.org/jdk/pull/17386#issuecomment-1889517014

From amenkov at openjdk.org  Fri Jan 12 20:44:33 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Jan 2024 20:44:33 GMT
Subject: Integrated: JDK-8318563: GetClassFields should not use random access
 to field
In-Reply-To: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
References: <AjiiAEVp5Vlqa6O4lIQy0AhNjicCufU4XTURIsWzJYE=.1f9be908-da59-43cc-83fb-da48a8b90921@github.com>
Message-ID: <vkuNUYv0Rfu4gC75KxzHceE34Lx_99R7neJJJlAn7xc=.5156576d-847b-4029-95f4-ec346ad77209@github.com>

On Wed, 13 Dec 2023 21:32:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> FieldStream/FilteredFieldStream classes from reflectionUtils.hpp iterate class fields in the reverse order and use field indexes to access instead of forward iteration. This is performance ineffective (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> The change introduces new class FilteredJavaFieldStream as a replacement for FilteredFieldStream.
> It uses the same FilteredField/FilteredFieldsMap stuff as FilteredJavaFieldStream does.
> 
> FieldStream/FilteredFieldStream are still used by heap walking API, will be cleaned by [JDK-8317636](https://bugs.openjdk.org/browse/JDK-8317636)
> 
> Testing:
> - tier1..3
> - all tests which calls GetClassFields: open/test/hotspot/jtreg/serviceability/jvmti,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap,open/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic
> including
>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java - tests that GetClassFields returns fields in correct order;
>   - test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/FilteredFieldsTest.java - test that GetClassFields filters out field like reflection.

This pull request has now been integrated.

Changeset: 84cf4cb3
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84cf4cb350331aac147fdf4c6d130cdf5448c987
Stats:     52 lines in 2 files changed: 35 ins; 8 del; 9 mod

8318563: GetClassFields should not use random access to field

Reviewed-by: sspitsyn, cjplummer, fparain

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

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

From cjplummer at openjdk.org  Fri Jan 12 20:52:19 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 12 Jan 2024 20:52:19 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation [v3]
In-Reply-To: <t5AFnzelHtihLgqEh3TOW_8TOkbehDAmD3ySbQReLPM=.3ceabfce-eaf6-414c-b650-ff8f6f84eda1@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
 <t5AFnzelHtihLgqEh3TOW_8TOkbehDAmD3ySbQReLPM=.3ceabfce-eaf6-414c-b650-ff8f6f84eda1@github.com>
Message-ID: <Hx6LFGODgOn4XMUpC6rEqWDwzBugCS5_BOqbldBORXE=.4c92bd39-96e9-42b5-80b3-0592822c41a1@github.com>

On Fri, 12 Jan 2024 15:26:34 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8234502.
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

SA change looks good. But...

It looks like all the copyright updates to 2024 are missing from this PR and the previous PR. We may need another PR for that. Also, the two new files in that PR should have a copyright that just says 2024, since that is the year it was added. Instead they say "Copyright (c) 2000, 2023"

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17398#pullrequestreview-1819022919

From amenkov at openjdk.org  Fri Jan 12 21:25:21 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Jan 2024 21:25:21 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v3]
In-Reply-To: <5tlqtm3ruUcH8OcrMMbUKBil6873u0uLchtaB-31Ocg=.6ef3aafe-1025-4fa5-8079-e27f51bbe9f1@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
 <5tlqtm3ruUcH8OcrMMbUKBil6873u0uLchtaB-31Ocg=.6ef3aafe-1025-4fa5-8079-e27f51bbe9f1@github.com>
Message-ID: <x1LqYK6-C8uJZELAPsq8_qYZajbernrmDpTleBeZVMQ=.a5fe5fab-eef8-4ab8-8905-09be961c659a@github.com>

On Fri, 12 Jan 2024 11:28:32 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   following proposals of alexmenkov

src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c line 400:

> 398: /*
> 399:  * Input is in_addr just because all clients have it.
> 400:  */

The comment does not make sense anymore: in_addr represents IPv4 address, in6_addr represents IPv6 address.
Could you remove it please.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17374#discussion_r1450935959

From never at openjdk.org  Fri Jan 12 21:35:24 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 12 Jan 2024 21:35:24 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
Message-ID: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>

The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.

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

Commit messages:
 - Add missing files
 - 8318682: SA decoding of scalar replaced objects is broken

Changes: https://git.openjdk.org/jdk/pull/17407/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17407&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318682
  Stats: 416 lines in 13 files changed: 400 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17407/head:pull/17407

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

From kvn at openjdk.org  Fri Jan 12 21:50:18 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 12 Jan 2024 21:50:18 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
In-Reply-To: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
Message-ID: <8TIOHMQ-dorvfEM37DclRT-I8uhp3Ec2-JWr1d-2kwg=.6f227ece-ddb4-4652-ab3e-2b7912ead46b@github.com>

On Fri, 12 Jan 2024 21:26:36 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.

Thank you, Tom, for updating SA for new EA code.

test/hotspot/jtreg/serviceability/sa/ClhsdbTestAllocationMerge.java line 36:

> 34:  * @requires vm.hasSA
> 35:  * @library /test/lib
> 36:  * @run main/othervm -XX:CompileThresholdScaling=0.01 -XX:CompileCommand=compileonly,compiler.c2.HeapDumper::testIt -XX:CompileCommand=exclude,compiler.c2.HeapDumper::dummy ClhsdbTestAllocationMerge

`LingeredAppWithAllocationMerge` instead of `compiler.c2.HeapDumper`

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

PR Review: https://git.openjdk.org/jdk/pull/17407#pullrequestreview-1819108372
PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1450953352

From duke at openjdk.org  Sat Jan 13 02:00:23 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 13 Jan 2024 02:00:23 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation [v3]
In-Reply-To: <Hx6LFGODgOn4XMUpC6rEqWDwzBugCS5_BOqbldBORXE=.4c92bd39-96e9-42b5-80b3-0592822c41a1@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
 <t5AFnzelHtihLgqEh3TOW_8TOkbehDAmD3ySbQReLPM=.3ceabfce-eaf6-414c-b650-ff8f6f84eda1@github.com>
 <Hx6LFGODgOn4XMUpC6rEqWDwzBugCS5_BOqbldBORXE=.4c92bd39-96e9-42b5-80b3-0592822c41a1@github.com>
Message-ID: <pGARNr-y0LGd-tMipAt6kQq0gMqzNJUWvyrK5Odo1Zc=.3cf1136d-6fe0-4bfa-9614-5c9f58515d92@github.com>

On Fri, 12 Jan 2024 20:49:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> SA change looks good. But...
> 
> It looks like all the copyright updates to 2024 are missing from this PR and the previous PR. We may need another PR for that. Also, the two new files in that PR should have a copyright that just says 2024, since that is the year it was added. Instead they say "Copyright (c) 2000, 2023"

reported.
https://bugs.openjdk.org/browse/JDK-8323693

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

PR Comment: https://git.openjdk.org/jdk/pull/17398#issuecomment-1890248270

From duke at openjdk.org  Sat Jan 13 02:26:20 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 13 Jan 2024 02:26:20 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation [v3]
In-Reply-To: <t5AFnzelHtihLgqEh3TOW_8TOkbehDAmD3ySbQReLPM=.3ceabfce-eaf6-414c-b650-ff8f6f84eda1@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
 <t5AFnzelHtihLgqEh3TOW_8TOkbehDAmD3ySbQReLPM=.3ceabfce-eaf6-414c-b650-ff8f6f84eda1@github.com>
Message-ID: <WnvTL_AJn-W54OO5LcotTfNFQngIwWO12bxLfbPdjhw=.f200cb2c-fbaa-44e3-9df7-5ac9d98186d1@github.com>

On Fri, 12 Jan 2024 15:26:34 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8234502.
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17398#issuecomment-1890259324

From duke at openjdk.org  Sat Jan 13 02:27:28 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 13 Jan 2024 02:27:28 GMT
Subject: RFR: 8323693: Update some copyright announcements in the new files
 created in 8234502
Message-ID: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>

see 'https://github.com/openjdk/jdk/pull/17398#pullrequestreview-1819022919'

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

Commit messages:
 - update copyright

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

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

From kbarrett at openjdk.org  Sat Jan 13 20:14:21 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 13 Jan 2024 20:14:21 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation [v3]
In-Reply-To: <t5AFnzelHtihLgqEh3TOW_8TOkbehDAmD3ySbQReLPM=.3ceabfce-eaf6-414c-b650-ff8f6f84eda1@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
 <t5AFnzelHtihLgqEh3TOW_8TOkbehDAmD3ySbQReLPM=.3ceabfce-eaf6-414c-b650-ff8f6f84eda1@github.com>
Message-ID: <mp9V95dlI4_nwIwjrrk9MgX2Bc-ImlSDxLnc5syEHBk=.3c796e33-62c9-4fc1-8e77-509820f654b5@github.com>

On Fri, 12 Jan 2024 15:26:34 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8234502.
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/serial/serialHeap.cpp line 105:

> 103:   _eden_pool(nullptr),
> 104:   _survivor_pool(nullptr),
> 105:   _old_pool(nullptr) {

Don't make this change to the indentation of the mem-initializer-list.  The existing indentation is one of
several styles used in GC code, including throughtout Z.  The proposed new indentation is one which is
also probably still used in older code.  But some time ago there was discussion amongst the Oracle GC
team about constructor formatting and which of several we might prefer.  We didn't reach a consensus
at the time, but this one was unanimously, and strongly, disliked.  The problem is that with the indentation
of the mem-initializer-list being the same as the body, and the opening brace of the body cuddled with
the end of the mem-initializer-list, it is hard to spot where the mem-initializer-list ends and the body
begins.

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

PR Review: https://git.openjdk.org/jdk/pull/17398#pullrequestreview-1820092218
PR Review Comment: https://git.openjdk.org/jdk/pull/17398#discussion_r1451597990

From dholmes at openjdk.org  Sun Jan 14 01:08:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 14 Jan 2024 01:08:19 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
Message-ID: <bAZ8jwfDCNK9QZ7I8UdWYqM7U4GvwU7f4twoE7o9cDQ=.ee80d3b7-25dc-4d05-b198-64b294c8a719@github.com>

On Fri, 12 Jan 2024 02:07:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The jcmd docs for Compiler.perfmap currently say:
>> 
>>     - *filename*: (Optional) The name of the map file (STRING, no default value)
>> 
>> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
>> 
>> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
>> 
>> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
>> 
>>     *arguments*:
>> 
>>     - *flag name*: The name of the flag that you want to set (STRING, no
>>         default value)
>> 
>>     - *string value*: (Optional) The value that you want to set (STRING, no
>>         default value)
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix default filename issue

I must not understand how the help text is generated because I did not expect to see the changes to the functional code.

And I still think the VM.CDS change show have its own issue (if not PR).

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

PR Review: https://git.openjdk.org/jdk/pull/17359#pullrequestreview-1820127497

From dholmes at openjdk.org  Sun Jan 14 01:08:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 14 Jan 2024 01:08:21 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>
Message-ID: <9nlCrUZzKV2L3akqXRS0WCLj1mFLsKgdCz5-YfGmi5E=.0383f14f-4877-4f7c-bf8f-5bae36ef29b0@github.com>

On Fri, 12 Jan 2024 10:27:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix default filename issue
>
> src/hotspot/share/services/diagnosticCommand.cpp line 866:
> 
>> 864:   const char* filename = _filename.value();
>> 865:   if (strncmp(filename, DEFAULT_PERFMAP_FILENAME, strlen(DEFAULT_PERFMAP_FILENAME)) == 0) {
>> 866:       filename = nullptr; // use the default filename based on the pid
> 
> Nit: the indent has to be 2, not 4.

I only expected to see a change to the help string, I don't understand why the actual Dcmd is being modified here! ???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17359#discussion_r1451634237

From cjplummer at openjdk.org  Sun Jan 14 01:31:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sun, 14 Jan 2024 01:31:22 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <bAZ8jwfDCNK9QZ7I8UdWYqM7U4GvwU7f4twoE7o9cDQ=.ee80d3b7-25dc-4d05-b198-64b294c8a719@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <bAZ8jwfDCNK9QZ7I8UdWYqM7U4GvwU7f4twoE7o9cDQ=.ee80d3b7-25dc-4d05-b198-64b294c8a719@github.com>
Message-ID: <GaLHamcaKfHnGUqcrIsNsG0szdZ8BoJoFJwNNpsttlc=.e3f1ed1f-40f0-4e00-acd6-72829be538c1@github.com>

On Sun, 14 Jan 2024 01:05:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> And I still think the VM.CDS change show have its own issue (if not PR).

Yes, and I asked why that is the case. The VM.cds changes are very much related to the Compiler.perfmap changes. I think it's actually correct to do them together, not just easier.

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

PR Comment: https://git.openjdk.org/jdk/pull/17359#issuecomment-1890815806

From cjplummer at openjdk.org  Sun Jan 14 01:31:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sun, 14 Jan 2024 01:31:23 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <9nlCrUZzKV2L3akqXRS0WCLj1mFLsKgdCz5-YfGmi5E=.0383f14f-4877-4f7c-bf8f-5bae36ef29b0@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>
 <9nlCrUZzKV2L3akqXRS0WCLj1mFLsKgdCz5-YfGmi5E=.0383f14f-4877-4f7c-bf8f-5bae36ef29b0@github.com>
Message-ID: <7Y1E0tYvXgiIJBFdLW6cb_Nge8--x93yDTFITQb_oMY=.837c158d-4bbb-4800-a329-72eb791dc493@github.com>

On Sun, 14 Jan 2024 01:03:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/services/diagnosticCommand.cpp line 866:
>> 
>>> 864:   const char* filename = _filename.value();
>>> 865:   if (strncmp(filename, DEFAULT_PERFMAP_FILENAME, strlen(DEFAULT_PERFMAP_FILENAME)) == 0) {
>>> 866:       filename = nullptr; // use the default filename based on the pid
>> 
>> Nit: the indent has to be 2, not 4.
>
> I only expected to see a change to the help string, I don't understand why the actual Dcmd is being modified here! ???

The default value for the argument is what gets displayed in the help text. For example:


ThreadDumpToFileDCmd::ThreadDumpToFileDCmd(outputStream* output, bool heap) :
                                           DCmdWithParser(output, heap),
  _overwrite("-overwrite", "May overwrite existing file", "BOOLEAN", false, "false"),
  _format("-format", "Output format ("plain" or "json")", "STRING", false, "plain"),
  _filepath("filepath", "The file path to the output file", "STRING", true) {
  _dcmdparser.add_dcmd_option(&_overwrite);
  _dcmdparser.add_dcmd_option(&_format);
  _dcmdparser.add_dcmd_argument(&_filepath);
}


And the help text:


Options: (options must be specified using the <key> or <key>=<value> syntax)
	-overwrite : [optional] May overwrite existing file (BOOLEAN, false)
	-format : [optional] Output format ("plain" or "json") (STRING, plain)


The help output that indicates that "plain" is the default format comes from the intialization of the _format argument. There is no separate help text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17359#discussion_r1451636226

From duke at openjdk.org  Sun Jan 14 01:33:45 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sun, 14 Jan 2024 01:33:45 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation [v4]
In-Reply-To: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
Message-ID: <cU7RzTnPWoXkgA9bdoGqHWAi2HTThRUZgXm7XqA28sM=.60b9733e-0b11-4c76-9d10-1ee3692a79c9@github.com>

> follow up 8234502.

Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:

  fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17398/files
  - new: https://git.openjdk.org/jdk/pull/17398/files/ed54e312..c0e47a0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17398&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17398&range=02-03

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

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

From cjplummer at openjdk.org  Sun Jan 14 02:56:18 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sun, 14 Jan 2024 02:56:18 GMT
Subject: RFR: 8323693: Update some copyright announcements in the new files
 created in 8234502
In-Reply-To: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>
References: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>
Message-ID: <IFJnutew69J10SXUl3kNZA1CwPOFc80GZWmQl08RfGs=.ac53d83e-5053-445a-a1f7-64090423756f@github.com>

On Sat, 13 Jan 2024 02:21:37 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> see 'https://github.com/openjdk/jdk/pull/17398#pullrequestreview-1819022919'

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17412#pullrequestreview-1820135652

From kbarrett at openjdk.org  Sun Jan 14 05:29:20 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 14 Jan 2024 05:29:20 GMT
Subject: RFR: 8323660: Serial: Fix header ordering and indentation [v4]
In-Reply-To: <cU7RzTnPWoXkgA9bdoGqHWAi2HTThRUZgXm7XqA28sM=.60b9733e-0b11-4c76-9d10-1ee3692a79c9@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
 <cU7RzTnPWoXkgA9bdoGqHWAi2HTThRUZgXm7XqA28sM=.60b9733e-0b11-4c76-9d10-1ee3692a79c9@github.com>
Message-ID: <6hidV72D81lrtytHBtWJMBqEFgNU33mYwb47JlZ-YbE=.816390b3-7b79-475c-819f-5d42b5f98119@github.com>

On Sun, 14 Jan 2024 01:33:45 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8234502.
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Marked as reviewed by kbarrett (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17398#pullrequestreview-1820153819

From duke at openjdk.org  Sun Jan 14 07:00:21 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sun, 14 Jan 2024 07:00:21 GMT
Subject: RFR: 8323693: Update some copyright announcements in the new files
 created in 8234502
In-Reply-To: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>
References: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>
Message-ID: <HbqIbYiK00u4HWHKut3-jVQZJ80UPW50EpdIfppttlg=.ff41bcd8-8b5c-4baa-bb23-e561c06e961a@github.com>

On Sat, 13 Jan 2024 02:21:37 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> see 'https://github.com/openjdk/jdk/pull/17398#pullrequestreview-1819022919'

This patch seems trivial. I wonder if it needs two reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/17412#issuecomment-1890866200

From dholmes at openjdk.org  Mon Jan 15 01:34:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Jan 2024 01:34:22 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <GaLHamcaKfHnGUqcrIsNsG0szdZ8BoJoFJwNNpsttlc=.e3f1ed1f-40f0-4e00-acd6-72829be538c1@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <bAZ8jwfDCNK9QZ7I8UdWYqM7U4GvwU7f4twoE7o9cDQ=.ee80d3b7-25dc-4d05-b198-64b294c8a719@github.com>
 <GaLHamcaKfHnGUqcrIsNsG0szdZ8BoJoFJwNNpsttlc=.e3f1ed1f-40f0-4e00-acd6-72829be538c1@github.com>
Message-ID: <pJu_aAK8sKJDXIXLIzHW49jPLGBCGZyRY5m4yoD7Lzo=.e7a334e0-feeb-4a2d-a278-495f5f1a4f6f@github.com>

On Sun, 14 Jan 2024 01:28:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > And I still think the VM.CDS change show have its own issue (if not PR).
> 
> Yes, and I asked why that is the case. The VM.cds changes are very much related to the Compiler.perfmap changes. I think it's actually correct to do them together, not just easier.

And I gave an answer. At a minimum if you insist of doing these two distinct updates together then the JBS issue needs a new title and description.

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

PR Comment: https://git.openjdk.org/jdk/pull/17359#issuecomment-1891166004

From dholmes at openjdk.org  Mon Jan 15 01:34:23 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Jan 2024 01:34:23 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <7Y1E0tYvXgiIJBFdLW6cb_Nge8--x93yDTFITQb_oMY=.837c158d-4bbb-4800-a329-72eb791dc493@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>
 <9nlCrUZzKV2L3akqXRS0WCLj1mFLsKgdCz5-YfGmi5E=.0383f14f-4877-4f7c-bf8f-5bae36ef29b0@github.com>
 <7Y1E0tYvXgiIJBFdLW6cb_Nge8--x93yDTFITQb_oMY=.837c158d-4bbb-4800-a329-72eb791dc493@github.com>
Message-ID: <XQc1IjkPhsh39K8SBv2_F0zmn4hoCbp97isYb4tqHWI=.700029ff-8fed-405b-b76f-e1beed087681@github.com>

On Sun, 14 Jan 2024 01:26:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I only expected to see a change to the help string, I don't understand why the actual Dcmd is being modified here! ???
>
> The default value for the argument is what gets displayed in the help text. For example:
> 
> 
> ThreadDumpToFileDCmd::ThreadDumpToFileDCmd(outputStream* output, bool heap) :
>                                            DCmdWithParser(output, heap),
>   _overwrite("-overwrite", "May overwrite existing file", "BOOLEAN", false, "false"),
>   _format("-format", "Output format ("plain" or "json")", "STRING", false, "plain"),
>   _filepath("filepath", "The file path to the output file", "STRING", true) {
>   _dcmdparser.add_dcmd_option(&_overwrite);
>   _dcmdparser.add_dcmd_option(&_format);
>   _dcmdparser.add_dcmd_argument(&_filepath);
> }
> 
> 
> And the help text:
> 
> 
> Options: (options must be specified using the <key> or <key>=<value> syntax)
> 	-overwrite : [optional] May overwrite existing file (BOOLEAN, false)
> 	-format : [optional] Output format ("plain" or "json") (STRING, plain)
> 
> 
> The help output that indicates that "plain" is the default format comes from the intialization of the _format argument. There is no separate help text.

Ugghh! So the help text is an actual stringification of the actual default value of the "field", whereas in this case the real default value comes from passing null to `CodeCache::write_perf_map`. So we need this hack to deal with that. That is truly awful IMO. The only way to cleanly address that is to expand things so that you can set an actual help string to be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17359#discussion_r1451850960

From dholmes at openjdk.org  Mon Jan 15 02:09:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Jan 2024 02:09:21 GMT
Subject: RFR: 8323693: Update some copyright announcements in the new files
 created in 8234502
In-Reply-To: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>
References: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>
Message-ID: <U_MtjtyiA97LhsHAJfzIhCyiyG8IdBT35dS-n1jb5bA=.284a59d7-695f-4686-91fb-d78ab222800e@github.com>

On Sat, 13 Jan 2024 02:21:37 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> see 'https://github.com/openjdk/jdk/pull/17398#pullrequestreview-1819022919'

Yes this could be considered trivial, but Reviewed anyway.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17412#pullrequestreview-1820494931

From iklam at openjdk.org  Mon Jan 15 04:31:21 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 15 Jan 2024 04:31:21 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <XQc1IjkPhsh39K8SBv2_F0zmn4hoCbp97isYb4tqHWI=.700029ff-8fed-405b-b76f-e1beed087681@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>
 <9nlCrUZzKV2L3akqXRS0WCLj1mFLsKgdCz5-YfGmi5E=.0383f14f-4877-4f7c-bf8f-5bae36ef29b0@github.com>
 <7Y1E0tYvXgiIJBFdLW6cb_Nge8--x93yDTFITQb_oMY=.837c158d-4bbb-4800-a329-72eb791dc493@github.com>
 <XQc1IjkPhsh39K8SBv2_F0zmn4hoCbp97isYb4tqHWI=.700029ff-8fed-405b-b76f-e1beed087681@github.com>
Message-ID: <AOJRWMkriQ5lF-DFTyvov3hAtUNc3C02jL5wrKPLJsI=.7a3126cc-d9e8-4a76-b148-4ed71e308ce1@github.com>

On Mon, 15 Jan 2024 01:29:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The default value for the argument is what gets displayed in the help text. For example:
>> 
>> 
>> ThreadDumpToFileDCmd::ThreadDumpToFileDCmd(outputStream* output, bool heap) :
>>                                            DCmdWithParser(output, heap),
>>   _overwrite("-overwrite", "May overwrite existing file", "BOOLEAN", false, "false"),
>>   _format("-format", "Output format ("plain" or "json")", "STRING", false, "plain"),
>>   _filepath("filepath", "The file path to the output file", "STRING", true) {
>>   _dcmdparser.add_dcmd_option(&_overwrite);
>>   _dcmdparser.add_dcmd_option(&_format);
>>   _dcmdparser.add_dcmd_argument(&_filepath);
>> }
>> 
>> 
>> And the help text:
>> 
>> 
>> Options: (options must be specified using the <key> or <key>=<value> syntax)
>> 	-overwrite : [optional] May overwrite existing file (BOOLEAN, false)
>> 	-format : [optional] Output format ("plain" or "json") (STRING, plain)
>> 
>> 
>> The help output that indicates that "plain" is the default format comes from the intialization of the _format argument. There is no separate help text.
>
> Ugghh! So the help text is an actual stringification of the actual default value of the "field", whereas in this case the real default value comes from passing null to `CodeCache::write_perf_map`. So we need this hack to deal with that. That is truly awful IMO. The only way to cleanly address that is to expand things so that you can set an actual help string to be used.

This check is problematic:


if (strncmp(filename, DEFAULT_PERFMAP_FILENAME, strlen(DEFAULT_PERFMAP_FILENAME)) == 0)


Because it cannot tell whether `filename` was explicitly given by the user. As a result, if the user specifies:


jcmd 1234 perfmap '/tmp/perf-<pid>.map'


the file will be written as `/tmp/perf-1234.map`, but if the user specifies


jcmd 1234 perfmap '/tmp/<pid>-perf.map'


then the file will be written as  `/tmp/<pid>-perf.map`.

This gives the confusing impression that the string `<pid>` is sometimes substituted and sometimes not.

I think it's better to do this (similarly for the `VM.cds` case):


void PerfMapDCmd::execute(DCmdSource source, TRAPS) {
  CodeCache::write_perf_map(_filename.is_set() ? _filename.value() : nullptr);
}


This essentially makes the JVM behavior exactly the same as before, so I think we can change the JBS issue title to something like "Clarify docs for filename parameter to Compiler.perfmap and VM.cds".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17359#discussion_r1451918737

From never at openjdk.org  Mon Jan 15 04:32:13 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 15 Jan 2024 04:32:13 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v2]
In-Reply-To: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
Message-ID: <N6JFnrN3pdNwglWRlAxD5g-YRoMGqgGLvAVEOrhgtgQ=.fd231e0d-35c2-46f0-8ce4-9ad258ad4852@github.com>

> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.

Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:

  Fix problem list and correct jtreg arguments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17407/files
  - new: https://git.openjdk.org/jdk/pull/17407/files/c0618b46..278377fd

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

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17407/head:pull/17407

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

From duke at openjdk.org  Mon Jan 15 05:06:18 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Mon, 15 Jan 2024 05:06:18 GMT
Subject: RFR: 8323693: Update some copyright announcements in the new files
 created in 8234502
In-Reply-To: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>
References: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>
Message-ID: <4CHz4gTyf8uM5dokgRsdrN3IFgMpZ3xsIy9Wb8MijGg=.c43f25cc-0e29-40dd-b24c-aaff7bde9169@github.com>

On Sat, 13 Jan 2024 02:21:37 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> see 'https://github.com/openjdk/jdk/pull/17398#pullrequestreview-1819022919'

thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17412#issuecomment-1891307949

From never at openjdk.org  Mon Jan 15 05:10:20 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 15 Jan 2024 05:10:20 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v2]
In-Reply-To: <8TIOHMQ-dorvfEM37DclRT-I8uhp3Ec2-JWr1d-2kwg=.6f227ece-ddb4-4652-ab3e-2b7912ead46b@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <8TIOHMQ-dorvfEM37DclRT-I8uhp3Ec2-JWr1d-2kwg=.6f227ece-ddb4-4652-ab3e-2b7912ead46b@github.com>
Message-ID: <oL3t_VI1HoTuv31ZnJIe0vtkEuo0X64kZzUTkoXM6qI=.fa58021d-a753-4610-bfe8-5d664e7c95f5@github.com>

On Fri, 12 Jan 2024 21:46:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix problem list and correct jtreg arguments
>
> test/hotspot/jtreg/serviceability/sa/ClhsdbTestAllocationMerge.java line 36:
> 
>> 34:  * @requires vm.hasSA
>> 35:  * @library /test/lib
>> 36:  * @run main/othervm -XX:CompileThresholdScaling=0.01 -XX:CompileCommand=compileonly,compiler.c2.HeapDumper::testIt -XX:CompileCommand=exclude,compiler.c2.HeapDumper::dummy ClhsdbTestAllocationMerge
> 
> `LingeredAppWithAllocationMerge` instead of `compiler.c2.HeapDumper`

Those options are actually in the wrong place since they actually need to be passed to the lingered app but it also seems like they are wrong.  I'd confirmed that the the test as written actually failed without the SA changes but when I added these arguments to the launch of the lingered app it no longer failed.  So since it properly detects the problem without any arguments I'm just going to drop them from the @run directive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1451932539

From never at openjdk.org  Mon Jan 15 05:37:02 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 15 Jan 2024 05:37:02 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v3]
In-Reply-To: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
Message-ID: <DbFwlgobR1HGHNstJKr6JyVHjD5GO3wEZiSuMre11so=.65a5034f-5da2-4197-a58e-8a0e35105fd6@github.com>

> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.

Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:

  Pass the proper options to the lingered app

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17407/files
  - new: https://git.openjdk.org/jdk/pull/17407/files/278377fd..49477222

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

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

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

From aturbanov at openjdk.org  Mon Jan 15 07:31:22 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Jan 2024 07:31:22 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v3]
In-Reply-To: <DbFwlgobR1HGHNstJKr6JyVHjD5GO3wEZiSuMre11so=.65a5034f-5da2-4197-a58e-8a0e35105fd6@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <DbFwlgobR1HGHNstJKr6JyVHjD5GO3wEZiSuMre11so=.65a5034f-5da2-4197-a58e-8a0e35105fd6@github.com>
Message-ID: <0mvleMixbsjHNgyumtnIx7-PDgb_H_9p3yASQZytWzg=.d1d67564-9b4f-4750-adf4-da5bdca83b9c@github.com>

On Mon, 15 Jan 2024 05:37:02 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass the proper options to the lingered app

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 1662:

> 1660:                             }
> 1661:                             if (blob instanceof NMethod) {
> 1662:                                 NMethod nm = (NMethod)  blob;

Suggestion:

                                NMethod nm = (NMethod) blob;

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java line 286:

> 284:     for (Address p = scopesPCsBegin(); p.lessThan(scopesPCsEnd()); p = p.addOffsetTo(pcDescSize)) {
> 285:       PCDesc pd = new PCDesc(p);
> 286:       if (pd.getPCOffset()  == -1) {

Suggestion:

      if (pd.getPCOffset() == -1) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1452005032
PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1452004835

From dholmes at openjdk.org  Mon Jan 15 07:35:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Jan 2024 07:35:21 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <AOJRWMkriQ5lF-DFTyvov3hAtUNc3C02jL5wrKPLJsI=.7a3126cc-d9e8-4a76-b148-4ed71e308ce1@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>
 <9nlCrUZzKV2L3akqXRS0WCLj1mFLsKgdCz5-YfGmi5E=.0383f14f-4877-4f7c-bf8f-5bae36ef29b0@github.com>
 <7Y1E0tYvXgiIJBFdLW6cb_Nge8--x93yDTFITQb_oMY=.837c158d-4bbb-4800-a329-72eb791dc493@github.com>
 <XQc1IjkPhsh39K8SBv2_F0zmn4hoCbp97isYb4tqHWI=.700029ff-8fed-405b-b76f-e1beed087681@github.com>
 <AOJRWMkriQ5lF-DFTyvov3hAtUNc3C02jL5wrKPLJsI=.7a3126cc-d9e8-4a76-b148-4ed71e308ce1@github.com>
Message-ID: <KBkogaVHVThYEVOt-FP3IMGEXuaNZUhENbHp0sNzh2E=.77878630-ffe6-40b2-bdfd-fa18b258f937@github.com>

On Mon, 15 Jan 2024 04:28:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Ugghh! So the help text is an actual stringification of the actual default value of the "field", whereas in this case the real default value comes from passing null to `CodeCache::write_perf_map`. So we need this hack to deal with that. That is truly awful IMO. The only way to cleanly address that is to expand things so that you can set an actual help string to be used.
>
> This check is problematic:
> 
> 
> if (strncmp(filename, DEFAULT_PERFMAP_FILENAME, strlen(DEFAULT_PERFMAP_FILENAME)) == 0)
> 
> 
> Because it cannot tell whether `filename` was explicitly given by the user. As a result, if the user specifies:
> 
> 
> jcmd 1234 perfmap '/tmp/perf-<pid>.map'
> 
> 
> the file will be written as `/tmp/perf-1234.map`, but if the user specifies
> 
> 
> jcmd 1234 perfmap '/tmp/<pid>-perf.map'
> 
> 
> then the file will be written as  `/tmp/<pid>-perf.map`.
> 
> This gives the confusing impression that the string `<pid>` is sometimes substituted and sometimes not.
> 
> I think it's better to do this (similarly for the `VM.cds` case):
> 
> 
> void PerfMapDCmd::execute(DCmdSource source, TRAPS) {
>   CodeCache::write_perf_map(_filename.is_set() ? _filename.value() : nullptr);
> }
> 
> 
> This essentially makes the JVM behavior exactly the same as before, so I think we can change the JBS issue title to something like "Clarify docs for filename parameter to Compiler.perfmap and VM.cds".

@iklam but IIUC that does not address the issue of updationg the help output.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17359#discussion_r1452007868

From duke at openjdk.org  Mon Jan 15 07:43:35 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Mon, 15 Jan 2024 07:43:35 GMT
Subject: Integrated: 8323693: Update some copyright announcements in the new
 files created in 8234502
In-Reply-To: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>
References: <LiH8EqpvXysT2T_vFmZuzac72t48VLbmRwozwnwvNYg=.abb366fc-9e3f-4178-90a6-3592d573fd17@github.com>
Message-ID: <NDYG26igQUfFSUyBghLQ6WbDeUihEA6chnroxP7VKwo=.14e2c068-91cf-4286-8160-1a3226925bf3@github.com>

On Sat, 13 Jan 2024 02:21:37 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> see 'https://github.com/openjdk/jdk/pull/17398#pullrequestreview-1819022919'

This pull request has now been integrated.

Changeset: 922f8e44
Author:    Lei Zaakjyu <lizbing07734 at icloud.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/922f8e44eed74b79a76a3628ebd0bca144e28091
Stats:     18 lines in 18 files changed: 0 ins; 0 del; 18 mod

8323693: Update some copyright announcements in the new files created in 8234502

Reviewed-by: cjplummer, dholmes

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

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

From iklam at openjdk.org  Mon Jan 15 08:16:20 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 15 Jan 2024 08:16:20 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <KBkogaVHVThYEVOt-FP3IMGEXuaNZUhENbHp0sNzh2E=.77878630-ffe6-40b2-bdfd-fa18b258f937@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>
 <9nlCrUZzKV2L3akqXRS0WCLj1mFLsKgdCz5-YfGmi5E=.0383f14f-4877-4f7c-bf8f-5bae36ef29b0@github.com>
 <7Y1E0tYvXgiIJBFdLW6cb_Nge8--x93yDTFITQb_oMY=.837c158d-4bbb-4800-a329-72eb791dc493@github.com>
 <XQc1IjkPhsh39K8SBv2_F0zmn4hoCbp97isYb4tqHWI=.700029ff-8fed-405b-b76f-e1beed087681@github.com>
 <AOJRWMkriQ5lF-DFTyvov3hAtUNc3C02jL5wrKPLJsI=.7a3126cc-d9e8-4a76-b148-4ed71e308ce1@github.com>
 <KBkogaVHVThYEVOt-FP3IMGEXuaNZUhENbHp0sNzh2E=.77878630-ffe6-40b2-bdfd-fa18b258f937@github.com>
Message-ID: <bVZrQun_bGHKJoKJ4F3ipwvKyrcAANN8JnSoMR7xOBU=.c4a71607-6c19-4f13-a513-0681d70ee9ef@github.com>

On Mon, 15 Jan 2024 07:32:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This check is problematic:
>> 
>> 
>> if (strncmp(filename, DEFAULT_PERFMAP_FILENAME, strlen(DEFAULT_PERFMAP_FILENAME)) == 0)
>> 
>> 
>> Because it cannot tell whether `filename` was explicitly given by the user. As a result, if the user specifies:
>> 
>> 
>> jcmd 1234 perfmap '/tmp/perf-<pid>.map'
>> 
>> 
>> the file will be written as `/tmp/perf-1234.map`, but if the user specifies
>> 
>> 
>> jcmd 1234 perfmap '/tmp/<pid>-perf.map'
>> 
>> 
>> then the file will be written as  `/tmp/<pid>-perf.map`.
>> 
>> This gives the confusing impression that the string `<pid>` is sometimes substituted and sometimes not.
>> 
>> I think it's better to do this (similarly for the `VM.cds` case):
>> 
>> 
>> void PerfMapDCmd::execute(DCmdSource source, TRAPS) {
>>   CodeCache::write_perf_map(_filename.is_set() ? _filename.value() : nullptr);
>> }
>> 
>> 
>> This essentially makes the JVM behavior exactly the same as before, so I think we can change the JBS issue title to something like "Clarify docs for filename parameter to Compiler.perfmap and VM.cds".
>
> @iklam but IIUC that does not address the issue of updationg the help output.

My suggestion is to be used in combination with this change:


_filename("filename", "Name of the map file", "STRING", false, DEFAULT_PERFMAP_FILENAME)


So the help message will be printed as: 


*filename*: (Optional) The name of the map file (STRING /tmp/perf-<pid>.map)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17359#discussion_r1452040385

From jkern at openjdk.org  Mon Jan 15 09:13:24 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 15 Jan 2024 09:13:24 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v4]
In-Reply-To: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
Message-ID: <15jP-E-7KUq-IjEKFPC91QPEpJWTxW7toYssu090YX4=.561b5b11-baf7-4361-9668-a7766135c695@github.com>

> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  cosmetic changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17374/files
  - new: https://git.openjdk.org/jdk/pull/17374/files/0266dc12..f31e1d98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17374&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17374&range=02-03

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

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

From jkern at openjdk.org  Mon Jan 15 09:13:27 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 15 Jan 2024 09:13:27 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v3]
In-Reply-To: <x1LqYK6-C8uJZELAPsq8_qYZajbernrmDpTleBeZVMQ=.a5fe5fab-eef8-4ab8-8905-09be961c659a@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
 <5tlqtm3ruUcH8OcrMMbUKBil6873u0uLchtaB-31Ocg=.6ef3aafe-1025-4fa5-8079-e27f51bbe9f1@github.com>
 <x1LqYK6-C8uJZELAPsq8_qYZajbernrmDpTleBeZVMQ=.a5fe5fab-eef8-4ab8-8905-09be961c659a@github.com>
Message-ID: <X0Zy01tIXMkGFLgL3LzMkd1llOnNdSpjWl1qKr43QQA=.66eb8217-590e-40bc-b850-e71cb3ab3952@github.com>

On Fri, 12 Jan 2024 21:22:35 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   following proposals of alexmenkov
>
> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c line 400:
> 
>> 398: /*
>> 399:  * Input is in_addr just because all clients have it.
>> 400:  */
> 
> The comment does not make sense anymore: in_addr represents IPv4 address, in6_addr represents IPv6 address.
> Could you remove it please.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17374#discussion_r1452098775

From duke at openjdk.org  Mon Jan 15 09:16:31 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Mon, 15 Jan 2024 09:16:31 GMT
Subject: Integrated: 8323660: Serial: Fix header ordering and indentation
In-Reply-To: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
References: <RWtPMOcwutIAoX6T8w6bfXl9zv7bjypH0s8ZbHFkPtw=.093fc5b0-6348-446b-9c74-09c62f8a690b@github.com>
Message-ID: <o79CmNw9oU2BOY5vC2CTGAscHFhLwOh_i0S87m-1Mmc=.4baa000e-77e3-4c03-9564-60841820b3f8@github.com>

On Fri, 12 Jan 2024 14:31:54 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> follow up 8234502.

This pull request has now been integrated.

Changeset: e66a76f5
Author:    Lei Zaakjyu <lizbing07734 at icloud.com>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e66a76f52410d8a4d6aadbd424679409650da9ae
Stats:     57 lines in 4 files changed: 15 ins; 21 del; 21 mod

8323660: Serial: Fix header ordering and indentation

Reviewed-by: ayang, cjplummer, kbarrett

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

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

From kevinw at openjdk.org  Mon Jan 15 11:12:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 15 Jan 2024 11:12:25 GMT
Subject: RFR: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature [v4]
In-Reply-To: <MTxYN1H-yYAS30YtR_QD7TdWAMIniVBAO5zWlZsr6so=.fd202cec-2734-4ba6-bfe8-9f78e9da2e4f@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
 <MTxYN1H-yYAS30YtR_QD7TdWAMIniVBAO5zWlZsr6so=.fd202cec-2734-4ba6-bfe8-9f78e9da2e4f@github.com>
Message-ID: <26_kHVq8XDJUfy6Db0Z8isGhPUg-AQ6WKQDWN-ZfXeI=.744e7c4f-608b-499d-a10e-dd9bb3c28608@github.com>

On Thu, 11 Jan 2024 20:59:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the MLet feature and its tests.
>> 
>> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
>> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update using URLClassLoader MBeans, more like original tests

Thanks Daniel and Serguei for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/16363#issuecomment-1891937743

From kevinw at openjdk.org  Mon Jan 15 11:15:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 15 Jan 2024 11:15:30 GMT
Subject: Integrated: 8318707: Remove the Java Management Extension (JMX)
 Management Applet (m-let) feature
In-Reply-To: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
References: <yFnjNE8vjxOTv4PSu3mqV031szuztUiZmuom-nyFFAM=.19bd44c0-68ab-4fec-8e1f-cd59aac892cb@github.com>
Message-ID: <Kkd898VNDA-CFmWbv6zWq_ZCSeeZvA6_-aIRWK-INHk=.dc3cf273-2322-4a29-ae26-9f119c382946@github.com>

On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the MLet feature and its tests.
> 
> Some tests use MLet classes but are not testing MLets.  These are updated, to use another test MBean or an MBean which is a URLClassLoader, e.g.
> test/jdk/javax/management/MBeanServer/PostExceptionTest.java
> test/jdk/javax/management/remote/mandatory/loading/TargetMBeanTest.java

This pull request has now been integrated.

Changeset: 8c238edd
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c238eddce67219c3ad4b8fbe61bbcef17b939ab
Stats:     3543 lines in 41 files changed: 53 ins; 3404 del; 86 mod

8318707: Remove the Java Management Extension (JMX) Management Applet (m-let) feature

Reviewed-by: sspitsyn, dfuchs

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

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

From never at openjdk.org  Mon Jan 15 16:03:03 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 15 Jan 2024 16:03:03 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v4]
In-Reply-To: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
Message-ID: <ZthG05Q5u3R6HVQvsi-ka-OX8JjSuCYqpbXk64vS51w=.cdf48cd2-b995-431a-aef5-4fb62236c458@github.com>

> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.

Tom Rodriguez has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17407/files
  - new: https://git.openjdk.org/jdk/pull/17407/files/49477222..1a4e625e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17407&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17407&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17407/head:pull/17407

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

From liach at openjdk.org  Mon Jan 15 18:00:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Jan 2024 18:00:30 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v9]
In-Reply-To: <T6XBH6CjII7HTsLbIoTK-Ly1Cm6JsWVr-nUBgNb5408=.cdb3d02d-a919-432c-928e-2db76f6f15e2@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
 <nUxCWqXBbfxXKWnOpQ9aEqXAz3GInytnmLBi_pSnsqI=.8ccaf3ed-426b-4859-82ac-66e06243c09f@github.com>
 <T6XBH6CjII7HTsLbIoTK-Ly1Cm6JsWVr-nUBgNb5408=.cdb3d02d-a919-432c-928e-2db76f6f15e2@github.com>
Message-ID: <T807cPhIWirNToF6XCiTbYEiWpK7Kf0R-Qf3Gokcs24=.c5bdea10-1f15-41e3-be0e-af9b4de800a5@github.com>

On Thu, 21 Sep 2023 11:46:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Classfile object update
>>  - Merge branch 'master' into invoke-test-classfile
>>  - Merge branch 'master' into invoke-test-classfile
>>  - Switch to ConstantDescs for <init> <clinit> and void constants
>>  - Merge AnnotationsTest, remove ModuleTargetAttribute call
>>  - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile
>>  - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Merge branch 'master' into invoke-test-classfile
>>  - Fix LambdaStackTrace after running
>>  - formatting
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/526dba1a...d0b6c2ae
>
> I would integrate conversions that are ready, otherwise the work spend to fix and reflect changes would double in the preview branch.

Keep alive, @asotona can you review this again as it's up-to-date against current master's Classfile API? (i.e. without the instruction renames)

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

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1892590106

From dholmes at openjdk.org  Tue Jan 16 01:50:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Jan 2024 01:50:19 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <bVZrQun_bGHKJoKJ4F3ipwvKyrcAANN8JnSoMR7xOBU=.c4a71607-6c19-4f13-a513-0681d70ee9ef@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>
 <9nlCrUZzKV2L3akqXRS0WCLj1mFLsKgdCz5-YfGmi5E=.0383f14f-4877-4f7c-bf8f-5bae36ef29b0@github.com>
 <7Y1E0tYvXgiIJBFdLW6cb_Nge8--x93yDTFITQb_oMY=.837c158d-4bbb-4800-a329-72eb791dc493@github.com>
 <XQc1IjkPhsh39K8SBv2_F0zmn4hoCbp97isYb4tqHWI=.700029ff-8fed-405b-b76f-e1beed087681@github.com>
 <AOJRWMkriQ5lF-DFTyvov3hAtUNc3C02jL5wrKPLJsI=.7a3126cc-d9e8-4a76-b148-4ed71e308ce1@github.com>
 <KBkogaVHVThYEVOt-FP3IMGEXuaNZUhENbHp0sNzh2E=.77878630-ffe6-40b2-bdfd-fa18b258f937@github.com>
 <bVZrQun_bGHKJoKJ4F3ipwvKyrcAANN8JnSoMR7xOBU=.c4a71607-6c19-4f13-a513-0681d70ee9ef@github.com>
Message-ID: <gaGR0C86h0JnLP9-PrFUtXdsFHhcvsu9YUA9mgn976E=.64f415c4-da71-454d-8d59-a35a0fcd7b5b@github.com>

On Mon, 15 Jan 2024 08:13:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> @iklam but IIUC that does not address the issue of updationg the help output.
>
> My suggestion is to be used in combination with this change:
> 
> 
> _filename("filename", "Name of the map file", "STRING", false, DEFAULT_PERFMAP_FILENAME)
> 
> 
> So the help message will be printed as: 
> 
> 
> *filename*: (Optional) The name of the map file (STRING /tmp/perf-<pid>.map)

But that only works if `init_value` is never called, else `is_set` will be true. This seems a rather fragile way to have the "default string" available for the help command, but avoiding actually using it as a default value.

That said, after having a much deeper look at how this all hangs together, it may be this will have to suffice, at least for now. Really we need a way to express that the default-string is only intended for providing the help information it is not actually intended to be parsed to "generate" the default value. But I will also note that part of the problem here is that the DCmd help needs to report the default filename, but the DCmd is not actually responsible for establishing what that default is - we have to hard-wire into the DCMd help knowledge of what the underlying API does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17359#discussion_r1452847348

From cjplummer at openjdk.org  Tue Jan 16 02:24:21 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 16 Jan 2024 02:24:21 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <gaGR0C86h0JnLP9-PrFUtXdsFHhcvsu9YUA9mgn976E=.64f415c4-da71-454d-8d59-a35a0fcd7b5b@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>
 <9nlCrUZzKV2L3akqXRS0WCLj1mFLsKgdCz5-YfGmi5E=.0383f14f-4877-4f7c-bf8f-5bae36ef29b0@github.com>
 <7Y1E0tYvXgiIJBFdLW6cb_Nge8--x93yDTFITQb_oMY=.837c158d-4bbb-4800-a329-72eb791dc493@github.com>
 <XQc1IjkPhsh39K8SBv2_F0zmn4hoCbp97isYb4tqHWI=.700029ff-8fed-405b-b76f-e1beed087681@github.com>
 <AOJRWMkriQ5lF-DFTyvov3hAtUNc3C02jL5wrKPLJsI=.7a3126cc-d9e8-4a76-b148-4ed71e308ce1@github.com>
 <KBkogaVHVThYEVOt-FP3IMGEXuaNZUhENbHp0sNzh2E=.77878630-ffe6-40b2-bdfd-fa18b258f937@github.com>
 <bVZrQun_bGHKJoKJ4F3ipwvKyrcAANN8JnSoMR7xOBU=.c4a71607-6c19-4f13-a513-0681d70ee9ef@github.com>
 <gaGR0C86h0JnLP9-PrFUtXdsFHhcvsu9YUA9mgn976E=.64f415c4-da71-454d-8d59-a35a0fcd7b5b@github.com>
Message-ID: <_EhkMUKd4CxPXdNQvGl0CuC4U4Na00DMQQ_3k0CYE8M=.544eead4-1a0f-412d-be24-e9d2b602195b@github.com>

On Tue, 16 Jan 2024 01:47:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> My suggestion is to be used in combination with this change:
>> 
>> 
>> _filename("filename", "Name of the map file", "STRING", false, DEFAULT_PERFMAP_FILENAME)
>> 
>> 
>> So the help message will be printed as: 
>> 
>> 
>> *filename*: (Optional) The name of the map file (STRING /tmp/perf-<pid>.map)
>
> But that only works if `init_value` is never called, else `is_set` will be true. This seems a rather fragile way to have the "default string" available for the help command, but avoiding actually using it as a default value.
> 
> That said, after having a much deeper look at how this all hangs together, it may be this will have to suffice, at least for now. Really we need a way to express that the default-string is only intended for providing the help information it is not actually intended to be parsed to "generate" the default value. But I will also note that part of the problem here is that the DCmd help needs to report the default filename, but the DCmd is not actually responsible for establishing what that default is - we have to hard-wire into the DCMd help knowledge of what the underlying API does.

For the dcmd help output, we could take a dynamic approach and have the dcmd call an API (which does not currently exist) which is responsible for generating the default file name. For CDS, this would have to be an upcall to java since that is where the default filename is currently generated.

...or we could just punt on this for now and continue with not actually specifying the default in the help output or the man page.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17359#discussion_r1452862140

From cjplummer at openjdk.org  Tue Jan 16 02:28:19 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 16 Jan 2024 02:28:19 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <pJu_aAK8sKJDXIXLIzHW49jPLGBCGZyRY5m4yoD7Lzo=.e7a334e0-feeb-4a2d-a278-495f5f1a4f6f@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <bAZ8jwfDCNK9QZ7I8UdWYqM7U4GvwU7f4twoE7o9cDQ=.ee80d3b7-25dc-4d05-b198-64b294c8a719@github.com>
 <GaLHamcaKfHnGUqcrIsNsG0szdZ8BoJoFJwNNpsttlc=.e3f1ed1f-40f0-4e00-acd6-72829be538c1@github.com>
 <pJu_aAK8sKJDXIXLIzHW49jPLGBCGZyRY5m4yoD7Lzo=.e7a334e0-feeb-4a2d-a278-495f5f1a4f6f@github.com>
Message-ID: <NYmu4jF2IMMC-dQFWcB_4VY5ZCvYi5ylgD4VOlUWNGQ=.fee072eb-51b2-426b-9d8a-3d88b04b078e@github.com>

On Mon, 15 Jan 2024 01:31:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > > And I still think the VM.CDS change show have its own issue (if not PR).
> > 
> > 
> > Yes, and I asked why that is the case. The VM.cds changes are very much related to the Compiler.perfmap changes. I think it's actually correct to do them together, not just easier.
> 
> And I gave an answer. At a minimum if you insist of doing these two distinct updates together then the JBS issue needs a new title and description.

Sorry I missed your response, although I still honestly don't know when/where it was. I looked throughout this PR and the CR and don't see any suggestion to update the synopsis, but certainly that is needed. I'll take care of it once we've settled the other issues in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/17359#issuecomment-1892978142

From dholmes at openjdk.org  Tue Jan 16 02:33:20 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Jan 2024 02:33:20 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <_EhkMUKd4CxPXdNQvGl0CuC4U4Na00DMQQ_3k0CYE8M=.544eead4-1a0f-412d-be24-e9d2b602195b@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <K0pEY6tsFhHNmNbOHOKUlx0R-Mi603yB2Iylj6ZZEWg=.b36dbbde-361f-4532-9f5d-db7717c8ffa9@github.com>
 <9nlCrUZzKV2L3akqXRS0WCLj1mFLsKgdCz5-YfGmi5E=.0383f14f-4877-4f7c-bf8f-5bae36ef29b0@github.com>
 <7Y1E0tYvXgiIJBFdLW6cb_Nge8--x93yDTFITQb_oMY=.837c158d-4bbb-4800-a329-72eb791dc493@github.com>
 <XQc1IjkPhsh39K8SBv2_F0zmn4hoCbp97isYb4tqHWI=.700029ff-8fed-405b-b76f-e1beed087681@github.com>
 <AOJRWMkriQ5lF-DFTyvov3hAtUNc3C02jL5wrKPLJsI=.7a3126cc-d9e8-4a76-b148-4ed71e308ce1@github.com>
 <KBkogaVHVThYEVOt-FP3IMGEXuaNZUhENbHp0sNzh2E=.77878630-ffe6-40b2-bdfd-fa18b258f937@github.com>
 <bVZrQun_bGHKJoKJ4F3ipwvKyrcAANN8JnSoMR7xOBU=.c4a71607-6c19-4f13-a513-0681d70ee9ef@github.com>
 <gaGR0C86h0JnLP9-PrFUtXdsFHhcvsu9YUA9mgn976E=.64f415c4-da71-454d-8d59-a35a0fcd7b5b@github.com>
 <_EhkMUKd4CxPXdNQvGl0CuC4U4Na00DMQQ_
 3k0CYE8M=.544eead4-1a0f-412d-be24-e9d2b602195b@github.com>
Message-ID: <lvV_v1VRl2iXb4u4FoKqZauoRvwT1bQxwtA26LvrktE=.e9d17a85-787f-43b6-93a7-52382f67ad5a@github.com>

On Tue, 16 Jan 2024 02:21:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> But that only works if `init_value` is never called, else `is_set` will be true. This seems a rather fragile way to have the "default string" available for the help command, but avoiding actually using it as a default value.
>> 
>> That said, after having a much deeper look at how this all hangs together, it may be this will have to suffice, at least for now. Really we need a way to express that the default-string is only intended for providing the help information it is not actually intended to be parsed to "generate" the default value. But I will also note that part of the problem here is that the DCmd help needs to report the default filename, but the DCmd is not actually responsible for establishing what that default is - we have to hard-wire into the DCMd help knowledge of what the underlying API does.
>
> For the dcmd help output, we could take a dynamic approach and have the dcmd call an API (which does not currently exist) which is responsible for generating the default file name. For CDS, this would have to be an upcall to java since that is where the default filename is currently generated.
> 
> ...or we could just punt on this for now and continue with not actually specifying the default in the help output or the man page.

I don't think we want that for the help output - I think we want the generic form with the "<pid>" text, not the filename with the actual pid value inserted.

I do think we want the help and manpage to document the default filenames. So I think Ioi's suggestion is the best option at the moment. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17359#discussion_r1452866002

From dholmes at openjdk.org  Tue Jan 16 02:39:23 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Jan 2024 02:39:23 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v4]
In-Reply-To: <NYmu4jF2IMMC-dQFWcB_4VY5ZCvYi5ylgD4VOlUWNGQ=.fee072eb-51b2-426b-9d8a-3d88b04b078e@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <BFqD78O8kc-KT8uRASSnJN6gvPj30rR3ZBZHV2fENpg=.7d16fb8d-0eeb-4857-9864-4be23b11081f@github.com>
 <bAZ8jwfDCNK9QZ7I8UdWYqM7U4GvwU7f4twoE7o9cDQ=.ee80d3b7-25dc-4d05-b198-64b294c8a719@github.com>
 <GaLHamcaKfHnGUqcrIsNsG0szdZ8BoJoFJwNNpsttlc=.e3f1ed1f-40f0-4e00-acd6-72829be538c1@github.com>
 <pJu_aAK8sKJDXIXLIzHW49jPLGBCGZyRY5m4yoD7Lzo=.e7a334e0-feeb-4a2d-a278-495f5f1a4f6f@github.com>
 <NYmu4jF2IMMC-dQFWcB_4VY5ZCvYi5ylgD4VOlUWNGQ=.fee072eb-51b2-426b-9d8a-3d88b04b078e@github.com>
Message-ID: <uYLYnadmOsJN0I7dj5E1HizVkZUtxR0Id5ZWt4hcb8g=.a9bb7083-6073-47aa-92e8-2a32143f8e11@github.com>

On Tue, 16 Jan 2024 02:25:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Sorry I missed your response, although I still honestly don't know when/where it was. 

No I'm sorry, I can't find it either. I must have forgotten to click the right button at some point. :( My concern was that once we were changing functional code (not just the manpage) then I didn't want a functional change to the CDS DCmd code hidden in this issue doc issue.

> I looked throughout this PR and the CR and don't see any suggestion to update the synopsis, but certainly that is needed. 

No that was a new suggestion for if you decided to keep them together.

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

PR Comment: https://git.openjdk.org/jdk/pull/17359#issuecomment-1892984909

From sroy at openjdk.org  Tue Jan 16 08:33:39 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 16 Jan 2024 08:33:39 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v8]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <imLZ7Eye31wFAGKFO5FRSfMZl5QEGPxBPSKOlCcr4QE=.5b471406-c6c0-4173-8e86-4e841de9a8f3@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Fix merge conflicts
 - Spaces fix
 - Restore lines
 -  Remove trailing spaces.
 - Change return type
 - Change dll load function signature that does dlopen
 - Remove AIX macros
 - Add wrapper function to check extension before dlopen
 - merge pr/16920
 - cosmetic changes
 - ... and 14 more: https://git.openjdk.org/jdk/compare/36f4b34f...6a5ce4a2

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

Changes: https://git.openjdk.org/jdk/pull/16604/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=07
  Stats: 28 lines in 2 files changed: 27 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604

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

From sroy at openjdk.org  Tue Jan 16 08:36:49 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 16 Jan 2024 08:36:49 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v9]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <bc_wdOVEpiUqCq4hExhn7Otl3-6XZWm92RgRPqVwTC4=.e1bced71-47f2-4708-b234-f95f1c37cf85@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:

 - Update porting_aix.cpp
 - Update porting_aix.cpp
 - Update os_aix.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/6a5ce4a2..212f16be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=07-08

  Stats: 6 lines in 2 files changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604

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

From sroy at openjdk.org  Tue Jan 16 08:46:27 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 16 Jan 2024 08:46:27 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v7]
In-Reply-To: <Ie6JpROYJCGgyWRW05_EP1o4Q6SPA6MXpUctR65k6Ko=.d3a8f7ce-accc-4475-b7da-31e02aa118b7@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <QnORwi8c5OCcUV51-xB91wPbXS-rGeJPEI4BxNMsBxc=.ac951d81-1db2-4549-abe0-025b99a1de4e@github.com>
 <Ie6JpROYJCGgyWRW05_EP1o4Q6SPA6MXpUctR65k6Ko=.d3a8f7ce-accc-4475-b7da-31e02aa118b7@github.com>
Message-ID: <34N1MQU3CaBHa22aH-xp8234QcVaRlFZDZ6oeKXZpqo=.9630fc7a-623b-472b-980b-2cf3d0848fc0@github.com>

On Wed, 20 Dec 2023 13:29:05 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Spaces fix
>
> src/hotspot/os/aix/os_aix.cpp line 1168:
> 
>> 1166:   int extension_length = 3;
>> 1167:   char* file_path = NEW_C_HEAP_ARRAY(char, buffer_length + extension_length + 1, mtInternal);
>> 1168:   strncpy(file_path,filename, buffer_length + 1);
> 
> Why not using 
> `char* file_path = os::strdup (filename);`
> which would replace lines 1167+1168
> and use the corresponding 
> `os::free (file_path);`
> at the end

Ok. Any performance advantage to using that ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1453094259

From mbaesken at openjdk.org  Tue Jan 16 10:16:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 16 Jan 2024 10:16:22 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v4]
In-Reply-To: <15jP-E-7KUq-IjEKFPC91QPEpJWTxW7toYssu090YX4=.561b5b11-baf7-4361-9668-a7766135c695@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
 <15jP-E-7KUq-IjEKFPC91QPEpJWTxW7toYssu090YX4=.561b5b11-baf7-4361-9668-a7766135c695@github.com>
Message-ID: <_eHYyZDeIWsKy87sAHAYjF_7wwgE9gWET7U7R9WcuZE=.d33f66ee-8a88-4bf1-8e85-15274c305f36@github.com>

On Mon, 15 Jan 2024 09:13:24 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17374#pullrequestreview-1822980246

From jkern at openjdk.org  Tue Jan 16 10:48:32 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 16 Jan 2024 10:48:32 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v7]
In-Reply-To: <34N1MQU3CaBHa22aH-xp8234QcVaRlFZDZ6oeKXZpqo=.9630fc7a-623b-472b-980b-2cf3d0848fc0@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <QnORwi8c5OCcUV51-xB91wPbXS-rGeJPEI4BxNMsBxc=.ac951d81-1db2-4549-abe0-025b99a1de4e@github.com>
 <Ie6JpROYJCGgyWRW05_EP1o4Q6SPA6MXpUctR65k6Ko=.d3a8f7ce-accc-4475-b7da-31e02aa118b7@github.com>
 <34N1MQU3CaBHa22aH-xp8234QcVaRlFZDZ6oeKXZpqo=.9630fc7a-623b-472b-980b-2cf3d0848fc0@github.com>
Message-ID: <Vhtzy7KmQs_kd3F_5QMWmsicKoBWccwPzRKotIdy5B0=.6a1dcac3-80b3-48c6-bf73-c59ca9023856@github.com>

On Tue, 16 Jan 2024 08:43:34 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> src/hotspot/os/aix/os_aix.cpp line 1168:
>> 
>>> 1166:   int extension_length = 3;
>>> 1167:   char* file_path = NEW_C_HEAP_ARRAY(char, buffer_length + extension_length + 1, mtInternal);
>>> 1168:   strncpy(file_path,filename, buffer_length + 1);
>> 
>> Why not using 
>> `char* file_path = os::strdup (filename);`
>> which would replace lines 1167+1168
>> and use the corresponding 
>> `os::free (file_path);`
>> at the end
>
> Ok. Any performance advantage to using that ?

No, I do not believe that it has performance advantage, but I think it is simpler to understand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1453249951

From mdoerr at openjdk.org  Tue Jan 16 16:15:25 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 16 Jan 2024 16:15:25 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v7]
In-Reply-To: <hX5s13YzFiPxFoyjZwvyq-prh2xRP8r-f5Rv_ZCFTyA=.a09e4c89-e74f-4f2e-88a7-6b967ce342a3@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <QnORwi8c5OCcUV51-xB91wPbXS-rGeJPEI4BxNMsBxc=.ac951d81-1db2-4549-abe0-025b99a1de4e@github.com>
 <hX5s13YzFiPxFoyjZwvyq-prh2xRP8r-f5Rv_ZCFTyA=.a09e4c89-e74f-4f2e-88a7-6b967ce342a3@github.com>
Message-ID: <GJzTjModxYfQcXvgYlJA81odbT91iIwfkAyAGb2QvXo=.aa314f47-10a8-4573-b9d1-1a95a514a38f@github.com>

On Fri, 5 Jan 2024 12:10:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I have tried to build jextract (https://github.com/openjdk/jextract/tree/jdk22) with LLVM (https://github.com/llvm/llvm-project/releases/download/llvmorg-16.0.4/clang+llvm-16.0.4-powerpc64-ibm-aix-7.2.tar.xz). I noticed that llvm mainly consists of .a files. So, I think we need to support that for FFI compatibility with other libraries and open source projects.

Seems like this change is not sufficient for that. `clang` is compiled to `libclang.a` on AIX, but `libclang.so` on linux. I'm getting "System error: Exec format error" when trying to load `libclang.a` via `System.loadLibrary(libName);`.
So the question remains: Are .a files really supposed to be dynamically loadable on AIX? If so, where is that documented?

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1894060171

From amenkov at openjdk.org  Tue Jan 16 19:04:28 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 16 Jan 2024 19:04:28 GMT
Subject: RFR: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures on
 AIX if prefixLen of mask is larger than 32 in IPv6 case [v4]
In-Reply-To: <15jP-E-7KUq-IjEKFPC91QPEpJWTxW7toYssu090YX4=.561b5b11-baf7-4361-9668-a7766135c695@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
 <15jP-E-7KUq-IjEKFPC91QPEpJWTxW7toYssu090YX4=.561b5b11-baf7-4361-9668-a7766135c695@github.com>
Message-ID: <F2gyqAXViwyRUgp7Q8X7aeZyCEPCsozItDaT9_0gCWY=.41476464-0995-478d-a92c-fc404847eb33@github.com>

On Mon, 15 Jan 2024 09:13:24 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17374#pullrequestreview-1824662970

From cjplummer at openjdk.org  Tue Jan 16 22:58:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 16 Jan 2024 22:58:53 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v4]
In-Reply-To: <ZthG05Q5u3R6HVQvsi-ka-OX8JjSuCYqpbXk64vS51w=.cdf48cd2-b995-431a-aef5-4fb62236c458@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <ZthG05Q5u3R6HVQvsi-ka-OX8JjSuCYqpbXk64vS51w=.cdf48cd2-b995-431a-aef5-4fb62236c458@github.com>
Message-ID: <eaVbB3MegYjgPxTlh6elfqgIOSM9PqxUcl7lCHHmmkY=.798396f6-d8b6-484f-afdb-bc6b1ffb6059@github.com>

On Mon, 15 Jan 2024 16:03:03 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.
>
> Tom Rodriguez has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

I can't really review the implementation details because this requires compiler expertise I don't have. I did review the parts that were understandable without compiler knowledge and made a few suggestions.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 1644:

> 1642:             }
> 1643:         },
> 1644:         new Command("testdebuginfodecode", "testdebuginfodecode", false) {

This doesn't belong in clhsdb. You can do all of this directly in the test if you launch it properly. 
See for example `TestObjectAlignment.java`.

test/hotspot/jtreg/serviceability/sa/ClhsdbTestAllocationMerge.java line 58:

> 56:             Map<String, List<String>> expStrMap = new HashMap<>();
> 57:             Map<String, List<String>> unExpStrMap = new HashMap<>();
> 58:             test.run(theApp.getPid(), cmds, expStrMap, unExpStrMap);

You can just pass `null` for the two Map args, and no need to import java.util.HashMap or java.util.Map.

test/hotspot/jtreg/serviceability/sa/ClhsdbTestDebugInfodDecode.java line 52:

> 50:             System.out.println("Started LingeredAppWithEnum with pid " + theApp.getPid());
> 51: 
> 52:             List<String> cmds = List.of("testdebuginfodecode");

This will need to change given my suggestion to instead include the contents of clshdb command within this test.

test/hotspot/jtreg/serviceability/sa/ClhsdbTestDebugInfodDecode.java line 58:

> 56:             Map<String, List<String>> expStrMap = new HashMap<>();
> 57:             Map<String, List<String>> unExpStrMap = new HashMap<>();
> 58:             test.run(theApp.getPid(), cmds, expStrMap, unExpStrMap);

You can just pass null for the two Map args, and no need to import java.util.HashMap or java.util.Map.

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

Changes requested by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17407#pullrequestreview-1825478257
PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1454151509
PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1454163583
PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1454171208
PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1454166498

From cjplummer at openjdk.org  Tue Jan 16 23:46:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 16 Jan 2024 23:46:02 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v5]
In-Reply-To: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
Message-ID: <9VyZm9GSgnfarcob-SvqJTiW5uQ_leAVyoKZGFo6-SU=.2f1a9d03-3760-4990-925c-74b1e39cb740@github.com>

> The jcmd docs for Compiler.perfmap currently say:
> 
>     - *filename*: (Optional) The name of the map file (STRING, no default value)
> 
> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
> 
> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
> 
> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
> 
>     *arguments*:
> 
>     - *flag name*: The name of the flag that you want to set (STRING, no
>         default value)
> 
>     - *string value*: (Optional) The value that you want to set (STRING, no
>         default value)

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Fix issue with not allowing user to specify a filename that is equivalent to the default filename descripiton.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17359/files
  - new: https://git.openjdk.org/jdk/pull/17359/files/ba64b6f2..7238d2d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17359&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17359&range=03-04

  Stats: 23 lines in 2 files changed: 13 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17359/head:pull/17359

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

From jiangli at openjdk.org  Wed Jan 17 00:22:02 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 17 Jan 2024 00:22:02 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
Message-ID: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>

Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.

Contributed by Chuck Rasbold and @jianglizhou.

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

Commit messages:
 - 8311846: Resolve duplicate 'Thread' related symbols with JDK static linking

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

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

From cjplummer at openjdk.org  Wed Jan 17 02:26:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Jan 2024 02:26:22 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v6]
In-Reply-To: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
Message-ID: <B5809zKUvr7NFfUyHXMG7zw1em4P5GoLTZ8NJFtAgOw=.96257598-34cc-4d57-8158-890e8555e951@github.com>

> The jcmd docs for Compiler.perfmap currently say:
> 
>     - *filename*: (Optional) The name of the map file (STRING, no default value)
> 
> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
> 
> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
> 
> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
> 
>     *arguments*:
> 
>     - *flag name*: The name of the flag that you want to set (STRING, no
>         default value)
> 
>     - *string value*: (Optional) The value that you want to set (STRING, no
>         default value)

Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:

 - Get rid of extra empty line.
 - Remove quotes from around filename to be consistent with how jcmd STRING defaults are printed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17359/files
  - new: https://git.openjdk.org/jdk/pull/17359/files/7238d2d6..86fb2c37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17359&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17359&range=04-05

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17359/head:pull/17359

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

From cjplummer at openjdk.org  Wed Jan 17 02:27:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Jan 2024 02:27:53 GMT
Subject: RFR: 8323546: Clarify docs for Compiler.perfmap filename
 parameter, and other misc related jcmd doc cleanups [v5]
In-Reply-To: <9VyZm9GSgnfarcob-SvqJTiW5uQ_leAVyoKZGFo6-SU=.2f1a9d03-3760-4990-925c-74b1e39cb740@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <9VyZm9GSgnfarcob-SvqJTiW5uQ_leAVyoKZGFo6-SU=.2f1a9d03-3760-4990-925c-74b1e39cb740@github.com>
Message-ID: <iDiwPxeG4F5DFvoRpNTNcgxVXhQsCEOTlfF5Sx0Egjg=.9480f0f8-add4-4c1e-80a8-25395e460b33@github.com>

On Tue, 16 Jan 2024 23:46:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The jcmd docs for Compiler.perfmap currently say:
>> 
>>     - *filename*: (Optional) The name of the map file (STRING, no default value)
>> 
>> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
>> 
>> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
>> 
>> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
>> 
>>     *arguments*:
>> 
>>     - *flag name*: The name of the flag that you want to set (STRING, no
>>         default value)
>> 
>>     - *string value*: (Optional) The value that you want to set (STRING, no
>>         default value)
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue with not allowing user to specify a filename that is equivalent to the default filename descripiton.

I've updated the PR with Ioi's suggestion and also added a test cast to PerfMapTest.java to make sure if the default is specified, then it actually gets used as the filename (it failed before I added Ioi's fix). Ioi, let me know if you think a similar test for VM.cds is warranted.

i also updated the javadoc to not include quotes around the default filename. This is consistent with how other defaults are printed, and also how jcmd "help" prints the default argument.

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

PR Comment: https://git.openjdk.org/jdk/pull/17359#issuecomment-1894833574

From iklam at openjdk.org  Wed Jan 17 07:24:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Jan 2024 07:24:54 GMT
Subject: RFR: 8323546: Cleanup jcmd docs for Compiler.perfmap and VM.cds
 filename parameter [v6]
In-Reply-To: <B5809zKUvr7NFfUyHXMG7zw1em4P5GoLTZ8NJFtAgOw=.96257598-34cc-4d57-8158-890e8555e951@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <B5809zKUvr7NFfUyHXMG7zw1em4P5GoLTZ8NJFtAgOw=.96257598-34cc-4d57-8158-890e8555e951@github.com>
Message-ID: <9o0Bl1IJGiRAl65T4jtMu1c_xKdRQ0FAs4FHnz-PHaw=.1d387751-e91b-475e-a723-15212545206e@github.com>

On Wed, 17 Jan 2024 02:26:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The jcmd docs for Compiler.perfmap currently say:
>> 
>>     - *filename*: (Optional) The name of the map file (STRING, no default value)
>> 
>> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
>> 
>> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
>> 
>> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
>> 
>>     *arguments*:
>> 
>>     - *flag name*: The name of the flag that you want to set (STRING, no
>>         default value)
>> 
>>     - *string value*: (Optional) The value that you want to set (STRING, no
>>         default value)
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Get rid of extra empty line.
>  - Remove quotes from around filename to be consistent with how jcmd STRING defaults are printed.

LGTM. I think having one test case for perfmap should be enough.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17359#pullrequestreview-1826632142

From asotona at openjdk.org  Wed Jan 17 08:32:59 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Jan 2024 08:32:59 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v11]
In-Reply-To: <A323ixd32QcT5_Vjdjd0_2DkYVyCEdDQbh0mpXbqGS0=.77b21938-215d-4752-ba87-f428d75cac2c@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
 <A323ixd32QcT5_Vjdjd0_2DkYVyCEdDQbh0mpXbqGS0=.77b21938-215d-4752-ba87-f428d75cac2c@github.com>
Message-ID: <a3DCIaX_uJ7WBhTp-slq0QQiHJ44333E3ybzYtGYCtc=.6c1ca6f0-000d-427a-ad8a-c46c545fbe33@github.com>

On Sun, 17 Dec 2023 23:11:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Summaries:
>> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
>> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
>> 3. Most tests are included in tier1, but some are not:
>> In `:jdk_io`: (tier2, part 2)
>> 
>> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
>> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
>> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
>> 
>> In `:jdk_instrument`: (tier 3)
>> 
>> test/jdk/java/lang/instrument/RetransformAgent.java
>> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
>> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
>> 
>> 
>> @asotona Would you mind reviewing?
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the 2 failing tests and add notes

Yes, CodeBuilder method renames will require some refactoring.
This is good.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13009#pullrequestreview-1826743185

From jkern at openjdk.org  Wed Jan 17 09:36:54 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 17 Jan 2024 09:36:54 GMT
Subject: Integrated: JDK-8319382: com/sun/jdi/JdwpAllowTest.java shows failures
 on AIX if prefixLen of mask is larger than 32 in IPv6 case
In-Reply-To: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
References: <XMkSAPNNhZuXsxn8SxF1t_GtiaAa-b4LN4zXfEojNvg=.1b5fe552-619d-47dd-85ab-982ab7d88db3@github.com>
Message-ID: <xyuHAVJF5F39wS56_nRR9Z-rPsIfup7Q_rGjpIYGWqQ=.bdd49699-da1e-4e60-a069-004a27de74ca@github.com>

On Thu, 11 Jan 2024 15:46:59 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> In parseAllowedMask in socketTransport.c, prefixLen of mask is compared with a maxValue (32 for IPv4, 128 otherwise).  This fails if it is larger than 32, because getaddrinfo seems to detect IPv4 family, if IPv6 address has set only some of the last 32 Bits. So we take the wrong maxValue.

This pull request has now been integrated.

Changeset: 22642ff0
Author:    Joachim Kern <jkern at openjdk.org>
Committer: Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/22642ff0aac71eceb71f6a9eebb2988a9bd5f091
Stats:     37 lines in 1 file changed: 3 ins; 24 del; 10 mod

8319382: com/sun/jdi/JdwpAllowTest.java shows failures on AIX if prefixLen of mask is larger than 32 in IPv6 case

Reviewed-by: mbaesken, amenkov

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

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

From aph at openjdk.org  Wed Jan 17 10:09:50 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 17 Jan 2024 10:09:50 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
Message-ID: <W-ELetwdthl4PrCyRexhg7K0YcvOkxO0TJz6GzUpqvY=.e8cd88d9-cc65-4310-a640-a95e1d987752@github.com>

On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
> 
> Contributed by Chuck Rasbold and @jianglizhou.

Hooboy, this is an ugly solution, with some nasty side effects such as confusing error mesasges for developers and a very confusing debugger experience. Let's try to find a solution with a smaller blast radius.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1895486108

From jiangli at openjdk.org  Wed Jan 17 17:20:53 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 17 Jan 2024 17:20:53 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <W-ELetwdthl4PrCyRexhg7K0YcvOkxO0TJz6GzUpqvY=.e8cd88d9-cc65-4310-a640-a95e1d987752@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <W-ELetwdthl4PrCyRexhg7K0YcvOkxO0TJz6GzUpqvY=.e8cd88d9-cc65-4310-a640-a95e1d987752@github.com>
Message-ID: <b6vH8ngby-jJ-cRJqLGtu-c0XoOLLHcd8jGjn5BqRZA=.0dfe1ce3-76e8-4b54-9b7e-47677b943fd5@github.com>

On Wed, 17 Jan 2024 10:07:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
>> 
>> Contributed by Chuck Rasbold and @jianglizhou.
>
> Hooboy, this is an ugly solution, with some nasty side effects such as confusing error mesasges for developers and a very confusing debugger experience. Let's try to find a solution with a smaller blast radius.

Hi @theRealAph Thanks for looking into this! https://github.com/openjdk/jdk/pull/14808 comments touched on several options:

1. Using namespace, in smaller scope for specific class such as `StringTable` or for all hotspot code in a global scope.

   Most seem to prefer using a specific namespace for all hotspot code, but there were still concerns.

2. Using #define to redefine the symbol (using in the current PR)

   This is a somewhat hacky solution. It requires small changes without touching many source code for renaming. 

3. Redefine symbol at build/compile time. This is similar to the above. 

4. Direct rename in the source 

Earlier discussions and feedback seem to prefer options requiring non-large scale change (except hotspot namespace solution). If acceptable by everyone, direct renaming would be the least confusion causing option. Any other suggestions and ideas for resolving the `Thread` issue?

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1896255274

From never at openjdk.org  Wed Jan 17 17:35:39 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 17 Jan 2024 17:35:39 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v5]
In-Reply-To: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
Message-ID: <eFXgn9OTYOdRu9Qkdihacr62PFhspYODQOrNq_9hZLk=.40a8b0cf-dcc8-4758-a049-5109f4cce025@github.com>

> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.

Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:

  Remove testdebuginfodecode command

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17407/files
  - new: https://git.openjdk.org/jdk/pull/17407/files/1a4e625e..07eefccd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17407&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17407&range=03-04

  Stats: 223 lines in 3 files changed: 119 ins; 103 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17407/head:pull/17407

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

From never at openjdk.org  Wed Jan 17 17:35:42 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 17 Jan 2024 17:35:42 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v4]
In-Reply-To: <eaVbB3MegYjgPxTlh6elfqgIOSM9PqxUcl7lCHHmmkY=.798396f6-d8b6-484f-afdb-bc6b1ffb6059@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <ZthG05Q5u3R6HVQvsi-ka-OX8JjSuCYqpbXk64vS51w=.cdf48cd2-b995-431a-aef5-4fb62236c458@github.com>
 <eaVbB3MegYjgPxTlh6elfqgIOSM9PqxUcl7lCHHmmkY=.798396f6-d8b6-484f-afdb-bc6b1ffb6059@github.com>
Message-ID: <UWQ1TO5mlNHZloxo6Q6EdfrygvHmEETMQPTeQqlMS_Y=.e2f18695-00e8-4059-9077-2b26b49c44cb@github.com>

On Tue, 16 Jan 2024 22:36:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Tom Rodriguez has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 1644:
> 
>> 1642:             }
>> 1643:         },
>> 1644:         new Command("testdebuginfodecode", "testdebuginfodecode", false) {
> 
> This doesn't belong in clhsdb. You can do all of this directly in the test if you launch it properly. 
> See for example `TestObjectAlignment.java`.

Yes that's much better.  I've updated the test and renamed it.  Please rereview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1456153937

From cjplummer at openjdk.org  Wed Jan 17 19:42:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Jan 2024 19:42:53 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v5]
In-Reply-To: <eFXgn9OTYOdRu9Qkdihacr62PFhspYODQOrNq_9hZLk=.40a8b0cf-dcc8-4758-a049-5109f4cce025@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <eFXgn9OTYOdRu9Qkdihacr62PFhspYODQOrNq_9hZLk=.40a8b0cf-dcc8-4758-a049-5109f4cce025@github.com>
Message-ID: <tIX3JPOdYLedhMpo2i1cCJLbzvqtlqRd97GDtthJQXI=.b5e6e80a-b077-4e7e-b913-b38875f879a9@github.com>

On Wed, 17 Jan 2024 17:35:39 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove testdebuginfodecode command

test/hotspot/jtreg/ProblemList-generational-zgc.txt line 108:

> 106: serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java     8307393   generic-all
> 107: serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java     8307393   generic-all
> 108: serviceability/sa/ClhsdbTestAllocationMerge.java              8307393   generic-all

Do you need to add TestDebugInfoDecode.java?

test/hotspot/jtreg/serviceability/sa/TestDebugInfoDecode.java line 109:

> 107:         if (args == null || args.length == 0) {
> 108:             try {
> 109:                 theApp = new LingeredApp();

Is there a reason why previously you had used LingeredAppWithEnum and now you are using LingeredApp?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1456382492
PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1456375716

From cjplummer at openjdk.org  Wed Jan 17 19:42:57 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Jan 2024 19:42:57 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v4]
In-Reply-To: <eaVbB3MegYjgPxTlh6elfqgIOSM9PqxUcl7lCHHmmkY=.798396f6-d8b6-484f-afdb-bc6b1ffb6059@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <ZthG05Q5u3R6HVQvsi-ka-OX8JjSuCYqpbXk64vS51w=.cdf48cd2-b995-431a-aef5-4fb62236c458@github.com>
 <eaVbB3MegYjgPxTlh6elfqgIOSM9PqxUcl7lCHHmmkY=.798396f6-d8b6-484f-afdb-bc6b1ffb6059@github.com>
Message-ID: <TCHW3-HDIMt_xHop9IjZDDcjPtkP9wy9hk1drcFhN_A=.52554b5a-5df3-4206-a5c1-5212d15fa6af@github.com>

On Tue, 16 Jan 2024 22:47:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Tom Rodriguez has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/hotspot/jtreg/serviceability/sa/ClhsdbTestAllocationMerge.java line 58:
> 
>> 56:             Map<String, List<String>> expStrMap = new HashMap<>();
>> 57:             Map<String, List<String>> unExpStrMap = new HashMap<>();
>> 58:             test.run(theApp.getPid(), cmds, expStrMap, unExpStrMap);
> 
> You can just pass `null` for the two Map args, and no need to import java.util.HashMap or java.util.Map.

This still needs to be taken care of.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1456380163

From never at openjdk.org  Wed Jan 17 19:46:53 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 17 Jan 2024 19:46:53 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v5]
In-Reply-To: <tIX3JPOdYLedhMpo2i1cCJLbzvqtlqRd97GDtthJQXI=.b5e6e80a-b077-4e7e-b913-b38875f879a9@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <eFXgn9OTYOdRu9Qkdihacr62PFhspYODQOrNq_9hZLk=.40a8b0cf-dcc8-4758-a049-5109f4cce025@github.com>
 <tIX3JPOdYLedhMpo2i1cCJLbzvqtlqRd97GDtthJQXI=.b5e6e80a-b077-4e7e-b913-b38875f879a9@github.com>
Message-ID: <COz3xcqRBiXa191mi-UebD6g4NKGAWsvtvrGH_0z_EM=.d07e267f-bdc8-4ab7-b73f-9000df9d5a26@github.com>

On Wed, 17 Jan 2024 19:40:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove testdebuginfodecode command
>
> test/hotspot/jtreg/ProblemList-generational-zgc.txt line 108:
> 
>> 106: serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java     8307393   generic-all
>> 107: serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java     8307393   generic-all
>> 108: serviceability/sa/ClhsdbTestAllocationMerge.java              8307393   generic-all
> 
> Do you need to add TestDebugInfoDecode.java?

No.  ClhsdbTestAllocationMerge is using `jstack -v` which doesn't work with ZGC because the `-v` part needs to iterate the heap looking for AbstractQueuedSynchronizers which doesn't work with ZGC and the SA.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1456389516

From never at openjdk.org  Wed Jan 17 19:52:32 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 17 Jan 2024 19:52:32 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v6]
In-Reply-To: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
Message-ID: <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>

> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.

Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17407/files
  - new: https://git.openjdk.org/jdk/pull/17407/files/07eefccd..f25c92ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17407&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17407&range=04-05

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

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

From never at openjdk.org  Wed Jan 17 19:52:32 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 17 Jan 2024 19:52:32 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v5]
In-Reply-To: <eFXgn9OTYOdRu9Qkdihacr62PFhspYODQOrNq_9hZLk=.40a8b0cf-dcc8-4758-a049-5109f4cce025@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <eFXgn9OTYOdRu9Qkdihacr62PFhspYODQOrNq_9hZLk=.40a8b0cf-dcc8-4758-a049-5109f4cce025@github.com>
Message-ID: <Ctf5CMdC9h7lJFPVUG6uWpc_LIz1CHUrGpWrMsZNAQE=.8c4b246e-7191-4217-a59a-3ff975aaca63@github.com>

On Wed, 17 Jan 2024 17:35:39 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove testdebuginfodecode command

I pushed the removal of the empty maps as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/17407#issuecomment-1896561935

From never at openjdk.org  Wed Jan 17 19:52:32 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 17 Jan 2024 19:52:32 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v5]
In-Reply-To: <tIX3JPOdYLedhMpo2i1cCJLbzvqtlqRd97GDtthJQXI=.b5e6e80a-b077-4e7e-b913-b38875f879a9@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <eFXgn9OTYOdRu9Qkdihacr62PFhspYODQOrNq_9hZLk=.40a8b0cf-dcc8-4758-a049-5109f4cce025@github.com>
 <tIX3JPOdYLedhMpo2i1cCJLbzvqtlqRd97GDtthJQXI=.b5e6e80a-b077-4e7e-b913-b38875f879a9@github.com>
Message-ID: <O0gq4PHv4gn3kajOmWHPJsvi0K8rx3oa0sLdmpANa_c=.7d0ff279-74d4-4a25-b092-389fd1d14366@github.com>

On Wed, 17 Jan 2024 19:34:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove testdebuginfodecode command
>
> test/hotspot/jtreg/serviceability/sa/TestDebugInfoDecode.java line 109:
> 
>> 107:         if (args == null || args.length == 0) {
>> 108:             try {
>> 109:                 theApp = new LingeredApp();
> 
> Is there a reason why previously you had used LingeredAppWithEnum and now you are using LingeredApp?

Both were chosen as a result of copy/paste from existing tests and it honestly doesn't matter.  The Xcomp is what's producing nmethods so the actual test doesn't matter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1456392560

From cjplummer at openjdk.org  Wed Jan 17 19:55:50 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Jan 2024 19:55:50 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v5]
In-Reply-To: <COz3xcqRBiXa191mi-UebD6g4NKGAWsvtvrGH_0z_EM=.d07e267f-bdc8-4ab7-b73f-9000df9d5a26@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <eFXgn9OTYOdRu9Qkdihacr62PFhspYODQOrNq_9hZLk=.40a8b0cf-dcc8-4758-a049-5109f4cce025@github.com>
 <tIX3JPOdYLedhMpo2i1cCJLbzvqtlqRd97GDtthJQXI=.b5e6e80a-b077-4e7e-b913-b38875f879a9@github.com>
 <COz3xcqRBiXa191mi-UebD6g4NKGAWsvtvrGH_0z_EM=.d07e267f-bdc8-4ab7-b73f-9000df9d5a26@github.com>
Message-ID: <4w-z2fWkarVhJBKQR2uqImInWy5vC9w0zrSAl_oYGfg=.327fb654-8164-406d-8b46-5cec4326de6f@github.com>

On Wed, 17 Jan 2024 19:44:38 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> test/hotspot/jtreg/ProblemList-generational-zgc.txt line 108:
>> 
>>> 106: serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java     8307393   generic-all
>>> 107: serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java     8307393   generic-all
>>> 108: serviceability/sa/ClhsdbTestAllocationMerge.java              8307393   generic-all
>> 
>> Do you need to add TestDebugInfoDecode.java?
>
> No.  ClhsdbTestAllocationMerge is using `jstack -v` which doesn't work with ZGC because the `-v` part needs to iterate the heap looking for AbstractQueuedSynchronizers which doesn't work with ZGC and the SA.

It's not -v that is making it do that. It does it without -v also. It can be a very slow operation, and I recently was running into cases where even after 10 minutes it was not done, so I gave up waiting. I'm about to file a CR to make it so it does not do that by default, and add a -l argument to optionally enable it. This will make it consistent with what bin/jstack is doing. I already have the fix ready. Just need to get the CR filed and and publish the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1456400105

From never at openjdk.org  Wed Jan 17 20:05:50 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 17 Jan 2024 20:05:50 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v5]
In-Reply-To: <4w-z2fWkarVhJBKQR2uqImInWy5vC9w0zrSAl_oYGfg=.327fb654-8164-406d-8b46-5cec4326de6f@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <eFXgn9OTYOdRu9Qkdihacr62PFhspYODQOrNq_9hZLk=.40a8b0cf-dcc8-4758-a049-5109f4cce025@github.com>
 <tIX3JPOdYLedhMpo2i1cCJLbzvqtlqRd97GDtthJQXI=.b5e6e80a-b077-4e7e-b913-b38875f879a9@github.com>
 <COz3xcqRBiXa191mi-UebD6g4NKGAWsvtvrGH_0z_EM=.d07e267f-bdc8-4ab7-b73f-9000df9d5a26@github.com>
 <4w-z2fWkarVhJBKQR2uqImInWy5vC9w0zrSAl_oYGfg=.327fb654-8164-406d-8b46-5cec4326de6f@github.com>
Message-ID: <KsZiPGSnQ5Q4t0oSo40mpDFm3_WjQ7bWCW6h9lbtyJs=.3d1501f2-94d9-48de-beaa-145615a46362@github.com>

On Wed, 17 Jan 2024 19:52:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> No.  ClhsdbTestAllocationMerge is using `jstack -v` which doesn't work with ZGC because the `-v` part needs to iterate the heap looking for AbstractQueuedSynchronizers which doesn't work with ZGC and the SA.
>
> It's not -v that is making it do that. It does it without -v also. It can be a very slow operation, and I recently was running into cases where even after 10 minutes it was not done, so I gave up waiting. I'm about to file a CR to make it so it does not do that by default, and add a -l argument to optionally enable it. This will make it consistent with what bin/jstack is doing. I already have the fix ready. Just need to get the CR filed and and publish the PR.

Ok.  I was assuming that the `-v` option was like the `-l` option.  Anyway, TestDebugInfoDecode doesn't use jstack so it doesn't need the problem list entry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1456412077

From never at openjdk.org  Wed Jan 17 20:58:51 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 17 Jan 2024 20:58:51 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v6]
In-Reply-To: <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>
Message-ID: <c8W_mNTK30-RyqLhT-Fzx5GaPYVpjrOQ9QfYFO90Mg8=.b59c7f66-b0d7-47b3-8579-3a5e5bbeec35@github.com>

On Wed, 17 Jan 2024 19:52:32 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

So I can get any approvals for this?  Testing was clean and is rerunning after the refactoring.

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

PR Comment: https://git.openjdk.org/jdk/pull/17407#issuecomment-1896672894

From cjplummer at openjdk.org  Wed Jan 17 21:12:54 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Jan 2024 21:12:54 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v5]
In-Reply-To: <KsZiPGSnQ5Q4t0oSo40mpDFm3_WjQ7bWCW6h9lbtyJs=.3d1501f2-94d9-48de-beaa-145615a46362@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <eFXgn9OTYOdRu9Qkdihacr62PFhspYODQOrNq_9hZLk=.40a8b0cf-dcc8-4758-a049-5109f4cce025@github.com>
 <tIX3JPOdYLedhMpo2i1cCJLbzvqtlqRd97GDtthJQXI=.b5e6e80a-b077-4e7e-b913-b38875f879a9@github.com>
 <COz3xcqRBiXa191mi-UebD6g4NKGAWsvtvrGH_0z_EM=.d07e267f-bdc8-4ab7-b73f-9000df9d5a26@github.com>
 <4w-z2fWkarVhJBKQR2uqImInWy5vC9w0zrSAl_oYGfg=.327fb654-8164-406d-8b46-5cec4326de6f@github.com>
 <KsZiPGSnQ5Q4t0oSo40mpDFm3_WjQ7bWCW6h9lbtyJs=.3d1501f2-94d9-48de-beaa-145615a46362@github.com>
Message-ID: <VszkwArjmTV5wIRQ1o2r_3aqbVWVmVtcRfmS_uuN_SU=.9338421c-78e3-4bc8-84b8-70ad887228d6@github.com>

On Wed, 17 Jan 2024 20:02:44 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> It's not -v that is making it do that. It does it without -v also. It can be a very slow operation, and I recently was running into cases where even after 10 minutes it was not done, so I gave up waiting. I'm about to file a CR to make it so it does not do that by default, and add a -l argument to optionally enable it. This will make it consistent with what bin/jstack is doing. I already have the fix ready. Just need to get the CR filed and and publish the PR.
>
> Ok.  I was assuming that the `-v` option was like the `-l` option.  Anyway, TestDebugInfoDecode doesn't use jstack so it doesn't need the problem list entry.

I think generally speaking we problem list all SA tests with generational ZGC, but probably those that don't deal with the heap at all (which means they don't even use jstack) are ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17407#discussion_r1456488468

From cjplummer at openjdk.org  Wed Jan 17 21:12:52 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Jan 2024 21:12:52 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v6]
In-Reply-To: <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>
Message-ID: <NqxSq1Eg3Pl-4P6fyKY5fVIcZdU8CSnb5jkGBX3Pwyk=.61fc2255-8471-434d-8911-098cf42f11dc@github.com>

On Wed, 17 Jan 2024 19:52:32 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17407#pullrequestreview-1828194783

From coleenp at openjdk.org  Wed Jan 17 23:08:49 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 17 Jan 2024 23:08:49 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
Message-ID: <sYRlv44lCPMlurfmnjpIhuImePBHMFBjoS54XWe2CjM=.2b728ee2-91e2-48e7-8421-affc05e4bd86@github.com>

On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
> 
> Contributed by Chuck Rasbold and @jianglizhou.

I was reading through the other PR for StringTable and was wonder how difficult it would be to wrap all of hotspot in namespace hotspot {}; using namespace hotspot;  It would need a JEP as discussed in the other PR.

Alternatively if there's a #ifdef you can use for renaming the Thread to HotspotThread for static linking only, it might make this change less worrysome.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1897336087

From cslucas at openjdk.org  Thu Jan 18 00:28:36 2024
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 18 Jan 2024 00:28:36 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v6]
In-Reply-To: <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>
Message-ID: <17YfaEJSuTxnz3XEN42ubHPK-nN0qx93iTsAIT4Xbsk=.e328cb16-3bdd-44ec-b4d7-b093202cabc7@github.com>

On Wed, 17 Jan 2024 19:52:32 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by cslucas (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/17407#pullrequestreview-1828474714

From dcubed at openjdk.org  Thu Jan 18 01:34:17 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 01:34:17 GMT
Subject: RFR: 8324082: more monitoring test timeout adjustments
Message-ID: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>

Trivial fixes to adjust more monitoring test timeouts.

See the bug report for the gory timeout details.

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

Commit messages:
 - 8324082: more monitoring test timeout adjustments

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

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

From cjplummer at openjdk.org  Thu Jan 18 02:50:27 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Jan 2024 02:50:27 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow
Message-ID: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>

I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:


at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/StackTrace.java:71)


This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.

Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).

This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).

The same changes are also being made to "clhsdb pstack".

Tested with all tier1, tier2, and tier5 svc tests.

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

Commit messages:
 - fix jcheck errors
 - Minor cleanup
 - Don't search for l.u.c lock instances by default. Must pass -l option.

Changes: https://git.openjdk.org/jdk/pull/17479/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324066
  Stats: 226 lines in 9 files changed: 204 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/17479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17479/head:pull/17479

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

From cjplummer at openjdk.org  Thu Jan 18 05:19:13 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Jan 2024 05:19:13 GMT
Subject: RFR: 8324082: more monitoring test timeout adjustments
In-Reply-To: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
References: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
Message-ID: <5pasLmNz1pQ1KnMYzIN5Ho7D4t8Ylgu8e0Y5bJ_NOx0=.af51c5f7-2b0d-4051-82e4-e35caf7c1ff4@github.com>

On Thu, 18 Jan 2024 01:28:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to adjust more monitoring test timeouts.
> 
> See the bug report for the gory timeout details.

Shouldn't we use a larger timeoutfactor for slowdebug builds?

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

PR Comment: https://git.openjdk.org/jdk/pull/17478#issuecomment-1897815509

From dholmes at openjdk.org  Thu Jan 18 07:30:14 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Jan 2024 07:30:14 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
Message-ID: <YOfBpo9fBUGei-XrDM6DpFpjwlqkCdvvh48M_1rh4JM=.9ead2139-ab05-4320-8864-caa7d01d5939@github.com>

On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
> 
> Contributed by Chuck Rasbold and @jianglizhou.

> Linking failures were observed when statically linking the launcher executable with hotspot and user native code together: 

So the problem is that the user native code defines Thread as well - right? So this could keep happening for name after name depending on what native code is being linked. 

I second what @theRealAph said! This is really ugly. The way disparate libraries just get munged into a single namespace with static linking just seems wrong to me.

At a minimum this hack should only be used when doing static linking as Coleen suggested. But I'd much prefer a solution that came from the tools doing the linking.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1897940456

From dholmes at openjdk.org  Thu Jan 18 07:39:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 18 Jan 2024 07:39:18 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
Message-ID: <c5DeTKIkS-5v3mvsI6pXyAokgklLTq4S9RV-xW9is4s=.23e20fbe-a368-4266-8a21-9ee06cc19655@github.com>

On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
> 
> Contributed by Chuck Rasbold and @jianglizhou.

Okay so now that I have context switched in the discussion from:

https://github.com/openjdk/jdk/pull/14808

what happened to doing a JEP for namespaces?

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1897950301

From duke at openjdk.org  Thu Jan 18 08:29:12 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Thu, 18 Jan 2024 08:29:12 GMT
Subject: RFR: 8313710: jcmd: typo in the documentation of JFR.start and
 JFR.dump [v3]
In-Reply-To: <GZpDr_8S5T7KrB6fcmhVafpMTz9y_qAkermZMhLRn08=.62a7521a-47dd-4434-ad4b-9e4fc3210758@github.com>
References: <NCQ9Mq777-jfXsiBgIdgcUV-9Q2Xr0qbLNdJOgZL9kI=.7c2bd4c7-37fd-4467-8982-a5858ff52276@github.com>
 <MtUYjI3FqmC3AiiDFDi4so-x9ruW7KFA0kfa8MpbLVo=.175ce1aa-4869-4a04-8070-34caf9b96380@github.com>
 <LMK6QA3k93vjeCQmIKf0o0ad2P_VgtQnBfDhw7WN8wE=.f5dae290-5dd3-458f-ab6c-2c942037f720@github.com>
 <GZpDr_8S5T7KrB6fcmhVafpMTz9y_qAkermZMhLRn08=.62a7521a-47dd-4434-ad4b-9e4fc3210758@github.com>
Message-ID: <JIis2Bfh_ESSP8NDZnYo7cz1EZoj8zgfMuEzHP6aYNo=.3b00881d-26f0-46ab-8d1b-97b37a542f7e@github.com>

On Tue, 28 Nov 2023 07:44:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thank you for telling me about how to jcmd.1 nroff file is managed.
>> I will split this change into separate subtasks. Then if one of the Oracle engineers finds that subtask, will he/she work on it like any other bug?
>
> Yes it will be assigned and addressed. Thanks

@dholmes-ora 
Sorry for the late response again.  
I issued sub-task.  
https://bugs.openjdk.org/browse/JDK-8324089

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16413#discussion_r1457086198

From kevinw at openjdk.org  Thu Jan 18 10:00:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 18 Jan 2024 10:00:16 GMT
Subject: RFR: 8324082: more monitoring test timeout adjustments
In-Reply-To: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
References: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
Message-ID: <cNg3_8WnqgjdGg4CSL2z5bzlCYp1oB0kxfsSFLAPTZU=.4110dc13-f5ab-45fe-bae7-134f08cabd51@github.com>

On Thu, 18 Jan 2024 01:28:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to adjust more monitoring test timeouts.
> 
> See the bug report for the gory timeout details.

Looks good.  Maybe we could be cleverer with different timeout for different builds, but I like the simple update... 8-)

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17478#pullrequestreview-1829294492

From sspitsyn at openjdk.org  Thu Jan 18 11:46:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 18 Jan 2024 11:46:13 GMT
Subject: RFR: 8324082: more monitoring test timeout adjustments
In-Reply-To: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
References: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
Message-ID: <Ws7goCE0nvVYTL-2qPkgZY_dF2fGU1h8O-4_fdwEXpE=.973916d2-5ca5-4e9a-b52b-b2f27a76ca9d@github.com>

On Thu, 18 Jan 2024 01:28:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to adjust more monitoring test timeouts.
> 
> See the bug report for the gory timeout details.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17478#pullrequestreview-1829493830

From dcubed at openjdk.org  Thu Jan 18 13:11:24 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 13:11:24 GMT
Subject: RFR: 8324082: more monitoring test timeout adjustments [v2]
In-Reply-To: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
References: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
Message-ID: <IQPtcJ8t3C_V-DGtlHQ_nHVFMF0i-K34EfPHvn03RB4=.63de2196-d37b-4a09-959c-8d507adc9393@github.com>

> Trivial fixes to adjust more monitoring test timeouts.
> 
> See the bug report for the gory timeout details.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17478/files
  - new: https://git.openjdk.org/jdk/pull/17478/files/a31a5d19..db7f12f7

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

  Stats: 14 lines in 14 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/17478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17478/head:pull/17478

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

From dcubed at openjdk.org  Thu Jan 18 13:18:23 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 13:18:23 GMT
Subject: Integrated: 8324082: more monitoring test timeout adjustments
In-Reply-To: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
References: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
Message-ID: <sI8EJKmHPDR42PIc1BVsdwrC8-q0Kvk8RnpJhLT7be0=.90a8f908-a9b9-4caa-894d-639eae2911ba@github.com>

On Thu, 18 Jan 2024 01:28:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to adjust more monitoring test timeouts.
> 
> See the bug report for the gory timeout details.

This pull request has now been integrated.

Changeset: 806ffb10
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/806ffb108572236cb9908ad6f93d7b09dfc6a600
Stats:     28 lines in 14 files changed: 0 ins; 0 del; 28 mod

8324082: more monitoring test timeout adjustments

Reviewed-by: kevinw, sspitsyn

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

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

From dcubed at openjdk.org  Thu Jan 18 13:18:21 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 13:18:21 GMT
Subject: RFR: 8324082: more monitoring test timeout adjustments
In-Reply-To: <5pasLmNz1pQ1KnMYzIN5Ho7D4t8Ylgu8e0Y5bJ_NOx0=.af51c5f7-2b0d-4051-82e4-e35caf7c1ff4@github.com>
References: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
 <5pasLmNz1pQ1KnMYzIN5Ho7D4t8Ylgu8e0Y5bJ_NOx0=.af51c5f7-2b0d-4051-82e4-e35caf7c1ff4@github.com>
Message-ID: <Dwl8pQ4bOMtfs_PaaLt-pkCOT2uQd-7FhzIP45_Zn4M=.603c27f6-6291-4168-96a8-a7d150025ba8@github.com>

On Thu, 18 Jan 2024 05:16:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Trivial fixes to adjust more monitoring test timeouts.
>> 
>> See the bug report for the gory timeout details.
>
> Shouldn't we use a larger timeoutfactor for slowdebug builds?

@plummercj, @kevinjwalls and @sspitsyn  - Thanks for the reviews. Copyright years updated.

@plummercj - The collection of adjustments I have been making to the monitoring tests have
all been made with TimeoutFactor == 1. This is intentional because these tests pass with that
timeout factor when they are run by themselves on a system. It is only with extremely high
stress levels that we see these slowdebug timeouts.

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

PR Comment: https://git.openjdk.org/jdk/pull/17478#issuecomment-1898459015

From dcubed at openjdk.org  Thu Jan 18 15:32:28 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 15:32:28 GMT
Subject: [jdk22] RFR: 8324082: more monitoring test timeout adjustments
Message-ID: <ZXnMRSsYvIZq1ISXqPBL5n3gEAxMtDTYdalz1z2nrXU=.b7fc5158-8fea-42c3-80a4-0516cc993a5b@github.com>

Trivial fixes to adjust more monitoring test timeouts.

See the bug report for the gory timeout details.

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

Commit messages:
 - Backport 806ffb108572236cb9908ad6f93d7b09dfc6a600

Changes: https://git.openjdk.org/jdk22/pull/92/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=92&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324082
  Stats: 28 lines in 14 files changed: 0 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jdk22/pull/92.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/92/head:pull/92

PR: https://git.openjdk.org/jdk22/pull/92

From dchuyko at openjdk.org  Thu Jan 18 15:43:35 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 18 Jan 2024 15:43:35 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v22]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <XEyyrG01NGZdhOestVS2HDve0KRibY2s35rweEKsO-c=.447f0b34-2e50-40e2-97b1-fbac93c47611@github.com>

> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
> 
> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
> 
> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods).
> 
> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter.
> 
> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them.
> 
> In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ...

Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Deopt osr, cleanups
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - ... and 30 more: https://git.openjdk.org/jdk/compare/a2b117ae...d4bc29c9

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

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=21
  Stats: 381 lines in 15 files changed: 348 ins; 3 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/14111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111

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

From ayang at openjdk.org  Thu Jan 18 15:44:26 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 18 Jan 2024 15:44:26 GMT
Subject: [jdk22] RFR: 8324082: more monitoring test timeout adjustments
In-Reply-To: <ZXnMRSsYvIZq1ISXqPBL5n3gEAxMtDTYdalz1z2nrXU=.b7fc5158-8fea-42c3-80a4-0516cc993a5b@github.com>
References: <ZXnMRSsYvIZq1ISXqPBL5n3gEAxMtDTYdalz1z2nrXU=.b7fc5158-8fea-42c3-80a4-0516cc993a5b@github.com>
Message-ID: <FvvDnPWxM_3k96D5XBW12GItj-kCtQ16TXZ1tzDfAlA=.22a5ef30-fba9-44df-9869-32ad86e2c149@github.com>

On Thu, 18 Jan 2024 15:22:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to adjust more monitoring test timeouts.
> 
> See the bug report for the gory timeout details.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/92#pullrequestreview-1829973853

From kevinw at openjdk.org  Thu Jan 18 15:44:27 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 18 Jan 2024 15:44:27 GMT
Subject: [jdk22] RFR: 8324082: more monitoring test timeout adjustments
In-Reply-To: <ZXnMRSsYvIZq1ISXqPBL5n3gEAxMtDTYdalz1z2nrXU=.b7fc5158-8fea-42c3-80a4-0516cc993a5b@github.com>
References: <ZXnMRSsYvIZq1ISXqPBL5n3gEAxMtDTYdalz1z2nrXU=.b7fc5158-8fea-42c3-80a4-0516cc993a5b@github.com>
Message-ID: <qOcmkiU-jl8PyjWK9NPH-rAlsRh02w1bDyTrVRARvRI=.fa5e6959-a8b1-4c2d-974b-a26bb47797ef@github.com>

On Thu, 18 Jan 2024 15:22:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to adjust more monitoring test timeouts.
> 
> See the bug report for the gory timeout details.

Marked as reviewed by kevinw (Committer).

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

PR Review: https://git.openjdk.org/jdk22/pull/92#pullrequestreview-1829976633

From dcubed at openjdk.org  Thu Jan 18 15:44:28 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 15:44:28 GMT
Subject: [jdk22] RFR: 8324082: more monitoring test timeout adjustments
In-Reply-To: <FvvDnPWxM_3k96D5XBW12GItj-kCtQ16TXZ1tzDfAlA=.22a5ef30-fba9-44df-9869-32ad86e2c149@github.com>
References: <ZXnMRSsYvIZq1ISXqPBL5n3gEAxMtDTYdalz1z2nrXU=.b7fc5158-8fea-42c3-80a4-0516cc993a5b@github.com>
 <FvvDnPWxM_3k96D5XBW12GItj-kCtQ16TXZ1tzDfAlA=.22a5ef30-fba9-44df-9869-32ad86e2c149@github.com>
Message-ID: <LZGXM59gXb8J33bv_TMRf4DSXb074UwbsPCGPx5vt7o=.53aca373-00e7-4a44-bba3-86947361a2fb@github.com>

On Thu, 18 Jan 2024 15:36:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial fixes to adjust more monitoring test timeouts.
>> 
>> See the bug report for the gory timeout details.
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk and @kevinjwalls - Thanks for the fast reviews!

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

PR Comment: https://git.openjdk.org/jdk22/pull/92#issuecomment-1898719581

From dcubed at openjdk.org  Thu Jan 18 15:44:29 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 18 Jan 2024 15:44:29 GMT
Subject: [jdk22] Integrated: 8324082: more monitoring test timeout adjustments
In-Reply-To: <ZXnMRSsYvIZq1ISXqPBL5n3gEAxMtDTYdalz1z2nrXU=.b7fc5158-8fea-42c3-80a4-0516cc993a5b@github.com>
References: <ZXnMRSsYvIZq1ISXqPBL5n3gEAxMtDTYdalz1z2nrXU=.b7fc5158-8fea-42c3-80a4-0516cc993a5b@github.com>
Message-ID: <Qv5OA3p5BdldS9w5pe_iDSge-rBhggHnZJl-3yUmJqs=.5f6c8c06-7799-43ca-8430-02a9981f5777@github.com>

On Thu, 18 Jan 2024 15:22:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to adjust more monitoring test timeouts.
> 
> See the bug report for the gory timeout details.

This pull request has now been integrated.

Changeset: 79c3d47c
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/79c3d47cfe975fd7a6a66464e83f5abf6594f941
Stats:     28 lines in 14 files changed: 0 ins; 0 del; 28 mod

8324082: more monitoring test timeout adjustments

Reviewed-by: ayang, kevinw
Backport-of: 806ffb108572236cb9908ad6f93d7b09dfc6a600

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

PR: https://git.openjdk.org/jdk22/pull/92

From cjplummer at openjdk.org  Thu Jan 18 16:10:25 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Jan 2024 16:10:25 GMT
Subject: RFR: 8324082: more monitoring test timeout adjustments
In-Reply-To: <Dwl8pQ4bOMtfs_PaaLt-pkCOT2uQd-7FhzIP45_Zn4M=.603c27f6-6291-4168-96a8-a7d150025ba8@github.com>
References: <sD-qFogg8rLu7QOsANcYCi-oZ252FEMW_Er0E-ABrYE=.864facf7-3353-429a-8870-f82becd90110@github.com>
 <5pasLmNz1pQ1KnMYzIN5Ho7D4t8Ylgu8e0Y5bJ_NOx0=.af51c5f7-2b0d-4051-82e4-e35caf7c1ff4@github.com>
 <Dwl8pQ4bOMtfs_PaaLt-pkCOT2uQd-7FhzIP45_Zn4M=.603c27f6-6291-4168-96a8-a7d150025ba8@github.com>
Message-ID: <F81o1njEPBZCwtEUGt3PbwcQvfRid0nGuXrqdYjv07Y=.6d0aca70-3d8b-4199-842c-2c4bde372fa4@github.com>

On Thu, 18 Jan 2024 13:14:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> It is only with extremely high
> stress levels that we see these slowdebug timeouts.

I would have considered this as a reason to be using timeoutfactor and not increase the timeouts. Although I don't think what to use as the default timeout for any given test has ever been formalized, certainly the idea is that the test should be expected to pass with the provided timeout (default or specified) on a machine with some given performance expectations (num cores, performance of each core, machine load), and with a jdk build with some given performance expectations (product, fastdebug, slowdebug, -Xcomp, -Xint, etc). Anytime those expectations are not met, timeoutfactor should be used. Your changes imply that the timeout should be good enough for a slowdebug build on a machine with a heavy load. I'm not so sure that makes sense when we have timeoutfactor to deal with such situations. In other words, set one test parameter that will cover all your test runs instead of having to update a large number of tests to make the tests pass on your system. If that is not what timeou
 tfactor is for, then I don't see why it even exists.

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

PR Comment: https://git.openjdk.org/jdk/pull/17478#issuecomment-1898776484

From cjplummer at openjdk.org  Thu Jan 18 16:19:38 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Jan 2024 16:19:38 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v2]
In-Reply-To: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
Message-ID: <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>

> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
> 
> 
> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
> 
> 
> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
> 
> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
> 
> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
> 
> The same changes are also being made to "clhsdb pstack".
> 
> Tested with all tier1, tier2, and tier5 svc tests.

Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:

 - update clhsdb docs
 - update clhsdb docs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17479/files
  - new: https://git.openjdk.org/jdk/pull/17479/files/03f514af..814739bb

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

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

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

From jiangli at openjdk.org  Thu Jan 18 18:59:15 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 18 Jan 2024 18:59:15 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <sYRlv44lCPMlurfmnjpIhuImePBHMFBjoS54XWe2CjM=.2b728ee2-91e2-48e7-8421-affc05e4bd86@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <sYRlv44lCPMlurfmnjpIhuImePBHMFBjoS54XWe2CjM=.2b728ee2-91e2-48e7-8421-affc05e4bd86@github.com>
Message-ID: <VHCQ4G69m7832C_Jqe3Ztj7Xd1dk8sDxIxAmkIgFxvA=.0079894d-719e-4f67-b336-11bdcf79b3d7@github.com>

On Wed, 17 Jan 2024 23:06:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
>> 
>> Contributed by Chuck Rasbold and @jianglizhou.
>
> I was reading through the other PR for StringTable and was wonder how difficult it would be to wrap all of hotspot in namespace hotspot {}; using namespace hotspot;  It would need a JEP as discussed in the other PR.
> 
> Alternatively if there's a #ifdef you can use for renaming the Thread to HotspotThread for static linking only, it might make this change less worrysome.

Thanks @coleenp, @dholmes-ora. For using a hotspot namespace, there are probably similar complications like the symbol usages that the current PR addresses in src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S and src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java. There might also be some complications with accessing hotspot code in JNI code. Those issues probably could be resolved relatively easily, I haven't experimented it. It seems that we may be converging on using hotspot namespace?

For just redefining the symbol only when doing static linking, it adds more differences between the static and non-static support. It's more useful when we can create both `.so` and `.a` from the same set of `.o` files without having to build two different `.o` from each c/c++ source files.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1899039171

From dchuyko at openjdk.org  Thu Jan 18 21:39:31 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 18 Jan 2024 21:39:31 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v23]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <YlS0DyXITFedAE6DWXTl2iIbSuUVgE9h3zapeGm1C7I=.c81d9a36-fce0-40ca-96d8-54b1bc4532aa@github.com>

> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
> 
> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
> 
> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods).
> 
> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter.
> 
> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them.
> 
> In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ...

Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:

 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Deopt osr, cleanups
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - ... and 31 more: https://git.openjdk.org/jdk/compare/81df265e...b2261505

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

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=22
  Stats: 381 lines in 15 files changed: 348 ins; 3 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/14111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111

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

From cjplummer at openjdk.org  Thu Jan 18 22:59:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 18 Jan 2024 22:59:35 GMT
Subject: RFR: 8323680: SA PointerFinder code can do a better job of leveraging
 existing code to determine if an address is in the TLAB
Message-ID: <H17vx7Y1bWqd8QLwqR5UOxUi9VbtW3mDTTlLuQe69Ts=.f088c0f8-37f0-4ef2-be2e-cfe19513837f@github.com>

In PointerFinder.java we have some code to determine if a pointer is in a TLAB, but it only executes for the SerialGC. It should work for all GCs, so I moved the code out of the SerialGC block.

I also cleaned up the printing in PointerLocation. java a bit so when not using verbose mode not as much info about the tlab address is printed. This is consistent with other addresses, such as java stack addresses, which is what I modeled this change on.

It's hard to test this change since it is hard to consistently get an address to be in the tlab. I wrote a little test program that just sits in a loop doing allocations. I attached to it with clhsdb and ran the threadcontext command, which does a fincpc on each register. About half the time the main thread was suspended in a frame where some registers where pointing into the tlab, and I confirmed this was the case for both SerialGC and G1. Here's an example of one register with verbose off and verbose on:

rsi: 0x000000008a5d4448: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007ffa24029000

rsi: 0x000000008a5d4448: In TLAB for thread ("main" #1 prio=5 tid=0x00007ffa24029000 nid=25392 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_java
)  [0x000000008a5d4448,0x000000008ab724b8,0x000000008b0c0250,{0x000000008b0c0490})

For testing I ran all tier1, tier2, and tier5 svc tests (still in progress)

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

Commit messages:
 - better tlab support in PointerFinder and PointerLocation

Changes: https://git.openjdk.org/jdk/pull/17494/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17494&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323680
  Stats: 55 lines in 2 files changed: 26 ins; 21 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17494.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17494/head:pull/17494

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

From dholmes at openjdk.org  Fri Jan 19 02:00:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Jan 2024 02:00:28 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <VHCQ4G69m7832C_Jqe3Ztj7Xd1dk8sDxIxAmkIgFxvA=.0079894d-719e-4f67-b336-11bdcf79b3d7@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <sYRlv44lCPMlurfmnjpIhuImePBHMFBjoS54XWe2CjM=.2b728ee2-91e2-48e7-8421-affc05e4bd86@github.com>
 <VHCQ4G69m7832C_Jqe3Ztj7Xd1dk8sDxIxAmkIgFxvA=.0079894d-719e-4f67-b336-11bdcf79b3d7@github.com>
Message-ID: <i9AF1WsAj3iD_gUfQ6_Fyoa1iox6i3BWSoYB4w-upSg=.8410d3e7-7341-48b2-9693-f29237466f4b@github.com>

On Thu, 18 Jan 2024 18:56:23 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> It seems that we may be converging on using hotspot namespace?

Based on previous discussions I had been expecting to see a JEP on this after last US summer. I was surprised to see this PR pop up in this form.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1899516423

From jiangli at openjdk.org  Fri Jan 19 02:11:29 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 19 Jan 2024 02:11:29 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <i9AF1WsAj3iD_gUfQ6_Fyoa1iox6i3BWSoYB4w-upSg=.8410d3e7-7341-48b2-9693-f29237466f4b@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <sYRlv44lCPMlurfmnjpIhuImePBHMFBjoS54XWe2CjM=.2b728ee2-91e2-48e7-8421-affc05e4bd86@github.com>
 <VHCQ4G69m7832C_Jqe3Ztj7Xd1dk8sDxIxAmkIgFxvA=.0079894d-719e-4f67-b336-11bdcf79b3d7@github.com>
 <i9AF1WsAj3iD_gUfQ6_Fyoa1iox6i3BWSoYB4w-upSg=.8410d3e7-7341-48b2-9693-f29237466f4b@github.com>
Message-ID: <LinCop4taXQCm7nj7M3iVQEv4Vrr9vGwmr7-y19pMdA=.92ca0057-08a3-4f7f-8bbc-f17807517cb4@github.com>

On Fri, 19 Jan 2024 01:57:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > It seems that we may be converging on using hotspot namespace?
> 
> Based on previous discussions I had been expecting to see a JEP on this after last US summer. I was surprised to see this PR pop up in this form.

Ah, I see. Thanks for the clarification. I had an offline conversation with @iklam about the namespace and JEP topic during during last August JVM Language Summit. Based on the feedback from the conversion, it was not very clear if the namespace approach was broadly acceptable.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1899527918

From dholmes at openjdk.org  Fri Jan 19 02:12:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Jan 2024 02:12:26 GMT
Subject: RFR: 8323546: Cleanup jcmd docs for Compiler.perfmap and VM.cds
 filename parameter [v6]
In-Reply-To: <B5809zKUvr7NFfUyHXMG7zw1em4P5GoLTZ8NJFtAgOw=.96257598-34cc-4d57-8158-890e8555e951@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <B5809zKUvr7NFfUyHXMG7zw1em4P5GoLTZ8NJFtAgOw=.96257598-34cc-4d57-8158-890e8555e951@github.com>
Message-ID: <l-J-PMQRfj7pupa-x9pg8Kfor6UawlwDePHrSZ7ukTA=.dd1e5e56-4e0b-4393-8974-8a78cd5d57ed@github.com>

On Wed, 17 Jan 2024 02:26:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The jcmd docs for Compiler.perfmap currently say:
>> 
>>     - *filename*: (Optional) The name of the map file (STRING, no default value)
>> 
>> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
>> 
>> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
>> 
>> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
>> 
>>     *arguments*:
>> 
>>     - *flag name*: The name of the flag that you want to set (STRING, no
>>         default value)
>> 
>>     - *string value*: (Optional) The value that you want to set (STRING, no
>>         default value)
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Get rid of extra empty line.
>  - Remove quotes from around filename to be consistent with how jcmd STRING defaults are printed.

Looks good.

Thanks for all the effort on this one.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17359#pullrequestreview-1831064058

From dholmes at openjdk.org  Fri Jan 19 03:02:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Jan 2024 03:02:26 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v2]
In-Reply-To: <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
Message-ID: <L6uatmaWYSpwCx9Z9n_RQTnuSiimBVYY1NGzDsT_eQg=.89bc9eeb-02d3-4580-956e-d5382b90740a@github.com>

On Thu, 18 Jan 2024 16:19:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
>> 
>> 
>> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
>> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
>> 
>> 
>> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
>> 
>> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
>> 
>> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
>> 
>> The same changes are also being made to "clhsdb pstack".
>> 
>> Tested with all tier1, tier2, and tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update clhsdb docs
>  - update clhsdb docs

This seems to be a change that will impact the end user of these tools. Instead of disabling j.u.c.locks by default and proving an option to turn them on, you should provide an option to turn them off, and our tests can use that. What you proposed makes sense for an initial design of the tool, but not for a change after the fact.

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

PR Review: https://git.openjdk.org/jdk/pull/17479#pullrequestreview-1831190402

From cjplummer at openjdk.org  Fri Jan 19 05:10:25 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 19 Jan 2024 05:10:25 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v2]
In-Reply-To: <L6uatmaWYSpwCx9Z9n_RQTnuSiimBVYY1NGzDsT_eQg=.89bc9eeb-02d3-4580-956e-d5382b90740a@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
 <L6uatmaWYSpwCx9Z9n_RQTnuSiimBVYY1NGzDsT_eQg=.89bc9eeb-02d3-4580-956e-d5382b90740a@github.com>
Message-ID: <EKRqQHjr7OvlcMU1fMXiQ3mH9eLUNXly091VvSiceGg=.146b153a-d2c5-434b-9c16-1e9ef52bc579@github.com>

On Fri, 19 Jan 2024 02:59:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update clhsdb docs
>>  - update clhsdb docs
>
> This seems to be a change that will impact the end user of these tools. Instead of disabling j.u.c.locks by default and proving an option to turn them on, you should provide an option to turn them off, and our tests can use that. What you proposed makes sense for an initial design of the tool, but not for a change after the fact.

@dholmes-ora I understand your point. There are pros and cons to both approaches, and I think that needs to be considered. One advantage of my approach is preventing users from accidentally stumbling into this is issue, and wondering why jstack won't complete. I think this is more likely than being confused by the change (expecting locks and not seeing them). Another advantage is consistency with bin/jstack and "jhsdb jstack" in that the locks are not included by default.

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

PR Comment: https://git.openjdk.org/jdk/pull/17479#issuecomment-1899777777

From dholmes at openjdk.org  Fri Jan 19 05:42:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Jan 2024 05:42:26 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v2]
In-Reply-To: <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
Message-ID: <RJuDrBXDsk7OIaY8hBJqGSJp_yElmbyJ0qNdzA2Qiis=.f4e7da80-e840-4e07-aa3d-128906953132@github.com>

On Thu, 18 Jan 2024 16:19:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
>> 
>> 
>> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
>> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
>> 
>> 
>> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
>> 
>> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
>> 
>> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
>> 
>> The same changes are also being made to "clhsdb pstack".
>> 
>> Tested with all tier1, tier2, and tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update clhsdb docs
>  - update clhsdb docs

You will need a Release Note to document the change.

I also wonder if we should be looking at a different way to track j.u.c lock usage, as searching the full heap does not seem at all reasonable.

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

PR Comment: https://git.openjdk.org/jdk/pull/17479#issuecomment-1899803021

From cjplummer at openjdk.org  Fri Jan 19 05:54:29 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 19 Jan 2024 05:54:29 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v2]
In-Reply-To: <RJuDrBXDsk7OIaY8hBJqGSJp_yElmbyJ0qNdzA2Qiis=.f4e7da80-e840-4e07-aa3d-128906953132@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
 <RJuDrBXDsk7OIaY8hBJqGSJp_yElmbyJ0qNdzA2Qiis=.f4e7da80-e840-4e07-aa3d-128906953132@github.com>
Message-ID: <QrNEUyTETNHAj3ElEBadHLTPRbJISNw_qb1L5df2nlA=.9bed17d4-386c-45b0-a908-0765b2dc3e72@github.com>

On Fri, 19 Jan 2024 05:40:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I also wonder if we should be looking at a different way to track j.u.c lock usage, as searching the full heap does not seem at all reasonable.

Good question. It looks like bin/jstack does the same, but there is much less cost to doing this within hotspot than with using SA:


void ConcurrentLocksDump::dump_at_safepoint() {
  // dump all locked concurrent locks
  assert(SafepointSynchronize::is_at_safepoint(), "all threads are stopped");

  GrowableArray<oop>* aos_objects = new (mtServiceability) GrowableArray<oop>(INITIAL_ARRAY_SIZE, mtServiceability);

  // Find all instances of AbstractOwnableSynchronizer
  HeapInspection::find_instances_at_safepoint(vmClasses::java_util_concurrent_locks_AbstractOwnableSynchronizer_klass(),
                                              aos_objects);
  // Build a map of thread to its owned AQS locks
  build_map(aos_objects);

  delete aos_objects;
}

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

PR Comment: https://git.openjdk.org/jdk/pull/17479#issuecomment-1899810567

From aph at openjdk.org  Fri Jan 19 09:01:28 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 19 Jan 2024 09:01:28 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <LinCop4taXQCm7nj7M3iVQEv4Vrr9vGwmr7-y19pMdA=.92ca0057-08a3-4f7f-8bbc-f17807517cb4@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <sYRlv44lCPMlurfmnjpIhuImePBHMFBjoS54XWe2CjM=.2b728ee2-91e2-48e7-8421-affc05e4bd86@github.com>
 <VHCQ4G69m7832C_Jqe3Ztj7Xd1dk8sDxIxAmkIgFxvA=.0079894d-719e-4f67-b336-11bdcf79b3d7@github.com>
 <i9AF1WsAj3iD_gUfQ6_Fyoa1iox6i3BWSoYB4w-upSg=.8410d3e7-7341-48b2-9693-f29237466f4b@github.com>
 <LinCop4taXQCm7nj7M3iVQEv4Vrr9vGwmr7-y19pMdA=.92ca0057-08a3-4f7f-8bbc-f17807517cb4@github.com>
Message-ID: <YPHAq_4H8ngCgrcljIubp0zd2zwgPX4STLvDoLJZoMs=.f84bf232-b645-438e-9066-35a776957662@github.com>

On Fri, 19 Jan 2024 02:09:15 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > > It seems that we may be converging on using hotspot namespace?
> > 
> > 
> > Based on previous discussions I had been expecting to see a JEP on this after last US summer. I was surprised to see this PR pop up in this form.
> 
> Ah, I see. Thanks for the clarification. I had an offline conversation with @iklam about the namespace and JEP topic during during last August JVM Language Summit. Based on the feedback from the conversion, it was not very clear if the namespace approach was broadly acceptable.

Using a default namespace for everything could have bad effects on debugging and other maintenance tools. it's unlikely to be a low-cost option. Perhaps it could be restricted to the static linking case, but that further complicates testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1900008812

From coleenp at openjdk.org  Fri Jan 19 14:03:30 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Jan 2024 14:03:30 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
Message-ID: <oL1p-_PEAzeKgRCJXBq-41dm1Hup-dH7xXTDeG5Waf4=.53f6a5da-5e7f-436e-889a-9a505d7890fa@github.com>

On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
> 
> Contributed by Chuck Rasbold and @jianglizhou.

You could support one build by adding something like -DSUPPORTS_STATIC_LINK for both .so and .a builds for Google,  then use that to protect the renaming.

I don't know how bad "namespace hotspot" would be for debugging.  At least for some of the common names.  I suppose breakpoints would have to be specified in gdb as break at hotspot::Thread::is_owning_thread or something like that, and with a using namespace hotspot, it wouldn't be visible looking at the source code in that form.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1900475932

From jiangli at openjdk.org  Fri Jan 19 20:15:27 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 19 Jan 2024 20:15:27 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <YPHAq_4H8ngCgrcljIubp0zd2zwgPX4STLvDoLJZoMs=.f84bf232-b645-438e-9066-35a776957662@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <sYRlv44lCPMlurfmnjpIhuImePBHMFBjoS54XWe2CjM=.2b728ee2-91e2-48e7-8421-affc05e4bd86@github.com>
 <VHCQ4G69m7832C_Jqe3Ztj7Xd1dk8sDxIxAmkIgFxvA=.0079894d-719e-4f67-b336-11bdcf79b3d7@github.com>
 <i9AF1WsAj3iD_gUfQ6_Fyoa1iox6i3BWSoYB4w-upSg=.8410d3e7-7341-48b2-9693-f29237466f4b@github.com>
 <LinCop4taXQCm7nj7M3iVQEv4Vrr9vGwmr7-y19pMdA=.92ca0057-08a3-4f7f-8bbc-f17807517cb4@github.com>
 <YPHAq_4H8ngCgrcljIubp0zd2zwgPX4STLvDoLJZoMs=.f84bf232-b645-438e-9066-35a776957662@github.com>
Message-ID: <rbcI86va4YTRvgA5zErw1NXdVulDF_ZwY3GHPqBD0_s=.64c53433-d95e-43a5-8f86-ead49ad4c09d@github.com>

On Fri, 19 Jan 2024 08:58:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > > It seems that we may be converging on using hotspot namespace?
> > > 
> > > 
> > > Based on previous discussions I had been expecting to see a JEP on this after last US summer. I was surprised to see this PR pop up in this form.
> > 
> > 
> > Ah, I see. Thanks for the clarification. I had an offline conversation with @iklam about the namespace and JEP topic during during last August JVM Language Summit. Based on the feedback from the conversion, it was not very clear if the namespace approach was broadly acceptable.
> 
> Using a default namespace for everything could have bad effects on debugging and other maintenance tools. it's unlikely to be a low-cost option. Perhaps it could be restricted to the static linking case, but that further complicates testing.

Thanks. Agreed to both points. It seems to add too much complexities if the namespace usage is restricted to static linking case only.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1901043889

From jiangli at openjdk.org  Fri Jan 19 20:24:26 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 19 Jan 2024 20:24:26 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <oL1p-_PEAzeKgRCJXBq-41dm1Hup-dH7xXTDeG5Waf4=.53f6a5da-5e7f-436e-889a-9a505d7890fa@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <oL1p-_PEAzeKgRCJXBq-41dm1Hup-dH7xXTDeG5Waf4=.53f6a5da-5e7f-436e-889a-9a505d7890fa@github.com>
Message-ID: <ummqg2bQNv5kEwhiBbm4NpB5c8jMI_ak8ID_jiVB3WE=.ff1fe835-bcd4-46e0-84c8-1e131a68bef0@github.com>

On Fri, 19 Jan 2024 14:00:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> You could support one build by adding something like -DSUPPORTS_STATIC_LINK for both .so and .a builds for Google, then use that to protect the renaming.

Thanks, @coleenp. I think that could work for all different cases. I'll reflect that in this PR.

For longer term we probably still want to find a cleaner solution when the static support becomes more popular.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1901057917

From aph at openjdk.org  Sat Jan 20 18:02:26 2024
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 20 Jan 2024 18:02:26 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <ummqg2bQNv5kEwhiBbm4NpB5c8jMI_ak8ID_jiVB3WE=.ff1fe835-bcd4-46e0-84c8-1e131a68bef0@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <oL1p-_PEAzeKgRCJXBq-41dm1Hup-dH7xXTDeG5Waf4=.53f6a5da-5e7f-436e-889a-9a505d7890fa@github.com>
 <ummqg2bQNv5kEwhiBbm4NpB5c8jMI_ak8ID_jiVB3WE=.ff1fe835-bcd4-46e0-84c8-1e131a68bef0@github.com>
Message-ID: <_v-SmPJKuKfADRbcVs9bxD-oVlXlMY6bi1lsapciOhQ=.ee0d368c-0d55-4c43-99fc-565577714792@github.com>

On Fri, 19 Jan 2024 20:21:21 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > You could support one build by adding something like -DSUPPORTS_STATIC_LINK for both .so and .a builds for Google, then use that to protect the renaming.
> 
> Thanks, @coleenp. I think that could work for all different cases. I'll reflect that in this PR.
> 
> For longer term we probably still want to find a cleaner solution when the static support becomes more popular.

I think you should be able to use ld and objcopy to merge the .o files and hide all of the symbols you don't want to export.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1902207127

From jwaters at openjdk.org  Sun Jan 21 12:18:40 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 21 Jan 2024 12:18:40 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
Message-ID: <djt42Q1nmxYSG0DsBpZG8-KIYkBKfmmNjM7y2cc1qpU=.44851569-5e3d-45a4-9ffb-bfaec0d28041@github.com>

On Tue, 30 May 2023 19:15:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Align
>  - Suggestions

I'm an entire year late, but if poisoning NULL is desired, what about #pragma GCC poison?

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

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1902610611

From jwaters at openjdk.org  Sun Jan 21 12:21:46 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 21 Jan 2024 12:21:46 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
Message-ID: <bNlb5VIdi7-QnzNEqh1ldgtN9obxB9MHYhj28fsTh3Y=.5a16b6ad-6ed6-470f-b9cc-5fadf40b7de7@github.com>

On Tue, 30 May 2023 19:15:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Align
>  - Suggestions

For Visual C++, that would be #pragma deprecated("NULL")

To quote Microsoft:
"You can deprecate macro names. Place the macro name in quotes or else macro expansion will occur."

I have no idea how to achieve this with the xlc compiler

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

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1902611263

From jiangli at openjdk.org  Mon Jan 22 06:47:26 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 22 Jan 2024 06:47:26 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <_v-SmPJKuKfADRbcVs9bxD-oVlXlMY6bi1lsapciOhQ=.ee0d368c-0d55-4c43-99fc-565577714792@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <oL1p-_PEAzeKgRCJXBq-41dm1Hup-dH7xXTDeG5Waf4=.53f6a5da-5e7f-436e-889a-9a505d7890fa@github.com>
 <ummqg2bQNv5kEwhiBbm4NpB5c8jMI_ak8ID_jiVB3WE=.ff1fe835-bcd4-46e0-84c8-1e131a68bef0@github.com>
 <_v-SmPJKuKfADRbcVs9bxD-oVlXlMY6bi1lsapciOhQ=.ee0d368c-0d55-4c43-99fc-565577714792@github.com>
Message-ID: <RF_oUhjkWXERfHXhOAyBLWYQHRgJ-TJ28h69_PSrzEs=.79fe9a34-e8e4-4247-be8c-60df2e7a809b@github.com>

On Sat, 20 Jan 2024 18:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > You could support one build by adding something like -DSUPPORTS_STATIC_LINK for both .so and .a builds for Google, then use that to protect the renaming.
> > 
> > 
> > Thanks, @coleenp. I think that could work for all different cases. I'll reflect that in this PR.
> > For longer term we probably still want to find a cleaner solution when the static support becomes more popular.
> 
> I think you should be able to use ld and objcopy to merge the .o files and hide all of the symbols you don't want to export.

We also discussed about `objcopy` in https://github.com/openjdk/jdk/pull/14808#issuecomment-1631597197 and https://github.com/openjdk/jdk/pull/14808#issuecomment-1631611220. My main concern was the portability of `objcopy` approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1903359606

From duke at openjdk.org  Mon Jan 22 08:54:39 2024
From: duke at openjdk.org (sendaoYan)
Date: Mon, 22 Jan 2024 08:54:39 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v2]
In-Reply-To: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
References: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
Message-ID: <hy5TfhHxLgs5ws-tXG_zAT0_54_cdsIDEMkrNEzcOyI=.d1976ed7-4890-4658-9881-a7fa2d3b145c@github.com>

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

sendaoYan has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
  
  Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17386/files
  - new: https://git.openjdk.org/jdk/pull/17386/files/e8a99fe4..9f0aa2a1

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17386/head:pull/17386

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

From kbarrett at openjdk.org  Mon Jan 22 09:02:41 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 22 Jan 2024 09:02:41 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
Message-ID: <gY9Ddw9zMNtfFgiT6sBwl3oKgdIq3Db_LvZD3tgyOjQ=.9c25c0f8-f202-4105-811b-3c177e684b8e@github.com>

On Tue, 30 May 2023 19:15:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Align
>  - Suggestions

I don't think `#pragma GCC poison` works for us. It would complain about a
system or library header that uses NULL and is included after the pragma.

MSVC's deprecation pragma might work for this, at least for shared and
Windows-specific code. I couldn't find a way to use it for FORBID_C_FUNCTION,
but the problems I encountered for that don't seem applicable in this case.

However, there are still a lot of NULL's left.  All of the per-cpu .ad files,
and the jvmtiXXX.xsl files contain NULL's that will appear in the associated
generated code.  Also, NULL usage in gtests doesn't seem to have been addressed
yet.

But it does look like there's been a bit of backsliding:
https://bugs.openjdk.org/browse/JDK-8324286

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

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1903531104

From duke at openjdk.org  Mon Jan 22 09:26:36 2024
From: duke at openjdk.org (sendaoYan)
Date: Mon, 22 Jan 2024 09:26:36 GMT
Subject: Withdrawn: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
References: <9-YA-oDFJiD_ePHqwvScLwy3MhSZpZMtPC9sZtwFJDY=.1d3a8019-e2f5-40e6-b558-bf087c4e4768@github.com>
Message-ID: <zOHY3r1ICvZvzpy6JlunWBc0Gs5KTdPPhD8Jp8ycULo=.e890fed3-6115-4c9d-9155-0e0e9b164803@github.com>

On Fri, 12 Jan 2024 03:31:37 GMT, sendaoYan <duke at openjdk.org> wrote:

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

This pull request has been closed without being integrated.

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

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

From jwaters at openjdk.org  Mon Jan 22 09:28:46 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 22 Jan 2024 09:28:46 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <gY9Ddw9zMNtfFgiT6sBwl3oKgdIq3Db_LvZD3tgyOjQ=.9c25c0f8-f202-4105-811b-3c177e684b8e@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
 <gY9Ddw9zMNtfFgiT6sBwl3oKgdIq3Db_LvZD3tgyOjQ=.9c25c0f8-f202-4105-811b-3c177e684b8e@github.com>
Message-ID: <3ok9vLTR6ElUchHl9NGXoJgz_EGG9Fln3cE4BgPWGrw=.f1c53a24-9835-4e7a-a62b-6fffdfd1e05f@github.com>

On Mon, 22 Jan 2024 08:59:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I don't think `#pragma GCC poison` works for us. It would complain about a
> system or library header that uses NULL and is included after the pragma.

I see, that's a shame in that case



> However, there are still a lot of NULL's left. All of the per-cpu .ad files, and the jvmtiXXX.xsl files contain NULL's that will appear in the associated generated code. Also, NULL usage in gtests doesn't seem to have been addressed yet.
> 
> But it does look like there's been a bit of backsliding: https://bugs.openjdk.org/browse/JDK-8324286

That's a little worrying, maybe the Style Guide's NULL section could be reworded since now most usages of NULL are nullptr? The .ad files and .xsl files are a bit of a problem though



> MSVC's deprecation pragma might work for this, at least for shared and
> Windows-specific code. I couldn't find a way to use it for FORBID_C_FUNCTION,
> but the problems I encountered for that don't seem applicable in this case.

The deprecation pragma only works for macros and identifiers, it doesn't accept method signatures and would warn for every time a identifier is used, even in the method's declaration itself! Probably can't be used in FORBID_C_FUNCTION as mentioned above, but sounds good for a macro like NULL

I've also been trying to implement FORBID_C_FUNCTION and ALLOW_C_FUNCTION portably, speaking of it, but it hasn't been going great so far :/ https://github.com/openjdk/jdk/pull/17387

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

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1903579473

From duke at openjdk.org  Mon Jan 22 09:39:52 2024
From: duke at openjdk.org (sendaoYan)
Date: Mon, 22 Jan 2024 09:39:52 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
Message-ID: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>

8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

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

Commit messages:
 - 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

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

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

From duke at openjdk.org  Mon Jan 22 09:39:52 2024
From: duke at openjdk.org (sendaoYan)
Date: Mon, 22 Jan 2024 09:39:52 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
Message-ID: <pYkGoKqK_pO_Qgtv8bJvUlf-7hehohjedkl83eqrB9U=.a0b2b486-9d46-4805-95e0-f4e25ebd0c7b@github.com>

On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan <duke at openjdk.org> wrote:

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

The test case before this PR has a maximum heap of 64MB and applies for 8M of memory each time in the for loop. When applying for memory for the sixth time, it was killed by the docker container because of OOM, jdk.internal.platform.Metrics.systemMetrics().getMemoryFailCount( ) interface has no chance to return 1, and the Java process returns exit code 137. The maximum heap is also 64M, The PR is changed to 1KB each time to ensure that the getMemoryFailCount() interface has a chance to return 1 and the test case has a chance to exit the for loop of memory allocation.

## test result before this PR:

![image](https://github.com/openjdk/jdk/assets/24123821/4554dd00-6da5-4529-907a-45e2df5c902b)


## test result after this PR:

![image](https://github.com/openjdk/jdk/assets/24123821/32ea4fc8-aa04-425e-8481-a920265d2b1f)

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

PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-1903589872

From eastigeevich at openjdk.org  Mon Jan 22 13:11:27 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 22 Jan 2024 13:11:27 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing
In-Reply-To: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
Message-ID: <KCKrniTwBSR2yuyzXbnb6nMk2ESIXRHQTKPUEXTMPFo=.46738440-b259-4275-8de1-21110b5fc033@github.com>

On Sat, 20 Jan 2024 19:48:07 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
> 
> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
> 
> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
> 
> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
> ```c++
>  jint init_globals() {
>    management_init();
>    JvmtiExport::initialize_oop_storage();
> +#if INCLUDE_JVMTI
> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
> +  JvmtiExport::set_all_dependencies_are_recorded(true);
> +#endif
> 
> 
> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb. The ration remains about the same i...

lgtm

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

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17509#pullrequestreview-1836432196

From sgehwolf at openjdk.org  Mon Jan 22 15:06:29 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 22 Jan 2024 15:06:29 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
Message-ID: <LrIsvPuptlg6kpZIiEg2al4DO1sMxtQFcY-iOXx_5mg=.53e24cae-bd26-4c11-babb-a582d0971f13@github.com>

On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan <duke at openjdk.org> wrote:

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

`1k` increments for a total of `512k` times seems overkill. Are you sure that's needed to make the test pass? How about `1MB` increments for a total of `512` times?

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

PR Review: https://git.openjdk.org/jdk/pull/17514#pullrequestreview-1836685784

From shade at openjdk.org  Mon Jan 22 16:41:27 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 Jan 2024 16:41:27 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing
In-Reply-To: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
Message-ID: <FvABOpwsDmk1FegZHdt2Q2QkjEFfnnxqu_1mJh9T02c=.eb10b6b1-b457-4862-917b-5ca0d0d15c80@github.com>

On Sat, 20 Jan 2024 19:48:07 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Instead of unconditionally recording evol_method dependencies we could guard the recording by a new flag. But this would only make sense if that flag would be on by default and I don't know if such a flag is justified just for the rare (or non-existent?) cases where somebody wants to disable the recording of the dependencies.

I think introducing a diagnostic flag is sensible here. If we figure out much later that this solution comes with some other (worse) problems, the diagnostic flag gives us the options to: a) clearly point at this addition as the culprit; b) have the easily deployable solution to restore the original behavior.

For the change itself, we need to amend the comment near `VM_RedefineClasses::flush_dependent_code` definition that talks about this peculiar behavior, which now changes. Actually, maybe even the implementation of `flush_dependent_code` should now trust (and assert) that all dependencies are now recorded?

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

PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-1904382556

From phh at openjdk.org  Mon Jan 22 16:41:26 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 22 Jan 2024 16:41:26 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing
In-Reply-To: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
Message-ID: <e1jqFfZdRg29qInoanRA4EtMcP7U7EL6aCeAl_TN1aM=.cd847a8e-306b-480b-8e2f-e875d18d4996@github.com>

On Sat, 20 Jan 2024 19:48:07 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
> 
> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
> 
> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
> 
> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
> ```c++
>  jint init_globals() {
>    management_init();
>    JvmtiExport::initialize_oop_storage();
> +#if INCLUDE_JVMTI
> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
> +  JvmtiExport::set_all_dependencies_are_recorded(true);
> +#endif
> 
> 
> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb. The ration remains about the same i...

Marked as reviewed by phh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17509#pullrequestreview-1836891644

From eastigeevich at openjdk.org  Mon Jan 22 16:50:27 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 22 Jan 2024 16:50:27 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing
In-Reply-To: <FvABOpwsDmk1FegZHdt2Q2QkjEFfnnxqu_1mJh9T02c=.eb10b6b1-b457-4862-917b-5ca0d0d15c80@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <FvABOpwsDmk1FegZHdt2Q2QkjEFfnnxqu_1mJh9T02c=.eb10b6b1-b457-4862-917b-5ca0d0d15c80@github.com>
Message-ID: <VSpCOfMMRe_LO7ibx1YQechFqBR2hTt65XUaas2uyvk=.c8156dc8-8d2a-4e04-a1e1-df1af0e15200@github.com>

On Mon, 22 Jan 2024 16:37:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
>> 
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
>> 
>> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
>> 
>> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
>> ```c++
>>  jint init_globals() {
>>    management_init();
>>    JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> +  JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>> 
>> 
>> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb....
>
>> Instead of unconditionally recording evol_method dependencies we could guard the recording by a new flag. But this would only make sense if that flag would be on by default and I don't know if such a flag is justified just for the rare (or non-existent?) cases where somebody wants to disable the recording of the dependencies.
> 
> I think introducing a diagnostic flag is sensible here. If we figure out much later that this solution comes with some other (worse) problems, the diagnostic flag gives us the options to: a) clearly point at this addition as the culprit; b) have the easily deployable solution to restore the original behavior.
> 
> For the change itself, we need to amend the comment near `VM_RedefineClasses::flush_dependent_code` definition that talks about this peculiar behavior, which now changes. Actually, maybe even the implementation of `flush_dependent_code` should now trust (and assert) that all dependencies are now recorded?

@shipilev I filed https://bugs.openjdk.org/browse/JDK-8324318 which is related to this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-1904402169

From cjplummer at openjdk.org  Mon Jan 22 19:06:26 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Jan 2024 19:06:26 GMT
Subject: RFR: 8323680: SA PointerFinder code can do a better job of
 leveraging existing code to determine if an address is in the TLAB
In-Reply-To: <H17vx7Y1bWqd8QLwqR5UOxUi9VbtW3mDTTlLuQe69Ts=.f088c0f8-37f0-4ef2-be2e-cfe19513837f@github.com>
References: <H17vx7Y1bWqd8QLwqR5UOxUi9VbtW3mDTTlLuQe69Ts=.f088c0f8-37f0-4ef2-be2e-cfe19513837f@github.com>
Message-ID: <Vrf0BMwgwWvnIy9cL7aqUA4zan5wjFRRe5okaC3ekL0=.f215a47d-c58f-4c86-8bd8-939dcc2c6f14@github.com>

On Thu, 18 Jan 2024 22:54:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In PointerFinder.java we have some code to determine if a pointer is in a TLAB, but it only executes for the SerialGC. It should work for all GCs, so I moved the code out of the SerialGC block.
> 
> I also cleaned up the printing in PointerLocation. java a bit so when not using verbose mode not as much info about the tlab address is printed. This is consistent with other addresses, such as java stack addresses, which is what I modeled this change on.
> 
> It's hard to test this change since it is hard to consistently get an address to be in the tlab. I wrote a little test program that just sits in a loop doing allocations. I attached to it with clhsdb and ran the threadcontext command, which does a fincpc on each register. About half the time the main thread was suspended in a frame where some registers where pointing into the tlab, and I confirmed this was the case for both SerialGC and G1. Here's an example of one register with verbose off and verbose on:
> 
> rsi: 0x000000008a5d4448: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007ffa24029000
> 
> rsi: 0x000000008a5d4448: In TLAB for thread ("main" #1 prio=5 tid=0x00007ffa24029000 nid=25392 runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_java
> )  [0x000000008a5d4448,0x000000008ab724b8,0x000000008b0c0250,{0x000000008b0c0490})
> 
> For testing I ran all tier1, tier2, and tier5 svc tests (still in progress)

Ping! I still need 2 reviews. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17494#issuecomment-1904625532

From cjplummer at openjdk.org  Mon Jan 22 19:06:27 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Jan 2024 19:06:27 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v2]
In-Reply-To: <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
Message-ID: <vttbdNqcb0zM21ZwFHqA9qES7jirS6gCWEXBGDZuesE=.45ed84f3-a251-425a-b1cd-897d4c8c52b6@github.com>

On Thu, 18 Jan 2024 16:19:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
>> 
>> 
>> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
>> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](mailto:jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
>> 
>> 
>> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
>> 
>> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
>> 
>> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
>> 
>> The same changes are also being made to "clhsdb pstack".
>> 
>> Tested with all tier1, tier2, and tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update clhsdb docs
>  - update clhsdb docs

Ping! I still need 2 reviews. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17479#issuecomment-1904625954

From coleenp at openjdk.org  Mon Jan 22 20:53:27 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 22 Jan 2024 20:53:27 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing
In-Reply-To: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
Message-ID: <QhMqBAE5oOFYxL7loDmDXXB_0zYSasJulZq5oMdVG6g=.ab1607e5-b3bc-47c5-8064-1bca06a7c080@github.com>

On Sat, 20 Jan 2024 19:48:07 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
> 
> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
> 
> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
> 
> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
> ```c++
>  jint init_globals() {
>    management_init();
>    JvmtiExport::initialize_oop_storage();
> +#if INCLUDE_JVMTI
> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
> +  JvmtiExport::set_all_dependencies_are_recorded(true);
> +#endif
> 
> 
> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb. The ration remains about the same i...

I support adding this as a diagnostic option, therefore you won't have to make the change in VM_RedefineClasses::flush_dependent_code.

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

PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-1904784430

From simonis at openjdk.org  Mon Jan 22 21:26:41 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 22 Jan 2024 21:26:41 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
Message-ID: <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>

> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
> 
> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
> 
> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
> 
> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
> ```c++
>  jint init_globals() {
>    management_init();
>    JvmtiExport::initialize_oop_storage();
> +#if INCLUDE_JVMTI
> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
> +  JvmtiExport::set_all_dependencies_are_recorded(true);
> +#endif
> 
> 
> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb. The ration remains about the same i...

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Guard the feature with a diagnostic option and update the comments in the code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17509/files
  - new: https://git.openjdk.org/jdk/pull/17509/files/95db4a72..6d3e24ab

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

  Stats: 20 lines in 3 files changed: 8 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17509/head:pull/17509

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

From simonis at openjdk.org  Mon Jan 22 21:26:42 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 22 Jan 2024 21:26:42 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing
In-Reply-To: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
Message-ID: <FFPPRaB2eLphAiayqoNX37SKoBKkR13_ByZzbCFEjlk=.66ca6644-f9db-45f0-9a52-b1ac0497e1f5@github.com>

On Sat, 20 Jan 2024 19:48:07 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
> 
> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
> 
> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
> 
> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
> ```c++
>  jint init_globals() {
>    management_init();
>    JvmtiExport::initialize_oop_storage();
> +#if INCLUDE_JVMTI
> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
> +  JvmtiExport::set_all_dependencies_are_recorded(true);
> +#endif
> 
> 
> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb. The ration remains about the same i...

Thanks everybody for looking at this. I've now guarded the feature with a diagnostic command, updated the source code comments around `VM_RedefineClasses::flush_dependent_code` and added an assertion for the new flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-1904842722

From eastigeevich at openjdk.org  Mon Jan 22 23:28:28 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 22 Jan 2024 23:28:28 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
Message-ID: <7YLjZUNrhGYSma_Hop1JnZWj75lytQMnXczCP5JSQQc=.7da0a1c2-423f-4144-be20-2aa3707ce332@github.com>

On Mon, 22 Jan 2024 21:26:41 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
>> 
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
>> 
>> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
>> 
>> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
>> ```c++
>>  jint init_globals() {
>>    management_init();
>>    JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> +  JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>> 
>> 
>> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb....
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Guard the feature with a diagnostic option and update the comments in the code

src/hotspot/share/runtime/globals.hpp line 2013:

> 2011:           "Profile exception handlers")                                     \
> 2012:                                                                             \
> 2013:   product(bool, AlwaysRecordEvolDependencies, true, DIAGNOSTIC,             \

As we record all dependencies not only evol_method ones, should we name it just: `AlwaysRecordDependencies`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1462550445

From eastigeevich at openjdk.org  Mon Jan 22 23:35:28 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 22 Jan 2024 23:35:28 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
Message-ID: <MRlwrYGzcc7mNjBgrQxi4G4DQujrkK2YyJrZMIq81iU=.ef2d7215-860c-48cf-a7ee-e44c5a16af21@github.com>

On Mon, 22 Jan 2024 21:26:41 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
>> 
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
>> 
>> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
>> 
>> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
>> ```c++
>>  jint init_globals() {
>>    management_init();
>>    JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> +  JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>> 
>> 
>> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb....
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Guard the feature with a diagnostic option and update the comments in the code

src/hotspot/share/runtime/globals.hpp line 2014:

> 2012:                                                                             \
> 2013:   product(bool, AlwaysRecordEvolDependencies, true, DIAGNOSTIC,             \
> 2014:                 "Unconditionally record method dependencies on class "      \

"... record compiled method dependencies ..."?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1462553968

From coleenp at openjdk.org  Mon Jan 22 23:41:30 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 22 Jan 2024 23:41:30 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
Message-ID: <ns2Nq9tvJJVts4cBS-a9ZMKjAE330CZDkfPyp-Z9lxU=.9ed729dc-436f-4acc-961f-88f47d763f45@github.com>

On Mon, 22 Jan 2024 21:26:41 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
>> 
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
>> 
>> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
>> 
>> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
>> ```c++
>>  jint init_globals() {
>>    management_init();
>>    JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> +  JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>> 
>> 
>> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb....
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Guard the feature with a diagnostic option and update the comments in the code

This looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17509#pullrequestreview-1837600406

From jrose at openjdk.org  Mon Jan 22 23:41:33 2024
From: jrose at openjdk.org (John R Rose)
Date: Mon, 22 Jan 2024 23:41:33 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <7YLjZUNrhGYSma_Hop1JnZWj75lytQMnXczCP5JSQQc=.7da0a1c2-423f-4144-be20-2aa3707ce332@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
 <7YLjZUNrhGYSma_Hop1JnZWj75lytQMnXczCP5JSQQc=.7da0a1c2-423f-4144-be20-2aa3707ce332@github.com>
Message-ID: <GVLetexwDFn2BeX7cOT5zDeGPcGXHNmvfiQO76YN7Pg=.14ac92bc-0464-4840-86c5-82f79e421b64@github.com>

On Mon, 22 Jan 2024 23:26:08 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Guard the feature with a diagnostic option and update the comments in the code
>
> src/hotspot/share/runtime/globals.hpp line 2013:
> 
>> 2011:           "Profile exception handlers")                                     \
>> 2012:                                                                             \
>> 2013:   product(bool, AlwaysRecordEvolDependencies, true, DIAGNOSTIC,             \
> 
> As we record all dependencies not only evol_method ones, should we name it just: `AlwaysRecordDependencies`?

That?s not exactly right either.  `RecordAllDependencies` would be more like it.  Because:

  - We might record some dependencies that we know we need, and leave others out.
  - Or, we might record all dependencies, even ones we think we might not need.

(But we will need them all if somebody turns on JFR.)

I like this change.  Having a diagnostic switch means we can do a rough triage if something seems to go wrong with this change, down the road.

> src/hotspot/share/runtime/globals.hpp line 2014:
> 
>> 2012:                                                                             \
>> 2013:   product(bool, AlwaysRecordEvolDependencies, true, DIAGNOSTIC,             \
>> 2014:                 "Unconditionally record method dependencies on class "      \
> 
> "... record compiled method dependencies ..."?

(yes, ?compiled methods? or even ?nmethods?, or ?methods in code cache?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1462556769
PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1462557389

From coleenp at openjdk.org  Mon Jan 22 23:41:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 22 Jan 2024 23:41:34 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <GVLetexwDFn2BeX7cOT5zDeGPcGXHNmvfiQO76YN7Pg=.14ac92bc-0464-4840-86c5-82f79e421b64@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
 <7YLjZUNrhGYSma_Hop1JnZWj75lytQMnXczCP5JSQQc=.7da0a1c2-423f-4144-be20-2aa3707ce332@github.com>
 <GVLetexwDFn2BeX7cOT5zDeGPcGXHNmvfiQO76YN7Pg=.14ac92bc-0464-4840-86c5-82f79e421b64@github.com>
Message-ID: <ytPq0oxAuyHZ61e-QWZhLIZzwYe7k8bDho6Psd7Y9qU=.06ec5fb2-c9c9-4bc6-98aa-d9b51bf8d574@github.com>

On Mon, 22 Jan 2024 23:37:35 GMT, John R Rose <jrose at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 2013:
>> 
>>> 2011:           "Profile exception handlers")                                     \
>>> 2012:                                                                             \
>>> 2013:   product(bool, AlwaysRecordEvolDependencies, true, DIAGNOSTIC,             \
>> 
>> As we record all dependencies not only evol_method ones, should we name it just: `AlwaysRecordDependencies`?
>
> That?s not exactly right either.  `RecordAllDependencies` would be more like it.  Because:
> 
>   - We might record some dependencies that we know we need, and leave others out.
>   - Or, we might record all dependencies, even ones we think we might not need.
> 
> (But we will need them all if somebody turns on JFR.)
> 
> I like this change.  Having a diagnostic switch means we can do a rough triage if something seems to go wrong with this change, down the road.

No, because you want to turn on/off evol_method independently of the other dependencies that the compiler is recording.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1462556836

From duke at openjdk.org  Tue Jan 23 01:45:27 2024
From: duke at openjdk.org (sendaoYan)
Date: Tue, 23 Jan 2024 01:45:27 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <LrIsvPuptlg6kpZIiEg2al4DO1sMxtQFcY-iOXx_5mg=.53e24cae-bd26-4c11-babb-a582d0971f13@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
 <LrIsvPuptlg6kpZIiEg2al4DO1sMxtQFcY-iOXx_5mg=.53e24cae-bd26-4c11-babb-a582d0971f13@github.com>
Message-ID: <oT8uw1KKw8Td3c4XMWO_h0hzlFIpkv_pdiDQXtJXfXI=.a440943e-c4b4-4c9f-be97-4ce35b977b59@github.com>

On Mon, 22 Jan 2024 15:03:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> `1k` increments for a total of `512k` times seems overkill. Are you sure that's needed to make the test pass? How about `1MB` increments for a total of `512` times?

When the docker serivice work normally on the test machine, this test will always fail. This test want to verify the API `jdk.internal.platform.Metrics.systemMetrics().getMemoryFailCount()` work normally or not. The API return memory allocate fail times in jvm. But, before this PR, everytime it allocate `1M` memory, the API has no chance the catch the memory allocate fail, the jvm was killed by OOM. Change `8M` increments to `1K` mean to avoid OOM killed for the jvm in docker container.

jvm was killed by OOM in docker container:

![image](https://github.com/openjdk/jdk/assets/24123821/c00697cc-ceef-410e-a8b9-7c401fa76134)


`1M` Increnents also can avoid OOM killed.

![image](https://github.com/openjdk/jdk/assets/24123821/bab0a753-d15c-4759-a557-b8feafaa97cb)

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

PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-1905139487

From duke at openjdk.org  Tue Jan 23 01:58:40 2024
From: duke at openjdk.org (sendaoYan)
Date: Tue, 23 Jan 2024 01:58:40 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v2]
In-Reply-To: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
Message-ID: <yhwpfIMqwuQ158zvVxkWSew3trCHzoulCcD5c57JGb4=.7b055d31-0863-4c61-9e47-a746e51eacb7@github.com>

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

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

  8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
  
  Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17514/files
  - new: https://git.openjdk.org/jdk/pull/17514/files/be81665d..969b608d

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

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

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

From dlong at openjdk.org  Tue Jan 23 03:34:29 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 23 Jan 2024 03:34:29 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
Message-ID: <bq-TPJsBtB-pN8GFnuydtRPw9EaUpsUOLSqYMC940kY=.82d5dc33-8bd1-4dd2-aaf0-0a0c55f07140@github.com>

On Mon, 22 Jan 2024 21:26:41 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
>> 
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
>> 
>> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
>> 
>> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
>> ```c++
>>  jint init_globals() {
>>    management_init();
>>    JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> +  JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>> 
>> 
>> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb....
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Guard the feature with a diagnostic option and update the comments in the code

src/hotspot/share/runtime/init.cpp line 121:

> 119:   if (AlwaysRecordEvolDependencies) {
> 120:     JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
> 121:     JvmtiExport::set_all_dependencies_are_recorded(true);

I think the check for AlwaysRecordEvolDependencies needs to be moved into set_can_hotswap_or_post_breakpoint and set_all_dependencies_are_recorded, otherwise don't we risk the value being accidentally reset to false when set_can_hotswap_or_post_breakpoint() is called again by JvmtiManageCapabilities::update()?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1462685351

From sroy at openjdk.org  Tue Jan 23 05:34:32 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 23 Jan 2024 05:34:32 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v7]
In-Reply-To: <2sMyJ8mZ6EIULC67tK1IcI4uNnJMvpCzw1BKEDUaIms=.c90f1101-236e-4a80-869c-feca6abd3dc3@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <QnORwi8c5OCcUV51-xB91wPbXS-rGeJPEI4BxNMsBxc=.ac951d81-1db2-4549-abe0-025b99a1de4e@github.com>
 <_WrW-iHHdU-IgC7Z1b6oe_Qh0dkC6P3KJAdl7J2S1Do=.712dd065-6207-4632-a82f-8e12ad023cd5@github.com>
 <2sMyJ8mZ6EIULC67tK1IcI4uNnJMvpCzw1BKEDUaIms=.c90f1101-236e-4a80-869c-feca6abd3dc3@github.com>
Message-ID: <rHCEtTidcFLNX6MndD7073RPnOUWa6VPUJEwdtXrX7w=.72ed56b0-d8c7-4eef-86a0-8accb2de2eb7@github.com>

On Thu, 21 Dec 2023 10:01:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> > > What happens if we accidentally attempt to load a "real" static library, which is also named *.a? Would dlopen() then crash? What would happen?
>>> 
>>> > I don't think the problem is with *.a . They would load as the default behaviour of the dlopen. It is only when the dlopen fails for *.so , we give another chance to check for .a file with the same name.
>>> 
>>> No, what I meant, and what must be clarified before going forward with this solution, is the following:
>>> 
>>> * is _every_ `*.a` object on AIX loadable with `dlopen`, and will the result be the same as when loading a `*.so` object
>>> * or, if we present arbitrary `*.a` files to dlopen, is there a chance for dlopen to crash or misbehave.
>>> 
>>> Reason is that I was under the impression that *.a libraries are static libraries and cannot be loaded dynamically. This is what you now try to do.
>>> If we cannot safely answer this question, I would opt for a more narrow solution by hard-wiring known alternative names. So, do the second *.a attempt only for your `ibm_16_am.a` which you know works. That could also be done in a reasonably maintainable manner.
>>> 
>> In AIX, both static and dynamic libraries have *.a extension. And AIX also supports *.so files.Bascially shared objects in AIX have both *.a and *.so extension.  Hence we need to implement this logic.
>> If we try loading a static archive specifically ,how the dlopen would behave , that is something probably @JoKern65  can answer ? 
>> 
>> 
>>> > > Does this really have to be handled in the OpenJDK? What does J9 on AIX do? Could this be done in a simpler way outside OpenJDK, e.g. by providing an *.so variant of the library in question? Where does this library come from?
>>> 
>>> > I am not sure how J9 handles this. I would have to consult .
>>> 
>>> J9 is Open Source, can't you just look? :)
>> 
>> I did try comparing the file structures, and i do not see a similar file structure over there. 
>> I am unable to find the jvmTiAgent code and also os_aix file. So i am not sure which functions over there are doing the same functionality. You have any suggestion on how i can check and correlate ?  
>>> 
>>> > However as per current observation, this issue does not show up on Semuru. This issue is only happening on Adoptium. The team that release these file has always released *.a files which work fine for Semuru.
>>> 
>>> I don't know what Semuru is. What is the context, is that a different VM? Also OpenJDK? J9 derived? 
>> 
>> 
>> Semuru is J9 derived.
>
>> > > > What happens if we accidentally attempt to load a "real" static library, which is also named *.a? Would dlopen() then crash? What would happen?
>> > 
>> > 
>> > > I don't think the problem is with *.a . They would load as the default behaviour of the dlopen. It is only when the dlopen fails for *.so , we give another chance to check for .a file with the same name.
>> > 
>> > 
>> > No, what I meant, and what must be clarified before going forward with this solution, is the following:
>> > 
>> > * is _every_ `*.a` object on AIX loadable with `dlopen`, and will the result be the same as when loading a `*.so` object
>> > * or, if we present arbitrary `*.a` files to dlopen, is there a chance for dlopen to crash or misbehave.
>> > 
>> > Reason is that I was under the impression that *.a libraries are static libraries and cannot be loaded dynamically. This is what you now try to do.
>> > If we cannot safely answer this question, I would opt for a more narrow solution by hard-wiring known alternative names. So, do the second *.a attempt only for your `ibm_16_am.a` which you know works. That could also be done in a reasonably maintainable manner.
>> 
>> In AIX, both static and dynamic libraries have *.a extension. And AIX also supports *.so files.Bascially shared objects in AIX have both *.a and *.so extension. Hence we need to implement this logic. If we try loading a static archive specifically ,how the dlopen would behave , that is something probably @JoKern65 can answer ?
> 
> Rather, this is a question you have to ask your collegues at IBM that develop the AIX libc.
> 
> Since AIX libc is not open source, we cannot look for ourselves, nor can Joachim (her works at SAP).
> 
>> 
>> > > > Does this really have to be handled in the OpenJDK? What does J9 on AIX do? Could this be done in a simpler way outside OpenJDK, e.g. by providing an *.so variant of the library in question? Where does this library come from?
>> > 
>> > 
>> > > I am not sure how J9 handles this. I would have to consult .
>> > 
>> > 
>> > J9 is Open Source, can't you just look? :)
>> 
>> I did try comparing the file structures, and i do not see a similar file structure over there. I am unable to find the jvmTiAgent code and also os_aix file. So i am not sure which functions over there are doing the same functionality. You have any suggestion on how i can check and correlate ?
> 
> Someone must implement LoadLibrary. Try looking for places where dlopen() is called.
> 
>> 
>> > > However as per current observation, this issue does ...

Hi @tstuefe 
Any further clarifications ,required for this change ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1905320564

From sroy at openjdk.org  Tue Jan 23 05:34:33 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 23 Jan 2024 05:34:33 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v7]
In-Reply-To: <GJzTjModxYfQcXvgYlJA81odbT91iIwfkAyAGb2QvXo=.aa314f47-10a8-4573-b9d1-1a95a514a38f@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <QnORwi8c5OCcUV51-xB91wPbXS-rGeJPEI4BxNMsBxc=.ac951d81-1db2-4549-abe0-025b99a1de4e@github.com>
 <hX5s13YzFiPxFoyjZwvyq-prh2xRP8r-f5Rv_ZCFTyA=.a09e4c89-e74f-4f2e-88a7-6b967ce342a3@github.com>
 <GJzTjModxYfQcXvgYlJA81odbT91iIwfkAyAGb2QvXo=.aa314f47-10a8-4573-b9d1-1a95a514a38f@github.com>
Message-ID: <OnZwifOFjYOSs9LZNch3GwCXkO3ad2l6CeGnpMoFJaI=.58a8cd59-324d-4059-93b2-1e938bab2bc4@github.com>

On Tue, 16 Jan 2024 16:12:16 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > I have tried to build jextract (https://github.com/openjdk/jextract/tree/jdk22) with LLVM (https://github.com/llvm/llvm-project/releases/download/llvmorg-16.0.4/clang+llvm-16.0.4-powerpc64-ibm-aix-7.2.tar.xz). I noticed that llvm mainly consists of .a files. So, I think we need to support that for FFI compatibility with other libraries and open source projects.
> 
> Seems like this change is not sufficient for that. `clang` is compiled to `libclang.a` on AIX, but `libclang.so` on linux. I'm getting "System error: Exec format error" when trying to load `libclang.a` via `System.loadLibrary(libName);`. So the question remains: Are .a files really supposed to be dynamically loadable on AIX? If so, where is that documented?

Yes we have rhe case where .a files are dynamically loadable as well on AIX.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1905321150

From sgehwolf at openjdk.org  Tue Jan 23 09:45:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 23 Jan 2024 09:45:30 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v2]
In-Reply-To: <yhwpfIMqwuQ158zvVxkWSew3trCHzoulCcD5c57JGb4=.7b055d31-0863-4c61-9e47-a746e51eacb7@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
 <yhwpfIMqwuQ158zvVxkWSew3trCHzoulCcD5c57JGb4=.7b055d31-0863-4c61-9e47-a746e51eacb7@github.com>
Message-ID: <upACV4uWbUEt1pyRSTE3ieAy7fD4YEmyxl82WqT9WqI=.e551f527-fa63-408d-bc74-8fa877306d56@github.com>

On Tue, 23 Jan 2024 01:58:40 GMT, sendaoYan <duke at openjdk.org> wrote:

>> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>   
>   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

Looks fine now.

test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java line 75:

> 73:             long count = Metrics.systemMetrics().getMemoryFailCount();
> 74: 
> 75:             // Allocate 512M of data

Suggestion: Amend the comment to `Allocate 512M of data in 1M chunks per iteration`

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17514#pullrequestreview-1838306348
PR Review Comment: https://git.openjdk.org/jdk/pull/17514#discussion_r1462991886

From shade at openjdk.org  Tue Jan 23 10:11:30 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 Jan 2024 10:11:30 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
Message-ID: <9yE5_ZZtvuN0dMMV2HSztNLu4pbSSl6eVWeQHXf5Iqc=.20f2084e-d296-4994-95b0-e4e4ed528449@github.com>

On Mon, 22 Jan 2024 21:26:41 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
>> 
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
>> 
>> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
>> 
>> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
>> ```c++
>>  jint init_globals() {
>>    management_init();
>>    JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> +  JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>> 
>> 
>> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb....
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Guard the feature with a diagnostic option and update the comments in the code

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4078:

> 4076: void VM_RedefineClasses::flush_dependent_code() {
> 4077:   assert(SafepointSynchronize::is_at_safepoint(), "sanity check");
> 4078:   assert(AlwaysRecordEvolDependencies ? JvmtiExport::all_dependencies_are_recorded() : true, "sanity check");

This is just "assert all dependencies are recorded, unless we specifically requested not to do so", right?


assert(JvmtiExport::all_dependencies_are_recorded() || !AlwaysRecordEvolDependencies, "sanity check");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1463026061

From ayang at openjdk.org  Tue Jan 23 10:26:32 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 23 Jan 2024 10:26:32 GMT
Subject: RFR: 8324512: Serial: Remove Generation::Name
Message-ID: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>

Trivial removing redundant code.

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

Commit messages:
 - s1-enum

Changes: https://git.openjdk.org/jdk/pull/17530/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17530&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324512
  Stats: 66 lines in 9 files changed: 0 ins; 64 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17530/head:pull/17530

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

From duke at openjdk.org  Tue Jan 23 13:04:43 2024
From: duke at openjdk.org (sendaoYan)
Date: Tue, 23 Jan 2024 13:04:43 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v3]
In-Reply-To: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
Message-ID: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

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

  8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
  
  Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17514/files
  - new: https://git.openjdk.org/jdk/pull/17514/files/969b608d..d1eb4fac

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

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

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

From sgehwolf at openjdk.org  Tue Jan 23 13:15:27 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 23 Jan 2024 13:15:27 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v3]
In-Reply-To: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
 <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
Message-ID: <546Ycpctif9TFb7wOeHWUmaPsNSRL3N_skBeNZsjioU=.f969cf54-fdae-4aba-a6e3-4b073cab4faa@github.com>

On Tue, 23 Jan 2024 13:04:43 GMT, sendaoYan <duke at openjdk.org> wrote:

>> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>   
>   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

Marked as reviewed by sgehwolf (Reviewer).

Please enable GHA for your fork for future PRs.

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

PR Review: https://git.openjdk.org/jdk/pull/17514#pullrequestreview-1838761515
PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-1906034584

From duke at openjdk.org  Tue Jan 23 13:18:27 2024
From: duke at openjdk.org (sendaoYan)
Date: Tue, 23 Jan 2024 13:18:27 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v3]
In-Reply-To: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
 <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
Message-ID: <7rRKRaahK5RQ3AFiOVAbt3-zZxpCayg8JJF9tCfQfrM=.3bb7a366-e61f-4d4b-98de-4011fdc3a6e9@github.com>

On Tue, 23 Jan 2024 13:04:43 GMT, sendaoYan <duke at openjdk.org> wrote:

>> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>   
>   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

> GHA



> Please enable GHA for your fork for future PRs.

OK

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

PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-1906038625

From stefank at openjdk.org  Tue Jan 23 13:19:28 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 23 Jan 2024 13:19:28 GMT
Subject: RFR: 8324512: Serial: Remove Generation::Name
In-Reply-To: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
References: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
Message-ID: <WB7SJowplLVzf-xL-1aEzEX3L9HvaJ0RlmUAX5O2pL0=.284279f1-2cd7-4b45-b5ad-ad0dc543d89b@github.com>

On Tue, 23 Jan 2024 10:20:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing redundant code.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17530#pullrequestreview-1838769192

From duke at openjdk.org  Tue Jan 23 13:22:34 2024
From: duke at openjdk.org (sendaoYan)
Date: Tue, 23 Jan 2024 13:22:34 GMT
Subject: Integrated: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed
In-Reply-To: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
Message-ID: <zHxECVVzZwYzZtqYZCyE0wE2kDTidt141LB0ZPFFuck=.aa13576d-30e2-437f-8b0e-05ecf6a89720@github.com>

On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan <duke at openjdk.org> wrote:

> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

This pull request has now been integrated.

Changeset: 791b427f
Author:    sendaoYan <yansendao.ysd at alibaba-inc.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/791b427f4410057cdcdf8fd8ea0dcce71f7dc513
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

Reviewed-by: sgehwolf

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

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

From iwalulya at openjdk.org  Tue Jan 23 15:06:26 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 23 Jan 2024 15:06:26 GMT
Subject: RFR: 8324512: Serial: Remove Generation::Name
In-Reply-To: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
References: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
Message-ID: <aidvydjX--5Icrw3HNntXUJYXsleGD5jdV2GHQvojm0=.451090e5-54ce-406f-a753-0db5ecdd22c5@github.com>

On Tue, 23 Jan 2024 10:20:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing redundant code.

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17530#pullrequestreview-1839014944

From simonis at openjdk.org  Tue Jan 23 16:40:29 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 23 Jan 2024 16:40:29 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <bq-TPJsBtB-pN8GFnuydtRPw9EaUpsUOLSqYMC940kY=.82d5dc33-8bd1-4dd2-aaf0-0a0c55f07140@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
 <bq-TPJsBtB-pN8GFnuydtRPw9EaUpsUOLSqYMC940kY=.82d5dc33-8bd1-4dd2-aaf0-0a0c55f07140@github.com>
Message-ID: <ChDvOmT8at2omntVkKRA4jJWVbG2EnMBSqeP3z4P6uI=.ae8fc1e0-bbae-486e-9aef-8d1816ea2b36@github.com>

On Tue, 23 Jan 2024 03:31:59 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Guard the feature with a diagnostic option and update the comments in the code
>
> src/hotspot/share/runtime/init.cpp line 121:
> 
>> 119:   if (AlwaysRecordEvolDependencies) {
>> 120:     JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> 121:     JvmtiExport::set_all_dependencies_are_recorded(true);
> 
> I think the check for AlwaysRecordEvolDependencies needs to be moved into set_can_hotswap_or_post_breakpoint and set_all_dependencies_are_recorded, otherwise don't we risk the value being accidentally reset to false when set_can_hotswap_or_post_breakpoint() is called again by JvmtiManageCapabilities::update()?

A good question, but after deep digging (it took me quite some time to figure this out myself :) I don't think that `can_hotswap_or_post_breakpoint`/`all_dependencies_are_recorded` can ever be reset. Here's how it works:

- there's a global set of `always_capabilities` which is initialized when the first JVMTI environment is created:

// capabilities which are always potentially available
jvmtiCapabilities JvmtiManageCapabilities::always_capabilities;

void JvmtiManageCapabilities::initialize() {
  _capabilities_lock = new Mutex(Mutex::nosafepoint, "Capabilities_lock");
  always_capabilities = init_always_capabilities();


- as the name implies, this set of capabilities contains all generally available capabilities (except for the `onload` and `solo` capabilites, which are maintained in separate sets).
- `JvmtiManageCapabilities::update()` only operates on this global sets of capabilites (and *not* on the concrete capabilities of a specific JVMTI environment):

void JvmtiManageCapabilities::update() {
  jvmtiCapabilities avail;
  // all capabilities
  either(&always_capabilities, &always_solo_capabilities, &avail);
...
  // If can_redefine_classes is enabled in the onload phase then we know that the
  // dependency information recorded by the compiler is complete.
  if ((avail.can_redefine_classes || avail.can_retransform_classes) &&
      JvmtiEnv::get_phase() == JVMTI_PHASE_ONLOAD) {
    JvmtiExport::set_all_dependencies_are_recorded(true);
  }
...
  JvmtiExport::set_can_hotswap_or_post_breakpoint(
    avail.can_generate_breakpoint_events ||
    avail.can_redefine_classes ||
    avail.can_retransform_classes);

- This means that `JvmtiManageCapabilities::update()` is always conservative regarding its exports to `JvmtiExport` as it always exports *all* potentially available capabilites once a JVMTI environment is created and not only the specific capabilities requested by concrete JVMTI environment. This means that even if we create a JVMTI agent with an empty set of capabilities, `can_hotswap_or_post_breakpoint`/`all_dependencies_are_recorded` will still be set in `JvmtiExport`.
- There's no code path (at least I couldn't find one) which takes capabilities away from the `always_capabilities` set. Only if an environment requests `on_load` capabilities, they will be transferred from the global `onload_capabilities` to the `always_capabilities` set:

jvmtiError JvmtiManageCapabilities::add_capabilities(const jvmtiCapabilities *current,
                                                     const jvmtiCapabilities *prohibited,
                                                     const jvmtiCapabilities *desired,
                                                     jvmtiCapabilities *result) {
...
  // onload capabilities that got added are now permanent - so, also remove from onload
  both(&onload_capabilities, desired, &temp);
  either(&always_capabilities, &temp, &always_capabilities);
  exclude(&onload_capabilities, &temp, &onload_capabilities);


If you like I could put an assertion into `JvmtiExport::set_can_hotswap_or_post_breakpoint()` which verifies that `can_hotswap_or_post_breakpoint` never gets reset once it was set to `true`. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1463584725

From simonis at openjdk.org  Tue Jan 23 16:52:31 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 23 Jan 2024 16:52:31 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <9yE5_ZZtvuN0dMMV2HSztNLu4pbSSl6eVWeQHXf5Iqc=.20f2084e-d296-4994-95b0-e4e4ed528449@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
 <9yE5_ZZtvuN0dMMV2HSztNLu4pbSSl6eVWeQHXf5Iqc=.20f2084e-d296-4994-95b0-e4e4ed528449@github.com>
Message-ID: <YffXtyP2EwIruHhJ2-hoUXsOUWo5NGmBq68ypH0VdT0=.4a62ea24-8981-4108-884e-5c7a408cc6b9@github.com>

On Tue, 23 Jan 2024 10:06:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Guard the feature with a diagnostic option and update the comments in the code
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4078:
> 
>> 4076: void VM_RedefineClasses::flush_dependent_code() {
>> 4077:   assert(SafepointSynchronize::is_at_safepoint(), "sanity check");
>> 4078:   assert(AlwaysRecordEvolDependencies ? JvmtiExport::all_dependencies_are_recorded() : true, "sanity check");
> 
> This is just "assert all dependencies are recorded, unless we specifically requested not to do so", right?
> 
> 
> assert(JvmtiExport::all_dependencies_are_recorded() || !AlwaysRecordEvolDependencies, "sanity check");

Yes that's true (I must confess I had to use a truth table to verify it :) I'll take your version tough, because I thinks it's simpler to understand. Do you have other assertions in mind (also see my answer to Dean above)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1463608499

From cjplummer at openjdk.org  Tue Jan 23 17:46:27 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Jan 2024 17:46:27 GMT
Subject: RFR: 8324512: Serial: Remove Generation::Name
In-Reply-To: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
References: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
Message-ID: <Gqf-Hhzz8B9_GG1ulpLXUyeLMJjy2VCQCpcNjdFX_6w=.9f35598b-20a7-4b60-9adc-75e69d95348b@github.com>

On Tue, 23 Jan 2024 10:20:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing redundant code.

SA changes look good to me.

Copyrights still need updating in a few files.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17530#pullrequestreview-1839481177

From simonis at openjdk.org  Tue Jan 23 18:27:30 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 23 Jan 2024 18:27:30 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <GVLetexwDFn2BeX7cOT5zDeGPcGXHNmvfiQO76YN7Pg=.14ac92bc-0464-4840-86c5-82f79e421b64@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
 <7YLjZUNrhGYSma_Hop1JnZWj75lytQMnXczCP5JSQQc=.7da0a1c2-423f-4144-be20-2aa3707ce332@github.com>
 <GVLetexwDFn2BeX7cOT5zDeGPcGXHNmvfiQO76YN7Pg=.14ac92bc-0464-4840-86c5-82f79e421b64@github.com>
Message-ID: <OiL8KReW9rIxqCJgP0pXMaKQo8elQgXcDJh71_hYea8=.3f671583-9f04-431c-9c2f-54be028b8035@github.com>

On Mon, 22 Jan 2024 23:38:40 GMT, John R Rose <jrose at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 2014:
>> 
>>> 2012:                                                                             \
>>> 2013:   product(bool, AlwaysRecordEvolDependencies, true, DIAGNOSTIC,             \
>>> 2014:                 "Unconditionally record method dependencies on class "      \
>> 
>> "... record compiled method dependencies ..."?
>
> (yes, ?compiled methods? or even ?nmethods?, or ?methods in code cache?)

Thanks.  I went with "nmethods" because it's the shortest alternative :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1463767652

From ayang at openjdk.org  Tue Jan 23 18:37:45 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 23 Jan 2024 18:37:45 GMT
Subject: RFR: 8324512: Serial: Remove Generation::Name [v2]
In-Reply-To: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
References: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
Message-ID: <81gkky88Q9P2sYNK2Rneht66RQ-7aXj4Bcc0gbTVqvo=.8687ed7d-1b81-411e-bb28-364c4518e6be@github.com>

> Trivial removing redundant code.

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17530/files
  - new: https://git.openjdk.org/jdk/pull/17530/files/fd278ec6..6fc1a6c3

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

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17530/head:pull/17530

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

From simonis at openjdk.org  Tue Jan 23 19:00:51 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 23 Jan 2024 19:00:51 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v3]
In-Reply-To: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
Message-ID: <x6i_d3BOYQ4fwbS2v4PqYLp7lZ5r2tZGeXbekOfGTBc=.4143fa60-c8e2-4195-ab1d-0a8107f8436c@github.com>

> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
> 
> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
> 
> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
> 
> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
> ```c++
>  jint init_globals() {
>    management_init();
>    JvmtiExport::initialize_oop_storage();
> +#if INCLUDE_JVMTI
> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
> +  JvmtiExport::set_all_dependencies_are_recorded(true);
> +#endif
> 
> 
> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb. The ration remains about the same i...

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Updated option description and assertion based on review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17509/files
  - new: https://git.openjdk.org/jdk/pull/17509/files/6d3e24ab..7b750da5

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17509/head:pull/17509

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

From eastigeevich at openjdk.org  Tue Jan 23 19:49:28 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 23 Jan 2024 19:49:28 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v3]
In-Reply-To: <x6i_d3BOYQ4fwbS2v4PqYLp7lZ5r2tZGeXbekOfGTBc=.4143fa60-c8e2-4195-ab1d-0a8107f8436c@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <x6i_d3BOYQ4fwbS2v4PqYLp7lZ5r2tZGeXbekOfGTBc=.4143fa60-c8e2-4195-ab1d-0a8107f8436c@github.com>
Message-ID: <Fbe2EQJA4PWQ8y1b6CeB6S6BawG7V9-ASc5t8o5grzQ=.07669460-9230-40cf-bab3-16f4654b5122@github.com>

On Tue, 23 Jan 2024 19:00:51 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
>> 
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
>> 
>> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
>> 
>> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
>> ```c++
>>  jint init_globals() {
>>    management_init();
>>    JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> +  JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>> 
>> 
>> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb....
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated option description and assertion based on review feedback

lgtm

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

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17509#pullrequestreview-1839792795

From vlivanov at openjdk.org  Tue Jan 23 20:00:29 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 23 Jan 2024 20:00:29 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v3]
In-Reply-To: <x6i_d3BOYQ4fwbS2v4PqYLp7lZ5r2tZGeXbekOfGTBc=.4143fa60-c8e2-4195-ab1d-0a8107f8436c@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <x6i_d3BOYQ4fwbS2v4PqYLp7lZ5r2tZGeXbekOfGTBc=.4143fa60-c8e2-4195-ab1d-0a8107f8436c@github.com>
Message-ID: <vS3Xl7CkQgA-D9pHSObD7gIXKGo6KSMj1PmWYi1TEZY=.f4add870-5bab-4fe7-863c-92a3d10c340d@github.com>

On Tue, 23 Jan 2024 19:00:51 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
>> 
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
>> 
>> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
>> 
>> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
>> ```c++
>>  jint init_globals() {
>>    management_init();
>>    JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> +  JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>> 
>> 
>> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb....
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated option description and assertion based on review feedback

I support keeping the logic under a flag. I have some concerns about unconditionally turning it on. 

I expect significantly higher footprint overhead when an application has plenty of tiny methods and deep inlining trees. And java.lang.invoke implementation pushes it even further (with arbitrarily deep MethodHandle trees and unconditional inlining through them), so heavy users of MethodHandle API should experience higher overheads when evol dependencies are recorded.

I suggest to make the flag experimental. Once JFR implementation is improved, it can be superseded by `-XX:+EnableDynamicAgentLoading` check.

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

PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-1906824455

From cjplummer at openjdk.org  Tue Jan 23 20:36:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Jan 2024 20:36:36 GMT
Subject: RFR: 8323546: Cleanup jcmd docs for Compiler.perfmap and VM.cds
 filename parameter [v6]
In-Reply-To: <B5809zKUvr7NFfUyHXMG7zw1em4P5GoLTZ8NJFtAgOw=.96257598-34cc-4d57-8158-890e8555e951@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
 <B5809zKUvr7NFfUyHXMG7zw1em4P5GoLTZ8NJFtAgOw=.96257598-34cc-4d57-8158-890e8555e951@github.com>
Message-ID: <k6yS1nlhUh12VuAhNJMQhhkYCu-H0P496X7BmcMJpQg=.66bc9de8-729c-476b-b792-d03d04d07e90@github.com>

On Wed, 17 Jan 2024 02:26:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The jcmd docs for Compiler.perfmap currently say:
>> 
>>     - *filename*: (Optional) The name of the map file (STRING, no default value)
>> 
>> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
>> 
>> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
>> 
>> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
>> 
>>     *arguments*:
>> 
>>     - *flag name*: The name of the flag that you want to set (STRING, no
>>         default value)
>> 
>>     - *string value*: (Optional) The value that you want to set (STRING, no
>>         default value)
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Get rid of extra empty line.
>  - Remove quotes from around filename to be consistent with how jcmd STRING defaults are printed.

Thanks for the reviews David, Ioi, and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/17359#issuecomment-1906873073

From cjplummer at openjdk.org  Tue Jan 23 20:36:38 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Jan 2024 20:36:38 GMT
Subject: Integrated: 8323546: Cleanup jcmd docs for Compiler.perfmap and VM.cds
 filename parameter
In-Reply-To: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
References: <H8tIvzANrmcmVLjI3ifBq5Vk7Pyia6wX5nWOo3n8iec=.04a27880-49c7-4807-88f8-e6c9aae69312@github.com>
Message-ID: <ZbxySdCFD4ug6M7PXdS-6UtSOppMkRVHSN4FeLyg8tM=.77b52a63-030a-4c30-88f4-50eb22a38217@github.com>

On Wed, 10 Jan 2024 21:40:08 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The jcmd docs for Compiler.perfmap currently say:
> 
>     - *filename*: (Optional) The name of the map file (STRING, no default value)
> 
> However, there is a default, so not only should that be made more clear in the above, but also some descriptive text as to how the default is generated should be added.
> 
> VM.cds has a similar issue, but already has the descriptive text, so just the "no default value" part needs to be fixed.
> 
> Another change needed is to consistently use *filename* (italics) instead of `filename` (monospace). Note this is how html formatting is done. For the man page formatting, *filename* does no formatting and `filename` is displayed in color if supported. Personally I prefer `filename`, but it seems that there is already a strong precedence for using italics in the *arguments* list. For example:
> 
>     *arguments*:
> 
>     - *flag name*: The name of the flag that you want to set (STRING, no
>         default value)
> 
>     - *string value*: (Optional) The value that you want to set (STRING, no
>         default value)

This pull request has now been integrated.

Changeset: edfee7f3
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edfee7f348349cfa55a9acd92d3bbd9e0cd4f07f
Stats:     40 lines in 3 files changed: 28 ins; 0 del; 12 mod

8323546: Cleanup jcmd docs for Compiler.perfmap and VM.cds filename parameter

Reviewed-by: dholmes, sspitsyn, iklam

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

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

From dlong at openjdk.org  Tue Jan 23 23:39:26 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 23 Jan 2024 23:39:26 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <ChDvOmT8at2omntVkKRA4jJWVbG2EnMBSqeP3z4P6uI=.ae8fc1e0-bbae-486e-9aef-8d1816ea2b36@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
 <bq-TPJsBtB-pN8GFnuydtRPw9EaUpsUOLSqYMC940kY=.82d5dc33-8bd1-4dd2-aaf0-0a0c55f07140@github.com>
 <ChDvOmT8at2omntVkKRA4jJWVbG2EnMBSqeP3z4P6uI=.ae8fc1e0-bbae-486e-9aef-8d1816ea2b36@github.com>
Message-ID: <95WlbkH5Kqt53YrRttF5wzO8vjpZbJPetFlVEOR9Q-s=.8f6d6359-9705-457b-bb13-4621f1bb3b1d@github.com>

On Tue, 23 Jan 2024 16:37:35 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> src/hotspot/share/runtime/init.cpp line 121:
>> 
>>> 119:   if (AlwaysRecordEvolDependencies) {
>>> 120:     JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>>> 121:     JvmtiExport::set_all_dependencies_are_recorded(true);
>> 
>> I think the check for AlwaysRecordEvolDependencies needs to be moved into set_can_hotswap_or_post_breakpoint and set_all_dependencies_are_recorded, otherwise don't we risk the value being accidentally reset to false when set_can_hotswap_or_post_breakpoint() is called again by JvmtiManageCapabilities::update()?
>
> A good question, but after deep digging (it took me quite some time to figure this out myself :) I don't think that `can_hotswap_or_post_breakpoint`/`all_dependencies_are_recorded` can ever be reset. Here's how it works:
> 
> - there's a global set of `always_capabilities` which is initialized when the first JVMTI environment is created:
> 
> // capabilities which are always potentially available
> jvmtiCapabilities JvmtiManageCapabilities::always_capabilities;
> 
> void JvmtiManageCapabilities::initialize() {
>   _capabilities_lock = new Mutex(Mutex::nosafepoint, "Capabilities_lock");
>   always_capabilities = init_always_capabilities();
> 
> 
> - as the name implies, this set of capabilities contains all generally available capabilities (except for the `onload` and `solo` capabilites, which are maintained in separate sets).
> - `JvmtiManageCapabilities::update()` only operates on this global sets of capabilites (and *not* on the concrete capabilities of a specific JVMTI environment):
> 
> void JvmtiManageCapabilities::update() {
>   jvmtiCapabilities avail;
>   // all capabilities
>   either(&always_capabilities, &always_solo_capabilities, &avail);
> ...
>   // If can_redefine_classes is enabled in the onload phase then we know that the
>   // dependency information recorded by the compiler is complete.
>   if ((avail.can_redefine_classes || avail.can_retransform_classes) &&
>       JvmtiEnv::get_phase() == JVMTI_PHASE_ONLOAD) {
>     JvmtiExport::set_all_dependencies_are_recorded(true);
>   }
> ...
>   JvmtiExport::set_can_hotswap_or_post_breakpoint(
>     avail.can_generate_breakpoint_events ||
>     avail.can_redefine_classes ||
>     avail.can_retransform_classes);
> 
> - This means that `JvmtiManageCapabilities::update()` is always conservative regarding its exports to `JvmtiExport` as it always exports *all* potentially available capabilites once a JVMTI environment is created and not only the specific capabilities requested by concrete JVMTI environment. This means that even if we create a JVMTI agent with an empty set of capabilities, `can_hotswap_or_post_breakpoint`/`all_dependencies_are_recorded` will still be set in `JvmtiExport`.
> - There's no code path (at least I couldn't find one) which takes capabilities away from the `always_capabilities` set. Only if an environment requests `on_load` capabilities, they will be transferred from the global `onload_capabilities` to the `always_capabilities` set:
> 
> jvmtiError JvmtiManageCapabilities::add_capabilities(const jvmtiCapabilities *current,
>                      ...

An assert works for me.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1464120039

From lmesnik at openjdk.org  Wed Jan 24 02:47:33 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 24 Jan 2024 02:47:33 GMT
Subject: RFR: 8324582: Replace
 -Djava.util.concurrent.ForkJoinPool.common.parallelism to
 -Djdk.virtualThreadScheduler.parallelism in jvmti vthread tests
Message-ID: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>

Some jvmti tests use
-Djava.util.concurrent.ForkJoinPool.common.parallelism
to control the pool of virtual threads. However, it is controlled by
jdk.virtualThreadScheduler.parallelism property.

The non-continuations implementation doesn't use any of these properties and it was just deleted.

I verified the fix using jcmd Thread.dump and ran all jvmti tests in the default configuration.

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

Commit messages:
 - 8324582: Replace -Djava.util.concurrent.ForkJoinPool.common.parallelism to -Djdk.virtualThreadScheduler.parallelism in jvmti vthread tests

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

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

From mdoerr at openjdk.org  Wed Jan 24 04:00:35 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 24 Jan 2024 04:00:35 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v9]
In-Reply-To: <bc_wdOVEpiUqCq4hExhn7Otl3-6XZWm92RgRPqVwTC4=.e1bced71-47f2-4708-b234-f95f1c37cf85@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <bc_wdOVEpiUqCq4hExhn7Otl3-6XZWm92RgRPqVwTC4=.e1bced71-47f2-4708-b234-f95f1c37cf85@github.com>
Message-ID: <uMNvY_DO0L4qCtTLQ3BFC_UaRc3iRxxnBVKNeWSzvDk=.f8319534-4fb3-45c2-ad12-c0e88a317484@github.com>

On Tue, 16 Jan 2024 08:36:49 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update porting_aix.cpp
>  - Update porting_aix.cpp
>  - Update os_aix.cpp

Regarding `libclang.a`, Joachim told me that we would need to load `libclang.a(libclang.so.16)`. So that's a different issue which relates to `System.loadLibrary(libName)` (https://bugs.openjdk.org/browse/JDK-8319516) and not to this hotspot internal issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1907311369

From stuefe at openjdk.org  Wed Jan 24 07:33:32 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 24 Jan 2024 07:33:32 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v9]
In-Reply-To: <bc_wdOVEpiUqCq4hExhn7Otl3-6XZWm92RgRPqVwTC4=.e1bced71-47f2-4708-b234-f95f1c37cf85@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <bc_wdOVEpiUqCq4hExhn7Otl3-6XZWm92RgRPqVwTC4=.e1bced71-47f2-4708-b234-f95f1c37cf85@github.com>
Message-ID: <e4tUkrhF8ChHYsZraVh-bxYYfZgsHR3aOwN9jVttbSk=.52bd11a4-b049-42a4-99ad-8c801d6f2084@github.com>

On Tue, 16 Jan 2024 08:36:49 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update porting_aix.cpp
>  - Update porting_aix.cpp
>  - Update os_aix.cpp

For me the unresolved question is still:
- do we want an unconditional load of *.a for a given *.so (have yet to see any documentation for this a-file duality)
- if we do, do we want that to be bidirectional? Someone specifies *.a, do we want to attempt to load *.so?

When in doubt, we should just mimic what OpenJ9 is doing on AIX. But I would like a clear documentation as a comment in os_aix.cpp explaining the logic and referencing the relevant OpenJ9 files.

There are some minor issues with the code itself, but I will defer reviewing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1907550400

From aph at openjdk.org  Wed Jan 24 09:31:28 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 24 Jan 2024 09:31:28 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
Message-ID: <POaFoSfp8uLeUyTfDSbWMJS6_b6m_C7wgKkPA32LQrQ=.c7e1404f-5585-457f-9bd6-5d7dbbdbfd84@github.com>

On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
> 
> Contributed by Chuck Rasbold and @jianglizhou.

> > I think you should be able to use ld and objcopy to merge the .o files and hide all of the symbols you don't want to export.
> 
> We also discussed about `objcopy` in [#14808 (comment)](https://github.com/openjdk/jdk/pull/14808#issuecomment-1631597197) and [#14808 (comment)](https://github.com/openjdk/jdk/pull/14808#issuecomment-1631611220). My main concern was the portability of `objcopy` approach.

I replied:

OK, but it is the right thing to do on Linux. If some other operating systems don't provide useful tools, that's on them.
I haven't checked, but I strongly suspect that LLVM can do it too, so all that remains is Windows, and maybe they can't have static linking (or maybe they have to use something like this PR) until the right tooling is provided.

If Windows really can't do it, that's no reason to burden systems that can. Namespaces are not a low-cost solution for developers.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1907730900

From ayang at openjdk.org  Wed Jan 24 10:05:36 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 24 Jan 2024 10:05:36 GMT
Subject: RFR: 8324512: Serial: Remove Generation::Name [v2]
In-Reply-To: <81gkky88Q9P2sYNK2Rneht66RQ-7aXj4Bcc0gbTVqvo=.8687ed7d-1b81-411e-bb28-364c4518e6be@github.com>
References: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
 <81gkky88Q9P2sYNK2Rneht66RQ-7aXj4Bcc0gbTVqvo=.8687ed7d-1b81-411e-bb28-364c4518e6be@github.com>
Message-ID: <_gjWC4zGGtFirBXsQqGp6Y8TfgYBWH_utdEQLKscEaI=.38e6841d-42c7-4ab9-bc0f-cf0fb5bde853@github.com>

On Tue, 23 Jan 2024 18:37:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Trivial removing redundant code.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   year

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17530#issuecomment-1907796915

From ayang at openjdk.org  Wed Jan 24 10:05:38 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 24 Jan 2024 10:05:38 GMT
Subject: Integrated: 8324512: Serial: Remove Generation::Name
In-Reply-To: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
References: <0TYkcTugwZN9ibPR85aJZyR47EWlIIBu6I1Z_LIjDcE=.8da28aec-687f-4b9b-97b4-a82b2f9311bd@github.com>
Message-ID: <uxdCaW70oupiKRUOrlnveelR1r6TanpvWl8utd7hmQI=.2a44d277-d1c0-430e-8021-4399491fd50a@github.com>

On Tue, 23 Jan 2024 10:20:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing redundant code.

This pull request has now been integrated.

Changeset: 1c1cb048
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c1cb048cd7820042373f5d8a9f41fb30d9cef6e
Stats:     72 lines in 9 files changed: 0 ins; 64 del; 8 mod

8324512: Serial: Remove Generation::Name

Reviewed-by: stefank, iwalulya, cjplummer

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

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

From simonis at openjdk.org  Wed Jan 24 10:13:29 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 24 Jan 2024 10:13:29 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v2]
In-Reply-To: <95WlbkH5Kqt53YrRttF5wzO8vjpZbJPetFlVEOR9Q-s=.8f6d6359-9705-457b-bb13-4621f1bb3b1d@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <uDZqWU0wZS_beWEE4BAl60bnIrEnG6-QlwB3lYPYFZk=.4ce6edf7-9551-4e5d-b1ff-b698e8bf3b80@github.com>
 <bq-TPJsBtB-pN8GFnuydtRPw9EaUpsUOLSqYMC940kY=.82d5dc33-8bd1-4dd2-aaf0-0a0c55f07140@github.com>
 <ChDvOmT8at2omntVkKRA4jJWVbG2EnMBSqeP3z4P6uI=.ae8fc1e0-bbae-486e-9aef-8d1816ea2b36@github.com>
 <95WlbkH5Kqt53YrRttF5wzO8vjpZbJPetFlVEOR9Q-s=.8f6d6359-9705-457b-bb13-4621f1bb3b1d@github.com>
Message-ID: <N3Z0c0Gx3a1xGrRjDMCWh7hKGGYKoqCeNNZQohiJ1qk=.5d52d600-fc22-4e5c-8303-044b0c88a063@github.com>

On Tue, 23 Jan 2024 23:36:37 GMT, Dean Long <dlong at openjdk.org> wrote:

>> A good question, but after deep digging (it took me quite some time to figure this out myself :) I don't think that `can_hotswap_or_post_breakpoint`/`all_dependencies_are_recorded` can ever be reset. Here's how it works:
>> 
>> - there's a global set of `always_capabilities` which is initialized when the first JVMTI environment is created:
>> 
>> // capabilities which are always potentially available
>> jvmtiCapabilities JvmtiManageCapabilities::always_capabilities;
>> 
>> void JvmtiManageCapabilities::initialize() {
>>   _capabilities_lock = new Mutex(Mutex::nosafepoint, "Capabilities_lock");
>>   always_capabilities = init_always_capabilities();
>> 
>> 
>> - as the name implies, this set of capabilities contains all generally available capabilities (except for the `onload` and `solo` capabilites, which are maintained in separate sets).
>> - `JvmtiManageCapabilities::update()` only operates on this global sets of capabilites (and *not* on the concrete capabilities of a specific JVMTI environment):
>> 
>> void JvmtiManageCapabilities::update() {
>>   jvmtiCapabilities avail;
>>   // all capabilities
>>   either(&always_capabilities, &always_solo_capabilities, &avail);
>> ...
>>   // If can_redefine_classes is enabled in the onload phase then we know that the
>>   // dependency information recorded by the compiler is complete.
>>   if ((avail.can_redefine_classes || avail.can_retransform_classes) &&
>>       JvmtiEnv::get_phase() == JVMTI_PHASE_ONLOAD) {
>>     JvmtiExport::set_all_dependencies_are_recorded(true);
>>   }
>> ...
>>   JvmtiExport::set_can_hotswap_or_post_breakpoint(
>>     avail.can_generate_breakpoint_events ||
>>     avail.can_redefine_classes ||
>>     avail.can_retransform_classes);
>> 
>> - This means that `JvmtiManageCapabilities::update()` is always conservative regarding its exports to `JvmtiExport` as it always exports *all* potentially available capabilites once a JVMTI environment is created and not only the specific capabilities requested by concrete JVMTI environment. This means that even if we create a JVMTI agent with an empty set of capabilities, `can_hotswap_or_post_breakpoint`/`all_dependencies_are_recorded` will still be set in `JvmtiExport`.
>> - There's no code path (at least I couldn't find one) which takes capabilities away from the `always_capabilities` set. Only if an environment requests `on_load` capabilities, they will be transferred from the global `onload_capabilities` to the `always_capabilities` set:
>> 
>> jvmtiError JvmtiManageCapabilities::...
>
> An assert works for me.  Thanks.

Added assert in `JvmtiExport::set_can_hotswap_or_post_breakpoint()`. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1464670162

From kevinw at openjdk.org  Wed Jan 24 10:18:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 24 Jan 2024 10:18:28 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v2]
In-Reply-To: <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
Message-ID: <lzj3GDYn6WofHZxCahS8Z4KTV50EDagub4Pw4NnwhfQ=.bf553691-a22b-4299-9d28-6a64f8330345@github.com>

On Thu, 18 Jan 2024 16:19:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
>> 
>> 
>> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
>> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
>> 
>> 
>> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
>> 
>> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
>> 
>> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
>> 
>> The same changes are also being made to "clhsdb pstack".
>> 
>> Tested with all tier1, tier2, and tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update clhsdb docs
>  - update clhsdb docs

test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.java line 73:

> 71:                         }
> 72:                     }
> 73:                     if (addressString != null)

Did we break already, is this if not needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17479#discussion_r1464678290

From kevinw at openjdk.org  Wed Jan 24 10:39:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 24 Jan 2024 10:39:28 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v2]
In-Reply-To: <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
Message-ID: <XtvlPFwIgLBUR1Lk494I3jWZHnmJznyH1YDQZQYWcFM=.555b5d20-1bdf-4ab8-bfdb-5943ce56027e@github.com>

On Thu, 18 Jan 2024 16:19:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
>> 
>> 
>> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
>> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
>> 
>> 
>> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
>> 
>> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
>> 
>> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
>> 
>> The same changes are also being made to "clhsdb pstack".
>> 
>> Tested with all tier1, tier2, and tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update clhsdb docs
>  - update clhsdb docs

Looks good to me, I agree with the consistency and not  giving users the possibly long/slow operation unless requested. (Unless or until we have a fast method for this.)

Marked as reviewed by kevinw (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17479#pullrequestreview-1841051405
PR Review: https://git.openjdk.org/jdk/pull/17479#pullrequestreview-1841054141

From alanb at openjdk.org  Wed Jan 24 12:25:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Jan 2024 12:25:30 GMT
Subject: RFR: 8324582: Replace
 -Djava.util.concurrent.ForkJoinPool.common.parallelism to
 -Djdk.virtualThreadScheduler.parallelism in jvmti vthread tests
In-Reply-To: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
References: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
Message-ID: <0WTVa4k7Y1KfoXBsZumBIDF5Y4GH5wEmwQJGdrSh0js=.1635c681-bc4c-4508-bb84-a6624473e048@github.com>

On Wed, 24 Jan 2024 02:42:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Some jvmti tests use
> -Djava.util.concurrent.ForkJoinPool.common.parallelism
> to control the pool of virtual threads. However, it is controlled by
> jdk.virtualThreadScheduler.parallelism property.
> 
> The non-continuations implementation doesn't use any of these properties and it was just deleted.
> 
> I verified the fix using jcmd Thread.dump and ran all jvmti tests in the default configuration.

test/hotspot/jtreg/serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java line 42:

> 40:  * @library /test/lib
> 41:  * @compile allthr01.java
> 42:  * @run main/othervm/native -Djdk.virtualThreadScheduler.parallelism=1 -agentlib:allthr01 allthr01

Some operations temporarily increase the parallelism, I suspect you really want maxPoolSize=1 in these tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17547#discussion_r1464837680

From simonis at openjdk.org  Wed Jan 24 14:48:52 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 24 Jan 2024 14:48:52 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v4]
In-Reply-To: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
Message-ID: <RzaFrzY1VzoCAjvzGFV-DMzBDcnJs6lY44vhBGCJjIg=.c6488699-1208-458f-9a20-9e60d1fda74c@github.com>

> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
> 
> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
> 
> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
> 
> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
> ```c++
>  jint init_globals() {
>    management_init();
>    JvmtiExport::initialize_oop_storage();
> +#if INCLUDE_JVMTI
> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
> +  JvmtiExport::set_all_dependencies_are_recorded(true);
> +#endif
> 
> 
> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb. The ration remains about the same i...

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Made the flag experimental and added an assertion to set_can_hotswap_or_post_breakpoint()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17509/files
  - new: https://git.openjdk.org/jdk/pull/17509/files/7b750da5..29966635

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17509&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17509&range=02-03

  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17509/head:pull/17509

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

From cjplummer at openjdk.org  Wed Jan 24 19:28:31 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Jan 2024 19:28:31 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v2]
In-Reply-To: <lzj3GDYn6WofHZxCahS8Z4KTV50EDagub4Pw4NnwhfQ=.bf553691-a22b-4299-9d28-6a64f8330345@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
 <lzj3GDYn6WofHZxCahS8Z4KTV50EDagub4Pw4NnwhfQ=.bf553691-a22b-4299-9d28-6a64f8330345@github.com>
Message-ID: <QRyy21IvC3fq6SCpYvZJUeJwj72WTd2Wf8ybWCzWbgk=.3cc0d79b-3985-4b0f-ba72-5821dc460fa4@github.com>

On Wed, 24 Jan 2024 10:15:52 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update clhsdb docs
>>  - update clhsdb docs
>
> test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.java line 73:
> 
>> 71:                         }
>> 72:                     }
>> 73:                     if (addressString != null)
> 
> Did we break already, is this if not needed?

There are two nested loops. If we did not break out of the inner loop (which is scanning words in the given line),  then addressString might still be null and we need to search the next line. If we don't do this check and break here, then we will always search the next line even if addressString was found.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17479#discussion_r1465416304

From cjplummer at openjdk.org  Wed Jan 24 19:30:27 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Jan 2024 19:30:27 GMT
Subject: RFR: 8324582: Replace
 -Djava.util.concurrent.ForkJoinPool.common.parallelism to
 -Djdk.virtualThreadScheduler.parallelism in jvmti vthread tests
In-Reply-To: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
References: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
Message-ID: <M8nndQykWATvcZhiantauEnFmKz1MONmztjRIyIiQRc=.b2b2e614-6a07-48e8-849f-5bc766cee05e@github.com>

On Wed, 24 Jan 2024 02:42:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Some jvmti tests use
> -Djava.util.concurrent.ForkJoinPool.common.parallelism
> to control the pool of virtual threads. However, it is controlled by
> jdk.virtualThreadScheduler.parallelism property.
> 
> The non-continuations implementation doesn't use any of these properties and it was just deleted.
> 
> I verified the fix using jcmd Thread.dump and ran all jvmti tests in the default configuration.

test/hotspot/jtreg/serviceability/jvmti/thread/GetAllThreads/allthr01/liballthr01.cpp line 49:

> 47: static const char thread1_name[] = "thread1";
> 48: static const char sys_thread_name[] = "SysThread";
> 49: // Tes uses -Djdk.virtualThreadScheduler.parallelism=1

Maybe you can also fix the typo: Tes -> Test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17547#discussion_r1465440169

From lmesnik at openjdk.org  Wed Jan 24 20:21:39 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 24 Jan 2024 20:21:39 GMT
Subject: RFR: 8324582: Replace
 -Djava.util.concurrent.ForkJoinPool.common.parallelism to
 -Djdk.virtualThreadScheduler.maxPoolSize/parallelism in jvmti vthread tests
 [v2]
In-Reply-To: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
References: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
Message-ID: <HM50y5HM8CuDMQdI0kPXe1qZ6uJsDIWfWj94B91Gfqk=.ad058437-f040-4581-bf6b-9167dc76b17d@github.com>

> Some jvmti tests use
> -Djava.util.concurrent.ForkJoinPool.common.parallelism
> to control the pool of virtual threads. However, it is controlled by
> jdk.virtualThreadScheduler.parallelism property.
> 
> The non-continuations implementation doesn't use any of these properties and it was just deleted.
> 
> I verified the fix using jcmd Thread.dump and ran all jvmti tests in the default configuration.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17547/files
  - new: https://git.openjdk.org/jdk/pull/17547/files/6e034511..af0ceb3f

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

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17547.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17547/head:pull/17547

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

From cjplummer at openjdk.org  Wed Jan 24 20:45:26 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Jan 2024 20:45:26 GMT
Subject: RFR: 8324582: Replace
 -Djava.util.concurrent.ForkJoinPool.common.parallelism to
 -Djdk.virtualThreadScheduler.maxPoolSize/parallelism in jvmti vthread tests
 [v2]
In-Reply-To: <HM50y5HM8CuDMQdI0kPXe1qZ6uJsDIWfWj94B91Gfqk=.ad058437-f040-4581-bf6b-9167dc76b17d@github.com>
References: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
 <HM50y5HM8CuDMQdI0kPXe1qZ6uJsDIWfWj94B91Gfqk=.ad058437-f040-4581-bf6b-9167dc76b17d@github.com>
Message-ID: <huhJQ9z_kUxK63PsjAEL-PMRH-KJGmvssCdGVg8gHO8=.8262882e-9148-4974-8f4f-79bbd225ff0e@github.com>

On Wed, 24 Jan 2024 20:21:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some jvmti tests use
>> -Djava.util.concurrent.ForkJoinPool.common.parallelism
>> to control the pool of virtual threads. However, it is controlled by
>> jdk.virtualThreadScheduler.parallelism property.
>> 
>> The non-continuations implementation doesn't use any of these properties and it was just deleted.
>> 
>> I verified the fix using jcmd Thread.dump and ran all jvmti tests in the default configuration.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed.

VThreadStackRefTest.java and VThreadInHeapDump.java need copyright updates. Otherwise the changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17547#pullrequestreview-1842335010

From lmesnik at openjdk.org  Wed Jan 24 21:01:37 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 24 Jan 2024 21:01:37 GMT
Subject: RFR: 8324582: Replace
 -Djava.util.concurrent.ForkJoinPool.common.parallelism to
 -Djdk.virtualThreadScheduler.maxPoolSize/parallelism in jvmti vthread tests
 [v3]
In-Reply-To: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
References: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
Message-ID: <r3PytRKWoFaZADxvyhzRPZ62BGSOo3aU_bCsukTus_I=.8947cb36-a972-4dc4-9ef2-786e7a972389@github.com>

> Some jvmti tests use
> -Djava.util.concurrent.ForkJoinPool.common.parallelism
> to control the pool of virtual threads. However, it is controlled by
> jdk.virtualThreadScheduler.parallelism property.
> 
> The non-continuations implementation doesn't use any of these properties and it was just deleted.
> 
> I verified the fix using jcmd Thread.dump and ran all jvmti tests in the default configuration.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  update copyrights years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17547/files
  - new: https://git.openjdk.org/jdk/pull/17547/files/af0ceb3f..0f608fe5

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

  Stats: 4 lines in 3 files changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17547.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17547/head:pull/17547

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

From kirk.pepperdine at gmail.com  Wed Jan 24 21:19:55 2024
From: kirk.pepperdine at gmail.com (Kirk Pepperdine)
Date: Wed, 24 Jan 2024 22:19:55 +0100
Subject: hprof 1.1
Message-ID: <9C36DE44-D8A7-4CFB-B9B6-4F459F9AEC4C@gmail.com>

Hi all,

I was looking for a more recent version of the hprof documentation and it looks like the last version of that doc is with JDK 8. This doc acts as a spec for the file format for heap dumps (as well as the format for for execution and heap profiler output). 

Question, is this document an OpenJDK specification and if not, should it be one? If it is a spec should it live some where outside of a specific release? Is this a JSR or a JEP?

https://docs.oracle.com/javase/8/docs/technotes/samples/hprof.html

Kind regards,
Kirk




From chris.plummer at oracle.com  Wed Jan 24 21:47:04 2024
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 24 Jan 2024 13:47:04 -0800
Subject: hprof 1.1
In-Reply-To: <9C36DE44-D8A7-4CFB-B9B6-4F459F9AEC4C@gmail.com>
References: <9C36DE44-D8A7-4CFB-B9B6-4F459F9AEC4C@gmail.com>
Message-ID: <384593d0-1351-4546-8c41-15e19c6661a0@oracle.com>

I filed a CR for this 3 years ago:

https://bugs.openjdk.org/browse/JDK-8260478

Chris

On 1/24/24 1:19 PM, Kirk Pepperdine wrote:

> Hi all,
>
> I was looking for a more recent version of the hprof documentation and it looks like the last version of that doc is with JDK 8. This doc acts as a spec for the file format for heap dumps (as well as the format for for execution and heap profiler output).
>
> Question, is this document an OpenJDK specification and if not, should it be one? If it is a spec should it live some where outside of a specific release? Is this a JSR or a JEP?
>
> https://docs.oracle.com/javase/8/docs/technotes/samples/hprof.html
>
> Kind regards,
> Kirk
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240124/31b2ee37/attachment.htm>

From jiangli at openjdk.org  Wed Jan 24 22:33:28 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 24 Jan 2024 22:33:28 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <POaFoSfp8uLeUyTfDSbWMJS6_b6m_C7wgKkPA32LQrQ=.c7e1404f-5585-457f-9bd6-5d7dbbdbfd84@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <POaFoSfp8uLeUyTfDSbWMJS6_b6m_C7wgKkPA32LQrQ=.c7e1404f-5585-457f-9bd6-5d7dbbdbfd84@github.com>
Message-ID: <GHUgpoRQC7ordHnCGIa3eHazLiUDI-PyLiNSz7QuM9Y=.a4d7d427-0904-4e0c-83ca-0636d6b4137e@github.com>

On Wed, 24 Jan 2024 09:29:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > I think you should be able to use ld and objcopy to merge the .o files and hide all of the symbols you don't want to export.
> > 
> > 
> > We also discussed about `objcopy` in [#14808 (comment)](https://github.com/openjdk/jdk/pull/14808#issuecomment-1631597197) and [#14808 (comment)](https://github.com/openjdk/jdk/pull/14808#issuecomment-1631611220). My main concern was the portability of `objcopy` approach.
> 
> I replied:
> 
> OK, but it is the right thing to do on Linux. If some other operating systems don't provide useful tools, that's on them. I haven't checked, but I strongly suspect that LLVM can do it too, so all that remains is Windows, and maybe they can't have static linking (or maybe they have to use something like this PR) until the right tooling is provided.
> 
> If Windows really can't do it, that's no reason to burden systems that can. Namespaces are not a low-cost solution for developers.

Thanks, @theRealAph.

Yeah, I was mainly concerned about non-unix like systems, Windows particularly. It might not work on all potentially supported compilers (`gcc`) on linux, however. To localizing symbols in `libjvm` using `objcopy`, we can first partially link (with `-r`) all hotspot `.o` into a single object file, then run `objcopy` for the output object file to localize the affected symbols. The partial linking work (https://github.com/openjdk/jdk/blob/2003610b3b52eed04de6713a2a36151d0d86d7c9/make/common/NativeCompilation.gmk#L1245) has been added already. However, during the https://github.com/openjdk/jdk/pull/14064 work, we ran into issues with partial linking on older `gcc` for linux-aarch64. The details were captured in https://github.com/openjdk/jdk/pull/14064#issuecomment-1564908324 discussion with @erikj79. Only `clang` currently work well with the partial linking and symbol localizing solution.

Maybe we could live with symbol redefinition using #define (conditionally for static linking in OpenJDK, as Coleen suggested earlier) for now, until the tooling can support symbol localizing better. Then localizing symbols using tools like `objcopy` can be the longer term and cleaner solution, instead of using namespace. What's your thoughts on that?

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1909019550

From alanb at openjdk.org  Thu Jan 25 07:12:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Jan 2024 07:12:29 GMT
Subject: RFR: 8324582: Replace
 -Djava.util.concurrent.ForkJoinPool.common.parallelism to
 -Djdk.virtualThreadScheduler.maxPoolSize/parallelism in jvmti vthread tests
 [v3]
In-Reply-To: <r3PytRKWoFaZADxvyhzRPZ62BGSOo3aU_bCsukTus_I=.8947cb36-a972-4dc4-9ef2-786e7a972389@github.com>
References: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
 <r3PytRKWoFaZADxvyhzRPZ62BGSOo3aU_bCsukTus_I=.8947cb36-a972-4dc4-9ef2-786e7a972389@github.com>
Message-ID: <ZBFkPtePnvjzX5xeEcgR9AfnFhgsg3ouwYhxwMxogJw=.90c88ed1-ac3e-43de-b815-eda6626dc1ab@github.com>

On Wed, 24 Jan 2024 21:01:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some jvmti tests use
>> -Djava.util.concurrent.ForkJoinPool.common.parallelism
>> to control the pool of virtual threads. However, it is controlled by
>> jdk.virtualThreadScheduler.parallelism property.
>> 
>> The non-continuations implementation doesn't use any of these properties and it was just deleted.
>> 
>> I verified the fix using jcmd Thread.dump and ran all jvmti tests in the default configuration.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights years

@lmesnik Can you fix the JBS issue and description of this PR so that is aligns with the current solution? Using maxPoolSize is right here so I think the change is fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/17547#issuecomment-1909474774

From duke at openjdk.org  Thu Jan 25 07:13:46 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Thu, 25 Jan 2024 07:13:46 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
Message-ID: <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>

On Thu, 22 Apr 2021 21:50:45 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
>> 
>>   8200559: Java agents doing instrumentation need a means to define auxiliary classes
>
> Setting '-javaagent' is mainly an operations problem. Many build tools do
> not allow to declare a test dependency this way as the life cycles are not
> laid out for it, the internal repository location might be machine
> dependent, for example, and it's difficult to point to a specific folder
> and file reliably. In this case, I'd say it would be easier to specify a
> parameter in the sense of '-Djdk.attach.allowAttachSelf=true' as it is a
> static value. This would however only work for build tools that initiate a
> new VM for running tests which is not overly attractive for simple builds
> due to the overhead. Of course, Maven, Gradle and similar tools could set
> this parameter by default for their own JVM, that part is likely
> overcomeable but it will certainly create confusion about how to run
> libraries that are omnipresent today and make the JVM ecosystem less
> approachable.
> 
> What bothers me more is the tooling perspective for non-self-attached
> agents. For example, Aaeron offers a Java agent that adds plenty of debug
> logging to relevant lines of code. This affects method size and so forth,
> with Aaeron as a high-performance tool for banking and finance which is
> written very consciously with regards to the JIT, adding it directly was
> not feasible. Normally this logging is therefore thrown into a VM in
> retrospect, once an application starts failing and is already taken off the
> load balancer. For such a post-mortem, it would be rather annoying to
> realize that a JVM cannot be attached to with full capabilities if you
> forgot to set some flag. And often you did of course not consider the VM
> instance to fail, sometimes it takes months to get a JVM into this buggy
> state. This would be fairly inconvenient to face.
> 
> Therefore, I really hope that the dynamic attach from 'outside' the VM will
> survive without imposing limits and that rather the self-attachment problem
> will be targeted as such. When I mention a 'jdk.test' module in the Mockito
> context, I am also rather hoping to improve performance compared to
> convenience. The problem with '-Djdk.attach.allowAttachSelf=true' is that
> you still need to start a new VM etc. Since Java 9, running single tests
> with Mockito has for example become much slower compared to Java 8. Despite
> the startup performance improvements in the JVM. If one could avoid the
> location-bound '-javaagent:...', but get the Instrumentation instance
> directly, I think this would render a real performance improvement in
> actual execution scenarios.
> 
> Am Mi., 21. Apr. 2...

@raphw and everyone else, I apologise for commenting on an auto-closed issue, but I have no other way of contacting anyone, because neither do I have an account to comment on [JDK-8200559](https://bugs.openjdk.org/browse/JDK-8200559) nor am I a member in any other of the JDK development or "JVM rock star" circles for good reason: I simply have a very limited understanding of the topic at hand.

I am, however, the current maintainer and project lead of Eclipse AspectJ, and since JDK 16 the weaving agent requires `--add-opens java.base/java.lang=ALL-UNNAMED` along with `-javaagent:/path/to/aspectjweaver.jar` for the reason my predecessor Andy Clement has explained in [AspectJ bug 546305](https://bugs.eclipse.org/bugs/show_bug.cgi?id=546305), which is also linked to JDK-8200559. @mlchung was also involved in the discussion there.

Here, there has been a lot of discussion about Byte Buddy and Mockito. For AspectJ, which is widely used in the industry, not just in Spring but also in countless other productive contexts, there still is no solution to the problem that we need to instrument a target class to call an auxiliary class (generated by the agent) that does not have a Lookup object on the target class to begin with. The target class is still being transformed, i.e. not loaded yet, and hence we cannot look it up.

Is this case being considered? Can any of you advise me how to solve that problem? I am open for advice and hands-on chat, desktop sharing or audio/video call sessions.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1909444615

From adinn at openjdk.org  Thu Jan 25 10:06:46 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 25 Jan 2024 10:06:46 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
 <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>
Message-ID: <2RB7SwGiyahPB7R5RfttDGLfWp9jwy_5lU8CisrKSJI=.b2792938-08db-4146-b5d3-36370642d0e5@github.com>

On Thu, 25 Jan 2024 06:39:56 GMT, Alexander Kriegisch <duke at openjdk.org> wrote:

>> Setting '-javaagent' is mainly an operations problem. Many build tools do
>> not allow to declare a test dependency this way as the life cycles are not
>> laid out for it, the internal repository location might be machine
>> dependent, for example, and it's difficult to point to a specific folder
>> and file reliably. In this case, I'd say it would be easier to specify a
>> parameter in the sense of '-Djdk.attach.allowAttachSelf=true' as it is a
>> static value. This would however only work for build tools that initiate a
>> new VM for running tests which is not overly attractive for simple builds
>> due to the overhead. Of course, Maven, Gradle and similar tools could set
>> this parameter by default for their own JVM, that part is likely
>> overcomeable but it will certainly create confusion about how to run
>> libraries that are omnipresent today and make the JVM ecosystem less
>> approachable.
>> 
>> What bothers me more is the tooling perspective for non-self-attached
>> agents. For example, Aaeron offers a Java agent that adds plenty of debug
>> logging to relevant lines of code. This affects method size and so forth,
>> with Aaeron as a high-performance tool for banking and finance which is
>> written very consciously with regards to the JIT, adding it directly was
>> not feasible. Normally this logging is therefore thrown into a VM in
>> retrospect, once an application starts failing and is already taken off the
>> load balancer. For such a post-mortem, it would be rather annoying to
>> realize that a JVM cannot be attached to with full capabilities if you
>> forgot to set some flag. And often you did of course not consider the VM
>> instance to fail, sometimes it takes months to get a JVM into this buggy
>> state. This would be fairly inconvenient to face.
>> 
>> Therefore, I really hope that the dynamic attach from 'outside' the VM will
>> survive without imposing limits and that rather the self-attachment problem
>> will be targeted as such. When I mention a 'jdk.test' module in the Mockito
>> context, I am also rather hoping to improve performance compared to
>> convenience. The problem with '-Djdk.attach.allowAttachSelf=true' is that
>> you still need to start a new VM etc. Since Java 9, running single tests
>> with Mockito has for example become much slower compared to Java 8. Despite
>> the startup performance improvements in the JVM. If one could avoid the
>> location-bound '-javaagent:...', but get the Instrumentation instance
>> directly, I think this would render a real ...
>
> @raphw and everyone else, I apologise for commenting on an auto-closed issue, but I have no other way of contacting anyone, because neither do I have an account to comment on [JDK-8200559](https://bugs.openjdk.org/browse/JDK-8200559) nor am I a member in any other of the JDK development or "JVM rock star" circles for good reason: I simply have a very limited understanding of the topic at hand.
> 
> I am, however, the current maintainer and project lead of Eclipse AspectJ, and since JDK 16 the weaving agent requires `--add-opens java.base/java.lang=ALL-UNNAMED` along with `-javaagent:/path/to/aspectjweaver.jar` for the reason my predecessor Andy Clement has explained in [AspectJ bug 546305](https://bugs.eclipse.org/bugs/show_bug.cgi?id=546305), which is also linked to JDK-8200559. @mlchung was also involved in the discussion there.
> 
> Here, there has been a lot of discussion about Byte Buddy and Mockito. For AspectJ, which is widely used in the industry, not just in Spring but also in countless other productive contexts, there still is no solution to the problem that we need to instrument a target class to call an auxiliary class (generated by the agent) that does not have a Lookup object on the target class to begin with. The target class is still being transformed, i.e. not loaded yet, and hence we cannot look it up.
> 
> Is this case being considered? Can any of you advise me how to solve that problem? I am open for advice and hands-on chat, desktop sharing or audio/video call sessions.

@kriegaex I resolved this problem in Byteman by opening up the module of the target class to a module (dynamically) created by Byteman. The Instrumentation instance provided to the agent allows you to perform such an opens operation at runtime rather than on the command line.

Byteman relies on an API provided by this module to create the lookups and hand them back for use in woven code. n.b. although this relies on the module exporting a public API, that API can be secured by requiring callers to pass a non-null Instrumentation instance i.e. to have agent capabilities.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1909801331

From sroy at openjdk.org  Thu Jan 25 11:06:42 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 25 Jan 2024 11:06:42 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v9]
In-Reply-To: <e4tUkrhF8ChHYsZraVh-bxYYfZgsHR3aOwN9jVttbSk=.52bd11a4-b049-42a4-99ad-8c801d6f2084@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <bc_wdOVEpiUqCq4hExhn7Otl3-6XZWm92RgRPqVwTC4=.e1bced71-47f2-4708-b234-f95f1c37cf85@github.com>
 <e4tUkrhF8ChHYsZraVh-bxYYfZgsHR3aOwN9jVttbSk=.52bd11a4-b049-42a4-99ad-8c801d6f2084@github.com>
Message-ID: <FDdJ2J44jjDJV2KN8tkR2X8ZPqi0OftKTxXb5CdLqCE=.f2c05028-6ad4-42b6-ba5b-b2abfa2884d8@github.com>

On Wed, 24 Jan 2024 07:30:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For me the unresolved question is still:
> 
> * do we want an unconditional load of *.a for a given *.so (have yet to see any documentation for this a-file duality)

Yes. 
The documentation link - https://www.ibm.com/docs/en/aix/7.3?topic=memory-shared-objects-run-time-linking
The text  **In dynamic mode, input files specified with the -l flag may end in .so, as well as in .a. That is, a reference to -lfoo is satisfied by the first libfoo.so or libfoo.a found in any of the directories being searched. Dynamic mode is in effect by default unless the -bstatic option is used.**

https://www.ibm.com/docs/en/aix/7.3?topic=l-ld-command

Archive files are composite objects, which usually contain import files and object files, including shared objects. If an archive file contains another archive file or a member whose type is not recognized, the ld command issues a warning and ignores the unrecognized member. If an object file contained in an archive file has the F_LOADONLY bit set in the XCOFF header, the ld command ignores the member. This bit is usually used to designate old versions of shared objects that remain in the archive file to allow existing applications to load and run. New applications link with the new version of the shared object, that is, another member of the archive.



> * if we do, do we want that to be bidirectional? Someone specifies *.a, do we want to attempt to load *.so?
> 

Considering the different scenarios, loading .a after .so failure should suffice. 
I got a chance to look at the right file in  OpenJ9-omr ,which has a native code which does an attempt to load archive files after trying to load .so files. This code was always there and it explains why the issue did not occur in Semeru, which is derived from this repository. 




> When in doubt, we should just mimic what OpenJ9 is doing on AIX. But I would like a clear documentation as a comment in os_aix.cpp explaining the logic and referencing the relevant OpenJ9 files.
> 
Any example comment you can refer ? I mean i just mention the file name in OpenJ9 and explain the logic ? 
Let me know for any further clarifications

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1909927553

From winterhalter at openjdk.org  Thu Jan 25 12:18:49 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Thu, 25 Jan 2024 12:18:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

Requiring such an API opens the module to anybody, though, punching a hole into the module boundary.

BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation. This also caters the need to inject utility classes from an agent before any class file transformer is triggered, to maintain a well-defined life-cycle.

Of course I'd prefer if there was a way to resolve a lookup from Instrumentation for a given class loader and for example a package-info class, however rendering the issue that packages might not exist (yet).

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1910087337

From mbaesken at openjdk.org  Thu Jan 25 12:35:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Jan 2024 12:35:54 GMT
Subject: RFR: JDK-8324637: get_total_or_available_swap_space_size no support on
 AIX
Message-ID: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>

The get_total_or_available_swap_space_size coding misses AIX support, we only return 0. This should be enhanced.
The perfstat API can be used, see https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface .

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

Commit messages:
 - JDK-8324637

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

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

From dchuyko at openjdk.org  Thu Jan 25 12:38:48 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 25 Jan 2024 12:38:48 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v24]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <REQ3kEr3XoQ1NsjExNydrPdVu7aGQVowqovtwkpUeeU=.4c943b0f-b20d-4f16-b189-a54dc2f6a842@github.com>

> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
> 
> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
> 
> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods).
> 
> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter.
> 
> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them.
> 
> In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ...

Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Deopt osr, cleanups
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - ... and 32 more: https://git.openjdk.org/jdk/compare/7a798d3c...0c8f11bc

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

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=23
  Stats: 381 lines in 15 files changed: 348 ins; 3 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/14111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111

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

From simonis at openjdk.org  Thu Jan 25 13:28:40 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 25 Jan 2024 13:28:40 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v3]
In-Reply-To: <vS3Xl7CkQgA-D9pHSObD7gIXKGo6KSMj1PmWYi1TEZY=.f4add870-5bab-4fe7-863c-92a3d10c340d@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <x6i_d3BOYQ4fwbS2v4PqYLp7lZ5r2tZGeXbekOfGTBc=.4143fa60-c8e2-4195-ab1d-0a8107f8436c@github.com>
 <vS3Xl7CkQgA-D9pHSObD7gIXKGo6KSMj1PmWYi1TEZY=.f4add870-5bab-4fe7-863c-92a3d10c340d@github.com>
Message-ID: <VPWjMug-76u1yyb6LLys9WrEgLdEovKDJGwVkOVLXy4=.3fe6bc7e-405b-45b3-9bcc-c429cfc813a6@github.com>

On Tue, 23 Jan 2024 19:57:14 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated option description and assertion based on review feedback
>
> I support keeping the logic under a flag. I have some concerns about unconditionally turning it on. 
> 
> I expect significantly higher footprint overhead when an application has plenty of tiny methods and deep inlining trees. And java.lang.invoke implementation pushes it even further (with arbitrarily deep MethodHandle trees and unconditional inlining through them), so heavy users of MethodHandle API should experience higher overheads when evol dependencies are recorded.
> 
> I suggest to make the flag experimental. Once JFR implementation is improved, it can be superseded by `-XX:+EnableDynamicAgentLoading` check.

@iwanowww , @shipilev , @dean-long any more comments or concerns? Otherwise I'd like to finish this.

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

PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-1910218698

From adinn at openjdk.org  Thu Jan 25 13:35:45 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 25 Jan 2024 13:35:45 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
Message-ID: <G-3j-YJ-BW1budiSq44FNc7d7DewmnmczBVySYWq0qo=.e2d7de0e-ad55-451c-b3b4-427baa687489@github.com>

On Thu, 25 Jan 2024 12:16:13 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> Requiring such an API opens the module to anybody, though, punching a hole into the module boundary.

How so? Any module created to print Lookups can easily rely on a shared secret to secure the API. Byteman employs a non-null Instrumentation object (a value which any agent ought to keep secret). However, it could just as easily have employed an arbitrary bit length hash key. The key can be used to initialize a module-private static long[] field of an API implementation class generated into the module i.e. the hole can actually be a keyhole in the shape of a key known only to the API client and implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1910230873

From kevinw at openjdk.org  Thu Jan 25 14:14:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 25 Jan 2024 14:14:34 GMT
Subject: RFR: JDK-8324637: [aix] Implement support for reporting swap space
 in jdk.management
In-Reply-To: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
Message-ID: <psCCFi__wO2tmOXaET549HDbQPCS6eXfvBWQrnsDepg=.03245adb-004d-4dc8-b303-0e882f7919b9@github.com>

On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The get_total_or_available_swap_space_size coding misses AIX support, we only return 0. This should be enhanced.
> The perfstat API can be used, see https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface .

I can't try this and don't use AIX, but it looks good.
It follows the same pattern as the other AIX cases in the file.

Although the others (e.g. line 200) don't throw_internal_error if the call returns -1, they just return -1.  You might want to do that for consistency of behaviour.

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17569#pullrequestreview-1843836792

From stuefe at openjdk.org  Thu Jan 25 14:30:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 25 Jan 2024 14:30:41 GMT
Subject: RFR: JDK-8324637: [aix] Implement support for reporting swap space
 in jdk.management
In-Reply-To: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
Message-ID: <YhSlv2llqcd7jh2Ms8T-DXoH9CmGRVSPR3hwMFzteXk=.1ef43d63-120f-444e-98be-0066bf7f059a@github.com>

On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The get_total_or_available_swap_space_size coding misses AIX support, we only return 0. This should be enhanced.
> The perfstat API can be used, see https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface .

Small nit, otherwise good.

src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c line 113:

> 111:         throw_internal_error(env, "perfstat_memory_total failed");
> 112:     }
> 113:     return available ? (jlong)(memory_info.pgsp_free * 4L * 1024L) : (jlong)(memory_info.pgsp_total * 4L * 1024L);

Do we need the cast? perfstat_memory_total_t members are all 64-bit, no?

Also, can we shorten this to:


return (available ? memory_info.pgsp_free : memory_info.pgsp_total) * 4096;

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17569#pullrequestreview-1843868729
PR Review Comment: https://git.openjdk.org/jdk/pull/17569#discussion_r1466454083

From mbaesken at openjdk.org  Thu Jan 25 15:37:37 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Jan 2024 15:37:37 GMT
Subject: RFR: JDK-8324637: [aix] Implement support for reporting swap space
 in jdk.management
In-Reply-To: <psCCFi__wO2tmOXaET549HDbQPCS6eXfvBWQrnsDepg=.03245adb-004d-4dc8-b303-0e882f7919b9@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
 <psCCFi__wO2tmOXaET549HDbQPCS6eXfvBWQrnsDepg=.03245adb-004d-4dc8-b303-0e882f7919b9@github.com>
Message-ID: <I0cINnqzSXNCDBGg4W6ckyMtfTB8_uKbszyMx4Wp5Ik=.5273575f-6dff-4751-88d1-00dea96ccb6f@github.com>

On Thu, 25 Jan 2024 14:11:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I can't try this and don't use AIX, but it looks good. It follows the same pattern as the other AIX cases in the file.
> 
> Although the others (e.g. line 200) don't throw_internal_error if the call returns -1, they just return -1. You might want to do that for consistency of behaviour.

Hi I wanted to be consistent to the other OS in get_total_or_available_swap_space_size, that#s why the throw_internal_error .

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

PR Comment: https://git.openjdk.org/jdk/pull/17569#issuecomment-1910449037

From mbaesken at openjdk.org  Thu Jan 25 15:37:40 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Jan 2024 15:37:40 GMT
Subject: RFR: JDK-8324637: [aix] Implement support for reporting swap space
 in jdk.management
In-Reply-To: <YhSlv2llqcd7jh2Ms8T-DXoH9CmGRVSPR3hwMFzteXk=.1ef43d63-120f-444e-98be-0066bf7f059a@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
 <YhSlv2llqcd7jh2Ms8T-DXoH9CmGRVSPR3hwMFzteXk=.1ef43d63-120f-444e-98be-0066bf7f059a@github.com>
Message-ID: <1SPU_UdKBskpy-0lp-2EASO2XEWaC0I6v7gyp-_R5dY=.cd8f28ad-924c-4c56-b338-6cd8605f5840@github.com>

On Thu, 25 Jan 2024 14:25:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Do we need the cast? perfstat_memory_total_t members are all 64-bit, no?
> 
> Also, can we shorten this to:
> 
> ```
> return (available ? memory_info.pgsp_free : memory_info.pgsp_total) * 4096;
> ```

Hi Thomas, I see no types defined here https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface but most likely you are correct and they are 64bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17569#discussion_r1466552393

From sspitsyn at openjdk.org  Thu Jan 25 15:43:30 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 25 Jan 2024 15:43:30 GMT
Subject: RFR: 8324582: Replace
 -Djava.util.concurrent.ForkJoinPool.common.parallelism to
 -Djdk.virtualThreadScheduler.maxPoolSize/parallelism in jvmti vthread tests
 [v3]
In-Reply-To: <r3PytRKWoFaZADxvyhzRPZ62BGSOo3aU_bCsukTus_I=.8947cb36-a972-4dc4-9ef2-786e7a972389@github.com>
References: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
 <r3PytRKWoFaZADxvyhzRPZ62BGSOo3aU_bCsukTus_I=.8947cb36-a972-4dc4-9ef2-786e7a972389@github.com>
Message-ID: <VaE6RSY4frxMGqboYsYEtAoCB05rb3zHGOkPuDDH_18=.67afce2f-5e58-446a-be8f-b453bed6cf79@github.com>

On Wed, 24 Jan 2024 21:01:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some jvmti tests use
>> -Djava.util.concurrent.ForkJoinPool.common.parallelism
>> to control the pool of virtual threads. However, it is controlled by
>> jdk.virtualThreadScheduler.parallelism property.
>> 
>> The non-continuations implementation doesn't use any of these properties and it was just deleted.
>> 
>> I verified the fix using jcmd Thread.dump and ran all jvmti tests in the default configuration.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights years

This looks good but one test may still need an update?

test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/VThreadEventTest.java line 210:

> 208: 
> 209: }
> 210: 

Does this test also need an update?
It has a line 32:
    *   -Djdk.virtualThreadScheduler.parallelism=9

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17547#pullrequestreview-1844041016
PR Review Comment: https://git.openjdk.org/jdk/pull/17547#discussion_r1466558265

From kevinw at openjdk.org  Thu Jan 25 16:46:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 25 Jan 2024 16:46:37 GMT
Subject: RFR: JDK-8324637: [aix] Implement support for reporting swap space
 in jdk.management
In-Reply-To: <I0cINnqzSXNCDBGg4W6ckyMtfTB8_uKbszyMx4Wp5Ik=.5273575f-6dff-4751-88d1-00dea96ccb6f@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
 <psCCFi__wO2tmOXaET549HDbQPCS6eXfvBWQrnsDepg=.03245adb-004d-4dc8-b303-0e882f7919b9@github.com>
 <I0cINnqzSXNCDBGg4W6ckyMtfTB8_uKbszyMx4Wp5Ik=.5273575f-6dff-4751-88d1-00dea96ccb6f@github.com>
Message-ID: <OjltmvkjGR_pFE9EuwKIvi4caQipiGVaMOh_Xr2U4mg=.bb55983e-97f0-46f5-a633-8bebb59885a4@github.com>

On Thu, 25 Jan 2024 15:33:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > I can't try this and don't use AIX, but it looks good. It follows the same pattern as the other AIX cases in the file.
> > Although the others (e.g. line 200) don't throw_internal_error if the call returns -1, they just return -1. You might want to do that for consistency of behaviour.
> 
> Hi I wanted to be consistent to the other OS in get_total_or_available_swap_space_size, that#s why the throw_internal_error .

Ok yes, you can choose who to be consistent with... 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/17569#issuecomment-1910585693

From amenkov at openjdk.org  Thu Jan 25 23:15:02 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Jan 2024 23:15:02 GMT
Subject: RFR: JDK-8317636: Improve heap walking API tests to verify correctness
 of field indexes
Message-ID: <ggxEJbhFKJA_Wtu3sSugAis3XKUkba5V4b2J7ThjkS0=.bb27a8cd-66d6-4e1c-83b6-41c5bd04af36@github.com>

The fix adds new test for FollowReferences JVMTI function to verify correctness of reported field indexes.

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

Commit messages:
 - jcheck
 - new test

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

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

From duke at openjdk.org  Fri Jan 26 00:20:46 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Fri, 26 Jan 2024 00:20:46 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <G-3j-YJ-BW1budiSq44FNc7d7DewmnmczBVySYWq0qo=.e2d7de0e-ad55-451c-b3b4-427baa687489@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <G-3j-YJ-BW1budiSq44FNc7d7DewmnmczBVySYWq0qo=.e2d7de0e-ad55-451c-b3b4-427baa687489@github.com>
Message-ID: <J26pnHX2kDxTc6bHPAZxljwy88hUoDOXutM6A0PFQng=.5e44d19c-bd0b-4169-a190-66b849697e8c@github.com>

On Thu, 25 Jan 2024 13:33:10 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Requiring such an API opens the module to anybody, though, punching a hole into the module boundary.
>> 
>> BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation. This also caters the need to inject utility classes from an agent before any class file transformer is triggered, to maintain a well-defined life-cycle.
>> 
>> Of course I'd prefer if there was a way to resolve a lookup from Instrumentation for a given class loader and for example a package-info class, however rendering the issue that packages might not exist (yet).
>
>> Requiring such an API opens the module to anybody, though, punching a hole into the module boundary.
> 
> How so? Any module created to print Lookups can easily rely on a shared secret to secure the API. Byteman employs a non-null Instrumentation object (a value which any agent ought to keep secret). However, it could just as easily have employed an arbitrary bit length hash key. The key can be used to initialize a module-private static long[] field of an API implementation class generated into the module i.e. the hole can actually be a keyhole in the shape of a key known only to the API client and implementation.

Thanks @adinn, @raphw for your feedback. I am not pretending to fully understand what you just explained or to have the slightest clue how to do what you suggested, but reading it for the second time since yesterday seems to make it clearer already. I guess, I cannot hope for a how-to with sample code. But I can immerse myself into the topic some more next time I have a vacant time box and look at Byte Buddy and Byteman source code.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911208017

From dlong at openjdk.org  Fri Jan 26 00:58:29 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 26 Jan 2024 00:58:29 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v4]
In-Reply-To: <RzaFrzY1VzoCAjvzGFV-DMzBDcnJs6lY44vhBGCJjIg=.c6488699-1208-458f-9a20-9e60d1fda74c@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <RzaFrzY1VzoCAjvzGFV-DMzBDcnJs6lY44vhBGCJjIg=.c6488699-1208-458f-9a20-9e60d1fda74c@github.com>
Message-ID: <OrajdTWSXgKfkMqwNX44aNNnmi1p5kD4hV8O4PzsTms=.154b576a-b044-44e6-97d0-89b50ab82669@github.com>

On Wed, 24 Jan 2024 14:48:52 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
>> 
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
>> 
>> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
>> 
>> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
>> ```c++
>>  jint init_globals() {
>>    management_init();
>>    JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> +  JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>> 
>> 
>> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb....
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made the flag experimental and added an assertion to set_can_hotswap_or_post_breakpoint()

Marked as reviewed by dlong (Reviewer).

No, go ahead.

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

PR Review: https://git.openjdk.org/jdk/pull/17509#pullrequestreview-1844939013
PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-1911240540

From lmesnik at openjdk.org  Fri Jan 26 01:07:48 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 26 Jan 2024 01:07:48 GMT
Subject: RFR: 8324582: Replace
 -Djava.util.concurrent.ForkJoinPool.common.parallelism to
 -Djdk.virtualThreadScheduler.maxPoolSize in jvmti vthread tests [v4]
In-Reply-To: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
References: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
Message-ID: <PbvbuShiv3Vn8n_OHpfhV-Pn6WmhQ1KNuXNVE1nF8gI=.d1b28047-eb06-42f3-9307-cff5a389b992@github.com>

> Some jvmti tests use
> -Djava.util.concurrent.ForkJoinPool.common.parallelism
> to control the pool of virtual threads. However, it is controlled by
> jdk.virtualThreadScheduler.parallelism property.
> 
> The non-continuations implementation doesn't use any of these properties and it was just deleted.
> 
> I verified the fix using jcmd Thread.dump and ran all jvmti tests in the default configuration.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  reverted copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17547/files
  - new: https://git.openjdk.org/jdk/pull/17547/files/0f608fe5..bac51860

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17547&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17547&range=02-03

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

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

From mbaesken at openjdk.org  Fri Jan 26 08:00:41 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Jan 2024 08:00:41 GMT
Subject: Integrated: JDK-8324637: [aix] Implement support for reporting swap
 space in jdk.management
In-Reply-To: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
References: <Sqbe9596VgvUTnug9kcKUr1-RVAajnxOMeAg9IQhcAw=.4e017750-eedb-4f29-a9bd-2a6e71fdeebd@github.com>
Message-ID: <0V59YZgayJ1aqueveVFJm2WnX07bhOio4CUoAzvx19s=.19e3733c-d43f-4dea-a33a-763209269d38@github.com>

On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The get_total_or_available_swap_space_size coding misses AIX support, we only return 0. This should be enhanced.
> The perfstat API can be used, see https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface .

This pull request has now been integrated.

Changeset: 33324a59
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33324a59ccdb220250cb74e15ce13af0e99dcb07
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8324637: [aix] Implement support for reporting swap space in jdk.management

Reviewed-by: kevinw, stuefe

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

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

From duke at openjdk.org  Fri Jan 26 08:04:47 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Fri, 26 Jan 2024 08:04:47 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
Message-ID: <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>

On Thu, 25 Jan 2024 12:16:13 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.

@raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911633482

From stuefe at openjdk.org  Fri Jan 26 08:23:40 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 26 Jan 2024 08:23:40 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v9]
In-Reply-To: <FDdJ2J44jjDJV2KN8tkR2X8ZPqi0OftKTxXb5CdLqCE=.f2c05028-6ad4-42b6-ba5b-b2abfa2884d8@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <bc_wdOVEpiUqCq4hExhn7Otl3-6XZWm92RgRPqVwTC4=.e1bced71-47f2-4708-b234-f95f1c37cf85@github.com>
 <e4tUkrhF8ChHYsZraVh-bxYYfZgsHR3aOwN9jVttbSk=.52bd11a4-b049-42a4-99ad-8c801d6f2084@github.com>
 <FDdJ2J44jjDJV2KN8tkR2X8ZPqi0OftKTxXb5CdLqCE=.f2c05028-6ad4-42b6-ba5b-b2abfa2884d8@github.com>
Message-ID: <35wH1ZJVECbArnyk5QmOW1xK66UqhL2478hxCxvIY8E=.7db8c7d3-6979-49ee-9ebd-a6f1b2a65531@github.com>

On Thu, 25 Jan 2024 11:04:03 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > For me the unresolved question is still:
> > 
> > * do we want an unconditional load of *.a for a given *.so (have yet to see any documentation for this a-file duality)
> 
> Yes. The documentation link - https://www.ibm.com/docs/en/aix/7.3?topic=memory-shared-objects-run-time-linking The text **In dynamic mode, input files specified with the -l flag may end in .so, as well as in .a. That is, a reference to -lfoo is satisfied by the first libfoo.so or libfoo.a found in any of the directories being searched. Dynamic mode is in effect by default unless the -bstatic option is used.**
> 
> https://www.ibm.com/docs/en/aix/7.3?topic=l-ld-command
> 
> Archive files are composite objects, which usually contain import files and object files, including shared objects. If an archive file contains another archive file or a member whose type is not recognized, the ld command issues a warning and ignores the unrecognized member. If an object file contained in an archive file has the F_LOADONLY bit set in the XCOFF header, the ld command ignores the member. This bit is usually used to designate old versions of shared objects that remain in the archive file to allow existing applications to load and run. New applications link with the new version of the shared object, that is, another member of the archive.

Excellent, thank you.

> 
> > * if we do, do we want that to be bidirectional? Someone specifies *.a, do we want to attempt to load *.so?
> 
> Considering the different scenarios, loading .a after .so failure should suffice. I got a chance to look at the right file in OpenJ9-omr ,which has a native code which does an attempt to load archive files after trying to load .so files. This code was always there and it explains why the issue did not occur in Semeru, which is derived from this repository.

Okay. We don't have to be better than J9 then. If they do it, we should too.

So, for the following input, we do:

"library.so" -> load "library.so", then "library.a"
"library" 	 -> load "library.so", then "library.a" ?
"library.a"  -> only load "library.a" ?

(*)

> 
> > When in doubt, we should just mimic what OpenJ9 is doing on AIX. But I would like a clear documentation as a comment in os_aix.cpp explaining the logic and referencing the relevant OpenJ9 files.
> 
> Any example comment you can refer ? I mean i just mention the file name in OpenJ9 and explain the logic ? Let me know for any further clarifications

Just reference the excerpts you mentioned above, then describe your intended logic. Example:

"When loading <lib>.so, upon failure we attempt to load <lib.a>. When loading a library given without extension, ..."

Explaining the logic makes it easy to see for the casual code reader what your intent is, that you have thought of all cases (*), and makes it possible to check the coding against your intent.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1911652995

From alanb at openjdk.org  Fri Jan 26 08:30:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Jan 2024 08:30:42 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
Message-ID: <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>

On Fri, 26 Jan 2024 08:01:59 GMT, Alexander Kriegisch <duke at openjdk.org> wrote:

> > BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.
> 
> @raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.

Agents should not be using the JDK's internal Unsafe. This needs to said in the strongest possible terms.

For the discussion, it would be useful to provide a brief summary on what AspectJ is trying to do with this weaving. This PR was originally about load time instrumentation defining auxiliary classes, as you might get at compile time when compiling a source file containing more than one class.. I can't tell from your comments here or in Eclipse 546305 if this is relevant to what you are trying to do or not. It may even be better to start a new discussion on serviceability-dev.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911661044

From winterhalter at openjdk.org  Fri Jan 26 08:47:46 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Fri, 26 Jan 2024 08:47:46 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <dqRnJg7KSWR12Vm4fK8xWAkr4guZoOtYmvTnxmQEbEo=.f92c55e3-f3e6-4da9-9fab-1dedc527ac2c@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

I migrate the day https://bugs.openjdk.org/browse/JDK-8200559 finds a solution (and fallback for older JDKs).

I can start a new discussion, but briefly summarized from the last time this was on the mailing list:

- Agents sometimes need to add classes, for example when intercepting a reactive API where a modified callback subclass is injected, with an extra field, for instance.
- The suggestion was that an argument would be provided to ClassFileTransformer which would allow adding classes to the current package. A prototype was created.
- The (my) counter argument was that communication between two packages would be difficult then, as the agent does not control class loading order. If the reactive receiver would need to cast a callback object to read the field that was added, the agent's class might not yet have been instrumented and the class would not exist, yielding an error. The receiver instrumebtation can neither inject the class.
- Often there is also a need to inject infrastructure into class loaders/modules that the instrumentation relies on, so I argued that the facility shouldn't be added to ClassFileTransformer to begin with, but to Instrumentation. Otherwise one could also "pseudo-transform" classes to inject infrastructure, but that felt unnecessary.
- The discussion staled thereafter.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911679253

From duke at openjdk.org  Fri Jan 26 08:47:44 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Fri, 26 Jan 2024 08:47:44 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
Message-ID: <t-Zkp_lqkhdGjGTixtyumF5Zh-SAY_746-ppG11UoBw=.2c6eb2ed-8ad4-4b76-980d-392b62eaccf6@github.com>

On Fri, 26 Jan 2024 08:27:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.
>> 
>> @raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.
>
>> > BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.
>> 
>> @raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.
> 
> Agents should not be using the JDK's internal Unsafe. This needs to said in the strongest possible terms.
> 
> For the discussion, it would be useful to provide a brief summary on what AspectJ is trying to do with this weaving. This PR was originally about load time instrumentation defining auxiliary classes, as you might get at compile time when compiling a source file containing more than one class.. I can't tell from your comments here or in Eclipse 546305 if this is relevant to what you are trying to do or not. It may even be better to start a new discussion on serviceability-dev.

@AlanBateman, the AspectJ weaving agent creates an auxiliary class to implement an "around" advice for a method, i.e. a method execution is intercepted and the user has options to do something before optionally calling the target method and then do something afterwards too. In doing so, she can modify method arguments before calling the target method, then also modify the result. Instead of calling the target method, she may also return a result of the expected type instead. Before, after or instead of calling the target method, she can also throw an exception.

The target class is transformed in such a way to call the auxiliary class, which necessitates the the aux-class to be in the same classloader as the target class. But because the aux-class is defined while the target class is still being transformed during class-loading, we cannot have any look-up instance pointinmg to it yet.

IMO, this is absolutely on topic, which is why the Bugzilla bug is linked to the JDK issue and was discussed with Mandy in this context.

@AlanBateman: As for using means to achieve user benefit that the JDK team deems unfit, nobody would do that, if there was an adequate way to provide such user value. Neither AspectJ nor Byte Buddy have a reputation of being some kind of shady hacker tools.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911676808
PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911680020

From alanb at openjdk.org  Fri Jan 26 09:15:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Jan 2024 09:15:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
Message-ID: <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>

On Fri, 26 Jan 2024 08:27:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.
>> 
>> @raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.
>
>> > BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation.
>> 
>> @raphw, may I ask how? Is there any sample code that is not connected to the BB code base with its nested classes, interfaces etc.? I know, that caters nicely to the fluent DSL BB provides, but to me it is just a maze of code that is hard to comprehend.
> 
> Agents should not be using the JDK's internal Unsafe. This needs to said in the strongest possible terms.
> 
> For the discussion, it would be useful to provide a brief summary on what AspectJ is trying to do with this weaving. This PR was originally about load time instrumentation defining auxiliary classes, as you might get at compile time when compiling a source file containing more than one class.. I can't tell from your comments here or in Eclipse 546305 if this is relevant to what you are trying to do or not. It may even be better to start a new discussion on serviceability-dev.

> @AlanBateman, the AspectJ weaving agent creates an auxiliary class to implement an "around" advice for a method, i.e. a method execution is intercepted and the user has options to do something before optionally calling the target method and then do something afterwards too. In doing so, she can modify method arguments before calling the target method, then also modify the result. Instead of calling the target method, she may also return a result of the expected type instead. Before, after or instead of calling the target method, she can also throw an exception.
> 
> The target class is transformed in such a way to call the auxiliary class, which necessitates the the aux-class to be in the same classloader as the target class. But because the aux-class is defined while the target class is still being transformed during class-loading, we cannot have any look-up instance pointinmg to it yet.

Right, this is what JDK-8200559 was originally about. Mandy and I discussed it several times and load-time instrumentation that defines auxiliary classes in the same run-time package is a reasonable addition. 

The more general request for an "unrestricted defineClass" conflicts with several ongoing efforts so we've had to kick that to touch.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911716353

From mdoerr at openjdk.org  Fri Jan 26 09:30:33 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 26 Jan 2024 09:30:33 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v9]
In-Reply-To: <bc_wdOVEpiUqCq4hExhn7Otl3-6XZWm92RgRPqVwTC4=.e1bced71-47f2-4708-b234-f95f1c37cf85@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <bc_wdOVEpiUqCq4hExhn7Otl3-6XZWm92RgRPqVwTC4=.e1bced71-47f2-4708-b234-f95f1c37cf85@github.com>
Message-ID: <4nhlEYb7mye1qtUk_wptqHTED6Lw7jsgA48sTpWWbXs=.cd2aef1d-9f7f-499e-807f-ed294aee0f40@github.com>

On Tue, 16 Jan 2024 08:36:49 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update porting_aix.cpp
>  - Update porting_aix.cpp
>  - Update os_aix.cpp

I think a comment like this would be ideal:
Search order:
"library.so" -> load "library.so", then "library.a"
"library" -> load "library.so", then "library.a" ?
"library.a" -> only load "library.a" ?
(If that's correct.) I prefer that over a very verbose version. + References to Spec and J9 of course.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1911737129

From shade at openjdk.org  Fri Jan 26 09:48:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 Jan 2024 09:48:31 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v4]
In-Reply-To: <RzaFrzY1VzoCAjvzGFV-DMzBDcnJs6lY44vhBGCJjIg=.c6488699-1208-458f-9a20-9e60d1fda74c@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <RzaFrzY1VzoCAjvzGFV-DMzBDcnJs6lY44vhBGCJjIg=.c6488699-1208-458f-9a20-9e60d1fda74c@github.com>
Message-ID: <8GMtoehKpsPFAXIBfZnT9eLn9PjRuSvGfqvL6os8H9k=.9303d525-b1e5-4d8e-a45e-d55884063540@github.com>

On Wed, 24 Jan 2024 14:48:52 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
>> 
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
>> 
>> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
>> 
>> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
>> ```c++
>>  jint init_globals() {
>>    management_init();
>>    JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> +  JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>> 
>> 
>> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb....
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made the flag experimental and added an assertion to set_can_hotswap_or_post_breakpoint()

I am good with these changes, only a few stylistic nits.

I am on the fence where the default for this flag should stand. The 1% loss in nmethod size is probably okay, given that we gained as much with denser code improvements like [JDK-8319406](https://bugs.openjdk.org/browse/JDK-8319406). Maybe there are some tricks in dependency encoding that would drive this down even more.

src/hotspot/share/prims/jvmtiExport.hpp line 159:

> 157:     // recorded from that point on.
> 158:     assert(!_can_hotswap_or_post_breakpoint || on, "sanity check");
> 159:     _can_hotswap_or_post_breakpoint = (on != 0);

Pre-existing: wild that this code checks `!= 0` against `bool`, when it could have just used the bool directly, like the new assert does. I see no reason to keep `!= 0` here.

src/hotspot/share/runtime/globals.hpp line 2016:

> 2014:                 "Unconditionally record nmethod dependencies on class "     \
> 2015:                 "rewriting/transformation independently of the JVMTI "      \
> 2016:                 " can_{retransform/redefine}_classes capabilities.")        \

Probably match the indenting of previous delcarations?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17509#pullrequestreview-1845365087
PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1467418701
PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1467415176

From duke at openjdk.org  Fri Jan 26 10:20:44 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Fri, 26 Jan 2024 10:20:44 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
Message-ID: <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>

On Fri, 26 Jan 2024 09:12:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> load-time instrumentation that defines auxiliary classes in the same run-time package is a reasonable addition

Thanks for finding some common ground. I appreciate it.

> The more general request for an "unrestricted defineClass" conflicts with several ongoing efforts so we've had to kick that to touch.

I better do not start to share my general opinion about JMS _(edit: sorry, couldn't resist in the end)_ - I mean the ongoing effort that started with Jigsaw - in detail, because that would end up in a flame war.

Let me just say, that "well-meant" is not the necessarily same as "constructive", "helpful" or "necessary". Back when Jigsaw was designed, it seemed to be a good idea. But it has been introduced a long time ago, and all my enterprise customers since then are trying to ignore its excistence as much as they can, mostly seeing it as an impediment or at least a major annoyance. I think, one of the reasons why Python gained so much traction for enterprise-level big data and machine learning stuff is that you have a dynamic language environment in which you can pretty much do whatever you want and just get things done.

Those same enterprise customers want to use the tools of their choosing with as many and as easy to use features as possible. They do not trade those features for security, but implement security in a different way, such as devising a micro service architecture and isolating containers from each other in OpenShift or what have you, defining service mesh rules on top of that, if necessary.

Deprecating security managers was a laudable idea, but adding those unnecessary restrictions in the JVM in exchange was kind of one step forward, two steps back. They just get in the way of getting useful things done. This is what a language and a VM are for: getting things done in a productive way with as few barriers as possible. Instead, with every new Java release, users and tool providers alike are forced to jump through more hoops. There is so much great, innovative stuff in the JVM and Java SE API. E.g., virtual threads are the greatest thing since bread came sliced. We want more of that and fewer barriers. Streams, NIO, the whole lambda and functional bunch of stuff, structured concurrency, better GC, records and neat ways to deconstruct them etc. - wow, great stuff. But new "security features" (a.k.a. restrictions) like modules and sealed classes - not so great from a productivity perspective. Since JDK 9, I have seen generations of developers trying to be more productive no
 t because but despite those new JVM "features".

I know that my perspective is quite subjective and might be biased. But as an agile coach dealing mostly with developers in the JVM ecosystem, I have yet to find a team in which more than a tiny minority thinks that JMS is useful. That is not because they are lazy to learn or do not want to leave their confort zones. It is, because the JVM makes it progressively harder to get things done instead of treating users like adults and letting them take responsibility for security as they see fit. Enforcing things like a helicopter parent is not the smartest move.

I apologise for polluting the thread with what ended up to be too much text that is related to the topic, but not exactly focused on the problem at hand.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911803302

From adinn at openjdk.org  Fri Jan 26 12:29:44 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Fri, 26 Jan 2024 12:29:44 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
 <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>
Message-ID: <LNzmw9QhdWMr72Ej8bIhzdhhzfPQqPlrIqqvZMCOToI=.f226f9e7-52cc-4b6d-8fa4-c0ac28f14a18@github.com>

On Fri, 26 Jan 2024 10:17:16 GMT, Alexander Kriegisch <duke at openjdk.org> wrote:

>>> @AlanBateman, the AspectJ weaving agent creates an auxiliary class to implement an "around" advice for a method, i.e. a method execution is intercepted and the user has options to do something before optionally calling the target method and then do something afterwards too. In doing so, she can modify method arguments before calling the target method, then also modify the result. Instead of calling the target method, she may also return a result of the expected type instead. Before, after or instead of calling the target method, she can also throw an exception.
>>> 
>>> The target class is transformed in such a way to call the auxiliary class, which necessitates the the aux-class to be in the same classloader as the target class. But because the aux-class is defined while the target class is still being transformed during class-loading, we cannot have any look-up instance pointinmg to it yet.
>> 
>> Right, this is what JDK-8200559 was originally about. Mandy and I discussed it several times and load-time instrumentation that defines auxiliary classes in the same run-time package is a reasonable addition. 
>> 
>> The more general request for an "unrestricted defineClass" conflicts with several ongoing efforts so we've had to kick that to touch.
>
>> load-time instrumentation that defines auxiliary classes in the same run-time package is a reasonable addition
> 
> Thanks for finding some common ground. I appreciate it.
> 
>> The more general request for an "unrestricted defineClass" conflicts with several ongoing efforts so we've had to kick that to touch.
> 
> I better do not start to share my general opinion about JMS _(edit: sorry, couldn't resist in the end)_ - I mean the ongoing effort that started with Jigsaw - in detail, because that would end up in a flame war.
> 
> Let me just say, that "well-meant" is not the necessarily same as "constructive", "helpful" or "necessary". Back when Jigsaw was designed, it seemed to be a good idea. But it has been introduced a long time ago, and all my enterprise customers since then are trying to ignore its existence as much as they can, mostly seeing it as an impediment or at least a major annoyance. I think, one of the reasons why Python gained so much traction for enterprise-level big data and machine learning stuff is that you have a dynamic language environment in which you can pretty much do whatever you want and just get things done.
> 
> Those same enterprise customers want to use the tools of their choosing with as many and as easy to use features as possible. They do not trade those features for security, but implement security in a different way, such as devising a micro service architecture and isolating containers from each other in OpenShift or what have you, defining service mesh rules on top of that, if necessary.
> 
> Deprecating security managers was a laudable idea, but adding those unnecessary restrictions in the JVM in exchange was kind of one step forward, two steps back. They just get in the way of getting useful things done. This is what a language and a VM are for: getting things done in a productive way with as few barriers as possible. Instead, with every new Java release, users and tool providers alike are forced to jump through more hoops. There is so much great, innovative stuff in the JVM and Java SE API. E.g., virtual threads are the greatest thing since bread came sliced. We want more of that and fewer barriers. Streams, NIO, the whole lambda and functional bunch of stuff, structured concurrency, better GC, records and neat ways to deconstruct them etc. - wow, great stuff. But new "security features" (a.k.a. restrictions) like modules and sealed classes - not so great from a productivity perspective. Since JDK 9, I have seen generations of developer...

@kriegaex Luckily, you and your customers are not obliged to use the JPMS, nor find it useful for whatever libraries or apps you write or deploy. However, the fact that you or many other programmers do not use it does not mean it has not been a success. Anyone deeply involved with JDK and/or JVM development in recent years knows that it has been and continues to be critical to maintaining and extending the Java platform.

Regarding my previous comment about Byteman using its own dedicated, dynamic module to provide secure access to MethodLookup instance you might want to look at the relevant code. It relies on a sanctioned API of Instrumentation that was introduced as part of the negotiation of JPMS integration precisely to allow agents to interact with and reconfigurethe module system at runtime. The resulting Byteman code provides a simple API that allows methods to be executed indirectly, either via reflection in jdk8- or via method handles in jdk9+. You can see the details of how I achieved this in the Byteman [layer](https://github.com/bytemanproject/byteman/tree/main/layer) and [jigsaw](https://github.com/bytemanproject/byteman/tree/main/jigsaw) subdirectories.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911993356

From simonis at openjdk.org  Fri Jan 26 12:53:41 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 26 Jan 2024 12:53:41 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v4]
In-Reply-To: <8GMtoehKpsPFAXIBfZnT9eLn9PjRuSvGfqvL6os8H9k=.9303d525-b1e5-4d8e-a45e-d55884063540@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <RzaFrzY1VzoCAjvzGFV-DMzBDcnJs6lY44vhBGCJjIg=.c6488699-1208-458f-9a20-9e60d1fda74c@github.com>
 <8GMtoehKpsPFAXIBfZnT9eLn9PjRuSvGfqvL6os8H9k=.9303d525-b1e5-4d8e-a45e-d55884063540@github.com>
Message-ID: <5EFsj5nHnxdCfiKaJrkrhmn1XjMCFZ0209AEzklnIPU=.5667fffc-b365-41db-9378-bfd4547287aa@github.com>

On Fri, 26 Jan 2024 09:33:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made the flag experimental and added an assertion to set_can_hotswap_or_post_breakpoint()
>
> src/hotspot/share/runtime/globals.hpp line 2016:
> 
>> 2014:                 "Unconditionally record nmethod dependencies on class "     \
>> 2015:                 "rewriting/transformation independently of the JVMTI "      \
>> 2016:                 " can_{retransform/redefine}_classes capabilities.")        \
> 
> Probably match the indenting of previous delcarations?

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1467617316

From simonis at openjdk.org  Fri Jan 26 13:14:57 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 26 Jan 2024 13:14:57 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v5]
In-Reply-To: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
Message-ID: <Uic-G3-foi-h_eXkhPZZaESMU8Km2DB0pJ-9EqXcQ0g=.538ecbe1-4852-4a76-bc09-10fc0a5e19a4@github.com>

> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
> 
> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
> 
> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
> 
> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
> ```c++
>  jint init_globals() {
>    management_init();
>    JvmtiExport::initialize_oop_storage();
> +#if INCLUDE_JVMTI
> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
> +  JvmtiExport::set_all_dependencies_are_recorded(true);
> +#endif
> 
> 
> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb. The ration remains about the same i...

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Fixed whitepspace in flag documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17509/files
  - new: https://git.openjdk.org/jdk/pull/17509/files/29966635..fd1dbd9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17509&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17509&range=03-04

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

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

From simonis at openjdk.org  Fri Jan 26 13:14:58 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 26 Jan 2024 13:14:58 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v4]
In-Reply-To: <8GMtoehKpsPFAXIBfZnT9eLn9PjRuSvGfqvL6os8H9k=.9303d525-b1e5-4d8e-a45e-d55884063540@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <RzaFrzY1VzoCAjvzGFV-DMzBDcnJs6lY44vhBGCJjIg=.c6488699-1208-458f-9a20-9e60d1fda74c@github.com>
 <8GMtoehKpsPFAXIBfZnT9eLn9PjRuSvGfqvL6os8H9k=.9303d525-b1e5-4d8e-a45e-d55884063540@github.com>
Message-ID: <kZMCKBBsCeLe21sdWWCGdojS7wPXKmcyLjmLk9Aqbi4=.016e416a-239f-4586-a04e-0f9b3f4286c0@github.com>

On Fri, 26 Jan 2024 09:36:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made the flag experimental and added an assertion to set_can_hotswap_or_post_breakpoint()
>
> src/hotspot/share/prims/jvmtiExport.hpp line 159:
> 
>> 157:     // recorded from that point on.
>> 158:     assert(!_can_hotswap_or_post_breakpoint || on, "sanity check");
>> 159:     _can_hotswap_or_post_breakpoint = (on != 0);
> 
> Pre-existing: wild that this code checks `!= 0` against `bool`, when it could have just used the bool directly, like the new assert does. I see no reason to keep `!= 0` here.

I wondered myself about this strange style. But it's there since the first OpenJDK commit (probably it was written by a C programmer where `bool` isn't a builtin type and he wanted to make sure that all non-zero values get mapped to 1).

But as this style is used throughout the entire file, I prefer to keep it as is and not change a single occurrence only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17509#discussion_r1467632151

From simonis at openjdk.org  Fri Jan 26 13:14:58 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 26 Jan 2024 13:14:58 GMT
Subject: Integrated: 8324241: Always record evol_method deps to avoid excessive
 method flushing
In-Reply-To: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
Message-ID: <h_oPIfY-mH1ZzLyLqdZcg_IAPk208SLcsOwRyEIxS1g=.98a9b9ad-db5c-445b-aa4e-c408630fe426@github.com>

On Sat, 20 Jan 2024 19:48:07 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Currently we don't record dependencies on redefined methods (i.e. `evol_method` dependencies) in JIT compiled methods if none of the `can_redefine_classes`, `can_retransform_classes` or `can_generate_breakpoint_events` JVMTI capabalities is set. This means that if a JVMTI agent which requests one of these capabilities is dynamically attached, all the methods which have been JIT compiled until that point, will be marked for deoptimization and flushed from the code cache. For large, warmed-up applications this mean deoptimization and instant recompilation of thousands if not then-thousands of methods, which can lead to dramatic performance/latency drop-downs for several minutes.
> 
> One could argue that dynamic agent attach is now deprecated anyway (see [JEP 451: Prepare to Disallow the Dynamic Loading of Agents](https://openjdk.org/jeps/451)) and this problem could be solved by making the recording of `evol_method` dependencies dependent on the new `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI capabilities (because the presence of the flag indicates that an agent will be loaded eventually).
> 
> But there a single, however important exception to this rule and that's JFR. JFR is advertised as low overhead profiler which can be enabled in production at any time. However, when JFR is started dynamically (e.g. through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent which requests the `can_retransform_classes` and retransforms some classes. This will inevitably trigger the deoptimization of all compiled methods as described above.
> 
> I'd therefor like to propose to *always* and unconditionally record `evol_method` dependencies in JIT compiled code by exporting the relevant properties right at startup in `init_globals()`:
> ```c++
>  jint init_globals() {
>    management_init();
>    JvmtiExport::initialize_oop_storage();
> +#if INCLUDE_JVMTI
> +  JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
> +  JvmtiExport::set_all_dependencies_are_recorded(true);
> +#endif
> 
> 
> My measurements indicate that the overhead of doing so is minimal (around 1% increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 with C2) resulting in an aggregated nmethod size of around ~40bm. Additionally recording `evol_method` dependencies only increases this size be about 400kb. The ration remains about the same i...

This pull request has now been integrated.

Changeset: 62b3293d
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62b3293df0442b06cd00488774db7b608baca774
Stats:     31 lines in 4 files changed: 20 ins; 0 del; 11 mod

8324241: Always record evol_method deps to avoid excessive method flushing

Reviewed-by: eastigeevich, phh, coleenp, dlong, shade

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

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

From jvernee at openjdk.org  Fri Jan 26 13:22:49 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 26 Jan 2024 13:22:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
Message-ID: <mnVUsWqFW-fh69BqfmEs2dn4ktlMvbGzQkYJAilxTX8=.89fab6a6-3909-4aeb-8e24-1b4dc2e1eeb9@github.com>

On Fri, 26 Jan 2024 09:12:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The target class is transformed in such a way to call the auxiliary class, which necessitates the the aux-class to be in the same classloader as the target class. But because the aux-class is defined while the target class is still being transformed during class-loading, we cannot have any look-up instance pointinmg to it yet.

It seems like you could lazily define the aux class when the target class first needs it, instead of eagerly while the target class is being defined. e.g. generate the class bytes for the aux class up front, and embed them in the target class (For instance as a Base64 encoded string, which fits well into the constant pool). Then, have the transformed code in the target class define the the aux class when it is first needed, at which point you do have access to a lookup.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1912057333

From jpai at openjdk.org  Fri Jan 26 14:58:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 26 Jan 2024 14:58:44 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling
Message-ID: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>

Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?

The JVM can be launched with the `jdwp` agent, like `-agentlib:jdwp=transport=xxx,server=y`. Among other options to the `jdwp` agentlib, one option is the `launch` option, which is of the form `launch=<cmdline>`. `cmdline` can be any arbitrary command. 

When that option is set, `jdwp` during initialization will then launch that command. The implementation of launching the command (on *nix) involves `fork()` followed by `execvp()`. After the child process is forked, jdwp implementation, closes the file descriptors that were copied over (by fork()) from the parent (JVM) process into the (arbitrary) child process. Since jdwp doesn't know how many such file descriptors exist, it queries a system level configuration for that launched process to know max allowed file descriptors (`OPEN_MAX`). It then iterates over each of these file descriptor and calls close() on them sequentially one at a time, irrespective of whether or not those many file descriptors were indeed present or not.

Until recently, on macOS, for the JVM we used to limit the max file descriptors to 10240. The jdwp code above would then iterate over these 10240 file descriptors (I'm leaving out the part where the code skips the standard input/output/error file descriptors) and close them one at a time (even if there weren't that many). This apparently would finish in reasonable amount of time (likely slow, but wasn't noticed to cause any issues).

In https://bugs.openjdk.org/browse/JDK-8300088 we stopped setting that 10240 limit on macOS for the JVM. After that change, on macos, the max file descriptors for JVM turns out to be 2147483647. When jdwp then launches the child process from the JVM, it then has to now iterate almost 2147483647 times and close each of the file descriptors in that logic. This now became extremely slow and noticable and caused 3 tests (https://bugs.openjdk.org/browse/JDK-8324578) which were using the `launch=<cmdline>` option to start failing with a timeout - the jdwp process hadn't yet finished the iteration to close the file descriptors for the child process, by the time jtreg noticed the test had gone past the allowed timeout.

In theory, this entire code which deals with launching a child process from the JVM is what the native implementation of Java's `java.lang.ProcessBuilder.start()` might do. So l had a look at how it's handled there and it turns out, that the implementation there has an optimized way to close these copied over descriptors for the child process. That's done in the `closeDescriptors()` function here https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/childproc.c#L74. What that code does is, it relies on a platform specific directory whose entires contain the file descriptors that are open for the current process. Within the launched child process, that code then lists that platform specific directory and for each returned entry it closes that file descriptor. The advantage of this is that it returns a more accurate and realistic number of file descriptors that have been actually copied over to the child process, instead of using the (extremely high) `OPEN_MAX` v
 alue as the upper bound. The code in `libjava` has an additional fallback which it uses if this logic of closing descriptor doesn't succeed. The fallback is same as what jdwp current does as the default i.e. using `OPEN_MAX` as the upper bound and iterating over each and closing each descriptor.

The `closeDescriptors()` in `libjava` isn't exported, so we can't just use it in jdwp. The commit in this PR copies over `closeDescriptors()` function from `libjava` into the jdwp code and then uses that as the default approach of closing the copied over file descriptors of the child process. If that fails, then we fallback to the current approach of using `OPEN_MAX` as the upper bound for the iteration.

Relatively minor changes have also been introduced in the copied over code - changes like:
 -  adding a `JDI_ASSERT` at a couple of places
 -  additional code comments at relevant places 
 - usage of `errno` in one place
 - using `rlim_t` (from limits.h) instead of `int` for `max_fd` variable 

I have tested this change with and without the changes done in https://bugs.openjdk.org/browse/JDK-8300088 and the `com/sun/jdi/OnThrowTest.java`, `com/sun/jdi/JITDebug.java` and `com/sun/jdi/JdwpOnThrowTest.java` tests now pass in both cases.

My knowledge of C is elementary, so there might be a few more things that need to be considered in this change. Looking forward to any such changes that might be necessary. For example, I'm not sure if `<limits.h>` in AIX defines `rlim_t` type. However, looking at one other place where `rlim_t` gets used in the native JDK code is in `IOUtil.c` https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnio/ch/IOUtil.c#L161 and looking at that code, I don't see any AIX specific overriden files or code for its usage. So I'm guessing the usage of `rlim_t` that this change introduces should be OK on AIX too.

tier1, tier2 and tier3 testing is currently in progress with this change.

Finally, the libjava code for launching child process has some more specifics, which I didn't want to introduce/copy over here. I decided to focus solely on the file descriptors issue in this PR. I haven't yet reviewed whether jdwp would benefit from doing those additional things that libjava does when launching the child process.

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

Commit messages:
 - 8324668: JDWP process management needs more efficient file descriptor handling

Changes: https://git.openjdk.org/jdk/pull/17588/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17588&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324668
  Stats: 113 lines in 1 file changed: 98 ins; 12 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17588/head:pull/17588

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

From rriggs at openjdk.org  Fri Jan 26 15:05:34 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 Jan 2024 15:05:34 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling
In-Reply-To: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
Message-ID: <4tdoW18pna98E3cJoAS4lPk-Uj4m5WB2Pnw7PCTXS7s=.da87506a-b322-41e3-a6f4-f8705670fc6c@github.com>

On Fri, 26 Jan 2024 14:52:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
> 
> The JVM can be launched with the `jdwp` agent, like `-agentlib:jdwp=transport=xxx,server=y`. Among other options to the `jdwp` agentlib, one option is the `launch` option, which is of the form `launch=<cmdline>`. `cmdline` can be any arbitrary command. 
> 
> When that option is set, `jdwp` during initialization will then launch that command. The implementation of launching the command (on *nix) involves `fork()` followed by `execvp()`. After the child process is forked, jdwp implementation, closes the file descriptors that were copied over (by fork()) from the parent (JVM) process into the (arbitrary) child process. Since jdwp doesn't know how many such file descriptors exist, it queries a system level configuration for that launched process to know max allowed file descriptors (`OPEN_MAX`). It then iterates over each of these file descriptor and calls close() on them sequentially one at a time, irrespective of whether or not those many file descriptors were indeed present or not.
> 
> Until recently, on macOS, for the JVM we used to limit the max file descriptors to 10240. The jdwp code above would then iterate over these 10240 file descriptors (I'm leaving out the part where the code skips the standard input/output/error file descriptors) and close them one at a time (even if there weren't that many). This apparently would finish in reasonable amount of time (likely slow, but wasn't noticed to cause any issues).
> 
> In https://bugs.openjdk.org/browse/JDK-8300088 we stopped setting that 10240 limit on macOS for the JVM. After that change, on macos, the max file descriptors for JVM turns out to be 2147483647. When jdwp then launches the child process from the JVM, it then has to now iterate almost 2147483647 times and close each of the file descriptors in that logic. This now became extremely slow and noticable and caused 3 tests (https://bugs.openjdk.org/browse/JDK-8324578) which were using the `launch=<cmdline>` option to start failing with a timeout - the jdwp process hadn't yet finished the iteration to close the file descriptors for the child process, by the time jtreg noticed the test had gone past the allowed timeout.
> 
> In theory, this entire code which deals with launching a child process from the JVM is what the native implementation of Java's `java.lang.ProcessBuilder.start()` might do. So l had a look at how it's handled there and it turns out, t...

The PR description appears in *every* email sent for the PR. For PRs with extensive descriptions, perhaps they can be included as a separate comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/17588#issuecomment-1912212785

From jpai at openjdk.org  Fri Jan 26 15:34:35 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 26 Jan 2024 15:34:35 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling
In-Reply-To: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
Message-ID: <zuAd3g0G0brc_bhy1s5lj2aHZaqWn8MypfacaTukNK4=.d6a64136-60f5-4c50-933b-513577e1eac1@github.com>

On Fri, 26 Jan 2024 14:52:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
> 
> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.

The JVM can be launched with the jdwp agent, like `-agentlib:jdwp=transport=xxx,server=y`. Among other options to the jdwp agentlib, one option is the `launch` option, which is of the form `launch=<cmdline>`. `cmdline` can be any arbitrary command. 

When that option is set, jdwp during initialization will then launch that command. The implementation of launching the command (on *nix) involves `fork()` followed by `execvp()`. After the child process is forked, jdwp implementation, closes the file descriptors that were copied over (by fork()) from the parent (JVM) process into the (arbitrary) child process. Since jdwp doesn't know how many such file descriptors exist, it queries a system level configuration for that launched process to know max allowed file descriptors (`OPEN_MAX`). It then iterates over each of these file descriptor and calls close() on them sequentially one at a time, irrespective of whether or not those many file descriptors were indeed present or not.

Until recently, on macOS, for the JVM we used to limit the max file descriptors to 10240. The jdwp code above would then iterate over these 10240 file descriptors (I'm leaving out the part where the code skips the standard input/output/error file descriptors) and close them one at a time (even if there weren't that many). This apparently would finish in reasonable amount of time (likely slow, but wasn't noticed to cause any issues).

In https://bugs.openjdk.org/browse/JDK-8300088 we stopped setting that 10240 limit on macOS for the JVM. After that change, on macos, the max file descriptors for JVM turns out to be 2147483647. When jdwp then launches the child process from the JVM, it then has to now iterate almost 2147483647 times and close each of the file descriptors in that logic. This now became extremely slow and noticable and caused 3 tests (https://bugs.openjdk.org/browse/JDK-8324578) which were using the `launch=<cmdline>` option to start failing with a timeout - the jdwp process hadn't yet finished the iteration to close the file descriptors for the child process, by the time jtreg noticed the test had gone past the allowed timeout.

In theory, this entire code which deals with launching a child process from the JVM is what the native implementation of Java's `java.lang.ProcessBuilder.start()` might do. So l had a look at how it's handled there and it turns out, that the implementation there has an optimized way to close these copied over descriptors for the child process. That's done in the `closeDescriptors()` function here https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/childproc.c#L74. What that code does is, it relies on a platform specific directory whose entires contain the file descriptors that are open for the current process. Within the launched child process, that code then lists that platform specific directory and for each returned entry it closes that file descriptor. The advantage of this is that it returns a more accurate and realistic number of file descriptors that have been actually copied over to the child process, instead of using the (extremely high) `OPEN_MAX` v
 alue as the upper bound. The code in libjava has an additional fallback which it uses if this logic of closing descriptor doesn't succeed. The fallback is same as what jdwp current does as the default i.e. using `OPEN_MAX` as the upper bound and iterating over each and closing each descriptor.

The `closeDescriptors()` in libjava isn't exported, so we can't just use it in jdwp. The commit in this PR copies over closeDescriptors() function from libjava into the jdwp code and then uses that as the default approach of closing the copied over file descriptors of the child process. If that fails, then we fallback to the current approach of using OPEN_MAX as the upper bound for the iteration.

Relatively minor changes have also been introduced in the copied over code - changes like:

    - adding a JDI_ASSERT at a couple of places
    - additional code comments at relevant places
    - usage of errno in one place
    - using rlim_t (from limits.h) instead of int for max_fd variable

I have tested this change with and without the changes done in https://bugs.openjdk.org/browse/JDK-8300088 and the `com/sun/jdi/OnThrowTest.java`, `com/sun/jdi/JITDebug.java` and `com/sun/jdi/JdwpOnThrowTest.java` tests now pass in both cases.

My knowledge of C is elementary, so there might be a few more things that need to be considered in this change. Looking forward to any such changes that might be necessary. For example, I'm not sure if `<limits.h>` in AIX defines `rlim_t` type. However, looking at one other place where `rlim_t` gets used in the native JDK code is in IOUtil.c https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnio/ch/IOUtil.c#L161 and looking at that code, I don't see any AIX specific overridden files or code for its usage. So I'm guessing the usage of `rlim_t` that this change introduces should be OK on AIX too.

Finally, the libjava code for launching child process has some more specifics, which I didn't want to introduce/copy over here. I decided to focus solely on the file descriptors issue in this PR. I haven't yet reviewed whether jdwp would benefit from doing those additional things that libjava does when launching the child process.

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

PR Comment: https://git.openjdk.org/jdk/pull/17588#issuecomment-1912256075

From jpai at openjdk.org  Fri Jan 26 15:40:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 26 Jan 2024 15:40:27 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling
In-Reply-To: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
Message-ID: <iufTCOqf6ligIJ7LrD7jyGcZRTH59yQ26sBXju86FJo=.5d627e6b-aaad-4037-8338-bf084fad84f4@github.com>

On Fri, 26 Jan 2024 14:52:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
> 
> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.

Hello Roger,

> The PR description appears in _every_ email sent for the PR. For PRs with extensive descriptions, perhaps they can be included as a separate comment.

I had forgotten this. I've updated the description to be much shorter now and added a separate comment for the details.

The failures in Github actions jobs are related to this change:

/home/runner/work/jdk/jdk/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c:129:15: 
error: unknown type name 'rlim_t'


I will address them soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/17588#issuecomment-1912262794
PR Comment: https://git.openjdk.org/jdk/pull/17588#issuecomment-1912266391

From jpai at openjdk.org  Fri Jan 26 15:57:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 26 Jan 2024 15:57:57 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v2]
In-Reply-To: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
Message-ID: <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
> 
> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  use the right include for rlim_t - <sys/resource.h>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17588/files
  - new: https://git.openjdk.org/jdk/pull/17588/files/6508c95f..4a1155b6

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

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

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

From kevinw at openjdk.org  Fri Jan 26 17:08:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 26 Jan 2024 17:08:24 GMT
Subject: RFR: 8323680: SA PointerFinder code can do a better job of
 leveraging existing code to determine if an address is in the TLAB
In-Reply-To: <H17vx7Y1bWqd8QLwqR5UOxUi9VbtW3mDTTlLuQe69Ts=.f088c0f8-37f0-4ef2-be2e-cfe19513837f@github.com>
References: <H17vx7Y1bWqd8QLwqR5UOxUi9VbtW3mDTTlLuQe69Ts=.f088c0f8-37f0-4ef2-be2e-cfe19513837f@github.com>
Message-ID: <75IBmpuqKqfFxrwjS5_M8hsLLi5jE7oZhAB6s-5urow=.034b08f0-ba72-469b-9eb7-97c32108df33@github.com>

On Thu, 18 Jan 2024 22:54:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In PointerFinder.java we have some code to determine if a pointer is in a TLAB, but it only executes for the SerialGC. It should work for all GCs, so I moved the code out of the SerialGC block.
> 
> I also cleaned up the printing in PointerLocation. java a bit so when not using verbose mode not as much info about the tlab address is printed. This is consistent with other addresses, such as java stack addresses, which is what I modeled this change on.
> 
> It's hard to test this change since it is hard to consistently get an address to be in the tlab. I wrote a little test program that just sits in a loop doing allocations. I attached to it with clhsdb and ran the threadcontext command, which does a fincpc on each register. About half the time the main thread was suspended in a frame where some registers where pointing into the tlab, and I confirmed this was the case for both SerialGC and G1. Here's an example of one register with verbose off and verbose on:
> 
> rsi: 0x000000008a5d4448: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007ffa24029000
> 
> rsi: 0x000000008a5d4448: In TLAB for thread ("main" #1 prio=5 tid=0x00007ffa24029000 nid=25392 runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_java
> )  [0x000000008a5d4448,0x000000008ab724b8,0x000000008b0c0250,{0x000000008b0c0490})
> 
> For testing I ran all tier1, tier2, and tier5 svc tests (still in progress)

Looks good to me.

(Not critical, but maybe PointerLocation doesn't need the boolean inTlab.  It could use that its tlab is not null, like the isInHeap/stack/metadata checks that something is not null.)

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17494#pullrequestreview-1846152245

From gziemski at openjdk.org  Fri Jan 26 17:26:36 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 26 Jan 2024 17:26:36 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v2]
In-Reply-To: <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
Message-ID: <KkKe1jXEZwT83RDw5Gh91fjhw66vzR3ahysjF7kFEec=.a1920200-d7a1-454e-9350-fa281d002435@github.com>

On Fri, 26 Jan 2024 15:57:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use the right include for rlim_t - <sys/resource.h>

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 135:

> 133:         for (; i < max_fd; i++) {
> 134:             (void)close(i);
> 135:         }

I think I'd prefer to see standard:


        rlim_t i;
         for (STDERR_FILENO + 1; i < max_fd; i++) {
             (void)close(i);
         }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1467922003

From gziemski at openjdk.org  Fri Jan 26 17:36:28 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 26 Jan 2024 17:36:28 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v2]
In-Reply-To: <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
Message-ID: <GKSCmMTq_TUFfDTCZlqJVroRX2YSDg7Ig6LuPZ0WWYU=.a04ef702-9e94-4f07-973b-bf5244fae670@github.com>

On Fri, 26 Jan 2024 15:57:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use the right include for rlim_t - <sys/resource.h>

Have you considered using `fcntl(d, F_SETFD, 1)` instead of the fancy `closeDescriptors()`?

I haven't tested it myself, but per the man page:


Most of the descriptors can be rearranged with dup2(2) or deleted with close() before the execve is attempted, but if some of these descriptors will still be needed if the execve fails, it is necessary to arrange for them to be closed if the execve succeeds.  For this reason, the call ?fcntl(d, F_SETFD, 1)? is provided, which arranges that a descriptor will be closed after a successful execve;

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 129:

> 127:          * and assume all were opened for the parent process and
> 128:          * copied over to this child process. we close them all */
> 129:         const rlim_t max_fd = sysconf(_SC_OPEN_MAX);

Why not use `int`, like the original code, instead of  `rlim_t` - as per man page `close()` expects `int`, not  `rlim_t`, ex:


        const int max_fd = (int)sysconf(_SC_OPEN_MAX);
        JDI_ASSERT(max_fd != -1);
        int fd;
         /* leave out standard input/output/error file descriptors */
         for (fd = STDERR_FILENO + 1; fd < max_fd; fd++) {
             (void)close(fd);
         }

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

Changes requested by gziemski (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17588#pullrequestreview-1846188473
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1467927052

From gziemski at openjdk.org  Fri Jan 26 17:40:25 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 26 Jan 2024 17:40:25 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v2]
In-Reply-To: <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
Message-ID: <5d-MFEiDnUp7Yz-ShDtNxckJzcoq6gdiWwf7iGVcVrI=.08cf10b1-b480-4b28-9979-a3a91de2c803@github.com>

On Fri, 26 Jan 2024 15:57:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use the right include for rlim_t - <sys/resource.h>

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 112:

> 110:     }
> 111: 
> 112:     closedir(dp);

Should this be:

`    (void)closedir(dp);`

to show that we're ignoring the return value?

Since this area is pretty mysterious to deal with, should we consider checking whether `closedir()` actually returns am error, and at least be verbal and print a warning, as opposed to silently ignoring it?

Printing a warning, might help us diagnose any issue in the future?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1467934723

From gziemski at openjdk.org  Fri Jan 26 17:46:34 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 26 Jan 2024 17:46:34 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v2]
In-Reply-To: <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
Message-ID: <LnbR-cvpiIwywUQWyrtt-7JrIuOyHFV9rx2Aetf77b4=.a7f4f059-fca4-4a54-97a9-f0fc65519ece@github.com>

On Fri, 26 Jan 2024 15:57:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use the right include for rlim_t - <sys/resource.h>

Looks good, thank you for debugging this and providing a fix!

I did have some questions and feedback, nothing major, just making sure we cover all our bases.

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

PR Comment: https://git.openjdk.org/jdk/pull/17588#issuecomment-1912438110

From coleenp at openjdk.org  Fri Jan 26 20:13:59 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 26 Jan 2024 20:13:59 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native
 code files
Message-ID: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>

This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments or strings to just null.  If you run into this and it bothers you after this push, you can change it in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.

Ran tier1-4 testing.

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

Commit messages:
 - 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files

Changes: https://git.openjdk.org/jdk/pull/17593/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324681
  Stats: 8196 lines in 750 files changed: 0 ins; 7 del; 8189 mod
  Patch: https://git.openjdk.org/jdk/pull/17593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593

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

From coleenp at openjdk.org  Fri Jan 26 20:26:17 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 26 Jan 2024 20:26:17 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v2]
In-Reply-To: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
Message-ID: <PbzyegOH2TUSVKKVvD9PML-UJHLl96T8lBOH9OlwauI=.37fc9598-4354-4b4d-a573-e3b8801d2fb5@github.com>

> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments or strings to just null.  If you run into this and it bothers you after this push, you can change it in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
> 
> Ran tier1-4 testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix the comments to "null"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17593/files
  - new: https://git.openjdk.org/jdk/pull/17593/files/079b8931..e15a3a0b

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

  Stats: 229 lines in 103 files changed: 0 ins; 0 del; 229 mod
  Patch: https://git.openjdk.org/jdk/pull/17593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593

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

From coleenp at openjdk.org  Fri Jan 26 21:06:00 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 26 Jan 2024 21:06:00 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v3]
In-Reply-To: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
Message-ID: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com>

> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments or strings to just null.  If you run into this and it bothers you after this push, you can change it in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
> 
> Ran tier1-4 testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix nullptr only contained in strings.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17593/files
  - new: https://git.openjdk.org/jdk/pull/17593/files/e15a3a0b..33786c7d

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

  Stats: 19 lines in 3 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/17593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593

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

From cjplummer at openjdk.org  Fri Jan 26 21:20:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 26 Jan 2024 21:20:04 GMT
Subject: RFR: 8323680: SA PointerFinder code can do a better job of
 leveraging existing code to determine if an address is in the TLAB [v2]
In-Reply-To: <H17vx7Y1bWqd8QLwqR5UOxUi9VbtW3mDTTlLuQe69Ts=.f088c0f8-37f0-4ef2-be2e-cfe19513837f@github.com>
References: <H17vx7Y1bWqd8QLwqR5UOxUi9VbtW3mDTTlLuQe69Ts=.f088c0f8-37f0-4ef2-be2e-cfe19513837f@github.com>
Message-ID: <VNCNMH23it-ShOdlMzFu2wQod2wpc-EXTPw4SqRoabM=.cc0e7410-c63d-4aef-9b59-87106a6de48e@github.com>

> In PointerFinder.java we have some code to determine if a pointer is in a TLAB, but it only executes for the SerialGC. It should work for all GCs, so I moved the code out of the SerialGC block.
> 
> I also cleaned up the printing in PointerLocation. java a bit so when not using verbose mode not as much info about the tlab address is printed. This is consistent with other addresses, such as java stack addresses, which is what I modeled this change on.
> 
> It's hard to test this change since it is hard to consistently get an address to be in the tlab. I wrote a little test program that just sits in a loop doing allocations. I attached to it with clhsdb and ran the threadcontext command, which does a fincpc on each register. About half the time the main thread was suspended in a frame where some registers where pointing into the tlab, and I confirmed this was the case for both SerialGC and G1. Here's an example of one register with verbose off and verbose on:
> 
> rsi: 0x000000008a5d4448: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007ffa24029000
> 
> rsi: 0x000000008a5d4448: In TLAB for thread ("main" #1 prio=5 tid=0x00007ffa24029000 nid=25392 runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_java
> )  [0x000000008a5d4448,0x000000008ab724b8,0x000000008b0c0250,{0x000000008b0c0490})
> 
> For testing I ran all tier1, tier2, and tier5 svc tests (still in progress)

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Get rid of inTLAB field. Not needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17494/files
  - new: https://git.openjdk.org/jdk/pull/17494/files/ed620194..df3a1cf2

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

  Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17494.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17494/head:pull/17494

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

From cjplummer at openjdk.org  Fri Jan 26 21:20:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 26 Jan 2024 21:20:04 GMT
Subject: RFR: 8323680: SA PointerFinder code can do a better job of
 leveraging existing code to determine if an address is in the TLAB [v2]
In-Reply-To: <75IBmpuqKqfFxrwjS5_M8hsLLi5jE7oZhAB6s-5urow=.034b08f0-ba72-469b-9eb7-97c32108df33@github.com>
References: <H17vx7Y1bWqd8QLwqR5UOxUi9VbtW3mDTTlLuQe69Ts=.f088c0f8-37f0-4ef2-be2e-cfe19513837f@github.com>
 <75IBmpuqKqfFxrwjS5_M8hsLLi5jE7oZhAB6s-5urow=.034b08f0-ba72-469b-9eb7-97c32108df33@github.com>
Message-ID: <fmT3-embBME2gHeKYFXnzTsbq-XLfdHxkja46NzMv_g=.7f8afa46-a887-4dad-a283-1a80d8e8b443@github.com>

On Fri, 26 Jan 2024 17:05:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> (Not critical, but maybe PointerLocation doesn't need the boolean inTlab. It could use that its tlab is not null, like the isInHeap/stack/metadata checks that something is not null.)

Ok. I made that change.

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

PR Comment: https://git.openjdk.org/jdk/pull/17494#issuecomment-1912707628

From jpai at openjdk.org  Sat Jan 27 01:20:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 27 Jan 2024 01:20:26 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v2]
In-Reply-To: <GKSCmMTq_TUFfDTCZlqJVroRX2YSDg7Ig6LuPZ0WWYU=.a04ef702-9e94-4f07-973b-bf5244fae670@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
 <GKSCmMTq_TUFfDTCZlqJVroRX2YSDg7Ig6LuPZ0WWYU=.a04ef702-9e94-4f07-973b-bf5244fae670@github.com>
Message-ID: <I-zTW05Frb8E6eFJrQDKmt6WIzib4Xk_5TR2kz3l2kE=.40d73f10-8247-4e01-a587-5b0b078522c7@github.com>

On Fri, 26 Jan 2024 17:29:10 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use the right include for rlim_t - <sys/resource.h>
>
> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 129:
> 
>> 127:          * and assume all were opened for the parent process and
>> 128:          * copied over to this child process. we close them all */
>> 129:         const rlim_t max_fd = sysconf(_SC_OPEN_MAX);
> 
> Why not use `int`, like the original code, instead of  `rlim_t` - as per man page `close()` expects `int`, not  `rlim_t`, ex:
> 
> 
>         const int max_fd = (int)sysconf(_SC_OPEN_MAX);
>         JDI_ASSERT(max_fd != -1);
>         int fd;
>          /* leave out standard input/output/error file descriptors */
>          for (fd = STDERR_FILENO + 1; fd < max_fd; fd++) {
>              (void)close(fd);
>          }

Hello Gerard, my understanding is that the limit value configured may exceed the int range. I wanted to avoid the overflow by casting it to int in such cases. I had noticed close() takes an int, but I couldn't think of any other way of avoiding the overflow at this place.

In the JVM parent process we do however limit it to INT_MAX. So maybe I should assume that it will be an int cast it to int here, like you suggest, and add a code comment explaining this? Does that sound OK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1468270331

From weijun at openjdk.org  Sat Jan 27 02:15:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 27 Jan 2024 02:15:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
Message-ID: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>

This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.

One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.

Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

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

Commit messages:
 - remove exe bits
 - remove x bit
 - the patch

Changes: https://git.openjdk.org/jdk/pull/17472/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296244
  Stats: 620 lines in 14 files changed: 464 ins; 52 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

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

From alanb at openjdk.org  Sat Jan 27 02:15:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 27 Jan 2024 02:15:54 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <UljMASUOYPJsDz_kxVJ6lnfnGsH3PS-p6jaV66nYYm0=.770a0e3a-a471-4779-9928-5365d955c529@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

src/java.base/share/classes/javax/security/auth/Subject.java line 112:

> 110:  *
> 111:  * <p><b><a id="sm-not-allowed">These methods behave differently depending on
> 112:  * whether a security manager is allowed or disallowed</a></b>:

"is allowed or disallowed" but the detail presents them in the reverse order. I think it would be easier to read if the allowed case went first, this goes for all the methods. I understand that disallow is the default but I think a bit easier to present in that order.

src/java.base/share/classes/javax/security/auth/Subject.java line 298:

> 296:      * {@code AccessControlContext}. When a security manager is
> 297:      * <a href=#sm-not-allowed>not allowed</a>, this method is not supported
> 298:      * and throws an {@code UnsupportedOperationException}.

I think it might be better to say "This method is intended to be used with a security manager. It throws UOE if a security manager is not allowed".

src/java.base/share/classes/javax/security/auth/Subject.java line 379:

> 377:      * current subject binds to the period of the execution of the current
> 378:      * thread. Otherwise, it is associated with the current
> 379:      * {@code AccessControlContext}.

What would you think of "If a security manager is allowed, this method is equivalent to calling getSubject with the current ACC. If a security manager is not allowed, this returns the Subject bound to the current Thread."

src/java.base/share/classes/javax/security/auth/Subject.java line 411:

> 409:      * Finally, this method invokes {@code AccessController.doPrivileged},
> 410:      * passing it the provided {@code PrivilegedAction},
> 411:      * as well as the newly constructed {@code AccessControlContext}.

I think this method would be easier to present if the allowed and not-allowed cases were in separate paragraphs. The reason is that the SM allowed case has a lot more test. For the not allowed case then it would be clearer to say that the calls the value returning function with the current Thread bound to the given Subject.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467824941
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467826752
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467829318
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1467831325

From duke at openjdk.org  Sat Jan 27 05:14:49 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Sat, 27 Jan 2024 05:14:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <LNzmw9QhdWMr72Ej8bIhzdhhzfPQqPlrIqqvZMCOToI=.f226f9e7-52cc-4b6d-8fa4-c0ac28f14a18@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
 <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>
 <LNzmw9QhdWMr72Ej8bIhzdhhzfPQqPlrIqqvZMCOToI=.f226f9e7-52cc-4b6d-8fa4-c0ac28f14a18@github.com>
Message-ID: <7RTva_kbE-aUHejsBwTh8YFq43cB6-gt2JvvbhMXWqA=.50072ddc-9e12-4e42-a138-4e26d6c249b4@github.com>

On Fri, 26 Jan 2024 12:27:02 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Luckily, you and your customers are not obliged to use the JPMS

They are obliged to deal with it, and so am I as a tool maintainer. Just look the the approaches mentioned here. They all are in the category which in German we would call "von hinten durch die Brust ins Auge". That literally translates as "(a shot) from behind through the chest into the eye". Think Kennedy and "magic bullet". It means that something is unnecessarily complicated. But it is not of any developer's own choosing, but because the Java API and runtime environment requires them to jump through hoops. That is exactly what I meant before. Bytecode transformation should not be rocket science, but it progressively is developing in that direction. I have seen what Byte Buddy does to get access to an Unsafe instance, thought about what @JornVernee just suggested and have yet to look into the ByteMan source code. This all sounds pretty much like black magic and a maintenance nightmare to me.

A language ought to provide means to be productive and maybe offer some (opt-in) guard railing, but not be a corset so tight that I cannot breathe anymore. I need something that supports me without strangling me.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1912999685

From kevinw at openjdk.org  Sat Jan 27 11:57:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Sat, 27 Jan 2024 11:57:35 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v3]
In-Reply-To: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com>
Message-ID: <8G5I-7bp7jVg891XRUkSWJ6DMOoOBkhfkpNPNt40Ti0=.9e8391a5-9034-4b49-b0ee-ae3a62f37c32@github.com>

On Fri, 26 Jan 2024 21:06:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix nullptr only contained in strings.

test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/libVThreadTest.cpp line 426:

> 424:   }
> 425: 
> 426:   // #5: Test JVMTI GetLocalObject function with nullptr value_ptr

"with null value_ptr" ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17593#discussion_r1468449036

From kevinw at openjdk.org  Sat Jan 27 12:24:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Sat, 27 Jan 2024 12:24:34 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v3]
In-Reply-To: <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <9n3_W-gEDmcSZz8z5V_d-93x1Gy2Zl005gPEepDdIC4=.f7906413-3999-4e0d-acf3-bc7d8cc1d89b@github.com>
Message-ID: <HbaFbm_j1Qh3csmV63pbfrjGLTFpcWYTbrXCzwToHbI=.491cfdc1-0f92-4c99-a4bb-ff244f97bfb1@github.com>

On Fri, 26 Jan 2024 21:06:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix nullptr only contained in strings.

That is long.  Hypnotic to read. One very trivial nit, use or ignore as required, but all good that I can see.

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17593#pullrequestreview-1847074612

From jpai at openjdk.org  Sat Jan 27 13:09:45 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 27 Jan 2024 13:09:45 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v3]
In-Reply-To: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
Message-ID: <XIrn2WdSM-FXgv8_CQ9Fl-Aqr4SCZ2ykYBBkCfTQYXk=.c2ee8419-436c-4045-91a6-8e44d5992553@github.com>

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
> 
> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - log a warning message if we fallback to slower logic of closing file descriptors
 - ignore return values, cast to void

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17588/files
  - new: https://git.openjdk.org/jdk/pull/17588/files/4a1155b6..af2472d4

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

  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17588/head:pull/17588

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

From jpai at openjdk.org  Sat Jan 27 13:09:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 27 Jan 2024 13:09:46 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v2]
In-Reply-To: <GKSCmMTq_TUFfDTCZlqJVroRX2YSDg7Ig6LuPZ0WWYU=.a04ef702-9e94-4f07-973b-bf5244fae670@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
 <GKSCmMTq_TUFfDTCZlqJVroRX2YSDg7Ig6LuPZ0WWYU=.a04ef702-9e94-4f07-973b-bf5244fae670@github.com>
Message-ID: <3D0JN8zJ3PJKTdn2lHCJN1a5u5sjk6E75ZjgBiDnrGA=.6388e950-8fad-4440-8854-419eccaaa121@github.com>

On Fri, 26 Jan 2024 17:33:39 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Have you considered using `fcntl(d, F_SETFD, 1)` instead of the fancy `closeDescriptors()`?
> 
> I haven't tested it myself, but per the `man close` page:
> 
> ```
> Most of the descriptors can be rearranged with dup2(2) or deleted with close() before the execve is attempted, but if some of these descriptors will still be needed if the execve fails, it is necessary to arrange for them to be closed if the execve succeeds.  For this reason, the call ?fcntl(d, F_SETFD, 1)? is provided, which arranges that a descriptor will be closed after a successful execve;
> ```

I hadn't considered that. Now that you mentioned it, I had a look at what `man close` says and `man fcntl` says. My understanding of it is that we use `fcntl(fd, F_SETFD, FD_CLOEXEC)` (the `1` in the example corresponds to `FD_CLOEXEC`) if we want to close a specific file descriptor only if a subsequent call to `execvp` (or similar exec function) succeeds. If the subsequent call to `execvp` fails, then the file descriptor won't be closed. From what I understand of the code in jdwp, I don't think we need that behaviour here. Plus using `fcntl` won't get rid of our `closeDescriptors()` function. We will still need it, it's just the call to `close()` within the loop that gets replaced by a call to `fcntl`.

> Should this be:
> (void)close(fd);
> and
> (void)closedir(dp);
> to show that we're ignoring the return value?

Done. I've updated the PR to cast these calls to void.

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

PR Comment: https://git.openjdk.org/jdk/pull/17588#issuecomment-1913151651
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1468462470

From jpai at openjdk.org  Sat Jan 27 13:12:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 27 Jan 2024 13:12:34 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v2]
In-Reply-To: <3D0JN8zJ3PJKTdn2lHCJN1a5u5sjk6E75ZjgBiDnrGA=.6388e950-8fad-4440-8854-419eccaaa121@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
 <GKSCmMTq_TUFfDTCZlqJVroRX2YSDg7Ig6LuPZ0WWYU=.a04ef702-9e94-4f07-973b-bf5244fae670@github.com>
 <3D0JN8zJ3PJKTdn2lHCJN1a5u5sjk6E75ZjgBiDnrGA=.6388e950-8fad-4440-8854-419eccaaa121@github.com>
Message-ID: <02HMhkUIpSd3fGhJo95kpBWRqlX_PYIY2UZl0hlPYBo=.88cf5bf5-41a1-474a-b2e7-32df6d1e7407@github.com>

On Sat, 27 Jan 2024 13:06:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 112:
>> 
>>> 110:     }
>>> 111: 
>>> 112:     closedir(dp);
>> 
>> Should this be:
>> 
>> `(void)close(fd);`
>> 
>> and 
>> 
>> `(void)closedir(dp);`
>> 
>> to show that we're ignoring the return value?
>> 
>> Since this area is pretty mysterious to deal with, should we consider checking whether `closedir()` actually returns am error, and at least be verbal and print a warning, as opposed to silently ignoring it?
>> 
>> Printing a warning, might help us diagnose any issue in the future?
>
>> Should this be:
>> (void)close(fd);
>> and
>> (void)closedir(dp);
>> to show that we're ignoring the return value?
> 
> Done. I've updated the PR to cast these calls to void.

>Since this area is pretty mysterious to deal with, should we consider checking whether closedir() actually returns am error, and at least be verbal and print a warning, as opposed to silently ignoring it?
Printing a warning, might help us diagnose any issue in the future?

I think printing a warning if closedir() fails may not be useful and may be misleading too. But your point about logging a warning in this area sounds reasonable. I think what we could log as a warning is if we fallback to the slow sequential close() approach if/when this optimal closeDescriptor() implementation fails. I've updated the PR with such a log message. Do you think that would be enough?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1468463361

From sroy at openjdk.org  Sat Jan 27 17:34:51 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Sat, 27 Jan 2024 17:34:51 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v10]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <rRGKRVz6VgqhmsXOdx4Uytl6Kngn3OsNHezogzmIhm8=.4b4bb6ed-0d91-4e8c-8060-95f7ca45cf00@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  update comment for reveiew

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/212f16be..cbad4f9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=08-09

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

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

From sroy at openjdk.org  Sat Jan 27 17:38:59 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Sat, 27 Jan 2024 17:38:59 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v11]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <m0w6Rh_2nNuZ_vmFcBRok-cK5XDJtgZMGwKrl_VzrQE=.b469dc8d-50c2-44b4-8c3e-99036f6acb31@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  update comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/cbad4f9a..257f5def

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=09-10

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

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

From coleenp at openjdk.org  Sat Jan 27 18:24:45 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 27 Jan 2024 18:24:45 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v4]
In-Reply-To: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
Message-ID: <VDN-gIdDCqBkHkD35koqr2pfHVHSxwOdoq6s-ayJnx4=.6343f049-9a77-4754-b122-23674b2bd296@github.com>

> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
> 
> Ran tier1-4 testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix one nullptr in comments as found by @kevinw

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17593/files
  - new: https://git.openjdk.org/jdk/pull/17593/files/33786c7d..6eb051ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=02-03

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

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

From aturbanov at openjdk.org  Sat Jan 27 20:06:35 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 27 Jan 2024 20:06:35 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v2]
In-Reply-To: <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <JCXRTONFAN58B3-zIFuJss0udyQnvqjfm304GNBO7ys=.d2df9c19-3540-4e43-baa3-8e0ed48bae8a@github.com>
Message-ID: <0vwScnU8_Eth5eHORE8vCDizOD_zp4Gxn1w9kv8HMQ0=.949aeef5-1d10-416d-9bb2-12e745208ec5@github.com>

On Thu, 18 Jan 2024 16:19:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
>> 
>> 
>> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
>> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
>> 
>> 
>> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
>> 
>> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
>> 
>> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
>> 
>> The same changes are also being made to "clhsdb pstack".
>> 
>> Tested with all tier1, tier2, and tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update clhsdb docs
>  - update clhsdb docs

test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.java line 67:

> 65:                     String[] words = line.split(key + "|[, ]");
> 66:                     for (String word : words) {
> 67:                         word = word.replace("<","").replace(">","");

Suggestion:

                        word = word.replace("<", "").replace(">", "");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17479#discussion_r1468628161

From cjplummer at openjdk.org  Sun Jan 28 01:20:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sun, 28 Jan 2024 01:20:53 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v3]
In-Reply-To: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
Message-ID: <KpAfbrA-yX0I16-4GlN1OvoyYQ2Wdsfdlcehqu5Y50o=.0edde44e-c751-4a1b-9111-e53b875165c0@github.com>

> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
> 
> 
> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
> 
> 
> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
> 
> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
> 
> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
> 
> The same changes are also being made to "clhsdb pstack".
> 
> Tested with all tier1, tier2, and tier5 svc tests.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  fix spacing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17479/files
  - new: https://git.openjdk.org/jdk/pull/17479/files/814739bb..6c24a9a2

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

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

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

From kbarrett at openjdk.org  Sun Jan 28 20:28:26 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 28 Jan 2024 20:28:26 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v4]
In-Reply-To: <VDN-gIdDCqBkHkD35koqr2pfHVHSxwOdoq6s-ayJnx4=.6343f049-9a77-4754-b122-23674b2bd296@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <VDN-gIdDCqBkHkD35koqr2pfHVHSxwOdoq6s-ayJnx4=.6343f049-9a77-4754-b122-23674b2bd296@github.com>
Message-ID: <Q9h9trY8ckjV5nDfdjk8hJbRTsPqYc5FVj3LrwMeZzQ=.63db64a7-f965-4190-8026-5bf73a1ac85f@github.com>

On Sat, 27 Jan 2024 18:24:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one nullptr in comments as found by @kevinw

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17593#pullrequestreview-1847625136

From winterhalter at openjdk.org  Sun Jan 28 22:31:49 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Sun, 28 Jan 2024 22:31:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <7rswMpX1cL2AfryP_cxE3X7Hk842-nUFBQaWYMnKUcU=.782c5798-190b-449b-a2cb-db230dc8bab4@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

I tried to give the discussion a fresh start but moved it to the mailing list: https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/118622.html

I have given this some thought the recent years, so I hope that there is a solution in reach that satisfies everybody's concerns and needs.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1913742617

From winterhalter at openjdk.org  Sun Jan 28 22:35:48 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Sun, 28 Jan 2024 22:35:48 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <2RB7SwGiyahPB7R5RfttDGLfWp9jwy_5lU8CisrKSJI=.b2792938-08db-4146-b5d3-36370642d0e5@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
 <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>
 <2RB7SwGiyahPB7R5RfttDGLfWp9jwy_5lU8CisrKSJI=.b2792938-08db-4146-b5d3-36370642d0e5@github.com>
Message-ID: <Lo0JhBp8rq_V7WZ6vpDZrodCZ8MYuerDCx2DguNCqMk=.0d1eef24-c3b6-4bc7-b97e-81fd306d02d6@github.com>

On Thu, 25 Jan 2024 10:04:08 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> pass a non-null Instrumentation instance i.e. to have agent capabilities.

What stops people from supplying a fake instance? Wouldn't you need to "test run" the instance first?

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1913743577

From dholmes at openjdk.org  Mon Jan 29 04:46:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 29 Jan 2024 04:46:35 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v3]
In-Reply-To: <XIrn2WdSM-FXgv8_CQ9Fl-Aqr4SCZ2ykYBBkCfTQYXk=.c2ee8419-436c-4045-91a6-8e44d5992553@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <XIrn2WdSM-FXgv8_CQ9Fl-Aqr4SCZ2ykYBBkCfTQYXk=.c2ee8419-436c-4045-91a6-8e44d5992553@github.com>
Message-ID: <t-V0AbCi8QpMpgQ3JUN2AYQm8iWLwTnamTtW2mqO8xo=.3b540373-1847-4a3b-bdfe-8db05d1e411c@github.com>

On Sat, 27 Jan 2024 13:09:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - log a warning message if we fallback to slower logic of closing file descriptors
>  - ignore return values, cast to void

Thanks for taking this on @jaikiran and for determining the underlying problem!

Seems a reasonable approach to copy. A few nits and a suggestion.

Thanks.

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 52:

> 50: 
> 51: int
> 52: isAsciiDigit(char c)

The standard `isdigit` function from `ctype.h` does this.

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 75:

> 73: // input/output/error file descriptors will not be closed
> 74: // by this function. this function returns 0 on failure
> 75: // and 1 on success

Pre-existing nit: Please start sentences with a capital and end with a period. Thanks. This applies through the copied code.

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 103:

> 101: #endif
> 102: 
> 103:     if ((dp = opendir(FD_DIR)) == NULL)

It is better to log the failure here, where you can actually report the reason.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17588#pullrequestreview-1847815765
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1469067372
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1469067771
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1469069319

From dholmes at openjdk.org  Mon Jan 29 05:32:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 29 Jan 2024 05:32:34 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v4]
In-Reply-To: <VDN-gIdDCqBkHkD35koqr2pfHVHSxwOdoq6s-ayJnx4=.6343f049-9a77-4754-b122-23674b2bd296@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <VDN-gIdDCqBkHkD35koqr2pfHVHSxwOdoq6s-ayJnx4=.6343f049-9a77-4754-b122-23674b2bd296@github.com>
Message-ID: <mbjNOPXWZ93rQLnQzXpRHq1-dyU3vK6fj9L_INFgTdI=.ce754a0a-ebf5-485d-97df-a2bed6d76e1e@github.com>

On Sat, 27 Jan 2024 18:24:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one nullptr in comments as found by @kevinw

Looks good. Thanks for doing the text changes as well, they are a necessary part of the cleanup.

A number of files are missing copyright updates - the ones I spotted all had a single copyright year so maybe your script missed them?

My browser found 21 places where nullptr is cast to something else, which should no longer be needed.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17593#pullrequestreview-1847855251

From aph at openjdk.org  Mon Jan 29 09:45:37 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 29 Jan 2024 09:45:37 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <GHUgpoRQC7ordHnCGIa3eHazLiUDI-PyLiNSz7QuM9Y=.a4d7d427-0904-4e0c-83ca-0636d6b4137e@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <POaFoSfp8uLeUyTfDSbWMJS6_b6m_C7wgKkPA32LQrQ=.c7e1404f-5585-457f-9bd6-5d7dbbdbfd84@github.com>
 <GHUgpoRQC7ordHnCGIa3eHazLiUDI-PyLiNSz7QuM9Y=.a4d7d427-0904-4e0c-83ca-0636d6b4137e@github.com>
Message-ID: <EjtLTW8ZPUkYpHafr_jR5aLnssUJcedu08sByKGAgOo=.7b8badbb-c009-4eba-b3b9-2e597cb5bcb6@github.com>

On Wed, 24 Jan 2024 22:30:38 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Maybe we could live with symbol redefinition using #define (conditionally for static linking in OpenJDK, as Coleen suggested earlier) for now, until the tooling can support symbol localizing better. Then localizing symbols using tools like `objcopy` can be the longer term and cleaner solution, instead of using namespace. What's your thoughts on that?

I suppose so, but why?

Why should any of this have to work on old systems? If their binutils is broken, static linking of openjdk won't work there.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1914316881

From jkern at openjdk.org  Mon Jan 29 09:51:40 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 29 Jan 2024 09:51:40 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v11]
In-Reply-To: <m0w6Rh_2nNuZ_vmFcBRok-cK5XDJtgZMGwKrl_VzrQE=.b469dc8d-50c2-44b4-8c3e-99036f6acb31@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <m0w6Rh_2nNuZ_vmFcBRok-cK5XDJtgZMGwKrl_VzrQE=.b469dc8d-50c2-44b4-8c3e-99036f6acb31@github.com>
Message-ID: <oafXeyNylwlnKFzjgMkN4HdB_dEL0Qfu8MlL3kDtI5g=.e529938b-d393-4777-a4cf-50977fbdbb14@github.com>

On Sat, 27 Jan 2024 17:38:59 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comment

src/hotspot/os/aix/os_aix.cpp line 1166:

> 1164:  Search order:
> 1165:  libfilename-> load "libfilename.so" first,then load libfilename.a,on failure. 
> 1166:  In,OpenJ9,the libary with .so extension is loaded first and then .a extension,on failure.

Hi Suchi, I'm puzzled. Your comment implies for me, that load library gets a 'base' filename without 'lib' prefix and without extension (e.g. 'name'). Then the j9 code creates the filename 'libname.so' first and on failure 'libname.a' second. What about given libname.so explicitly (e.g. libname.so)? Does j9 really use 'libname.a' as a failure fallback in this case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1469331769

From jpai at openjdk.org  Mon Jan 29 10:00:37 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 29 Jan 2024 10:00:37 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
Message-ID: <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
> 
> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - add a log message to help debuggability
 - improve code comments
 - David's review - use standard isdigit instead of custom isAsciiDigit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17588/files
  - new: https://git.openjdk.org/jdk/pull/17588/files/af2472d4..e4a8573b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17588&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17588&range=02-03

  Stats: 25 lines in 1 file changed: 4 ins; 6 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/17588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17588/head:pull/17588

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

From jpai at openjdk.org  Mon Jan 29 10:05:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 29 Jan 2024 10:05:27 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v3]
In-Reply-To: <XIrn2WdSM-FXgv8_CQ9Fl-Aqr4SCZ2ykYBBkCfTQYXk=.c2ee8419-436c-4045-91a6-8e44d5992553@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <XIrn2WdSM-FXgv8_CQ9Fl-Aqr4SCZ2ykYBBkCfTQYXk=.c2ee8419-436c-4045-91a6-8e44d5992553@github.com>
Message-ID: <nGzgv7E1YbK43xzB4ojQFUTL6U2wqR-SemG-jo_Dgs4=.eea84afc-5943-466a-acfe-fca328a93242@github.com>

On Sat, 27 Jan 2024 13:09:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - log a warning message if we fallback to slower logic of closing file descriptors
>  - ignore return values, cast to void

Thank you David for those inputs, I've updated the PR to implement those suggestions. CI tests continue to pass with these latest changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/17588#issuecomment-1914348518

From jpai at openjdk.org  Mon Jan 29 10:05:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 29 Jan 2024 10:05:28 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v3]
In-Reply-To: <t-V0AbCi8QpMpgQ3JUN2AYQm8iWLwTnamTtW2mqO8xo=.3b540373-1847-4a3b-bdfe-8db05d1e411c@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <XIrn2WdSM-FXgv8_CQ9Fl-Aqr4SCZ2ykYBBkCfTQYXk=.c2ee8419-436c-4045-91a6-8e44d5992553@github.com>
 <t-V0AbCi8QpMpgQ3JUN2AYQm8iWLwTnamTtW2mqO8xo=.3b540373-1847-4a3b-bdfe-8db05d1e411c@github.com>
Message-ID: <VHR2peBOjLnGClr10u3YZ850_OshId0Zk3ZGaq8GK38=.828d7fb6-18d5-4f8d-96f5-8daa724f7aee@github.com>

On Mon, 29 Jan 2024 04:36:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - log a warning message if we fallback to slower logic of closing file descriptors
>>  - ignore return values, cast to void
>
> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 52:
> 
>> 50: 
>> 51: int
>> 52: isAsciiDigit(char c)
> 
> The standard `isdigit` function from `ctype.h` does this.

Done.

> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 75:
> 
>> 73: // input/output/error file descriptors will not be closed
>> 74: // by this function. this function returns 0 on failure
>> 75: // and 1 on success
> 
> Pre-existing nit: Please start sentences with a capital and end with a period. Thanks. This applies through the copied code.

I've fixed the code comments to follow this suggestion. I've left single sentence comments as is. If there's a preference to change them too, do let me know and I'll update those too.

> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 103:
> 
>> 101: #endif
>> 102: 
>> 103:     if ((dp = opendir(FD_DIR)) == NULL)
> 
> It is better to log the failure here, where you can actually report the reason.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1469351351
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1469351192
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1469349326

From coleenp at openjdk.org  Mon Jan 29 13:47:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 29 Jan 2024 13:47:10 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v5]
In-Reply-To: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
Message-ID: <I0UBah5NsZf9g0KrwVSwo0McRdcH_ypvwGSyv3xok-U=.f986066c-3bf8-4c50-9bcc-4511d5023086@github.com>

> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
> 
> Ran tier1-4 testing.

Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:

 - Fix some casts unnecessary with nullptr
 - Fix copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17593/files
  - new: https://git.openjdk.org/jdk/pull/17593/files/6eb051ed..6ac8aa85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17593&range=03-04

  Stats: 32 lines in 27 files changed: 0 ins; 0 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/17593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17593/head:pull/17593

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

From adinn at openjdk.org  Mon Jan 29 14:15:42 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 29 Jan 2024 14:15:42 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <Lo0JhBp8rq_V7WZ6vpDZrodCZ8MYuerDCx2DguNCqMk=.0d1eef24-c3b6-4bc7-b97e-81fd306d02d6@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
 <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>
 <2RB7SwGiyahPB7R5RfttDGLfWp9jwy_5lU8CisrKSJI=.b2792938-08db-4146-b5d3-36370642d0e5@github.com>
 <Lo0JhBp8rq_V7WZ6vpDZrodCZ8MYuerDCx2DguNCqMk=.0d1eef24-c3b6-4bc7-b97e-81fd306d02d6@github.com>
Message-ID: <C6ZCrH9DtLEQqsgUwAlXUJaIgStp_9Yf3P9n3-QsLMU=.f94f2e5d-90d4-4284-a8f4-fd939a2bd11a@github.com>

On Sun, 28 Jan 2024 22:33:01 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> What stops people from supplying a fake instance? Wouldn't you need to "test run" the instance first?

Not necessarily. When the generated API implementation relies on the capabilities of class `Instrumentation` -- such as opening modules -- to implement the invoked operation the obvious answer is that a fake instance just won't work.

However, if you want the implementation to validate an incoming call you can easily arrange for that. For example, provide a method on the agent class that says yes to its own instance and no for any other instances e.g.

    class AgentClass {
      private static Instrumentation myInst = null;
      
      void premain(Instrumentation inst) {
        myInst = inst;
        . . .
      }
      static boolean validate(Instrumentation inst) {
        return myInst != null && inst == myInst;
      }
?     . . .
    }

Method validate can be used to ensure API calls only proceed when invoked by the agent or code that the agent trusts.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1914771074

From alanb at openjdk.org  Mon Jan 29 14:15:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 29 Jan 2024 14:15:42 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <C6ZCrH9DtLEQqsgUwAlXUJaIgStp_9Yf3P9n3-QsLMU=.f94f2e5d-90d4-4284-a8f4-fd939a2bd11a@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <U_0p6ctLQReK0RbnRBgDiraMsJ_j-NxBT9Qi0Dev9W8=.e23b0ec6-c68f-479d-9e24-b7985f82d9a2@github.com>
 <5OaPKxqXNhRzrKVMMhcea-ETeGNKoy-o3h5U3Er28EI=.9fe50b1e-1c42-49da-b449-711cbbb39116@github.com>
 <2RB7SwGiyahPB7R5RfttDGLfWp9jwy_5lU8CisrKSJI=.b2792938-08db-4146-b5d3-36370642d0e5@github.com>
 <Lo0JhBp8rq_V7WZ6vpDZrodCZ8MYuerDCx2DguNCqMk=.0d1eef24-c3b6-4bc7-b97e-81fd306d02d6@github.com>
 <C6ZCrH9DtLEQqsgUwAlXUJaIgStp_9Yf3P9n3-QsLMU=.f94f2e5d-90d4-4284-a8f4-fd939a2bd11a@github.com>
Message-ID: <0mdILE5g2WCORrs1VlB020SXMvah9tMwJ9BUznM75YM=.835e3a50-1f36-4971-90a4-31414aa4229d@github.com>

On Mon, 29 Jan 2024 14:09:40 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> What stops people from supplying a fake instance? Wouldn't you need to "test run" the instance first?

In passing, Instrumentation was a candidate to be sealed at one point as the only implementations should be in the java.instrument module. I haven't seen any delegating or other implementations but they might exist so we would need to be careful with compatibility.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1914776078

From coleenp at openjdk.org  Mon Jan 29 14:26:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 29 Jan 2024 14:26:38 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v5]
In-Reply-To: <I0UBah5NsZf9g0KrwVSwo0McRdcH_ypvwGSyv3xok-U=.f986066c-3bf8-4c50-9bcc-4511d5023086@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <I0UBah5NsZf9g0KrwVSwo0McRdcH_ypvwGSyv3xok-U=.f986066c-3bf8-4c50-9bcc-4511d5023086@github.com>
Message-ID: <o4v044HFH-d92IoeI78R_3gTrDftveooAeF5hl40JNo=.759c3688-f42c-4b21-8508-cdcc9b893819@github.com>

On Mon, 29 Jan 2024 13:47:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix some casts unnecessary with nullptr
>  - Fix copyrights

Thanks Kevin, Kim and David for wading through this.  If there are other changes we can address them separately preserving your eyeballs.  My copyright script was broken so I fixed it.  I'll wait for GHA to make sure I didn't break anything before integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/17593#issuecomment-1914798074

From winterhalter at openjdk.org  Mon Jan 29 14:29:57 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Mon, 29 Jan 2024 14:29:57 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
Message-ID: <6kHfPwdakIRh3eVC19EOf2jP88YZi6ZsC83bur272CI=.8758fd3f-4186-420d-8ff7-edd4d0610a17@github.com>

On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8200559: Java agents doing instrumentation need a means to define auxiliary classes

There's plenty of them in Byte Buddy and I have seen a bunch in other agents.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1914804192

From adinn at openjdk.org  Mon Jan 29 14:34:04 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 29 Jan 2024 14:34:04 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <7RTva_kbE-aUHejsBwTh8YFq43cB6-gt2JvvbhMXWqA=.50072ddc-9e12-4e42-a138-4e26d6c249b4@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
 <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>
 <LNzmw9QhdWMr72Ej8bIhzdhhzfPQqPlrIqqvZMCOToI=.f226f9e7-52cc-4b6d-8fa4-c0ac28f14a18@github.com>
 <7RTva_kbE-aUHejsBwTh8YFq43cB6-gt2JvvbhMXWqA=.50072ddc-9e12-4e42-a138-4e26d6c249b4@github.com>
Message-ID: <lvXe_HcwLDsEJVHFdI3bRXvNF8BflBECkcO02oudXy8=.d6b04242-a81d-48a1-8f0c-8d60faa0e7ac@github.com>

On Sat, 27 Jan 2024 05:11:28 GMT, Alexander Kriegisch <duke at openjdk.org> wrote:

> Bytecode transformation should not be rocket science, but it progressively is developing in that direction.

Hmm? Bytecode transformation of the JDK runtime implementation is a lot more complicated than your comments seem to acknowledge and, here's the important thing, *it always has been*. You need to remember that instrumenting JDK runtime code involves rebuilding the engine that you are driving while you are in mid-flight. If you think there are few-to-none hidden gotchas involved in doing that then I suggest you are significantly underestimating the opportunity for things to go wrong -- not just when it comes to instrumenting some specific release of OpenJDK but also when it comes to keeping instrumentation working across legacy and future releases, with all the variety of moving parts that the (necessary) development of the platform requires. 

The same observation explains why project Jigsaw was needed. The danger of clients using internal JDK runtime APIs -- especially the core runtime APIs -- is much more subtle than many of the programmers who have routinely relied on it recognize. The biggest threat is that public runtime APIs are often implemented via calls to multiple internal APIs -- which may themselves involve multiple entries and re-entries to the JVM. It has always been (and always will be) the case that an isolated call from a client to an internal API can leave the JDK runtime and/or the JVM in an incoherent state because correct use of that internal API requires a correct sequence of invocations with matched inputs and outputs. It is easy even for OpenJDK developers to fails to get this right, especially when calls involve entry to the JVM. The possibility for a programmer who is not very familiar with the JDK runtime code and the JVM code to get it wrong are significant. Worse, the problems may not manifest 
 immediately or in all cases so the danger can be unapparent until disaster strikes.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1914812297

From kevinw at openjdk.org  Mon Jan 29 15:09:54 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 29 Jan 2024 15:09:54 GMT
Subject: RFR: 8324845: management.properties text "interface name" is
 misleading
Message-ID: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>

We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.

This change only affects comment text in a properties file.

(We don't currently mention this property in other docs, e.g. in the M&M guide.)

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

Commit messages:
 - 8324845: management.properties text "interface name" is misleading

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

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

From alanb at openjdk.org  Mon Jan 29 15:27:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 29 Jan 2024 15:27:46 GMT
Subject: RFR: 8324845: management.properties text "interface name" is
 misleading
In-Reply-To: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
Message-ID: <umLA7Z-w0LoiGkLIspdjUAjiDnliDq24TeYkvp8WSMY=.2f3b3c98-565c-4594-81ea-7e8ea52cfa9d@github.com>

On Mon, 29 Jan 2024 14:45:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.
> 
> This change only affects comment text in a properties file.
> 
> (We don't currently mention this property in other docs, e.g. in the M&M guide.)

src/jdk.management.agent/share/conf/management.properties line 258:

> 256: #
> 257: # com.sun.management.jmxremote.host=<host-name-or-address>
> 258: #      Specifies the address on which the JMX RMI agent will bind.

The placeholder is "host-name-or-address" so it might be clearer to say the local host name or IP address in the description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17615#discussion_r1469761254

From coleenp at openjdk.org  Mon Jan 29 17:10:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 29 Jan 2024 17:10:42 GMT
Subject: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files [v5]
In-Reply-To: <I0UBah5NsZf9g0KrwVSwo0McRdcH_ypvwGSyv3xok-U=.f986066c-3bf8-4c50-9bcc-4511d5023086@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
 <I0UBah5NsZf9g0KrwVSwo0McRdcH_ypvwGSyv3xok-U=.f986066c-3bf8-4c50-9bcc-4511d5023086@github.com>
Message-ID: <nG_zjtFu6UUgJ4xUOdf5O53odsLpn9a1UCfJsbT-iVQ=.9aaaa73f-b908-4bfa-88bb-d8288ea1e722@github.com>

On Mon, 29 Jan 2024 13:47:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
>> 
>> Ran tier1-4 testing.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix some casts unnecessary with nullptr
>  - Fix copyrights

macos-aarch64 build failure in GHA appears unrelated, internal testing passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17593#issuecomment-1915186403

From coleenp at openjdk.org  Mon Jan 29 17:10:43 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 29 Jan 2024 17:10:43 GMT
Subject: Integrated: 8324681: Replace NULL with nullptr in HotSpot jtreg test
 native code files
In-Reply-To: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
References: <OU3-NElpWa5GtiGr0yfe8pQmBlzVsuEP4HXgDUhhICs=.9936a00e-9ff2-4d1c-a4b7-24cf4d24cfa8@github.com>
Message-ID: <N5ZQ1ViMwFbAI4AUM1smPAoRTHPdo4nMoYS6D_m8mro=.b1ab6e02-7193-435c-a1f9-8cf6696d6bb5@github.com>

On Fri, 26 Jan 2024 16:40:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This mechanically replaces NULL with nullptr in hpp/cpp native files in test native code.  This didn't attempt to change NULL in comments to say null because nullptr is generally the right thing for the comment to say.  It does attempt to change NULL to "null" rather than "nullptr" in strings.  Any changes for "nullptr" to "null" in comments can be changed in a future RFE in a smaller patch. I didn't see any when it was scrolling by to make my script more complicated.
> 
> Ran tier1-4 testing.

This pull request has now been integrated.

Changeset: a6bdee48
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6bdee48f39993128d8095d40ab417f0102af0f4
Stats:     8218 lines in 750 files changed: 0 ins; 7 del; 8211 mod

8324681: Replace NULL with nullptr in HotSpot jtreg test native code files

Reviewed-by: kevinw, kbarrett, dholmes

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

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

From gziemski at openjdk.org  Mon Jan 29 17:59:41 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 29 Jan 2024 17:59:41 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
Message-ID: <o2BgRS6H2Z4cmEQy_oZwXKsJNBq3jfcpIg_94fzuxvM=.95f5efe1-2584-4f4c-83bf-68aeb1d68ab0@github.com>

On Mon, 29 Jan 2024 10:00:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - add a log message to help debuggability
>  - improve code comments
>  - David's review - use standard isdigit instead of custom isAsciiDigit

Again, the changes make the code better already, I just want to make sure take this opportunity to polish this code really well...

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 108:

> 106:         if (isdigit(dirp->d_name[0]) &&
> 107:             (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd) {
> 108:             (void)close(fd);

I'd really, really like to check `close()` for errors and report any.

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 138:

> 136:                   " %d file descriptors sequentially", (max_fd - i + 1)));
> 137:         for (; i < max_fd; i++) {
> 138:             (void)close(i);

Here as well, I'd really like to check for `close()`for errors here and report any.

And if we find errors here, do we really want to proceed knowing that something went wrong already?

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

Changes requested by gziemski (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17588#pullrequestreview-1849357100
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1469984071
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1469979677

From gziemski at openjdk.org  Mon Jan 29 17:59:41 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 29 Jan 2024 17:59:41 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v2]
In-Reply-To: <I-zTW05Frb8E6eFJrQDKmt6WIzib4Xk_5TR2kz3l2kE=.40d73f10-8247-4e01-a587-5b0b078522c7@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
 <GKSCmMTq_TUFfDTCZlqJVroRX2YSDg7Ig6LuPZ0WWYU=.a04ef702-9e94-4f07-973b-bf5244fae670@github.com>
 <I-zTW05Frb8E6eFJrQDKmt6WIzib4Xk_5TR2kz3l2kE=.40d73f10-8247-4e01-a587-5b0b078522c7@github.com>
Message-ID: <pg15xZVlpzWAZd5Qvkdl7OjGALd5vSB-Z0OAbJxj4PU=.4bebdf44-ed75-4a4d-a060-982250bebe90@github.com>

On Sat, 27 Jan 2024 01:18:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 129:
>> 
>>> 127:          * and assume all were opened for the parent process and
>>> 128:          * copied over to this child process. we close them all */
>>> 129:         const rlim_t max_fd = sysconf(_SC_OPEN_MAX);
>> 
>> Why not use `int`, like the original code, instead of  `rlim_t` - as per man page `close()` expects `int`, not  `rlim_t`, ex:
>> 
>> 
>>         const int max_fd = (int)sysconf(_SC_OPEN_MAX);
>>         JDI_ASSERT(max_fd != -1);
>>         int fd;
>>          /* leave out standard input/output/error file descriptors */
>>          for (fd = STDERR_FILENO + 1; fd < max_fd; fd++) {
>>              (void)close(fd);
>>          }
>
> Hello Gerard, my understanding is that the limit value configured may exceed the int range. I wanted to avoid the overflow by casting it to int in such cases. I had noticed close() takes an int, but I couldn't think of any other way of avoiding the overflow at this place.
> 
> In the JVM parent process we do however limit it to INT_MAX. So maybe I should assume that it will be an int cast it to int here, like you suggest, and add a code comment explaining this? Does that sound OK?

That is fine, but in that case we should also do:

`JDI_ASSERT(max_fd <= INT_MAX);`

in case `sysconf(_SC_OPEN_MAX)` returns value greater than `INT_MAX`, since `close()` only accepts `int`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1469976093

From cjplummer at openjdk.org  Mon Jan 29 19:23:40 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 29 Jan 2024 19:23:40 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <o2BgRS6H2Z4cmEQy_oZwXKsJNBq3jfcpIg_94fzuxvM=.95f5efe1-2584-4f4c-83bf-68aeb1d68ab0@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
 <o2BgRS6H2Z4cmEQy_oZwXKsJNBq3jfcpIg_94fzuxvM=.95f5efe1-2584-4f4c-83bf-68aeb1d68ab0@github.com>
Message-ID: <0yYC_Wz-BlaIrvMhaKAg-51Z3xH0mcCDKX1ps8gAU0s=.cb372918-ab17-44bb-a285-f506ecc023df@github.com>

On Mon, 29 Jan 2024 17:51:36 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - add a log message to help debuggability
>>  - improve code comments
>>  - David's review - use standard isdigit instead of custom isAsciiDigit
>
> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 108:
> 
>> 106:         if (isdigit(dirp->d_name[0]) &&
>> 107:             (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd) {
>> 108:             (void)close(fd);
> 
> I'd really, really like to check `close()` for errors and report any.

I agree. If we are seeing issues with close(), probably it is best to fail. That way we'll get a bug report and can figure out exactly why it is failing rather than blindly proceeding without having properly closed all fds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1470089453

From cjplummer at openjdk.org  Mon Jan 29 19:28:32 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 29 Jan 2024 19:28:32 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
Message-ID: <S3GQ86djs3MeWXtTVzy0236LqKLTkiVKI6_KxbdUdpI=.92cb0c03-3e46-49db-abb8-bcf40aa9e656@github.com>

On Mon, 29 Jan 2024 10:00:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - add a log message to help debuggability
>  - improve code comments
>  - David's review - use standard isdigit instead of custom isAsciiDigit

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 129:

> 127:         /* Find max allowed file descriptors for a process
> 128:          * and assume all were opened for the parent process and
> 129:          * copied over to this child process. We close them all. */

I'm somewhat leaning towards this just being a fatal error. Why would it ever fail? Do we think the version in childproc.c that also does this is doing so for a good reason, or perhaps just like jdwp it used to use the slow version and then kept it around as a backup when the faster version was introduced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1470094640

From duke at openjdk.org  Tue Jan 30 01:02:49 2024
From: duke at openjdk.org (Alexander Kriegisch)
Date: Tue, 30 Jan 2024 01:02:49 GMT
Subject: RFR: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes [v2]
In-Reply-To: <lvXe_HcwLDsEJVHFdI3bRXvNF8BflBECkcO02oudXy8=.d6b04242-a81d-48a1-8f0c-8d60faa0e7ac@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
 <CQQLO4gu1VuxmkByJ7xymp9D3wqFRmg2z8C3LUYlbsI=.65bc8dad-5859-4ff2-994d-3ca09284b47c@github.com>
 <YQZ4QJBHTjO_XFo30AmfC9udDGDL--lr9AdR0RfbN84=.61db56b8-b75e-4241-aa54-5978aabb876e@github.com>
 <TZYKYU9nc3X0XxQA7RROYwOgYXnEh3h2ipMIJoZjrZU=.12622e34-7593-40ed-9f9c-98ec38d069f1@github.com>
 <aRF-ee4mMzEPk3cAyMCbYCB3IedFYFP4rniNe6w3ovI=.e1c864b2-dbbf-42b9-b1f2-b2ec65ed21ae@github.com>
 <nLD0btpcjGydE6OcNaPuzmOZcAgZnFcqFqHx4jLK29Y=.de27f28d-110a-494f-b308-590646ee1ba5@github.com>
 <UcG-EbUP8X97R9QQyqzZE9DkQCPHM9oU5MsGYnnPqQA=.d499b80a-fc4d-4dde-8e71-3664a2e5372d@github.com>
 <LNzmw9QhdWMr72Ej8bIhzdhhzfPQqPlrIqqvZMCOToI=.f226f9e7-52cc-4b6d-8fa4-c0ac28f14a18@github.com>
 <7RTva_kbE-aUHejsBwTh8YFq43cB6-gt2JvvbhMXWqA=.50072ddc-9e12-4e42-a138-4e26d6c249b4@github.com>
 <lvXe_HcwLDsEJVHFdI3bRXvNF8BflBECkcO02oudXy8=.d6b04242-a81d-48a1-8f0c-8d60faa0e7ac@github.com>
Message-ID: <rZ2TyCYxB7JqMY1RDUGGrQbMywllrhX8QftJ7NqeVIk=.6885eb39-425c-423c-9d7d-2f4e2efebb24@github.com>

On Mon, 29 Jan 2024 14:31:10 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> > Bytecode transformation should not be rocket science, but it progressively is developing in that direction.
> 
> Hmm? Bytecode transformation of the JDK runtime implementation is a lot more complicated than your comments seem to acknowledge

That is, because I was not talking about JDK runtime transformation but about what the AspectJ weaving agent does: transformation of application classes during class-loading.

I am aware of the fact, that it is also possible to retransform already loaded classes, as a special case also bootstrap ones from the JRE. Of course, this is more complicated than the simple case. But my point was, that even the simple case is not simple, if I need to define classes in an arbitrary class loader - not because technically it is difficult, but simply because the JRE API to do so is more and more sealed off with each new Java release. This is also what I mean, when I said, that developers are not treated as adults but "protected" by well-meaning, but ill-doing helicopter parents.

> here's the important thing, _it always has been_.

No, byte code transformation is not complicated per se. Getting the transformed classes where they need to be is complicated, but artificially so.

> You need to remember that instrumenting JDK runtime code involves rebuilding the engine that you are driving while you are in mid-flight.

No, I do not need to remember, because I am aware of that fact. It is just off-topic here with regard to what I asked about. But that other use case, which I have experimented with in another context (test mocking and stubbing) in the past, is an intriguing one, too. I am not underestimating anything there, but for AspectJ it is simply out of scope. Should I ever decide to add the capability to weave aspects into JRE classes, of course that will up the complexity by a notch or two.

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

PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1915860036

From kbarrett at openjdk.org  Tue Jan 30 03:47:52 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 30 Jan 2024 03:47:52 GMT
Subject: RFR: 8324880: Rename get_stack_trace.h
Message-ID: <yofH_5Dxs3wJpKIwQFpNiooo1T0iascn5T91S1k3MyA=.8e6727dc-b5a4-4095-a32e-cc3ff0db5770@github.com>

Please review this trivial change that renames the file
test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/get_stack_trace.h
to get_stack_trace.hpp, and renames uses of NULL in that file.

The updates to #include lines in using files were performed mechanically.

Testing: mach5 tier1

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

Commit messages:
 - rename NULLs in get_stack_trace.hpp
 - rename get_stack_trace.h

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

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

From dholmes at openjdk.org  Tue Jan 30 04:09:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Jan 2024 04:09:37 GMT
Subject: RFR: 8318895: Deoptimization results in incorrect lightweight
 locking stack [v3]
In-Reply-To: <locHBZhVypq9uoqiad0vYK7vK2SMXqJB0rdhf98C0p0=.c605defc-c892-4890-8404-a9ce9fed26e4@github.com>
References: <eMUQpk_37Jze7CjtaNSlS8tpwH4l37CkeZszfrA__KI=.832614e8-f8ec-4ef3-bb09-7f290f97c05c@github.com>
 <locHBZhVypq9uoqiad0vYK7vK2SMXqJB0rdhf98C0p0=.c605defc-c892-4890-8404-a9ce9fed26e4@github.com>
Message-ID: <bqmKq7KWQXvdqdlwZpAL9iFIOu12QekMO3GnwLCuasM=.cfabcae0-4fca-4731-becf-50adc5ad05b4@github.com>

On Fri, 10 Nov 2023 10:41:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See JBS issue for details.
>> 
>> I basically:
>>  - took the test-modification and turned it into its own test-case
>>  - added test runners for lightweight- and legacy-locking, so that we keep testing both, no matter what is the default
>>  - added Axels fix (mentioned in the JBS issue) with the modification to only inflate when exec_mode == Unpack_none, as explained by Richard.
>> 
>> Testing:
>>  - [x] EATests.java
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/com/sun/jdi/EATests.java
>   
>   Co-authored-by: Richard Reingruber <richard.reingruber at sap.com>

This PR calls code that expects to be passed a reference to the current thread, but is instead passed the `deoptee_thread`! See https://bugs.openjdk.org/browse/JDK-8324881

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

PR Comment: https://git.openjdk.org/jdk/pull/16568#issuecomment-1916036852

From jiangli at openjdk.org  Tue Jan 30 04:23:41 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 30 Jan 2024 04:23:41 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <EjtLTW8ZPUkYpHafr_jR5aLnssUJcedu08sByKGAgOo=.7b8badbb-c009-4eba-b3b9-2e597cb5bcb6@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <POaFoSfp8uLeUyTfDSbWMJS6_b6m_C7wgKkPA32LQrQ=.c7e1404f-5585-457f-9bd6-5d7dbbdbfd84@github.com>
 <GHUgpoRQC7ordHnCGIa3eHazLiUDI-PyLiNSz7QuM9Y=.a4d7d427-0904-4e0c-83ca-0636d6b4137e@github.com>
 <EjtLTW8ZPUkYpHafr_jR5aLnssUJcedu08sByKGAgOo=.7b8badbb-c009-4eba-b3b9-2e597cb5bcb6@github.com>
Message-ID: <KeJt4PG288fXNTdf_CSXwDD7LTW7XHvSzJqAn4u4FDk=.c55192fc-e3de-4a67-a6e8-d34ba517b069@github.com>

On Mon, 29 Jan 2024 09:42:20 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Maybe we could live with symbol redefinition using #define (conditionally for static linking in OpenJDK, as Coleen suggested earlier) for now, until the tooling can support symbol localizing better. Then localizing symbols using tools like `objcopy` can be the longer term and cleaner solution, instead of using namespace. What's your thoughts on that?
> 
> I suppose so, but why?
> 
> Why should any of this have to work on old systems? If their binutils is broken, static linking of openjdk won't work there.

We ran into issues with older gcc on linux-aarch for partial linking, but the problem may not be older gcc only(?). At the current stage, limiting static/hermetic Java runtime support to only the platforms that support partial linking and `objcopy` seems to be overly restrictive (it does simplify the requirements significantly however :-)):

- The duplicate symbol problems are mostly found in JDK natives and have been resolved already. We've found very few symbol issues with hotspot code so far. As there are portable alternative solutions that can resolve the symbol issues in hotspot, choosing a less portable solution seems not too attractive currently.

- As we haven't found many duplicate symbol issues with hotspot code, resolving them case by case may still be a good choice. We don't have to tie into any permanent solution during the early stage. 

- Based on what we learned from the static/hermetic Java prototyping and investigations, majority of the work is non-os and non-cpu specific. If we can carefully handle the platform specific part with portable solution(s), we can support static/hermetic Java for different supported platforms as a more general solution.

Those are my reasonings. :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1916047210

From dholmes at openjdk.org  Tue Jan 30 06:50:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Jan 2024 06:50:41 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <0yYC_Wz-BlaIrvMhaKAg-51Z3xH0mcCDKX1ps8gAU0s=.cb372918-ab17-44bb-a285-f506ecc023df@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
 <o2BgRS6H2Z4cmEQy_oZwXKsJNBq3jfcpIg_94fzuxvM=.95f5efe1-2584-4f4c-83bf-68aeb1d68ab0@github.com>
 <0yYC_Wz-BlaIrvMhaKAg-51Z3xH0mcCDKX1ps8gAU0s=.cb372918-ab17-44bb-a285-f506ecc023df@github.com>
Message-ID: <IAMX53HQz3VAqTZmGND1xTxUOy9x3fZF6AGgNNvEXSE=.918ed3c2-ff4b-4ca9-9683-0990ef0d4ecd@github.com>

On Mon, 29 Jan 2024 19:21:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 108:
>> 
>>> 106:         if (isdigit(dirp->d_name[0]) &&
>>> 107:             (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd) {
>>> 108:             (void)close(fd);
>> 
>> I'd really, really like to check `close()` for errors and report any.
>
> I agree. If we are seeing issues with close(), probably it is best to fail. That way we'll get a bug report and can figure out exactly why it is failing rather than blindly proceeding without having properly closed all fds.

If we are going to check close for errors then we will have to know for certain we are only trying to close open fd's, and we will have to deal with EINTR. I would think this is a "best effort" to close open FD's and not something we have to care about in detail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1470666267

From dholmes at openjdk.org  Tue Jan 30 06:55:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Jan 2024 06:55:40 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <S3GQ86djs3MeWXtTVzy0236LqKLTkiVKI6_KxbdUdpI=.92cb0c03-3e46-49db-abb8-bcf40aa9e656@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
 <S3GQ86djs3MeWXtTVzy0236LqKLTkiVKI6_KxbdUdpI=.92cb0c03-3e46-49db-abb8-bcf40aa9e656@github.com>
Message-ID: <PuNXzbCvhejk4_KpjuSNJXQGL4LZnjzSktWbFI4tjuA=.4dd7734a-f5ec-4fde-8ccd-987e6cafab0a@github.com>

On Mon, 29 Jan 2024 19:25:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - add a log message to help debuggability
>>  - improve code comments
>>  - David's review - use standard isdigit instead of custom isAsciiDigit
>
> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 129:
> 
>> 127:         /* Find max allowed file descriptors for a process
>> 128:          * and assume all were opened for the parent process and
>> 129:          * copied over to this child process. We close them all. */
> 
> I'm somewhat leaning towards this just being a fatal error. Why would it ever fail? Do we think the version in childproc.c that also does this is doing so for a good reason, or perhaps just like jdwp it used to use the slow version and then kept it around as a backup when the faster version was introduced.

I think we are sliding into " the perfect is the enemy of the good" here. If you want to investigate the resilience of closing FD's then I suggest you look at that in a different PR and let Jai integrate this optimization to avoid the timeouts that were seen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1470670529

From dholmes at openjdk.org  Tue Jan 30 06:58:31 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Jan 2024 06:58:31 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
Message-ID: <7r9AVqFcdcN_Iaa5Xmm4LmvunFc9r63wpGTl1a01ZBU=.66dd84f3-fc97-4541-819f-cfd4371da434@github.com>

On Mon, 29 Jan 2024 10:00:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - add a log message to help debuggability
>  - improve code comments
>  - David's review - use standard isdigit instead of custom isAsciiDigit

Updates look good to me. Thanks.

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

PR Review: https://git.openjdk.org/jdk/pull/17588#pullrequestreview-1850352032

From alanb at openjdk.org  Tue Jan 30 07:17:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Jan 2024 07:17:31 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <IAMX53HQz3VAqTZmGND1xTxUOy9x3fZF6AGgNNvEXSE=.918ed3c2-ff4b-4ca9-9683-0990ef0d4ecd@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
 <o2BgRS6H2Z4cmEQy_oZwXKsJNBq3jfcpIg_94fzuxvM=.95f5efe1-2584-4f4c-83bf-68aeb1d68ab0@github.com>
 <0yYC_Wz-BlaIrvMhaKAg-51Z3xH0mcCDKX1ps8gAU0s=.cb372918-ab17-44bb-a285-f506ecc023df@github.com>
 <IAMX53HQz3VAqTZmGND1xTxUOy9x3fZF6AGgNNvEXSE=.918ed3c2-ff4b-4ca9-9683-0990ef0d4ecd@github.com>
Message-ID: <U36lxAEGrgSUE3Hne8JejFXlI3iBdOnt8LokkFfYakA=.29698e5d-6b04-4949-9874-a73e80eb7584@github.com>

On Tue, 30 Jan 2024 06:47:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If we are going to check close for errors then we will have to know for certain we are only trying to close open fd's, and we will have to deal with EINTR. I would think this is a "best effort" to close open FD's and not something we have to care about in detail.

Right, EINTR would need to be ignored as it would be wrong to restart. I'm scratching my head as to why this code would even do with EIO or if it even possible here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1470688246

From dholmes at openjdk.org  Tue Jan 30 07:42:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Jan 2024 07:42:41 GMT
Subject: RFR: 8324880: Rename get_stack_trace.h
In-Reply-To: <yofH_5Dxs3wJpKIwQFpNiooo1T0iascn5T91S1k3MyA=.8e6727dc-b5a4-4095-a32e-cc3ff0db5770@github.com>
References: <yofH_5Dxs3wJpKIwQFpNiooo1T0iascn5T91S1k3MyA=.8e6727dc-b5a4-4095-a32e-cc3ff0db5770@github.com>
Message-ID: <bM9UXyLVc7WdXf5DhcVHVEMsjFRB2ecnFWV9mfG2QIA=.29cb7db0-0797-4a1c-bf8d-9414f9c797e2@github.com>

On Tue, 30 Jan 2024 03:43:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change that renames the file
> test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/get_stack_trace.h
> to get_stack_trace.hpp, and renames uses of NULL in that file.
> 
> The updates to #include lines in using files were performed mechanically.
> 
> Testing: mach5 tier1

LGTM! Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17623#pullrequestreview-1850412496

From jwaters at openjdk.org  Tue Jan 30 10:18:22 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 30 Jan 2024 10:18:22 GMT
Subject: RFR: 8324880: Rename get_stack_trace.h
In-Reply-To: <yofH_5Dxs3wJpKIwQFpNiooo1T0iascn5T91S1k3MyA=.8e6727dc-b5a4-4095-a32e-cc3ff0db5770@github.com>
References: <yofH_5Dxs3wJpKIwQFpNiooo1T0iascn5T91S1k3MyA=.8e6727dc-b5a4-4095-a32e-cc3ff0db5770@github.com>
Message-ID: <aypNLtQM0_Wjgu61_rY4nfGEn0mSgd1rO-X7ne1Jlk0=.f59629c1-477c-4c4d-9bfb-9170f031da1b@github.com>

On Tue, 30 Jan 2024 03:43:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change that renames the file
> test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/get_stack_trace.h
> to get_stack_trace.hpp, and renames uses of NULL in that file.
> 
> The updates to #include lines in using files were performed mechanically.
> 
> Testing: mach5 tier1

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17623#pullrequestreview-1850791401

From aph at openjdk.org  Tue Jan 30 10:30:24 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 30 Jan 2024 10:30:24 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <KeJt4PG288fXNTdf_CSXwDD7LTW7XHvSzJqAn4u4FDk=.c55192fc-e3de-4a67-a6e8-d34ba517b069@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <POaFoSfp8uLeUyTfDSbWMJS6_b6m_C7wgKkPA32LQrQ=.c7e1404f-5585-457f-9bd6-5d7dbbdbfd84@github.com>
 <GHUgpoRQC7ordHnCGIa3eHazLiUDI-PyLiNSz7QuM9Y=.a4d7d427-0904-4e0c-83ca-0636d6b4137e@github.com>
 <EjtLTW8ZPUkYpHafr_jR5aLnssUJcedu08sByKGAgOo=.7b8badbb-c009-4eba-b3b9-2e597cb5bcb6@github.com>
 <KeJt4PG288fXNTdf_CSXwDD7LTW7XHvSzJqAn4u4FDk=.c55192fc-e3de-4a67-a6e8-d34ba517b069@github.com>
Message-ID: <yd7AuoyYw06uPXcpDlM1ehhTAD7RpjCE0QsArbvw2qA=.762ee933-4baf-4b6a-a93b-440305afa316@github.com>

On Tue, 30 Jan 2024 04:20:21 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > > Maybe we could live with symbol redefinition using #define (conditionally for static linking in OpenJDK, as Coleen suggested earlier) for now, until the tooling can support symbol localizing better. Then localizing symbols using tools like `objcopy` can be the longer term and cleaner solution, instead of using namespace. What's your thoughts on that?
> > 
> > 
> > I suppose so, but why?
> > Why should any of this have to work on old systems? If their binutils is broken, static linking of openjdk won't work there.
> 
> We ran into issues with older gcc on linux-aarch for partial linking, but the problem may not be older gcc only(?). At the current stage, limiting static/hermetic Java runtime support to only the platforms that support partial linking and `objcopy` seems to be overly restrictive (it does simplify the requirements significantly however :-)):
> 
> The duplicate symbol problems are mostly found in JDK natives and have been resolved already. We've found very few symbol issues with hotspot code so far. As there are portable alternative solutions that can resolve the symbol issues in hotspot, choosing a less portable solution seems not too attractive currently.

I believe this to be a mistake. HotSpot, by design, exports only the symbols intended for use by other components. Many of the symbol names are highly  generic, and will conflict with application code. 

Sure, you have enough to be able to do some prototyping, but for real-world deployment you must be able to control symbol exports.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1916535268

From sspitsyn at openjdk.org  Tue Jan 30 10:39:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 30 Jan 2024 10:39:31 GMT
Subject: RFR: 8324880: Rename get_stack_trace.h
In-Reply-To: <yofH_5Dxs3wJpKIwQFpNiooo1T0iascn5T91S1k3MyA=.8e6727dc-b5a4-4095-a32e-cc3ff0db5770@github.com>
References: <yofH_5Dxs3wJpKIwQFpNiooo1T0iascn5T91S1k3MyA=.8e6727dc-b5a4-4095-a32e-cc3ff0db5770@github.com>
Message-ID: <z9FZ9Wls7CzRzY7MYW0_4tcU-4qurlGoHhXTLxO26eo=.73e1f362-d8fa-42df-ac04-0554efb1b3d3@github.com>

On Tue, 30 Jan 2024 03:43:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change that renames the file
> test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/get_stack_trace.h
> to get_stack_trace.hpp, and renames uses of NULL in that file.
> 
> The updates to #include lines in using files were performed mechanically.
> 
> Testing: mach5 tier1

Looks good.
Thank you for taking care about this!

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17623#pullrequestreview-1850840521

From duke at openjdk.org  Tue Jan 30 10:52:49 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Tue, 30 Jan 2024 10:52:49 GMT
Subject: RFR: 8307977: Fix dynamic attach to processes with elevated
 capabilities on Linux
Message-ID: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>

8307977: Fix dynamic attach to processes with elevated capabilities on Linux

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

Commit messages:
 - 8307977: Fix dynamic attach to processes with elevated capabilities on Linux

Changes: https://git.openjdk.org/jdk/pull/17628/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17628&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307977
  Stats: 36 lines in 1 file changed: 21 ins; 11 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17628/head:pull/17628

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

From duke at openjdk.org  Tue Jan 30 10:59:33 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Tue, 30 Jan 2024 10:59:33 GMT
Subject: RFR: 8307977: Fix dynamic attach to processes with elevated
 capabilities on Linux
In-Reply-To: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
Message-ID: <EmxlQc4P1zqB9rC2Dn0VCksg9rDPBesRq-sLifPegeQ=.19da5a60-ceb4-40ee-856f-7873106502fc@github.com>

On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> 8307977: Fix dynamic attach to processes with elevated capabilities on Linux

I have poked around in the JDK sources but not found any tests related to this. Is there some prior art to look at?

Anyway, this is how I reproduced it locally, and verified that the fix works.

Basic environment information:


slovdahl at ubuntu2204:~/reproducer$ systemd --version
systemd 249 (249.11-0ubuntu3.12)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified
slovdahl at ubuntu2204:~/reproducer$ sudo apt-get install openjdk-17-jdk-headless
slovdahl at ubuntu2204:~/reproducer$ /usr/lib/jvm/java-17-openjdk-amd64/bin/java -version
openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment (build 17.0.9+9-Ubuntu-122.04)
OpenJDK 64-Bit Server VM (build 17.0.9+9-Ubuntu-122.04, mixed mode, sharing)
slovdahl at ubuntu2204:~/reproducer$ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/java -version
openjdk version "23-internal" 2024-09-17
OpenJDK Runtime Environment (build 23-internal-adhoc.slovdahl.jdk)
OpenJDK 64-Bit Server VM (build 23-internal-adhoc.slovdahl.jdk, mixed mode, sharing)

Reproducer systemd unit that can bind to port 81 as non-`root` user thanks to `AmbientCapabilities=CAP_NET_BIND_SERVICE` (https://man7.org/linux/man-pages/man7/capabilities.7.html):


slovdahl at ubuntu2204:~/reproducer$ cat Reproducer.java
import java.io.IOException;
import java.net.InetSocketAddress;
import java.net.ServerSocket;

public class Reproducer {
  public static void main(String[] args) throws InterruptedException, IOException {
    System.out.println("Hello, World!");
    try (var server = new ServerSocket()) {
      server.bind(new InetSocketAddress("localhost", 81));
      System.out.println("Bound to port 81");
      while (true) {
        Thread.sleep(1_000L);
      }
    }
  }
}

slovdahl at ubuntu2204:~/reproducer$ cat reproducer.service
[Service]
Type=simple
ExecStart=/usr/lib/jvm/java-17-openjdk-amd64/bin/java /home/slovdahl/reproducer/Reproducer.java

User=slovdahl
Group=slovdahl
ReadWritePaths=/tmp
AmbientCapabilities=CAP_NET_BIND_SERVICE



slovdahl at ubuntu2204:~/reproducer$ sudo cp -a reproducer.service /etc/systemd/system/
slovdahl at ubuntu2204:~/reproducer$ sudo systemctl daemon-reload
slovdahl at ubuntu2204:~/reproducer$ sudo systemctl start reproducer.service
slovdahl at ubuntu2204:~/reproducer$ sudo systemctl status reproducer.service
? reproducer.service
     Loaded: loaded (/etc/systemd/system/reproducer.service; static)
     Active: active (running) since Tue 2024-01-30 11:45:15 EET; 1s ago
   Main PID: 2543233 (java)
      Tasks: 26 (limit: 76971)
     Memory: 105.5M
        CPU: 751ms
     CGroup: /system.slice/reproducer.service
             ??2543233 /usr/lib/jvm/java-17-openjdk-amd64/bin/java /home/slovdahl/reproducer/Reproducer.java

jan 30 11:45:15 ubuntu2204 systemd[1]: Started reproducer.service.
jan 30 11:45:15 ubuntu2204 java[2543233]: Hello, World!
jan 30 11:45:15 ubuntu2204 java[2543233]: Bound to port 81

slovdahl at ubuntu2204:~/reproducer$ ls -lh /proc/$(pgrep -f Reproducer.java)/root
ls: cannot read symbolic link '/proc/2543233/root': Permission denied
lrwxrwxrwx 1 slovdahl slovdahl 0 jan 30 11:45 /proc/2543233/root
slovdahl at ubuntu2204:~/reproducer$ sudo ls -lh /proc/$(pgrep -f Reproducer.java)/root
lrwxrwxrwx 1 slovdahl slovdahl 0 jan 30 11:45 /proc/2543233/root -> /


Fails with vanilla OpenJDK 17:


slovdahl at ubuntu2204:~/reproducer$ /usr/lib/jvm/java-17-openjdk-amd64/bin/jcmd $(pgrep -f Reproducer.java) VM.version
2543233:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /proc/2543233/root/tmp/.java_pid2543233: target process 2543233 doesn't respond within 10500ms or HotSpot VM not loaded
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:104)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)


Works when trying to attach as `root` with vanilla OpenJDK 17:


slovdahl at ubuntu2204:~/reproducer$ sudo /usr/lib/jvm/java-17-openjdk-amd64/bin/jcmd $(pgrep -f Reproducer.java) VM.version
2543233:
OpenJDK 64-Bit Server VM version 17.0.9+9-Ubuntu-122.04
JDK 17.0.9


A JDK built with the fix in this PR:


slovdahl at ubuntu2204:~/reproducer$ sudo systemctl stop reproducer.service
slovdahl at ubuntu2204:~/reproducer$ cat reproducer-custom-jvm.service
[Service]
Type=simple
ExecStart=/home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/java /home/slovdahl/reproducer/Reproducer.java

User=slovdahl
Group=slovdahl
ReadWritePaths=/tmp
AmbientCapabilities=CAP_NET_BIND_SERVICE
slovdahl at ubuntu2204:~/reproducer$ sudo cp -a reproducer-custom-jvm.service /etc/systemd/system/
slovdahl at ubuntu2204:~/reproducer$ sudo systemctl daemon-reload
slovdahl at ubuntu2204:~/reproducer$ sudo systemctl start reproducer-custom-jvm.service
slovdahl at ubuntu2204:~/reproducer$ sudo systemctl status reproducer-custom-jvm.service
? reproducer-custom-jvm.service
     Loaded: loaded (/etc/systemd/system/reproducer-custom-jvm.service; static)
     Active: active (running) since Tue 2024-01-30 11:49:13 EET; 1s ago
   Main PID: 2546431 (java)
      Tasks: 26 (limit: 76971)
     Memory: 68.4M
        CPU: 809ms
     CGroup: /system.slice/reproducer-custom-jvm.service
             ??2546431 /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/java /home/slovdahl/reproducer/Reproducer.java

jan 30 11:49:13 ubuntu2204 systemd[1]: Started reproducer.service.
jan 30 11:49:14 ubuntu2204 java[2546431]: Hello, World!
jan 30 11:49:14 ubuntu2204 java[2546431]: Bound to port 81

slovdahl at ubuntu2204:~/reproducer$ ls -lh /proc/$(pgrep -f Reproducer.java)/root
ls: cannot read symbolic link '/proc/2546431/root': Permission denied
lrwxrwxrwx 1 slovdahl slovdahl 0 jan 30 11:49 /proc/2546431/root


Attaching works as non-`root` with the fixed JDK:

slovdahl at ubuntu2204:~/reproducer$ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep -f Reproducer.java) VM.version
2546431:
OpenJDK 64-Bit Server VM version 23-internal-adhoc.slovdahl.jdk
JDK 23.0.0


Attaching to a JVM inside a Docker container works as before with vanilla OpenJDK 17 and my locally built one (always requires `root`):

slovdahl at ubuntu2204:~/reproducer$ sudo systemctl stop reproducer-custom-jvm.service
slovdahl at ubuntu2204:~/reproducer$ docker run eclipse-temurin:17 java -version
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment Temurin-17.0.10+7 (build 17.0.10+7)
OpenJDK 64-Bit Server VM Temurin-17.0.10+7 (build 17.0.10+7, mixed mode, sharing)

slovdahl at ubuntu2204:~/reproducer$ docker run --rm -v .:/app -w /app eclipse-temurin:17 java Reproducer.java
Hello, World!
Bound to port 81

slovdahl at ubuntu2204:~/reproducer$ /usr/lib/jvm/java-17-openjdk-amd64/bin/jcmd $(pgrep --newest -f Reproducer.java) VM.version
2553682:
java.io.IOException: Permission denied
	at java.base/java.io.UnixFileSystem.createFileExclusively(Native Method)
	at java.base/java.io.File.createNewFile(File.java:1043)
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.createAttachFile(VirtualMachineImpl.java:308)
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:80)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
slovdahl at ubuntu2204:~/reproducer$ sudo /usr/lib/jvm/java-17-openjdk-amd64/bin/jcmd $(pgrep --newest -f Reproducer.java) VM.version
2553682:
OpenJDK 64-Bit Server VM version 17.0.10+7
JDK 17.0.10

slovdahl at ubuntu2204:~/reproducer$ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep --newest -f Reproducer.java) VM.version
2553682:
java.io.IOException: Unable to access root directory /proc/2553682/root of target process 2553682
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:247)
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:214)
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:71)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
	at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)
slovdahl at ubuntu2204:~/reproducer$ sudo /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep --newest -f Reproducer.java) VM.version
2553682:
OpenJDK 64-Bit Server VM version 17.0.10+7
JDK 17.0.10

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1916589081

From stuefe at openjdk.org  Tue Jan 30 11:54:30 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 30 Jan 2024 11:54:30 GMT
Subject: RFR: 8307977: jcmd and jstack broken for target processes running
 with elevated capabilities
In-Reply-To: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
Message-ID: <P5PVd_ZLvLC_-VNaPeFVH-jYjNUvDTYrFx2lqXOWMXA=.44032739-de10-4f4f-ae7c-7e05a2bb1787@github.com>

On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> 8307977: jcmd and jstack broken for target processes running with elevated capabilities

ping @jerboaa

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1916676356

From iklam at openjdk.org  Tue Jan 30 12:04:41 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 30 Jan 2024 12:04:41 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <yd7AuoyYw06uPXcpDlM1ehhTAD7RpjCE0QsArbvw2qA=.762ee933-4baf-4b6a-a93b-440305afa316@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <POaFoSfp8uLeUyTfDSbWMJS6_b6m_C7wgKkPA32LQrQ=.c7e1404f-5585-457f-9bd6-5d7dbbdbfd84@github.com>
 <GHUgpoRQC7ordHnCGIa3eHazLiUDI-PyLiNSz7QuM9Y=.a4d7d427-0904-4e0c-83ca-0636d6b4137e@github.com>
 <EjtLTW8ZPUkYpHafr_jR5aLnssUJcedu08sByKGAgOo=.7b8badbb-c009-4eba-b3b9-2e597cb5bcb6@github.com>
 <KeJt4PG288fXNTdf_CSXwDD7LTW7XHvSzJqAn4u4FDk=.c55192fc-e3de-4a67-a6e8-d34ba517b069@github.com>
 <yd7AuoyYw06uPXcpDlM1ehhTAD7RpjCE0QsArbvw2qA=.762ee933-4baf-4b6a-a93b-440305afa316@github.com>
Message-ID: <edDPNhsGLFJTeiqW0ukeb03fq7gRiSZkx8KoiGIgLro=.f4c12f33-b66e-4ef8-b600-46c3974cd233@github.com>

On Tue, 30 Jan 2024 10:27:08 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > > Maybe we could live with symbol redefinition using #define (conditionally for static linking in OpenJDK, as Coleen suggested earlier) for now, until the tooling can support symbol localizing better. Then localizing symbols using tools like `objcopy` can be the longer term and cleaner solution, instead of using namespace. What's your thoughts on that?
> > > 
> > > 
> > > I suppose so, but why?
> > > Why should any of this have to work on old systems? If their binutils is broken, static linking of openjdk won't work there.
> > 
> > 
> > We ran into issues with older gcc on linux-aarch for partial linking, but the problem may not be older gcc only(?). At the current stage, limiting static/hermetic Java runtime support to only the platforms that support partial linking and `objcopy` seems to be overly restrictive (it does simplify the requirements significantly however :-)):
> > The duplicate symbol problems are mostly found in JDK natives and have been resolved already. We've found very few symbol issues with hotspot code so far. As there are portable alternative solutions that can resolve the symbol issues in hotspot, choosing a less portable solution seems not too attractive currently.
> 
> I believe this to be a mistake. HotSpot, by design, exports only the symbols intended for use by other components. Many of the symbol names are highly generic, and will conflict with application code.
> 
> Sure, you have enough to be able to do some prototyping, but for real-world deployment you must be able to control symbol exports.

I agree with Andrew. We don't want the perfect to be the enemy of the good.

The only "perfect" solution is putting the HotSpot code in a namespace. This is going to be a huge undertaking. I don't think we have enough interest in the OpenJDK community to make such a change now.

I think partial linking with objcopy is a clean solution that's good enough for the actual use cases.

If someone wants to use `#define`, they can just make a local branch and add a few `#define` lines in their globalDefinitions.hpp. I suspect the configure script also allows adding C compiler options like `-DThread=HSThread`.

 `#define` is going to be a whack-a-mole hack. Google may need to isolate the `Thread` symbol, but other people may need to isolate things like `Symbol`, etc. It's not a good idea to add arbitrary `#define` in the HotSpot source code just because someone doesn't like it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1916692309

From duke at openjdk.org  Tue Jan 30 12:15:35 2024
From: duke at openjdk.org (Per Lundberg)
Date: Tue, 30 Jan 2024 12:15:35 GMT
Subject: RFR: 8307977: jcmd and jstack broken for target processes running
 with elevated capabilities
In-Reply-To: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
Message-ID: <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com>

On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> 8307977: jcmd and jstack broken for target processes running with elevated capabilities

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 217:

> 215:         // Instead, attach relative to the target root filesystem as exposed by
> 216:         // procfs regardless of namespaces.
> 217:         String root = "/proc/" + pid + "/root/" + tmpdir;

Helping myself and other future readers understand this: the problem with the previous implementation is that the code _assumed_ that the tmpdir could be accessed this way (`/proc/<pid>/root/<tmpdir>`). In other words:

* The code for creating the socket would correctly check if `pid != ns_pid` and then act accordingly (`/proc/<pid>/root/<tmpdir>` or just plain `<tmpdir>`)
* The code for reading the socket would not have the check the above. It would resort to always use `/proc/<pid>/root/<tmpdir>`.
* For certain scenarios (`CAP_NET_BIND_SERVICE`-processes, as described in https://github.com/openjdk/jdk/pull/17628#issuecomment-1916589081) would get a `Permission denied` when trying to access the temporary directory like this.

What this PR does is to ensure that the same `pid != ns_pid` check is used both when creating and reading the socket, and fall back to `<tmpdir>` when no namespacing is being used. This seems to work better for these processes with elevated permissions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17628#discussion_r1471105891

From aph at openjdk.org  Tue Jan 30 12:15:41 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 30 Jan 2024 12:15:41 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <edDPNhsGLFJTeiqW0ukeb03fq7gRiSZkx8KoiGIgLro=.f4c12f33-b66e-4ef8-b600-46c3974cd233@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <POaFoSfp8uLeUyTfDSbWMJS6_b6m_C7wgKkPA32LQrQ=.c7e1404f-5585-457f-9bd6-5d7dbbdbfd84@github.com>
 <GHUgpoRQC7ordHnCGIa3eHazLiUDI-PyLiNSz7QuM9Y=.a4d7d427-0904-4e0c-83ca-0636d6b4137e@github.com>
 <EjtLTW8ZPUkYpHafr_jR5aLnssUJcedu08sByKGAgOo=.7b8badbb-c009-4eba-b3b9-2e597cb5bcb6@github.com>
 <KeJt4PG288fXNTdf_CSXwDD7LTW7XHvSzJqAn4u4FDk=.c55192fc-e3de-4a67-a6e8-d34ba517b069@github.com>
 <yd7AuoyYw06uPXcpDlM1ehhTAD7RpjCE0QsArbvw2qA=.762ee933-4baf-4b6a-a93b-440305afa316@github.com>
 <edDPNhsGLFJTeiqW0ukeb03fq7gRiSZkx8KoiGIgLro=.f4c12f33-b66e-4ef8-b600-46c3974cd233@github.com>
Message-ID: <2YEod9zlzMWNdSu52nPlE8lvTcCwuxilXMluDpHbf7Y=.79994b5e-36e1-44ef-84f3-c995a135096b@github.com>

On Tue, 30 Jan 2024 12:01:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The only "perfect" solution is putting the HotSpot code in a namespace. This is going to be a huge undertaking. I don't think we have enough interest in the OpenJDK community to make such a change now.

I don't think that putting all of the HotSpot code in a namespace. At least, I hope not: it'll mess up debugging so much that it'll be intolerable, IMO, and there will be other side effects.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1916711165

From iklam at openjdk.org  Tue Jan 30 12:50:41 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 30 Jan 2024 12:50:41 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <2YEod9zlzMWNdSu52nPlE8lvTcCwuxilXMluDpHbf7Y=.79994b5e-36e1-44ef-84f3-c995a135096b@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
 <POaFoSfp8uLeUyTfDSbWMJS6_b6m_C7wgKkPA32LQrQ=.c7e1404f-5585-457f-9bd6-5d7dbbdbfd84@github.com>
 <GHUgpoRQC7ordHnCGIa3eHazLiUDI-PyLiNSz7QuM9Y=.a4d7d427-0904-4e0c-83ca-0636d6b4137e@github.com>
 <EjtLTW8ZPUkYpHafr_jR5aLnssUJcedu08sByKGAgOo=.7b8badbb-c009-4eba-b3b9-2e597cb5bcb6@github.com>
 <KeJt4PG288fXNTdf_CSXwDD7LTW7XHvSzJqAn4u4FDk=.c55192fc-e3de-4a67-a6e8-d34ba517b069@github.com>
 <yd7AuoyYw06uPXcpDlM1ehhTAD7RpjCE0QsArbvw2qA=.762ee933-4baf-4b6a-a93b-440305afa316@github.com>
 <edDPNhsGLFJTeiqW0ukeb03fq7gRiSZkx8KoiGIgLro=.f4c12f33-b66e-4ef8-b600-46c3974cd233@github.com>
 <2YEod9zlzMWNdSu52nPlE8lvTcCwuxilXMluDpHbf7Y=.79994b5e-36e1-44ef-84f3-c995a135096b@github.com>
Message-ID: <Dav4hC3httcs1QDFkqoallkHneS0iXR-P1kzc6ATeRk=.2023dcef-d2fb-4af0-ae73-68a3d03af89c@github.com>

On Tue, 30 Jan 2024 12:13:00 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > The only "perfect" solution is putting the HotSpot code in a namespace. This is going to be a huge undertaking. I don't think we have enough interest in the OpenJDK community to make such a change now.
> 
> I don't think that putting all of the HotSpot code in a namespace. At least, I hope not: it'll mess up debugging so much that it'll be intolerable, IMO, and there will be other side effects.

I forgot to qualify "perfect" only in the sense of isolating the HotSpot symbols. It's obviously not perfect at all in other aspects.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1916772980

From sgehwolf at openjdk.org  Tue Jan 30 13:56:41 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Jan 2024 13:56:41 GMT
Subject: RFR: 8307977: jcmd and jstack broken for target processes running
 with elevated capabilities
In-Reply-To: <EmxlQc4P1zqB9rC2Dn0VCksg9rDPBesRq-sLifPegeQ=.19da5a60-ceb4-40ee-856f-7873106502fc@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <EmxlQc4P1zqB9rC2Dn0VCksg9rDPBesRq-sLifPegeQ=.19da5a60-ceb4-40ee-856f-7873106502fc@github.com>
Message-ID: <Apdw0lzImHcACgil3f6c4mExCwAXYGZ2SA3cC8TaZvA=.344be70b-4b9e-4af7-8a61-1a3d8d309ff4@github.com>

On Tue, 30 Jan 2024 10:57:09 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> I have poked around in the JDK sources but not found any tests related to this. Is there some prior art to look at?

Please run container tests, which do some jcmd testing across containers (host system runs `jcmd` and containers have the JVMs): `test/hotspot/jtreg/containers` See [testing.md](https://github.com/openjdk/jdk/blob/master/doc/testing.md#docker-tests) as to how to run them. I'll give this PR a spin as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1916900904

From sgehwolf at openjdk.org  Tue Jan 30 14:00:41 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Jan 2024 14:00:41 GMT
Subject: RFR: 8307977: jcmd and jstack broken for target processes running
 with elevated capabilities
In-Reply-To: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
Message-ID: <xZ0hqixmRVbQVa4aebnHgnnOZQWh4p1TaCuBM3_gA10=.274b2e50-ed55-4e33-9137-01fa9c997751@github.com>

On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> 8307977: jcmd and jstack broken for target processes running with elevated capabilities

`test/hotspot/jtreg/serviceability` tests would also be worth running.

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1916910591

From dfuchs at openjdk.org  Tue Jan 30 14:01:24 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:01:24 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:

> 347:     @SuppressWarnings("removal")
> 348:     private Subject getSubject() {
> 349:         return Subject.current();

Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:

> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
> 306:                     public Subject run() {
> 307:                         return Subject.current();

Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471257982
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471263581

From dfuchs at openjdk.org  Tue Jan 30 14:21:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:21:32 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <K4rNAdIWeAQ1YRVn-4-H96Aj6nZ9JCk0vQRbwcivKo8=.3acbb46f-0d68-4904-aeac-a98a16b04e8f@github.com>

On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Changes requested by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17472#pullrequestreview-1851409950

From dfuchs at openjdk.org  Tue Jan 30 14:21:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Jan 2024 14:21:33 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
Message-ID: <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>

On Tue, 30 Jan 2024 13:53:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
> 
>> 347:     @SuppressWarnings("removal")
>> 348:     private Subject getSubject() {
>> 349:         return Subject.current();
> 
> Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.

OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:

`RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 

So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?

It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.

Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471308151

From jpai at openjdk.org  Tue Jan 30 16:17:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Jan 2024 16:17:58 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v5]
In-Reply-To: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
Message-ID: <9GE8apcJIAA9j0BfDQq2miUVQYGdRERGIgvwFb4NEi4=.cf3fb910-e958-41dd-858d-7b4d8e755f1d@github.com>

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
> 
> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  assert that we don't pass values higher than INT_MAX to close()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17588/files
  - new: https://git.openjdk.org/jdk/pull/17588/files/e4a8573b..c1decbff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17588&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17588&range=03-04

  Stats: 10 lines in 1 file changed: 4 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17588/head:pull/17588

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

From jpai at openjdk.org  Tue Jan 30 16:17:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Jan 2024 16:17:58 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <U36lxAEGrgSUE3Hne8JejFXlI3iBdOnt8LokkFfYakA=.29698e5d-6b04-4949-9874-a73e80eb7584@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
 <o2BgRS6H2Z4cmEQy_oZwXKsJNBq3jfcpIg_94fzuxvM=.95f5efe1-2584-4f4c-83bf-68aeb1d68ab0@github.com>
 <0yYC_Wz-BlaIrvMhaKAg-51Z3xH0mcCDKX1ps8gAU0s=.cb372918-ab17-44bb-a285-f506ecc023df@github.com>
 <IAMX53HQz3VAqTZmGND1xTxUOy9x3fZF6AGgNNvEXSE=.918ed3c2-ff4b-4ca9-9683-0990ef0d4ecd@github.com>
 <U36lxAEGrgSUE3Hne8JejFXlI3iBdOnt8LokkFfYakA=.29698e5d-6b04-4949-9874-a73e80eb7584@github.com>
Message-ID: <a0BNacdF74pUY77TKl6ecIWIrchNDW7vx5LZjuOVH4Y=.75cf80b2-b6f7-4c6a-86b0-0dbeb810ea98@github.com>

On Tue, 30 Jan 2024 07:14:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If we are going to check close for errors then we will have to know for certain we are only trying to close open fd's, and we will have to deal with EINTR. I would think this is a "best effort" to close open FD's and not something we have to care about in detail.
>
>> If we are going to check close for errors then we will have to know for certain we are only trying to close open fd's, and we will have to deal with EINTR. I would think this is a "best effort" to close open FD's and not something we have to care about in detail.
> 
> Right, EINTR would need to be ignored as it would be wrong to restart. I'm scratching my head as to why this code would even do with EIO or if it even possible here.

Looking at man close, EIO gets returned if:
> [EIO]              A previously-uncommitted write(2) encountered an input/output error.

If I understand this `launch=<cmd>` option correctly for the jdwp agent, then the arbitrary command gets launched very early in the lifecycle of the JVM. So in theory, I think there shouldn't be too many file descriptors that the JVM has opened so far and the chances of it having started writing to some of those opened file descriptors (other than standard out/err) perhaps is slim? But that's just a guess. Probably not a strong one too, given that if the JVM was launched with any other agent along with jdwp, then it's unknown if the other agent would have opened any file descriptors for write. 

My understanding of these close() calls after fork() in this code, matches David's - I think it's a best effort attempt. So perhaps ignoring such failures, like we do now, is OK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1471531584

From jpai at openjdk.org  Tue Jan 30 16:17:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Jan 2024 16:17:59 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <PuNXzbCvhejk4_KpjuSNJXQGL4LZnjzSktWbFI4tjuA=.4dd7734a-f5ec-4fde-8ccd-987e6cafab0a@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
 <S3GQ86djs3MeWXtTVzy0236LqKLTkiVKI6_KxbdUdpI=.92cb0c03-3e46-49db-abb8-bcf40aa9e656@github.com>
 <PuNXzbCvhejk4_KpjuSNJXQGL4LZnjzSktWbFI4tjuA=.4dd7734a-f5ec-4fde-8ccd-987e6cafab0a@github.com>
Message-ID: <IUJLVhjQl2trUGSYwXMH3ZtftJRQgf5OMMh74ULz5eE=.96a711e0-f6d2-4002-b21d-aea01f86fd8c@github.com>

On Tue, 30 Jan 2024 06:52:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 129:
>> 
>>> 127:         /* Find max allowed file descriptors for a process
>>> 128:          * and assume all were opened for the parent process and
>>> 129:          * copied over to this child process. We close them all. */
>> 
>> I'm somewhat leaning towards this just being a fatal error. Why would it ever fail? Do we think the version in childproc.c that also does this is doing so for a good reason, or perhaps just like jdwp it used to use the slow version and then kept it around as a backup when the faster version was introduced.
>
> I think we are sliding into " the perfect is the enemy of the good" here. If you want to investigate the resilience of closing FD's then I suggest you look at that in a different PR and let Jai integrate this optimization to avoid the timeouts that were seen.

Hello Chris, I had a look at the ProcessImpl implementation to see why that fallback is in place. Looking at the ProcessImpl implementation, it has "launch mechanisms" when launching a child process. It is configurable through a system property.
By default, when not configured, the ProcessImpl implementation uses posix_spawn() instead of fork(). So in its current form on macos (given the context of this PR), when the ProcessBuilder java API gets used to start child processes, the ProcessImpl's implementation ends up using posix_spawn() and thus this entire file descriptor closing in childproc.c never gets called - neither the closeDescriptors() nor the fallback of closing OPEN_MAX number of descriptors. (I won't go into implementation details of what ProcessImpl does when posix_spawn() is used, because after looking at it, I have more questions than answers and I think discussing those here is going to cause distraction).

As for this specific if block, the only time we enter here is if we can't `opendir()` the platform specific directory containing the open file descriptors. Whether or not it realistically happens, I'm unsure. I think having this fallback is perhaps a better option than just failing in such cases - this fallback when activated will certainly "slowdown" the launch of the arbitrary command but when no timeouts are in place, the arbritary command would indeed get launched.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1471506065

From jpai at openjdk.org  Tue Jan 30 16:17:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Jan 2024 16:17:59 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v2]
In-Reply-To: <pg15xZVlpzWAZd5Qvkdl7OjGALd5vSB-Z0OAbJxj4PU=.4bebdf44-ed75-4a4d-a060-982250bebe90@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <x8l2rb3LkeClqc6WkmPOj5i8uJBzMiy-boQ5CCs7LIU=.93c38501-1e70-4404-8b94-cb54e827e547@github.com>
 <GKSCmMTq_TUFfDTCZlqJVroRX2YSDg7Ig6LuPZ0WWYU=.a04ef702-9e94-4f07-973b-bf5244fae670@github.com>
 <I-zTW05Frb8E6eFJrQDKmt6WIzib4Xk_5TR2kz3l2kE=.40d73f10-8247-4e01-a587-5b0b078522c7@github.com>
 <pg15xZVlpzWAZd5Qvkdl7OjGALd5vSB-Z0OAbJxj4PU=.4bebdf44-ed75-4a4d-a060-982250bebe90@github.com>
Message-ID: <1ggEMx6lxn0YfW2xIIUt9auy5nOvDmdyl718mzNVDqQ=.0d709e5b-4e43-4794-8663-50d4cac7af95@github.com>

On Mon, 29 Jan 2024 17:45:34 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Hello Gerard, my understanding is that the limit value configured may exceed the int range. I wanted to avoid the overflow by casting it to int in such cases. I had noticed close() takes an int, but I couldn't think of any other way of avoiding the overflow at this place.
>> 
>> In the JVM parent process we do however limit it to INT_MAX. So maybe I should assume that it will be an int cast it to int here, like you suggest, and add a code comment explaining this? Does that sound OK?
>
> That is fine, but in that case we should also do:
> 
> `JDI_ASSERT(max_fd <= INT_MAX);`
> 
> in case `sysconf(_SC_OPEN_MAX)` returns value greater than `INT_MAX`, since `close()` only accepts `int`.

Done. I've updated the PR to add this assert. Additionally I've also slightly changed the implementation in the newly introduced closeDescriptors() method to ensure that we don't pass values to close() that exceed INT_MAX.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1471460024

From ecki at zusammenkunft.net  Tue Jan 30 16:25:53 2024
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 30 Jan 2024 17:25:53 +0100 (CET)
Subject: RFR: 8307977: jcmd and jstack broken for target processes running
 with elevated capabilities
In-Reply-To: <4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com><4Q7_OtfFcCEUnBHTWLZBNWQJVUgAaloGTrJ2RVqnsa8=.bd84f569-2ffd-4e47-8589-e98d3de70979@github.com>
Message-ID: <20240130162553.CBD50660BED@dd33810.kasserver.com>

Is that actually safe to allow low priveledged user context to attach and control to a higher prived? It can at least overwrite files, but probably also inject code? On the native level a ptrace(2) would probably not be allowed.

Gru?
Bernd
? 
https://bernd.eckenfels.net

From gziemski at openjdk.org  Tue Jan 30 16:31:02 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 30 Jan 2024 16:31:02 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v5]
In-Reply-To: <9GE8apcJIAA9j0BfDQq2miUVQYGdRERGIgvwFb4NEi4=.cf3fb910-e958-41dd-858d-7b4d8e755f1d@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <9GE8apcJIAA9j0BfDQq2miUVQYGdRERGIgvwFb4NEi4=.cf3fb910-e958-41dd-858d-7b4d8e755f1d@github.com>
Message-ID: <EeoMLppaWyt1TFXsi-u024khfNdDtt2xtLjwpAVCYeQ=.25d8efe6-ddac-4d0b-807e-d0ff84df057f@github.com>

On Tue, 30 Jan 2024 16:17:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert that we don't pass values higher than INT_MAX to close()

I filed https://bugs.openjdk.org/browse/JDK-8324979 as a followup to make sure we can get this code as robust as possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/17588#issuecomment-1917424839

From weijun at openjdk.org  Tue Jan 30 16:48:53 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 16:48:53 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
Message-ID: <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>

On Tue, 30 Jan 2024 14:19:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java line 349:
>> 
>>> 347:     @SuppressWarnings("removal")
>>> 348:     private Subject getSubject() {
>>> 349:         return Subject.current();
>> 
>> Since `Subject::current` is not deprecated the annotation at line 347 above should be removed.
>
> OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:
> 
> `RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 
> 
> So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?
> 
> It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.
> 
> Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.

This is complicated.

The benefit of `current()` is that it is always equivalent to `getSubject(AccessController.getContext())`  *as long as the latter works*. However, in this case, when a security manager is not allowed, the latter DOES NOT work but `current()` still works.

I'll revert the change. Before finding an alternative solution for `JMXSubjectDomainCombiner`, I assume this code only works when a security manager is allowed. It's better to throw an UOE instead of returning null.

I'm not sure of the other `getSubject` call (below), but I'll revert the change as all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471591997

From weijun at openjdk.org  Tue Jan 30 16:44:46 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 16:44:46 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
In-Reply-To: <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
Message-ID: <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>

On Tue, 30 Jan 2024 13:56:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
>> 
>> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
>> 
>> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.
>
> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:
> 
>> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
>> 306:                     public Subject run() {
>> 307:                         return Subject.current();
> 
> Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?

When a security manager is set, `current()` still calls `getSubject()` and it needs a permission unless it's called inside `doPrivileged`. But, see the comment above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471585097

From gziemski at openjdk.org  Tue Jan 30 16:36:37 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 30 Jan 2024 16:36:37 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v4]
In-Reply-To: <a0BNacdF74pUY77TKl6ecIWIrchNDW7vx5LZjuOVH4Y=.75cf80b2-b6f7-4c6a-86b0-0dbeb810ea98@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <jodYe59k9OUdJLLNgyuVUmAY8-gB2obQb724qsLKW1Q=.1bcb71b8-d3ed-4c02-8b0e-32dac8b40169@github.com>
 <o2BgRS6H2Z4cmEQy_oZwXKsJNBq3jfcpIg_94fzuxvM=.95f5efe1-2584-4f4c-83bf-68aeb1d68ab0@github.com>
 <0yYC_Wz-BlaIrvMhaKAg-51Z3xH0mcCDKX1ps8gAU0s=.cb372918-ab17-44bb-a285-f506ecc023df@github.com>
 <IAMX53HQz3VAqTZmGND1xTxUOy9x3fZF6AGgNNvEXSE=.918ed3c2-ff4b-4ca9-9683-0990ef0d4ecd@github.com>
 <U36lxAEGrgSUE3Hne8JejFXlI3iBdOnt8LokkFfYakA=.29698e5d-6b04-4949-9874-a73e80eb7584@github.com>
 <a0BNacdF74pUY77TKl6ecIWIrchNDW7vx5LZjuOVH4Y=.75cf80b2-b6f7-4c6a-86b0-0dbeb810ea98@github.com>
Message-ID: <h-uoDeEHBShF5L5KQFWcKGNmMcNr7fdXZiK23PZsYlA=.df3850ca-dd50-4434-adc4-fb265a071939@github.com>

On Tue, 30 Jan 2024 16:15:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> If we are going to check close for errors then we will have to know for certain we are only trying to close open fd's, and we will have to deal with EINTR. I would think this is a "best effort" to close open FD's and not something we have to care about in detail.
>> 
>> Right, EINTR would need to be ignored as it would be wrong to restart. I'm scratching my head as to why this code would even do with EIO or if it even possible here.
>
> Looking at man close, EIO gets returned if:
>> [EIO]              A previously-uncommitted write(2) encountered an input/output error.
> 
> If I understand this `launch=<cmd>` option correctly for the jdwp agent, then the arbitrary command gets launched very early in the lifecycle of the JVM. So in theory, I think there shouldn't be too many file descriptors that the JVM has opened so far and the chances of it having started writing to some of those opened file descriptors (other than standard out/err) perhaps is slim? But that's just a guess. Probably not a strong one too, given that if the JVM was launched with any other agent along with jdwp, then it's unknown if the other agent would have opened any file descriptors for write. 
> 
> My understanding of these close() calls after fork() in this code, matches David's - I think it's a best effort attempt. So perhaps ignoring such failures, like we do now, is OK?

Ignoring errors just doesn't seem like a good strategy.

This fix right here that we are doing doesn't have to deal with making this code more robust, as long as we follow up in another issue. For that, however, I filed JDK-8324979, and that frees us up to move on with this fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1471566159

From gziemski at openjdk.org  Tue Jan 30 16:36:37 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 30 Jan 2024 16:36:37 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v5]
In-Reply-To: <9GE8apcJIAA9j0BfDQq2miUVQYGdRERGIgvwFb4NEi4=.cf3fb910-e958-41dd-858d-7b4d8e755f1d@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <9GE8apcJIAA9j0BfDQq2miUVQYGdRERGIgvwFb4NEi4=.cf3fb910-e958-41dd-858d-7b4d8e755f1d@github.com>
Message-ID: <P72Gms2fdHoJB7IcsASI4E1SWur1vFILP8IFElJS7Cc=.0670b056-4dd5-4003-a23e-5deefa816a43@github.com>

On Tue, 30 Jan 2024 16:17:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert that we don't pass values higher than INT_MAX to close()

This fix looks very good, thank you @jaikiran !

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

Marked as reviewed by gziemski (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17588#pullrequestreview-1851797639

From kbarrett at openjdk.org  Tue Jan 30 18:09:14 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 30 Jan 2024 18:09:14 GMT
Subject: RFR: 8324880: Rename get_stack_trace.h
In-Reply-To: <bM9UXyLVc7WdXf5DhcVHVEMsjFRB2ecnFWV9mfG2QIA=.29cb7db0-0797-4a1c-bf8d-9414f9c797e2@github.com>
References: <yofH_5Dxs3wJpKIwQFpNiooo1T0iascn5T91S1k3MyA=.8e6727dc-b5a4-4095-a32e-cc3ff0db5770@github.com>
 <bM9UXyLVc7WdXf5DhcVHVEMsjFRB2ecnFWV9mfG2QIA=.29cb7db0-0797-4a1c-bf8d-9414f9c797e2@github.com>
Message-ID: <wGCrXbKvPV7fCltB0aKSUab9_PU0mTVy3xcYyZv1kYs=.dd85d4f8-b60a-4eba-b1a4-73a845421408@github.com>

On Tue, 30 Jan 2024 07:40:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this trivial change that renames the file
>> test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/get_stack_trace.h
>> to get_stack_trace.hpp, and renames uses of NULL in that file.
>> 
>> The updates to #include lines in using files were performed mechanically.
>> 
>> Testing: mach5 tier1
>
> LGTM! Thanks

Thanks for reviews, @dholmes-ora , @TheShermanTanker , and @sspitsyn .

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

PR Comment: https://git.openjdk.org/jdk/pull/17623#issuecomment-1917609671

From kbarrett at openjdk.org  Tue Jan 30 18:24:46 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 30 Jan 2024 18:24:46 GMT
Subject: Integrated: 8324880: Rename get_stack_trace.h
In-Reply-To: <yofH_5Dxs3wJpKIwQFpNiooo1T0iascn5T91S1k3MyA=.8e6727dc-b5a4-4095-a32e-cc3ff0db5770@github.com>
References: <yofH_5Dxs3wJpKIwQFpNiooo1T0iascn5T91S1k3MyA=.8e6727dc-b5a4-4095-a32e-cc3ff0db5770@github.com>
Message-ID: <9eUW_jik0VtY2iWnl7kfRoiLVgyrcaTPSO7KW3eNUNc=.946e3e00-318b-41da-90ed-87a957edb5fa@github.com>

On Tue, 30 Jan 2024 03:43:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change that renames the file
> test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/get_stack_trace.h
> to get_stack_trace.hpp, and renames uses of NULL in that file.
> 
> The updates to #include lines in using files were performed mechanically.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: f57c7223
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f57c7223cf9b732db5255b3e394ee07ff741f074
Stats:     15 lines in 9 files changed: 0 ins; 0 del; 15 mod

8324880: Rename get_stack_trace.h

Reviewed-by: dholmes, jwaters, sspitsyn

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

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

From jiangli at openjdk.org  Tue Jan 30 19:40:48 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 30 Jan 2024 19:40:48 GMT
Subject: RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK
 static linking
In-Reply-To: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
References: <AK3pEDl02hxX-KaUAyByfheJAgia26vFkHooatEQpIQ=.e270d808-5b36-4916-a975-bc7a6855c73c@github.com>
Message-ID: <blRv3XPwAKmh8a4aEWO6kSMJX8XinhNd2DkU42dYBsY=.0786e49c-a181-4cb7-acf2-b2cfb8e23fc5@github.com>

On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
> 
> Contributed by Chuck Rasbold and @jianglizhou.

We (@AlanBateman, @cushon, @magicus, @jerboaa, @pron, @jianglizhou) discussed this topic via zoom as part of a regular static/hermetic Java discussions. The outcome favors the partial-linking/objcopy to localize symbols for hotspot. Here is a summary:

- A general solution is preferred compared to resolving symbol issues case by case.
- We can address this for unix-like platforms with toolings supporting partial-linking/objcopy for now. @magicus will provide additional information on supported gcc versions and considerations for Windows support.
- There is also a preference to localize symbols automatically without editing the symbol list manually. In our prototype for handling freetype symbols (as mentioned in https://github.com/openjdk/jdk/pull/14808#issuecomment-1631611220), @cjmoon1 looked into using `nm` to generate symbol list and feed that into `objcopy`. That might be do-able for hotspot symbols.

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

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1917753387

From cjplummer at openjdk.org  Tue Jan 30 19:46:54 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 30 Jan 2024 19:46:54 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v5]
In-Reply-To: <9GE8apcJIAA9j0BfDQq2miUVQYGdRERGIgvwFb4NEi4=.cf3fb910-e958-41dd-858d-7b4d8e755f1d@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <9GE8apcJIAA9j0BfDQq2miUVQYGdRERGIgvwFb4NEi4=.cf3fb910-e958-41dd-858d-7b4d8e755f1d@github.com>
Message-ID: <nLc6eLH5W0W8EPR4FZPDMwfUXSt3dMQ2PS1HKhlpnmM=.cba4a92c-bbc5-4103-9e73-342fface2fac@github.com>

On Tue, 30 Jan 2024 16:17:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert that we don't pass values higher than INT_MAX to close()

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 139:

> 137:         LOG_MISC(("warning: failed to close file descriptors of"
> 138:                   " child process optimally, falling back to closing"
> 139:                   " %d file descriptors sequentially", (max_fd - i + 1)));

No one is ever going to see this. This logging is off by default, and when turned on goes to the logfile, not stdout or stderr. Perhaps ERROR_MESSAGE() would be better, which goes to stderr and also gives the option of aborting if the debug agent is launched with errorexit=y.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1471850043

From cjplummer at openjdk.org  Tue Jan 30 19:48:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 30 Jan 2024 19:48:10 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v3]
In-Reply-To: <KpAfbrA-yX0I16-4GlN1OvoyYQ2Wdsfdlcehqu5Y50o=.0edde44e-c751-4a1b-9111-e53b875165c0@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <KpAfbrA-yX0I16-4GlN1OvoyYQ2Wdsfdlcehqu5Y50o=.0edde44e-c751-4a1b-9111-e53b875165c0@github.com>
Message-ID: <26y_KIufmu-U-Nb_SNsKuIdLoN7BjN3Q9j0QgTOoYlc=.a6b31809-8d8c-481a-873c-71bf17e65140@github.com>

On Sun, 28 Jan 2024 01:20:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
>> 
>> 
>> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
>> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
>> 
>> 
>> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
>> 
>> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
>> 
>> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
>> 
>> The same changes are also being made to "clhsdb pstack".
>> 
>> Tested with all tier1, tier2, and tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix spacing

Thanks for the review Kevin. Can I get one more review please? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17479#issuecomment-1917767379

From cjplummer at openjdk.org  Tue Jan 30 19:53:06 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 30 Jan 2024 19:53:06 GMT
Subject: RFR: 8323680: SA PointerFinder code can do a better job of
 leveraging existing code to determine if an address is in the TLAB [v2]
In-Reply-To: <VNCNMH23it-ShOdlMzFu2wQod2wpc-EXTPw4SqRoabM=.cc0e7410-c63d-4aef-9b59-87106a6de48e@github.com>
References: <H17vx7Y1bWqd8QLwqR5UOxUi9VbtW3mDTTlLuQe69Ts=.f088c0f8-37f0-4ef2-be2e-cfe19513837f@github.com>
 <VNCNMH23it-ShOdlMzFu2wQod2wpc-EXTPw4SqRoabM=.cc0e7410-c63d-4aef-9b59-87106a6de48e@github.com>
Message-ID: <yPQF3hPQpl5Z0QO5hGoiPOIxN1NOT51vCsdEL2yCRpM=.e642e44a-e2cc-4434-9d98-c5ca2b6a9408@github.com>

On Fri, 26 Jan 2024 21:20:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> In PointerFinder.java we have some code to determine if a pointer is in a TLAB, but it only executes for the SerialGC. It should work for all GCs, so I moved the code out of the SerialGC block.
>> 
>> I also cleaned up the printing in PointerLocation. java a bit so when not using verbose mode not as much info about the tlab address is printed. This is consistent with other addresses, such as java stack addresses, which is what I modeled this change on.
>> 
>> It's hard to test this change since it is hard to consistently get an address to be in the tlab. I wrote a little test program that just sits in a loop doing allocations. I attached to it with clhsdb and ran the threadcontext command, which does a fincpc on each register. About half the time the main thread was suspended in a frame where some registers where pointing into the tlab, and I confirmed this was the case for both SerialGC and G1. Here's an example of one register with verbose off and verbose on:
>> 
>> rsi: 0x000000008a5d4448: In TLAB for thread "main" sun.jvm.hotspot.runtime.JavaThread at 0x00007ffa24029000
>> 
>> rsi: 0x000000008a5d4448: In TLAB for thread ("main" #1 prio=5 tid=0x00007ffa24029000 nid=25392 runnable [0x0000000000000000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_java
>> )  [0x000000008a5d4448,0x000000008ab724b8,0x000000008b0c0250,{0x000000008b0c0490})
>> 
>> For testing I ran all tier1, tier2, and tier5 svc tests (still in progress)
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of inTLAB field. Not needed

Thanks for the review Kevin. Can I get one more review please? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17494#issuecomment-1917766779

From weijun at openjdk.org  Tue Jan 30 20:29:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 20:29:06 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v2]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <lvRruRgRq_fjDZkadDnMl1l2mbn6riSOew16WnNQrok=.dc8a4d37-2300-4223-aaab-ea81ae8f7223@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:

 - JMX needs SM
 - Resolve Alan's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/75df9b0d..a16472fb

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

  Stats: 89 lines in 10 files changed: 36 ins; 16 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

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

From weijun at openjdk.org  Tue Jan 30 20:29:06 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 20:29:06 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v2]
In-Reply-To: <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <rW0PV-COoitld8Bh76qixyGvEUdlgZWIq8IApJ1EqOU=.fb3062db-3191-46f8-af5c-fe7878462cb8@github.com>
 <-gi0uJgQ3fslqyXhf4Y7B2DYBPjIEzdu5QluwXN6G3w=.ec51ee39-f028-447c-9c6a-83b252c0967e@github.com>
Message-ID: <HRBW0RxGY38lLNj0o0sFguRZ8nYqLjJMVZ2jQoxZkN0=.906bccdf-5e24-4449-a142-1a40491ffd13@github.com>

On Tue, 30 Jan 2024 16:45:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> OK - things seem to be a bit convoluted here and some pieces might be missing. I suspect that what needs to be done is more complicated:
>> 
>> `RMIConnectionImpl` sets up an ACC and calls doPrivileged with that ACC, on the assumption that the subject is tied to the ACC and it can be retrieved down the road from the ACC. `RMIConnectionImpl` has the subject, and the delegation subject too. 
>> 
>> So for `Subject::current` to work here, shouldn't `RMIConnectionImpl::doPrivilegedOperation` use `Subject::callAs` when the security manager is disallowed?
>> 
>> It seems that when `Subject::current` is used, some analysis should be done to verify where the Subject is supposed to come from - that is - how the caller is expecting the subject to reach the callee.
>> 
>> Typically, JMX doesn't use `Subject::doAs` but ties a `Subject` to an `AccessControlContext` and uses `doPrivileged` instead.
>
> This is complicated.
> 
> The benefit of `current()` is that it is always equivalent to `getSubject(AccessController.getContext())`  *as long as the latter works*. However, in this case, when a security manager is not allowed, the latter DOES NOT work but `current()` still works.
> 
> I'll revert the change. Before finding an alternative solution for `JMXSubjectDomainCombiner`, I assume this code only works when a security manager is allowed. It's better to throw an UOE instead of returning null.
> 
> I'm not sure of the other `getSubject` call (below), but I'll revert the change as all.

A new commit is push. The change in this class is reverted. I'm still investigating the other one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1471906073

From lmesnik at openjdk.org  Tue Jan 30 21:08:34 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 30 Jan 2024 21:08:34 GMT
Subject: Integrated: 8324582: Replace
 -Djava.util.concurrent.ForkJoinPool.common.parallelism to
 -Djdk.virtualThreadScheduler.maxPoolSize in jvmti vthread tests
In-Reply-To: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
References: <-BVhYTuKpaBjtOPULVfDLnkUJ_bDfTQwXeQj8kChyUc=.5ff376d3-1dde-42cd-9e8c-ae39a5905e08@github.com>
Message-ID: <i_xNaKq4uYascnPeOn3J-xriTm1KnmSgRc-Av6UjyrU=.4ea3d991-dbd0-4574-b196-7cf3693cfa19@github.com>

On Wed, 24 Jan 2024 02:42:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Some jvmti tests use
> -Djava.util.concurrent.ForkJoinPool.common.parallelism
> to control the pool of virtual threads. However, it is controlled by
> jdk.virtualThreadScheduler.parallelism property.
> 
> The non-continuations implementation doesn't use any of these properties and it was just deleted.
> 
> I verified the fix using jcmd Thread.dump and ran all jvmti tests in the default configuration.

This pull request has now been integrated.

Changeset: 8892d45b
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8892d45b9f0018c5a58c85094c305a03612749f4
Stats:     18 lines in 8 files changed: 0 ins; 3 del; 15 mod

8324582: Replace -Djava.util.concurrent.ForkJoinPool.common.parallelism to -Djdk.virtualThreadScheduler.maxPoolSize in jvmti vthread tests

Reviewed-by: cjplummer, sspitsyn

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

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

From weijun at openjdk.org  Tue Jan 30 21:58:28 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 21:58:28 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>

> This code change adds an alternative implementation of user-based authorization `Subject` APIs that doesn't depend on Security Manager APIs. Depending on if the Security Manager is allowed, the methods store the current subject differently. See the spec change in the `Subject.java` file for details. When the Security Manager APIs are finally removed in a future release, this new implementation will be only implementation for these methods.
> 
> One major change in the new implementation is that `Subject.getSubject` always throws an `UnsupportedOperationException` since it has an `AccessControlContext` argument but the current subject is no longer associated with an `AccessControlContext` object.
> 
> Now it's the time to migrate from the `getSubject` and `doAs` methods to `current` and `callAs`. If the user application is simply calling `getSubject(AccessController.getContext())`, then switching to `current()` would work. If the `AccessControlContext` argument is retrieved from an earlier `getContext()` call and the associated subject might be different from that of the current `AccessControlContext`, then instead of storing the previous `AccessControlContext` object and passing it into `getSubject` to get the "previous" subject, the application should store the `current()` return value directly.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  fix MBeanServerFileAccessController, more test in SM

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/a16472fb..8f270d09

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

  Stats: 18 lines in 2 files changed: 8 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17472/head:pull/17472

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

From weijun at openjdk.org  Tue Jan 30 22:36:47 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 Jan 2024 22:36:47 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v3]
In-Reply-To: <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <9pWwvpgeqBcIcRqJtZShKnuc-zHcshP78n1JGfE0EgY=.6fc22b58-b40c-4bed-a521-983d85984448@github.com>
 <uxBUlOZmpo0OZuRbe3-NRKGnVwalLaWmX-Pu0YW-KnI=.30740b65-b29b-4dfa-888b-d8bd7e1571f4@github.com>
Message-ID: <QRKZc0wq2LKmqFG9rnq3h92fu3Y-u-78gYcsAlnxm2M=.436b9a55-bb43-4026-84ab-c9c3ae35e1f9@github.com>

On Tue, 30 Jan 2024 16:41:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 307:
>> 
>>> 305:             AccessController.doPrivileged(new PrivilegedAction<>() {
>>> 306:                     public Subject run() {
>>> 307:                         return Subject.current();
>> 
>> Is the `doPrivileged` still needed here? Is there a chance that `Subject.current()` will throw a `SecurityException`, or return a different result if a security manager is present and `doPrivileged` is not used?
>
> When a security manager is set, `current()` still calls `getSubject()` and it needs a permission unless it's called inside `doPrivileged`. But, see the comment above.

I fixed it in the latest commit. The original code change is simply wrong. `AccessController.getContext()` would return different ACCs inside and outside `doPriv`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1472043888

From jpai at openjdk.org  Wed Jan 31 01:46:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Jan 2024 01:46:57 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v6]
In-Reply-To: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
Message-ID: <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com>

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
> 
> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Chris' review suggestion - replace LOG_MISC with ERROR_MESSAGE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17588/files
  - new: https://git.openjdk.org/jdk/pull/17588/files/c1decbff..3d323f7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17588&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17588&range=04-05

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17588/head:pull/17588

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

From jpai at openjdk.org  Wed Jan 31 01:46:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Jan 2024 01:46:59 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v5]
In-Reply-To: <nLc6eLH5W0W8EPR4FZPDMwfUXSt3dMQ2PS1HKhlpnmM=.cba4a92c-bbc5-4103-9e73-342fface2fac@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <9GE8apcJIAA9j0BfDQq2miUVQYGdRERGIgvwFb4NEi4=.cf3fb910-e958-41dd-858d-7b4d8e755f1d@github.com>
 <nLc6eLH5W0W8EPR4FZPDMwfUXSt3dMQ2PS1HKhlpnmM=.cba4a92c-bbc5-4103-9e73-342fface2fac@github.com>
Message-ID: <hrhFujjqAwikLSXAEYxDZ6MhcAHMxyL7X4r1X7Y3Cn8=.5f3bc1d3-576b-48ba-88b3-13ec0cacfe87@github.com>

On Tue, 30 Jan 2024 19:41:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   assert that we don't pass values higher than INT_MAX to close()
>
> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 139:
> 
>> 137:         LOG_MISC(("warning: failed to close file descriptors of"
>> 138:                   " child process optimally, falling back to closing"
>> 139:                   " %d file descriptors sequentially", (max_fd - i + 1)));
> 
> No one is ever going to see this. This logging is off by default, and when turned on goes to the logfile, not stdout or stderr. Perhaps ERROR_MESSAGE() would be better, which goes to stderr and also gives the option of aborting if the debug agent is launched with errorexit=y.

Thank you Chris for pointing to ERROR_MESSAGE(). I've updated the PR to use that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1472205736

From cjplummer at openjdk.org  Wed Jan 31 01:51:01 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 31 Jan 2024 01:51:01 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v6]
In-Reply-To: <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com>
Message-ID: <dcRRpPlwEYWMW9K0MV-NvgAxBWRydnXtIpmHCSD-iAM=.ecc75a5e-f8ae-4717-b0d4-f858fd4ee6fd@github.com>

On Wed, 31 Jan 2024 01:46:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chris' review suggestion - replace LOG_MISC with ERROR_MESSAGE

Looks good. Thanks for taking this on.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17588#pullrequestreview-1852749213

From jpai at openjdk.org  Wed Jan 31 02:23:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Jan 2024 02:23:07 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v6]
In-Reply-To: <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com>
Message-ID: <umaqfp7Wz3P-mAZAYIFktojofqv7C5T8AGGy7R-2TNE=.9a6573c8-5f01-447c-8878-831628cb9853@github.com>

On Wed, 31 Jan 2024 01:46:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chris' review suggestion - replace LOG_MISC with ERROR_MESSAGE

Thank you Chris, David and Gerard for the inputs and reviews. I'll integrate this in a day or two once I'm able to have a full CI run done.

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

PR Comment: https://git.openjdk.org/jdk/pull/17588#issuecomment-1918248456

From amenkov at openjdk.org  Wed Jan 31 03:54:03 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 31 Jan 2024 03:54:03 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v3]
In-Reply-To: <KpAfbrA-yX0I16-4GlN1OvoyYQ2Wdsfdlcehqu5Y50o=.0edde44e-c751-4a1b-9111-e53b875165c0@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <KpAfbrA-yX0I16-4GlN1OvoyYQ2Wdsfdlcehqu5Y50o=.0edde44e-c751-4a1b-9111-e53b875165c0@github.com>
Message-ID: <Xg4VEk2ATHQm0nkf4L-oKEQPhuTKsq04R4_B5wNFYV4=.2da4210d-280d-429a-82d5-e24b1009e9c0@github.com>

On Sun, 28 Jan 2024 01:20:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
>> 
>> 
>> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
>> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
>> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
>> 
>> 
>> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
>> 
>> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
>> 
>> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
>> 
>> The same changes are also being made to "clhsdb pstack".
>> 
>> Tested with all tier1, tier2, and tier5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix spacing

test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.java line 65:

> 63:             for (String line : lines) {
> 64:                 if (line.contains(key)) {
> 65:                     String[] words = line.split(key + "|[, ]");

String.split() expect regexp as an argument
Not sure how this code works (without escaping '$' and parentheses).
I think it would be clearer to use standard regexp pattern/matcher, something like


Pattern pattern = Pattern.compile("\\s+- <0x([0-9a-fA-F]+)>, \(a java/util/concurrent/locks/ReentrantLock\$NonfairSync\)");
for (String line: lines) {
    Matcher matcher = pattern.matcher(line);
    if (matcher.find()) {
        addressString = matcher.group(1);
        break;
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17479#discussion_r1472272773

From cjplummer at openjdk.org  Wed Jan 31 04:37:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 31 Jan 2024 04:37:02 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v3]
In-Reply-To: <Xg4VEk2ATHQm0nkf4L-oKEQPhuTKsq04R4_B5wNFYV4=.2da4210d-280d-429a-82d5-e24b1009e9c0@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
 <KpAfbrA-yX0I16-4GlN1OvoyYQ2Wdsfdlcehqu5Y50o=.0edde44e-c751-4a1b-9111-e53b875165c0@github.com>
 <Xg4VEk2ATHQm0nkf4L-oKEQPhuTKsq04R4_B5wNFYV4=.2da4210d-280d-429a-82d5-e24b1009e9c0@github.com>
Message-ID: <SV5gCa4iR5s_Ngx2KXw6QzAH46nnpEj73HpWlvbJKOc=.4dbbe069-25b2-425a-b1d2-5b8385c4733a@github.com>

On Wed, 31 Jan 2024 03:50:29 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix spacing
>
> test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.java line 65:
> 
>> 63:             for (String line : lines) {
>> 64:                 if (line.contains(key)) {
>> 65:                     String[] words = line.split(key + "|[, ]");
> 
> String.split() expect regexp as an argument
> Not sure how this code works (without escaping '$' and parentheses).
> I think it would be clearer to use standard regexp pattern/matcher, something like
> 
> 
> Pattern pattern = Pattern.compile("\\s+- <0x([0-9a-fA-F]+)>, \(a java/util/concurrent/locks/ReentrantLock\$NonfairSync\)");
> for (String line: lines) {
>     Matcher matcher = pattern.matcher(line);
>     if (matcher.find()) {
>         addressString = matcher.group(1);
>         break;
>     }
> }

I think `key` doesn't really matter when doing the split. `key` is mainly for finding the right line. The split is for tokenizing that line into words, and the only parts that matters for that are ' ' and the ',' being used as word delimiters. I think `key` should just be removed from the regex. I think the source of the bug is code copied from ClhsdbInspect.java:

                        // Escape the token "Method*=" because the split method uses
                        // a regex, not just a straight String.
                        String escapedKey = key.replace("*","\*");
                        String[] words = line.split(escapedKey+"|[ ]");

In this case key is `Method*=`. The code works and the escaping and searching for `key` is necessary because we are looking for something like `Method*=<0x00000000ffc2ed70>`, but I think this could have been simplified by including `=` in the split pattern rather than all of `escapedKey`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17479#discussion_r1472293801

From mdoerr at openjdk.org  Wed Jan 31 06:11:08 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 31 Jan 2024 06:11:08 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs
In-Reply-To: <crJJowOj-0J1vxYNDxWCZ2OzNbd496wucvDmZxXeNVU=.263c36e1-36ea-4370-9b2e-f3bb90eddafd@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <kkTuRO6ZLza4ZwhWc2qpyuVEfbapG6fUuEw4qzGJBqU=.c08f56ef-f199-4b51-aa1c-fbb6ae79754b@github.com>
 <HSbNrboWAJcLr9zvqUGJjihCorB9McjrG7F_MCaQuFk=.fcb8badd-f89a-4c35-8f5d-43675e46a2a6@github.com>
 <4Pd7oVMUE2HYXJtde1fxURXSaS24X2bK5t2448kwT8s=.8a8c6fbc-3537-4289-8577-a978636f55a2@github.com>
 <vUfeh1jMUQ3c-mkskGp_tsaUGng6iMXg46QDiDwEaWc=.6a5fdc5c-3d3e-466f-9563-486df83e3e7b@github.com>
 <crJJowOj-0J1vxYNDxWCZ2OzNbd496wucvDmZxXeNVU=.263c36e1-36ea-4370-9b2e-f3bb90eddafd@github.com>
Message-ID: <rfQ9NzxEvWiN7Z7WXezmTEVAs4Avy182f2bykzqBwHw=.6ce11f4a-adbc-48ec-a902-50ab5c42beb6@github.com>

On Tue, 30 Jan 2024 14:02:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> Yes there is a nice define in the AIX header
>> 
>> *sigh* On linux, they go to some lengths to avoid this, using a __REDEFINE mechanism. Oh well. 
>> 
>> Anyway, I think this particular can be resolved by not including the standard includes in the header file (which is bad practice anyway!). I'm currently testing this build in our CI to see that it does not break anything else. I'd appreciate if you could take the latest version for a spin, particularly a debug build...
>
>> I'd appreciate if you could take the latest version for a spin, particularly a debug build...
> 
> Yes we pick up the latest version of the PR in a couple of hours for the build+'lots of tests'  (and this includes a fastdebug too).

@MBaesken, @JoKern65: This seems to break the debug build (fast and slow) on AIX:

jdk/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c:101:24: error: no member named 'open64' in 'SpanIteratorFuncs'; did you mean 'open'?
    srData = (*pFuncs->open)(env, si);
                       ^~~~
                       open
/usr/include/fcntl.h:115:14: note: expanded from macro 'open'
#define open    open64
                ^
jdk/src/java.desktop/share/native/libawt/java2d/pipe/SpanIterator.h:37:17: note: 'open' declared here
    void     *(*open)(JNIEnv *env, jobject iterator);
                ^

Ah, that has already been reported above. Yeah, interesting that the normal build has passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1918443702

From dholmes at openjdk.org  Wed Jan 31 06:33:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 31 Jan 2024 06:33:04 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v6]
In-Reply-To: <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com>
Message-ID: <Fp-QEW8IeVJSA-mAS7bjm3rwJyEeaRjZArhuu6Z21TU=.75f22fce-7003-4608-b8d0-6ed6b25a038a@github.com>

On Wed, 31 Jan 2024 01:46:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chris' review suggestion - replace LOG_MISC with ERROR_MESSAGE

A couple of minor nits to fix before integrating but otherwise looks good. Thanks again for taking this on.

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 35:

> 33: #include "sys.h"
> 34: #include "util.h"
> 35: #include "error_messages.h"

Nit: to maintain include sort order this should have gone where `log_messages.h` was removed.

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 100:

> 98:     if ((dp = opendir(FD_DIR)) == NULL) {
> 99:         ERROR_MESSAGE(("failed to open dir %s while determining"
> 100:                   " file descriptors to close for process %d", FD_DIR, getpid()));

Nit: indent of second line is now off - please align "

src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 139:

> 137:         ERROR_MESSAGE(("failed to close file descriptors of"
> 138:                   " child process optimally, falling back to closing"
> 139:                   " %d file descriptors sequentially", (max_fd - i + 1)));

Nit: please realign lines on "

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17588#pullrequestreview-1852976350
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1472358835
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1472359191
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1472359972

From duke at openjdk.org  Wed Jan 31 06:44:02 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Wed, 31 Jan 2024 06:44:02 GMT
Subject: RFR: 8313710: jcmd: typo in the documentation of JFR.start and
 JFR.dump [v3]
In-Reply-To: <MtUYjI3FqmC3AiiDFDi4so-x9ruW7KFA0kfa8MpbLVo=.175ce1aa-4869-4a04-8070-34caf9b96380@github.com>
References: <NCQ9Mq777-jfXsiBgIdgcUV-9Q2Xr0qbLNdJOgZL9kI=.7c2bd4c7-37fd-4467-8982-a5858ff52276@github.com>
 <MtUYjI3FqmC3AiiDFDi4so-x9ruW7KFA0kfa8MpbLVo=.175ce1aa-4869-4a04-8070-34caf9b96380@github.com>
Message-ID: <4AmewOHYpmDuaD4H4sk9wb2z6EsQwJinORtc73FCIX0=.ea07369a-c8b0-4c99-8fe0-32ad8ffb9300@github.com>

On Mon, 30 Oct 2023 22:39:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8313710: jcmd: typo in the documentation of JFR.start and JFR.dump
>
> Changes requested by dholmes (Reviewer).

@dholmes-ora @egahlin 

I'm sorry that my slow response has prolonged this issue. I created a subtask and modified the source. If possible, please review them.

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

PR Comment: https://git.openjdk.org/jdk/pull/16413#issuecomment-1918482452

From sroy at openjdk.org  Wed Jan 31 07:45:06 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 31 Jan 2024 07:45:06 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v11]
In-Reply-To: <oafXeyNylwlnKFzjgMkN4HdB_dEL0Qfu8MlL3kDtI5g=.e529938b-d393-4777-a4cf-50977fbdbb14@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <m0w6Rh_2nNuZ_vmFcBRok-cK5XDJtgZMGwKrl_VzrQE=.b469dc8d-50c2-44b4-8c3e-99036f6acb31@github.com>
 <oafXeyNylwlnKFzjgMkN4HdB_dEL0Qfu8MlL3kDtI5g=.e529938b-d393-4777-a4cf-50977fbdbb14@github.com>
Message-ID: <aNgfepuaa1Z7omQhZ7Ywl6FeegnSZ3gUc97Sbo-fQYw=.d7ca62a8-496f-4f51-8f64-8bdf679c89ca@github.com>

On Mon, 29 Jan 2024 09:48:40 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update comment
>
> src/hotspot/os/aix/os_aix.cpp line 1166:
> 
>> 1164:  Search order:
>> 1165:  libfilename-> load "libfilename.so" first,then load libfilename.a,on failure. 
>> 1166:  In,OpenJ9,the libary with .so extension is loaded first and then .a extension,on failure.
> 
> Hi Suchi, I'm puzzled. Your comment implies for me, that load library gets a 'base' filename without 'lib' prefix and without extension (e.g. 'name'). Then the j9 code creates the filename 'libname.so' first and on failure 'libname.a' second. What about given libname.so explicitly (e.g. libname.so)? Does j9 really use 'libname.a' as a failure fallback in this case?

The load library gets the entire library name, after construction from dll_build_name. This is always a .so file name. When .so file name fails to load, we fallback to .a filename. 
Do i need to mention the filename as libfilename.so then ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1472417159

From jpai at openjdk.org  Wed Jan 31 07:55:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Jan 2024 07:55:02 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v6]
In-Reply-To: <Fp-QEW8IeVJSA-mAS7bjm3rwJyEeaRjZArhuu6Z21TU=.75f22fce-7003-4608-b8d0-6ed6b25a038a@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com>
 <Fp-QEW8IeVJSA-mAS7bjm3rwJyEeaRjZArhuu6Z21TU=.75f22fce-7003-4608-b8d0-6ed6b25a038a@github.com>
Message-ID: <JpT46XybqeBxRhb5LmZvpzCo7fuq_za555ifp0QA8nI=.636d0f8a-5842-4663-a34f-25ec1fe6a369@github.com>

On Wed, 31 Jan 2024 06:27:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chris' review suggestion - replace LOG_MISC with ERROR_MESSAGE
>
> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 35:
> 
>> 33: #include "sys.h"
>> 34: #include "util.h"
>> 35: #include "error_messages.h"
> 
> Nit: to maintain include sort order this should have gone where `log_messages.h` was removed.

Hello David, I had actually first put it in that line you noted, but that then lead to a compilation error:


In file included from /jdk/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c:33:
/jdk/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h:35:20: error: unknown type name 'FILE'
void print_message(FILE *fp, const char *prefix,  const char *suffix,
                   ^
/jdk/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h:41:29: error: a parameter list without types is only allowed in a function definition
const char * jvmtiErrorText(jvmtiError);
                            ^
/jdk/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h:43:28: error: a parameter list without types is only allowed in a function definition
const char * jdwpErrorText(jdwpError);
                           ^
3 errors generated.



I think the reason for those compilation errors is that `error_messages.h` and a few other header files are not explicitly listing their necessary includes and are relying on transitive includes. So I decided to take the easy route out, by adding the `error_messages.h` after the `util.h` to rely on the transitive includes to get past that compilation error. 

I think to properly fix that compile error, this following change (which I tested locally and works) would be needed:


diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h b/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h
index 92a9f457e8a..04f10bcb019 100644
--- a/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h
+++ b/src/jdk.jdwp.agent/share/native/libjdwp/JDWP.h
@@ -27,6 +27,7 @@
 #define JDWP_JDWP_H
 
 #include "JDWPCommands.h"
+#include "vm_interface.h"
 
 /*
  * JDWPCommands.h is the javah'ed version of all the constants defined
diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h b/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h
index 4126b76f226..810ab384f1a 100644
--- a/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h
+++ b/src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h
@@ -26,6 +26,9 @@
 #ifndef JDWP_ERROR_MESSAGES_H
 #define JDWP_ERROR_MESSAGES_H
 
+#include <stdio.h>
+#include "JDWP.h"
+
 /* It is assumed that ALL strings are UTF-8 safe on entry */
 #define TTY_MESSAGE(args) ( tty_message args )
 #define ERROR_MESSAGE(args) ( \
diff --git a/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c b/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c
index 44f8a463522..0c6ee5b8b6a 100644
--- a/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c
+++ b/src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c
@@ -30,9 +30,9 @@
 #include <unistd.h>
 #include <string.h>
 #include <ctype.h>
+#include "error_messages.h"
 #include "sys.h"
 #include "util.h"
-#include "error_messages.h"
 
 static char *skipWhitespace(char *p) {
     while ((*p != '\0') && isspace(*p)) {



Do you think this should be fixed? I can file a JBS issue for it and address it as a separate PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1472425903

From jpai at openjdk.org  Wed Jan 31 08:01:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Jan 2024 08:01:15 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v7]
In-Reply-To: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
Message-ID: <VqgN7RcgoFCZUhzJgfHsD3N6_2986kgObxn7dZfJk0Q=.e2c1227c-88ea-4436-b12d-efabb6f9f75c@github.com>

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
> 
> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Minor - fix alignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17588/files
  - new: https://git.openjdk.org/jdk/pull/17588/files/3d323f7d..afef982f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17588&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17588&range=05-06

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

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

From jpai at openjdk.org  Wed Jan 31 08:01:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Jan 2024 08:01:16 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v6]
In-Reply-To: <Fp-QEW8IeVJSA-mAS7bjm3rwJyEeaRjZArhuu6Z21TU=.75f22fce-7003-4608-b8d0-6ed6b25a038a@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <320ZUOt54O9BjSxRIwDOzpQIVxtA-yBwk1g_VmtVwU4=.33e5d178-f55c-417a-b8c7-79a9102c3a32@github.com>
 <Fp-QEW8IeVJSA-mAS7bjm3rwJyEeaRjZArhuu6Z21TU=.75f22fce-7003-4608-b8d0-6ed6b25a038a@github.com>
Message-ID: <wv8Rr-ZI6cPdEuFbCwaegr5XBgtK6osIDZRt3C-rp6I=.04bf2bf1-e55e-4439-9bb2-962ddee8e2b1@github.com>

On Wed, 31 Jan 2024 06:28:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chris' review suggestion - replace LOG_MISC with ERROR_MESSAGE
>
> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 100:
> 
>> 98:     if ((dp = opendir(FD_DIR)) == NULL) {
>> 99:         ERROR_MESSAGE(("failed to open dir %s while determining"
>> 100:                   " file descriptors to close for process %d", FD_DIR, getpid()));
> 
> Nit: indent of second line is now off - please align "

Done. PR has been update to fix this.

> src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 139:
> 
>> 137:         ERROR_MESSAGE(("failed to close file descriptors of"
>> 138:                   " child process optimally, falling back to closing"
>> 139:                   " %d file descriptors sequentially", (max_fd - i + 1)));
> 
> Nit: please realign lines on "

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1472430580
PR Review Comment: https://git.openjdk.org/jdk/pull/17588#discussion_r1472430298

From duke at openjdk.org  Wed Jan 31 08:02:03 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 31 Jan 2024 08:02:03 GMT
Subject: RFR: 8307977: jcmd and jstack broken for target processes running
 with elevated capabilities
In-Reply-To: <xZ0hqixmRVbQVa4aebnHgnnOZQWh4p1TaCuBM3_gA10=.274b2e50-ed55-4e33-9137-01fa9c997751@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <xZ0hqixmRVbQVa4aebnHgnnOZQWh4p1TaCuBM3_gA10=.274b2e50-ed55-4e33-9137-01fa9c997751@github.com>
Message-ID: <ItRUVzm5UCPUgD31-Wur2xreTpARWVxYHTuxGeBQez0=.f9fa911a-5f9b-465f-8a6b-a98648942414@github.com>

On Tue, 30 Jan 2024 13:57:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> 8307977: jcmd and jstack broken for target processes running with elevated capabilities
>
> `test/hotspot/jtreg/serviceability` tests would also be worth running.

Hi @jerboaa, thanks a lot for the hints! The container tests were new to me at least.

Just out of curiosity, are the container tests run as part of the tier1 tests (`make test-tier1`)? I'm not sure if I'm looking at the right place, but I get the feeling this is defined in `test/hotspot/jtreg/TEST.groups`, and the answer is maybe "no" in that case.

> Please run container tests, which do some jcmd testing across containers (host system runs jcmd and containers have the JVMs): `test/hotspot/jtreg/containers` See [testing.md](https://github.com/openjdk/jdk/blob/master/doc/testing.md#docker-tests) as to how to run them. I'll give this PR a spin as well.

If I understand it correctly, this is the way to run them. Please correct me if I'm wrong.


$ make test TEST="jtreg:test/hotspot/jtreg/containers"

...

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/containers                  14    14     0     0   
==============================
TEST SUCCESS


> `test/hotspot/jtreg/serviceability` tests would also be worth running.


$ make test TEST="jtreg:test/hotspot/jtreg/serviceability"

...

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/serviceability             368   368     0     0   
==============================
TEST SUCCESS

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1918576420

From duke at openjdk.org  Wed Jan 31 08:30:01 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 31 Jan 2024 08:30:01 GMT
Subject: RFR: 8307977: jcmd and jstack broken for target processes running
 with elevated capabilities
In-Reply-To: <20240130162553.CBD50660BED@dd33810.kasserver.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <20240130162553.CBD50660BED@dd33810.kasserver.com>
Message-ID: <mRW8V9ubFVbdK0aHdPBo2wo6SD9lA6tcJqZ3BXQp9JU=.f2ccc644-42fd-438f-b0c0-a1b39a1c5166@github.com>

On Tue, 30 Jan 2024 17:00:16 GMT, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:

> Is that actually safe to allow low priveledged user context to attach and control to a higher prived? It can at least overwrite files, but probably also inject code? On the native level a ptrace(2) would probably not be allowed.

It's a good question. For context, this has worked fine in JDK 8, and AFAIK it was never intentionally broken for security reasons.

In some cases the opposite can also be true - that one needs root access to attach to a process is not acceptable or even possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1918616533

From mbaesken at openjdk.org  Wed Jan 31 09:22:07 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 31 Jan 2024 09:22:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
In-Reply-To: <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
References: <EmaP88PgNk6hjVCYJMOdBOhUH0p_vmzobMTtKDuR1LM=.599dd222-d843-4a8e-a962-b5512328d47a@github.com>
 <rl5N6C24qN6mBIpOK951TbegJtUPmd-qc9mJEXBd6JM=.378619ec-17e5-4058-b6b3-7fb4ebb02879@github.com>
Message-ID: <FXqfV9eIuqQE5fj65sXIKoou-w-ZOko1PbtbISfMIRQ=.558df97e-2941-47d0-9a45-1c450cf6dc39@github.com>

On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie 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 branch 'master' into jdk-FOB64
>  - Move #include <stdlib/io.h> out of debug_util.h
>  - Restore AIX dirent64 et al defines
>  - Rollback AIX changes since they are now tracked in JDK-8324834
>  - Remove superfluous setting of FOB64
>  - Replace all foo64() with foo() for large-file functions in the JDK
>  - 8324539: Do not use LFS64 symbols in JDK libs

After adding this additional patch I  fully build fastdebug on AIX (hav to admit it does not look very nice).


diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
index 823475b0a23..ee0109b6806 100644
--- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
+++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c
@@ -31,6 +31,10 @@
 #include "SpanIterator.h"
 #include "Trace.h"
 
+#if defined(_AIX) && defined(open)
+#undef open
+#endif
+
 /* The "header" consists of a jint opcode and a jint span count value */
 #define INTS_PER_HEADER  2
 #define BYTES_PER_HEADER 8

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1918699480

From sgehwolf at openjdk.org  Wed Jan 31 10:06:02 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 31 Jan 2024 10:06:02 GMT
Subject: RFR: 8307977: jcmd and jstack broken for target processes running
 with elevated capabilities
In-Reply-To: <xZ0hqixmRVbQVa4aebnHgnnOZQWh4p1TaCuBM3_gA10=.274b2e50-ed55-4e33-9137-01fa9c997751@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <xZ0hqixmRVbQVa4aebnHgnnOZQWh4p1TaCuBM3_gA10=.274b2e50-ed55-4e33-9137-01fa9c997751@github.com>
Message-ID: <E5_5vSbaWhWCPcsxxQCM1H26FFwVv2zwiRH00j6XDII=.126e8d7e-ff40-4794-a9c4-6cbce4ebcc39@github.com>

On Tue, 30 Jan 2024 13:57:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> 8307977: jcmd and jstack broken for target processes running with elevated capabilities
>
> `test/hotspot/jtreg/serviceability` tests would also be worth running.

> Hi @jerboaa, thanks a lot for the hints! The container tests were new to me at least.
> 
> Just out of curiosity, are the container tests run as part of the tier1 tests (`make test-tier1`)? I'm not sure if I'm looking at the right place, but I get the feeling this is defined in `test/hotspot/jtreg/TEST.groups`, and the answer is maybe "no" in that case.
> 
> > Please run container tests, which do some jcmd testing across containers (host system runs jcmd and containers have the JVMs): `test/hotspot/jtreg/containers` See [testing.md](https://github.com/openjdk/jdk/blob/master/doc/testing.md#docker-tests) as to how to run them. I'll give this PR a spin as well.
> 
> If I understand it correctly, this is the way to run them. Please correct me if I'm wrong.
> 
> ```
> $ make test TEST="jtreg:test/hotspot/jtreg/containers"
> 
> ...
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/containers                  14    14     0     0   
> ==============================
> TEST SUCCESS
> ```

Thanks! Please make sure that the tests actually ran. If, for example, `docker` is not installed, they get skipped.

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1918774353

From duke at openjdk.org  Wed Jan 31 10:06:02 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 31 Jan 2024 10:06:02 GMT
Subject: RFR: 8307977: jcmd and jstack broken for target processes running
 with elevated capabilities
In-Reply-To: <E5_5vSbaWhWCPcsxxQCM1H26FFwVv2zwiRH00j6XDII=.126e8d7e-ff40-4794-a9c4-6cbce4ebcc39@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <xZ0hqixmRVbQVa4aebnHgnnOZQWh4p1TaCuBM3_gA10=.274b2e50-ed55-4e33-9137-01fa9c997751@github.com>
 <E5_5vSbaWhWCPcsxxQCM1H26FFwVv2zwiRH00j6XDII=.126e8d7e-ff40-4794-a9c4-6cbce4ebcc39@github.com>
Message-ID: <-QNvqBJ0TsflwWny_OvvMx8M6ghHTPQjvKWP-3vbTHM=.a801b7aa-7683-482b-94ed-afa5caa3daad@github.com>

On Wed, 31 Jan 2024 10:01:37 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Thanks! Please make sure that the tests actually ran. If, for example, docker is not installed, they get skipped.

Ah, good point. Running the tests did take some amount of time, so it felt like they did something. And by spamming `docker ps` while the tests are running I could see e.g. this:


$ docker ps
CONTAINER ID   IMAGE                                                          COMMAND                  CREATED         STATUS                  PORTS                                                NAMES
179ff2470b18   jdk-internal:test-containers-docker-TestJFREvents-jfr-events   "/jdk/bin/java -cp /?"   1 second ago    Up Less than a second                                                        stoic_clarke

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1918778186

From jpai at openjdk.org  Wed Jan 31 11:25:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Jan 2024 11:25:04 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v7]
In-Reply-To: <VqgN7RcgoFCZUhzJgfHsD3N6_2986kgObxn7dZfJk0Q=.e2c1227c-88ea-4436-b12d-efabb6f9f75c@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <VqgN7RcgoFCZUhzJgfHsD3N6_2986kgObxn7dZfJk0Q=.e2c1227c-88ea-4436-b12d-efabb6f9f75c@github.com>
Message-ID: <6uslrgtoCRVSIV-3wv_vIimlIn5gchx7w3n6Ac98XPw=.03be11c7-89bd-422e-bf40-68722775286a@github.com>

On Wed, 31 Jan 2024 08:01:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor - fix alignment

tier1, tier2 and tier3 testing of the latest state of this PR has passed both with and without the changes that were done in https://bugs.openjdk.org/browse/JDK-8300088.

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

PR Comment: https://git.openjdk.org/jdk/pull/17588#issuecomment-1918911434

From jkern at openjdk.org  Wed Jan 31 11:25:07 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 31 Jan 2024 11:25:07 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v11]
In-Reply-To: <aNgfepuaa1Z7omQhZ7Ywl6FeegnSZ3gUc97Sbo-fQYw=.d7ca62a8-496f-4f51-8f64-8bdf679c89ca@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <m0w6Rh_2nNuZ_vmFcBRok-cK5XDJtgZMGwKrl_VzrQE=.b469dc8d-50c2-44b4-8c3e-99036f6acb31@github.com>
 <oafXeyNylwlnKFzjgMkN4HdB_dEL0Qfu8MlL3kDtI5g=.e529938b-d393-4777-a4cf-50977fbdbb14@github.com>
 <aNgfepuaa1Z7omQhZ7Ywl6FeegnSZ3gUc97Sbo-fQYw=.d7ca62a8-496f-4f51-8f64-8bdf679c89ca@github.com>
Message-ID: <odz-rX0Gz897NF26n2ZEXl9vz35IJ8TUSFUKU5gPYdo=.92a5106b-c6cc-4522-bcfb-ec14b0a19638@github.com>

On Wed, 31 Jan 2024 07:42:49 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> src/hotspot/os/aix/os_aix.cpp line 1166:
>> 
>>> 1164:  Search order:
>>> 1165:  libfilename-> load "libfilename.so" first,then load libfilename.a,on failure. 
>>> 1166:  In,OpenJ9,the libary with .so extension is loaded first and then .a extension,on failure.
>> 
>> Hi Suchi, I'm puzzled. Your comment implies for me, that load library gets a 'base' filename without 'lib' prefix and without extension (e.g. 'name'). Then the j9 code creates the filename 'libname.so' first and on failure 'libname.a' second. What about given libname.so explicitly (e.g. libname.so)? Does j9 really use 'libname.a' as a failure fallback in this case?
>
> The load library gets the entire library name, after construction from dll_build_name. This is always a .so file name. When .so file name fails to load, we fallback to .a filename. 
> Do i need to mention the filename as libfilename.so then ?

Yes, I think this would make it clear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1472683336

From sroy at openjdk.org  Wed Jan 31 13:10:25 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 31 Jan 2024 13:10:25 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v12]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <V0ujbj5l55x7cTtT0FP6Ybx4sJavAnMw45NTOPe2rYI=.57c6e086-9fcc-454a-8dd5-c8ebb6179652@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Clarify comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/257f5def..713e514b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=10-11

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

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

From sroy at openjdk.org  Wed Jan 31 13:17:21 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 31 Jan 2024 13:17:21 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v13]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  spelling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/713e514b..af761abb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=11-12

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

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

From mdoerr at openjdk.org  Wed Jan 31 13:23:06 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 31 Jan 2024 13:23:06 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v13]
In-Reply-To: <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>
Message-ID: <LD7xQjA92D2M6JElPhJcBIHxXrQ9GkGU07qmlh8RKNo=.0b1855c9-202a-40aa-9bc3-feb2ca32c70e@github.com>

On Wed, 31 Jan 2024 13:17:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spelling

src/hotspot/os/aix/os_aix.cpp line 1176:

> 1174:   strncpy(file_path,filename, buffer_length + 1);
> 1175:   char* const pointer_to_dot = strrchr(file_path, '.');
> 1176:   assert(pointer_to_dot != nullptr, "Attempting to load a shared object without extension? %s", filename);

This should not only be an assertion. I think the check could be used instead of the strcmp below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1472813890

From sroy at openjdk.org  Wed Jan 31 15:09:09 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 31 Jan 2024 15:09:09 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v13]
In-Reply-To: <LD7xQjA92D2M6JElPhJcBIHxXrQ9GkGU07qmlh8RKNo=.0b1855c9-202a-40aa-9bc3-feb2ca32c70e@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>
 <LD7xQjA92D2M6JElPhJcBIHxXrQ9GkGU07qmlh8RKNo=.0b1855c9-202a-40aa-9bc3-feb2ca32c70e@github.com>
Message-ID: <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com>

On Wed, 31 Jan 2024 13:20:52 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   spelling
>
> src/hotspot/os/aix/os_aix.cpp line 1176:
> 
>> 1174:   strncpy(file_path,filename, buffer_length + 1);
>> 1175:   char* const pointer_to_dot = strrchr(file_path, '.');
>> 1176:   assert(pointer_to_dot != nullptr, "Attempting to load a shared object without extension? %s", filename);
> 
> This should not only be an assertion. I think the check could be used instead of the strcmp below.

I didn't follow that. You mean i need to keep a check if it is null and print it out ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1472963709

From kbarrett at openjdk.org  Wed Jan 31 15:12:24 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 31 Jan 2024 15:12:24 GMT
Subject: RFR: 8325055: Rename Injector.h
Message-ID: <HOaXp8CC7j5S0J7ZtnQFcKfpQnoW8atTTa4HPUqERiM=.221e3ec6-5e8b-4ba7-9dc5-c739d8998ec5@github.com>

Please review this trivial change that renames the file
test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp.

Testing: mach5 tier1

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

Commit messages:
 - rename Injector.h

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

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

From kbarrett at openjdk.org  Wed Jan 31 15:15:16 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 31 Jan 2024 15:15:16 GMT
Subject: RFR: 8325055: Rename Injector.h [v2]
In-Reply-To: <HOaXp8CC7j5S0J7ZtnQFcKfpQnoW8atTTa4HPUqERiM=.221e3ec6-5e8b-4ba7-9dc5-c739d8998ec5@github.com>
References: <HOaXp8CC7j5S0J7ZtnQFcKfpQnoW8atTTa4HPUqERiM=.221e3ec6-5e8b-4ba7-9dc5-c739d8998ec5@github.com>
Message-ID: <T_4Aw0a84PU9h4x-0Vxs4gNzZAw-QeuEfnNJX4bUQ4I=.f05184f9-b86f-4de8-b324-c30de141a799@github.com>

> Please review this trivial change that renames the file
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.h to Injector.hpp.
> 
> Testing: mach5 tier1

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  fix name in README

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17656/files
  - new: https://git.openjdk.org/jdk/pull/17656/files/ea9edad1..0ab5cf73

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

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

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

From gziemski at openjdk.org  Wed Jan 31 15:50:05 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 31 Jan 2024 15:50:05 GMT
Subject: RFR: 8324668: JDWP process management needs more efficient file
 descriptor handling [v7]
In-Reply-To: <VqgN7RcgoFCZUhzJgfHsD3N6_2986kgObxn7dZfJk0Q=.e2c1227c-88ea-4436-b12d-efabb6f9f75c@github.com>
References: <ho3qVssLxkg31vCPKy8Qz-_wzrv-8vtmC3hon13D6NM=.971c9cf3-c62e-4658-b4e7-2b008582daca@github.com>
 <VqgN7RcgoFCZUhzJgfHsD3N6_2986kgObxn7dZfJk0Q=.e2c1227c-88ea-4436-b12d-efabb6f9f75c@github.com>
Message-ID: <--dDlK42xbUCG_6_-GTYlNa6atGiA4SdIPERLHNtjqk=.76ca24ab-6f83-4644-a418-51d676f1b04b@github.com>

On Wed, 31 Jan 2024 08:01:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8324668?
>> 
>> This change proposes to fix the issue in jdwp where when launching a child process (for the `launch=<cmd>` option), it iterates over an extremely large number of file descriptors to close each one of those. Details about the issue and the proposed fixed are added in a subsequent comment in this PR https://github.com/openjdk/jdk/pull/17588#issuecomment-1912256075. tier1, tier2 and tier3 testing is currently in progress with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor - fix alignment

Marked as reviewed by gziemski (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17588#pullrequestreview-1854147646

From coleenp at openjdk.org  Wed Jan 31 19:02:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 31 Jan 2024 19:02:08 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
Message-ID: <zsgIr8-Xrh0jfgEEvfwhmlCViCSJuC5-NhUiSGgycgs=.c54cd0a0-11f4-4963-a976-8c63907cdae3@github.com>

This change uses a claim token to allocate multi dimensional arrays rather than holding MultiArray_lock around metaspace allocation.  We can't hold a mutex around metaspace allocation because it can create an OOM object and it can also call into JVMTI for a resource exhausted event.  Also, we were creating mirrors and more metadata arrays while holding this lock.   See the bug for more details and other ideas considered and rejected.

Tested with tier1-7.

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

Commit messages:
 - Some more cleanups, and make token really recursive.
 - 8308745: ObjArrayKlass::allocate_objArray_klass may call into java while holding a lock

Changes: https://git.openjdk.org/jdk/pull/17660/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17660&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308745
  Stats: 156 lines in 10 files changed: 90 ins; 17 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/17660.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17660/head:pull/17660

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

From dchuyko at openjdk.org  Wed Jan 31 21:12:19 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Wed, 31 Jan 2024 21:12:19 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v25]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <hB_b875iSEC03cyQZ-VoMEcny7ZaoBu_yeH9lohqF44=.5c8f186c-44f8-407a-941e-328ad077f14a@github.com>

> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
> 
> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
> 
> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods).
> 
> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter.
> 
> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them.
> 
> In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ...

Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:

 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Deopt osr, cleanups
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - ... and 33 more: https://git.openjdk.org/jdk/compare/5b9b176c...ea0322cd

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

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=24
  Stats: 381 lines in 15 files changed: 348 ins; 3 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/14111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111

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

From kevinw at openjdk.org  Wed Jan 31 21:29:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 31 Jan 2024 21:29:14 GMT
Subject: RFR: 8324845: management.properties text "interface name" is
 misleading [v2]
In-Reply-To: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
Message-ID: <tQVu8b_7H1uge7tw1CsxMVCTVY8pY2-b3nkmtOWp8R0=.6b2cc8ed-5c93-4561-adf9-ee18ccc5e2e4@github.com>

> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.
> 
> This change only affects comment text in a properties file.
> 
> (We don't currently mention this property in other docs, e.g. in the M&M guide.)

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

  text update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17615/files
  - new: https://git.openjdk.org/jdk/pull/17615/files/d1eaf87b..58cdf0cf

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

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

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

From kevinw at openjdk.org  Wed Jan 31 21:29:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 31 Jan 2024 21:29:14 GMT
Subject: RFR: 8324845: management.properties text "interface name" is
 misleading [v2]
In-Reply-To: <umLA7Z-w0LoiGkLIspdjUAjiDnliDq24TeYkvp8WSMY=.2f3b3c98-565c-4594-81ea-7e8ea52cfa9d@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
 <umLA7Z-w0LoiGkLIspdjUAjiDnliDq24TeYkvp8WSMY=.2f3b3c98-565c-4594-81ea-7e8ea52cfa9d@github.com>
Message-ID: <TZLE8XWzI3OhbNr7b-NAVJ5C--TPlZqOdag2djfcF_w=.57bd932c-1171-4eb2-ae7a-5828dc27c394@github.com>

On Mon, 29 Jan 2024 15:24:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   text update
>
> src/jdk.management.agent/share/conf/management.properties line 258:
> 
>> 256: #
>> 257: # com.sun.management.jmxremote.host=<host-name-or-address>
>> 258: #      Specifies the address on which the JMX RMI agent will bind.
> 
> The placeholder is "host-name-or-address" so it might be clearer to say the local host name or IP address in the description.

ok!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17615#discussion_r1473484519

From amenkov at openjdk.org  Wed Jan 31 21:34:11 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 31 Jan 2024 21:34:11 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream
Message-ID: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>

FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
Heap walking API implementation is the last user of the klasses.
The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code.
Additionally removed/updated includes of reflectionUtils.hpp.

Testing:
  - tier1..4;
  - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions);
  - new test from #17580 (now the test runs several times faster).

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/17661/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17661&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318566
  Stats: 290 lines in 10 files changed: 41 ins; 230 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/17661.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17661/head:pull/17661

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

From cjplummer at openjdk.org  Wed Jan 31 23:07:16 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 31 Jan 2024 23:07:16 GMT
Subject: RFR: 8324066: "clhsdb jstack" should not by default scan for j.u.c
 locks because it can be very slow [v4]
In-Reply-To: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
References: <CUQflVF5bdwl2OZ3wdX76WVCIQbWd0lxorfW-XQPgCQ=.dc563387-06a9-4b24-8185-cea5e8414c03@github.com>
Message-ID: <T2jz7IinHBaSQEFhVqsG2QtZKpCRdIh4ppGyISAaFUY=.c55b8e87-4db3-4b6b-8486-40534685cc2d@github.com>

> I noticed that "clhsdb jstack" seemed to hang when I attached to process with a somewhat large heap. It had taken over 10 minutes when I finally decided to have a look at the SA process (using bin/jstack), which came up with the following in the stack:
> 
> 
> at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ObjectHeap.java:117)
> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:70)
> at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/ConcurrentLocksPrinter.java:36)
> at sun.jvm.hotspot.tools.StackTrace.run([jdk.hotspot.agent at 23-internal](jdk.hotspot.agent at 23-internal)/StackTrace.java:71)
> 
> 
> This code is meant to print information about j.u.c. locks. It it works by searching the entire java heap for instances of AbstractOwnableSynchronizer. This is a very expensive operation because it means not only does SA need to read in the entire java heap, but it needs to create a Klass mirror for every heap object so it can determine its type.
> 
> Our testing doesn't seem to run into this slowness problem because "clhsdb jstack" only iterates over the heap if AbstractOwnableSynchronizer has been loaded, which it won't be if no j.u.c. locks have been created. This seems to be the case wherever we use "clhsdb jstack" in testing. We do have some tests that likely result in j.u.c locks, but they all use "jhsdb jstack", which doesn't have this issue (it requires use of the --locks argument to enable printing of j.u.c locks).
> 
> This issue was already called out in [JDK-8262098](https://bugs.openjdk.org/browse/JDK-8262098). For this CR I am proposing that "clhsdb jstack" not include j.u.c lock scanning by default, and add the -l argument to enable it. This will make it similar to bin/jstack, which also has a -l argument, and to "clhsdb jstack", which has a --locks argument (which maps internally to the Jstack.java -l argument).
> 
> The same changes are also being made to "clhsdb pstack".
> 
> Tested with all tier1, tier2, and tier5 svc tests.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  simplify regex passed to String.split().

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17479/files
  - new: https://git.openjdk.org/jdk/pull/17479/files/6c24a9a2..929de70f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17479&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17479&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17479/head:pull/17479

PR: https://git.openjdk.org/jdk/pull/17479

From mchung at openjdk.org  Wed Jan 31 23:16:00 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 31 Jan 2024 23:16:00 GMT
Subject: RFR: 8324845: management.properties text "interface name" is
 misleading [v2]
In-Reply-To: <tQVu8b_7H1uge7tw1CsxMVCTVY8pY2-b3nkmtOWp8R0=.6b2cc8ed-5c93-4561-adf9-ee18ccc5e2e4@github.com>
References: <WniTMUWus1sHcpZgZa3rZWz4Zaof2yHzHZiO0Q9bTPE=.c5fd53fc-320f-4680-bb27-4f6bbb84d69d@github.com>
 <tQVu8b_7H1uge7tw1CsxMVCTVY8pY2-b3nkmtOWp8R0=.6b2cc8ed-5c93-4561-adf9-ee18ccc5e2e4@github.com>
Message-ID: <v02sksMol1wSYEAa3IZG2FDWRXRS1HTj-DtkuK0pMv8=.06fd2b94-0c7a-4042-bf72-5d9fef26d396@github.com>

On Wed, 31 Jan 2024 21:29:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> We have the text "host-or-interface-name" describing the com.sun.management.jmxremote.host property in management.properties, but interface names (like "eth0" or "lo", or "ens3"...) are not what it accepts.  It should just say it needs to be a host name or address.
>> 
>> This change only affects comment text in a properties file.
>> 
>> (We don't currently mention this property in other docs, e.g. in the M&M guide.)
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   text update

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17615#pullrequestreview-1855055246

From cjplummer at openjdk.org  Wed Jan 31 23:39:00 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 31 Jan 2024 23:39:00 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream
In-Reply-To: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
Message-ID: <EMTaDvCBQ2Ham6qJmwLvyc_mlHPvtzYbRA2eZXkZhBA=.bdc8e162-d2dc-4c29-a445-6ca4bb217342@github.com>

On Wed, 31 Jan 2024 21:28:34 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> Heap walking API implementation is the last user of the klasses.
> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code.
> Additionally removed/updated includes of reflectionUtils.hpp.
> 
> Testing:
>   - tier1..4;
>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions);
>   - new test from #17580 (now the test runs several times faster).

src/hotspot/share/prims/jvmtiTagMap.cpp line 453:

> 451:   InstanceKlass* super_klass = ik->java_super();
> 452:   if (super_klass != nullptr) {
> 453:     start_index += add_instance_fields(super_klass, start_index);

Does hotspot have any rules against potentially very deep recursion that can overflow the stack?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1473607788