From kevinw at openjdk.org  Fri Mar  1 09:20:07 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Mar 2024 09:20:07 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v3]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <8KXxb75bSLsxawDFsEpe_JO4gZVMQwCA8kX5SYNLfWw=.f820b262-dc16-48fa-a982-4d0435b3dc32@github.com>

> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
> 
> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.

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

  Test update omitted from previous commit.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/f57f7274..cacbca27

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

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

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

From kevinw at openjdk.org  Fri Mar  1 09:34:58 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Mar 2024 09:34:58 GMT
Subject: RFR: 8226919: attach in linux hangs due to permission denied
 accessing /proc/pid/root
In-Reply-To: <Tnxg3PZLqM5MbwNpIZQp5eYSJfzJAwdmb7lJfy7BSKA=.4c997ccb-37e1-453e-8911-07f71c5574cb@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <7vessvLp3h1VbXvYrU855MWBnK6MB0XLsQokmm6ynM4=.e97f68cc-efd7-4c83-a36f-4031d784e5b1@github.com>
 <2ofyu9f8afgL3MxQ4YeMk9Bk6p-a55rMOXlHq3Q41ZY=.d6d2606a-3a95-479e-8f0b-7ca87cf83575@github.com>
 <Xld_4AoPH_tTfYzwfe2sqSDlZVN4aylJ9rli9dMqVWw=.42ea36fb-7b77-4e59-936a-357d82eb4dcf@github.com>
 <Tnxg3PZLqM5MbwNpIZQp5eYSJfzJAwdmb7lJfy7BSKA=.4c997ccb-37e1-453e-8911-07f71c5574cb@github.com>
Message-ID: <RoRpyedryq8wYcfZG-xLQI1vRfuL9NIvAFuVF5jIZ7w=.f9dcc4b6-55bc-4303-828c-bbe468b664ef@github.com>

On Wed, 28 Feb 2024 20:02:39 GMT, jdoylei <duke at openjdk.org> wrote:

>> Thank you @kevinjwalls and @jerboaa for reviewing and guiding me through this process, this was a great as a first-time JDK contributor!
>> 
>> One more question, can I do anything to help getting this backported to e.g. 21 and 17?
>
> @slovdahl - Apologies for adding a comment to a closed Pull Request, but I happened on https://bugs.openjdk.org/browse/JDK-8307977 via the earlier https://bugs.openjdk.org/browse/JDK-8179498 after researching "AttachNotSupportedException: Unable to open socket file" and troubleshooting our own OpenJDK 17 jcmd setup on top of containers and Kubernetes.  Reading the code changes and discussion here, I'm concerned that this change, which I understand is not yet in OpenJDK 17, might cause a regression with our setup.
> 
> We're running jcmd (OpenJDK build 17.0.10+7-LTS) and the target JVM in two separate containers in a Kubernetes pod.  The target JVM container is already running, and then we use `kubectl debug --target=...` to start a Kubernetes debug container with jcmd that targets the first container.  Given the `--target` option, they share the same Linux process namespace (both think the target JVM is PID 1).  But since they are separate containers, they see different root filesystems (jcmd container sees the target JVM tmpdir under /proc/1/root/tmp but has its own distinct /tmp directory).  
> 
> I believe the attach file and socket file paths then work like this in OpenJDK 17:
> * jcmd creates the .attach_pid1 attach file without issues using /proc/1/cwd
> * Target JVM finds the .attach_pid1 attach file in its cwd.
> * Target JVM creates the .java_pid1 socket file in its tmpdir /tmp
> * jcmd finds the .java_pid1 socket file in /proc/1/root/tmp
> 
> I think this scenario with a Kubernetes debug container may be a little different from other Docker container scenarios because these are two different containers with _different root filesystems_ but _the same Linux process namespace_.  So jcmd using `/proc/<pid>/root` is necessary to find the socket file, even though jcmd and the target JVM both agree the PID is the same (1).  A similar scenario with just Docker Engine is described at [docker container run - Example, join another container's PID namespace](https://docs.docker.com/reference/cli/docker/container/run/#example-join-another-containers-pid-namespace).
> 
> If I understand the code change for this PR, I think it will change the behavior in this scenario, because `findSocketFile` will have `pid == ns_pid`, and now will use /tmp instead of `/proc/<pid>/root/tmp`, based on `findTargetProcessTmpDirectory`.
> 
> We are lucky currently that the only place the current OpenJDK 17 code checks `pid == ns_pid` is the `createAttachFile` catch block that runs if `/proc/<pid>/cwd/.attach...

Logged https://bugs.openjdk.org/browse/JDK-8327114 for investigation.  Thanks @jdoylei  !

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1972833655

From kevinw at openjdk.org  Fri Mar  1 09:44:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Mar 2024 09:44:18 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature
Message-ID: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>

The deprecated Subject Delegation feature in JMX will be removed.

This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

Commit messages:
 - JMXConnector to throw UnsupportedOperationException
 - RMIConnectionImpl to throw when RMI calls invoke with delegatedSubject.  Removal of SubjectDelegator class.
 - Use default method.
 - Remove delegationSubject from private class RemoteMBeanServerConnection
 - 8326666: Remove the Java Management Extension (JMX) Subject Delegation feature

Changes: https://git.openjdk.org/jdk/pull/18025/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326666
  Stats: 1642 lines in 29 files changed: 18 ins; 1547 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Fri Mar  1 09:44:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Mar 2024 09:44:18 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <Kn3IGHIVy5uhHscpa63rRJsv9GnuVdD2md_IvWjcs10=.e56720f5-3288-4326-9b21-0984a5095933@github.com>

On Tue, 27 Feb 2024 10:44:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

This covers the public interface to the feature, and tests.

Locally the feature is refused during a call to getMBeanServerConnection(with a non-null delegationSubject).

Remotely, `javax.management.remote.rmi.RMIConnectionImpl` has methods which accept a Subject parameter for Subject Delegation.  This cannot now be non-null in local usage, but an RMI Connection from an older JDK can invoke these methods with a non-null delegationSubject.  Such access will be recognised and an UnsupportedOperationException will be thrown (which the client will see).

RMIConnectionImpl can be simplified, and the class SubjectDelegator removed.

JMXSubjectDomainCombiner I would like to remove separately after this is done.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1972845693

From sspitsyn at openjdk.org  Fri Mar  1 11:04:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Mar 2024 11:04:58 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v19]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <xMHfnmVY1lg9NIcKzxZVGz9le-H-sabVcpw982hb5sg=.df818c28-dba3-43ac-8b7c-3082cedc3a3e@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:

 - review: update comment in threads.hpp
 - fix deadlock with carrier threads starvation in ObjectMonitorUsage test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/06711644..7244d349

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=17-18

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

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

From sspitsyn at openjdk.org  Fri Mar  1 11:10:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Mar 2024 11:10:57 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v3]
In-Reply-To: <CBZj7aDkrUIrsBESROtQUouIACD0QFQ4KP0n0KdPj38=.a8365bb6-cd25-4754-8d15-83b5006ea9be@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <CBZj7aDkrUIrsBESROtQUouIACD0QFQ4KP0n0KdPj38=.a8365bb6-cd25-4754-8d15-83b5006ea9be@github.com>
Message-ID: <wuH3lKimgcHQ2P8vcZd6Emw9JCN17TaTzZlKKz7syIg=.5d5c6f8a-8823-4681-b51a-58746a1e639c@github.com>

On Thu, 29 Feb 2024 04:17:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
>> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
>> 
>> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
>> 
>> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> 
>> Testing:
>>  - tested with the mach5 tiers 1-6
>
> 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
>  - fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method
>  - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

PING!! Need a couple of reviews, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/17944#issuecomment-1972989702

From sspitsyn at openjdk.org  Fri Mar  1 11:17:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Mar 2024 11:17:21 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v20]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <AcrCKVToPO4IQYcdRRk-tYx9W-cv7hVFKVcyCGXUngo=.d02d136c-e131-40d5-b54e-d24330b549ec@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge
 - review: update comment in threads.hpp
 - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
 - resolve merge conflict for deleted file objmonusage003.cpp
 - fix a typo in libObjectMonitorUsage.cpp
 - fix potential sync gap in the test ObjectMonitorUsage
 - improve ObjectMonitorUsage test native agent output
 - improved the ObjectMonitorUsage test to make it more elegant
 - review: remove test objmonusage003; improve test ObjectMonitorUsage
 - review: addressed minor issue with use of []; corrected the test desctiption
 - ... and 12 more: https://git.openjdk.org/jdk/compare/e85265ab...f1a97f51

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

Changes: https://git.openjdk.org/jdk/pull/17680/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=19
  Stats: 1123 lines in 15 files changed: 686 ins; 389 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

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

From sspitsyn at openjdk.org  Fri Mar  1 11:19:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Mar 2024 11:19:21 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v4]
In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
Message-ID: <FUW7Auwbo5fmBuS6k61jgn9gUBGf7oFZdm_NKq2VYR0=.26b02b4b-3868-4fab-9679-b3de35637d5a@github.com>

> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
> 
> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
> 
> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
> 
> Testing:
>  - tested with the mach5 tiers 1-6

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

 - Merge
 - Merge
 - fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method
 - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17944/files
  - new: https://git.openjdk.org/jdk/pull/17944/files/a4e8c5b5..1a3d1c19

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

  Stats: 2399 lines in 780 files changed: 475 ins; 436 del; 1488 mod
  Patch: https://git.openjdk.org/jdk/pull/17944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17944/head:pull/17944

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

From sspitsyn at openjdk.org  Fri Mar  1 11:50:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Mar 2024 11:50:05 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  rename after merge: jvmti_common.h to jvmti_common.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/f1a97f51..b449f04a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=19-20

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

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

From duke at openjdk.org  Fri Mar  1 15:25:49 2024
From: duke at openjdk.org (jdoylei)
Date: Fri, 1 Mar 2024 15:25:49 GMT
Subject: RFR: 8226919: attach in linux hangs due to permission denied
 accessing /proc/pid/root
In-Reply-To: <RoRpyedryq8wYcfZG-xLQI1vRfuL9NIvAFuVF5jIZ7w=.f9dcc4b6-55bc-4303-828c-bbe468b664ef@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <7vessvLp3h1VbXvYrU855MWBnK6MB0XLsQokmm6ynM4=.e97f68cc-efd7-4c83-a36f-4031d784e5b1@github.com>
 <2ofyu9f8afgL3MxQ4YeMk9Bk6p-a55rMOXlHq3Q41ZY=.d6d2606a-3a95-479e-8f0b-7ca87cf83575@github.com>
 <Xld_4AoPH_tTfYzwfe2sqSDlZVN4aylJ9rli9dMqVWw=.42ea36fb-7b77-4e59-936a-357d82eb4dcf@github.com>
 <Tnxg3PZLqM5MbwNpIZQp5eYSJfzJAwdmb7lJfy7BSKA=.4c997ccb-37e1-453e-8911-07f71c5574cb@github.com>
 <RoRpyedryq8wYcfZG-xLQI1vRfuL9NIvAFuVF5jIZ7w=.f9dcc4b6-55bc-4303-828c-bbe468b664ef@github.com>
Message-ID: <Zes91i-g8se0PkACelUnPKZAmWrQoRE_unPWK9M84Ck=.629874af-b415-4009-83d2-c74db89930e7@github.com>

On Fri, 1 Mar 2024 09:31:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> @slovdahl - Apologies for adding a comment to a closed Pull Request, but I happened on https://bugs.openjdk.org/browse/JDK-8307977 via the earlier https://bugs.openjdk.org/browse/JDK-8179498 after researching "AttachNotSupportedException: Unable to open socket file" and troubleshooting our own OpenJDK 17 jcmd setup on top of containers and Kubernetes.  Reading the code changes and discussion here, I'm concerned that this change, which I understand is not yet in OpenJDK 17, might cause a regression with our setup.
>> 
>> We're running jcmd (OpenJDK build 17.0.10+7-LTS) and the target JVM in two separate containers in a Kubernetes pod.  The target JVM container is already running, and then we use `kubectl debug --target=...` to start a Kubernetes debug container with jcmd that targets the first container.  Given the `--target` option, they share the same Linux process namespace (both think the target JVM is PID 1).  But since they are separate containers, they see different root filesystems (jcmd container sees the target JVM tmpdir under /proc/1/root/tmp but has its own distinct /tmp directory).  
>> 
>> I believe the attach file and socket file paths then work like this in OpenJDK 17:
>> * jcmd creates the .attach_pid1 attach file without issues using /proc/1/cwd
>> * Target JVM finds the .attach_pid1 attach file in its cwd.
>> * Target JVM creates the .java_pid1 socket file in its tmpdir /tmp
>> * jcmd finds the .java_pid1 socket file in /proc/1/root/tmp
>> 
>> I think this scenario with a Kubernetes debug container may be a little different from other Docker container scenarios because these are two different containers with _different root filesystems_ but _the same Linux process namespace_.  So jcmd using `/proc/<pid>/root` is necessary to find the socket file, even though jcmd and the target JVM both agree the PID is the same (1).  A similar scenario with just Docker Engine is described at [docker container run - Example, join another container's PID namespace](https://docs.docker.com/reference/cli/docker/container/run/#example-join-another-containers-pid-namespace).
>> 
>> If I understand the code change for this PR, I think it will change the behavior in this scenario, because `findSocketFile` will have `pid == ns_pid`, and now will use /tmp instead of `/proc/<pid>/root/tmp`, based on `findTargetProcessTmpDirectory`.
>> 
>> We are lucky currently that the only place the current OpenJDK 17 code checks `pid == ns_pid` is the `createAttachFile` catch block that ru...
>
> Logged https://bugs.openjdk.org/browse/JDK-8327114 for investigation.  Thanks @jdoylei  !

@kevinjwalls - Perfect, thank you for opening the JBS bug!

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1973380664

From dnsimon at openjdk.org  Fri Mar  1 17:28:12 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 1 Mar 2024 17:28:12 GMT
Subject: RFR: 8327136:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java fails
 on libgraal
Message-ID: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>

To account for slightly slower compile times on libgraal + fastdebug + `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from 2000 ms to 3000 ms.
With this change, the test now reliably passes.

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

Commit messages:
 - adjust timeout in NotifReconnectDeadlockTest.java

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

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

From never at openjdk.org  Fri Mar  1 18:00:53 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 1 Mar 2024 18:00:53 GMT
Subject: RFR: 8327136:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java fails
 on libgraal
In-Reply-To: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
References: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
Message-ID: <pTleWEVysb5lBj6Bl6ETg_aXPEwDatFMUrJre6aVuao=.2fd589bd-71ec-4fc7-9c8e-a72f870b65c6@github.com>

On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> To account for slightly slower compile times on libgraal + fastdebug + `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.

Looks good

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18085#pullrequestreview-1911730736

From sspitsyn at openjdk.org  Fri Mar  1 18:13:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Mar 2024 18:13:55 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v8]
In-Reply-To: <225C3AcEAOR7Zd--eHOBiqFHVv6h3Vpqet9TvXM1t08=.a086aa88-bb89-4d2d-9186-9a22eab00db4@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <i4ilc2XEworX6I0J0trCxtd9jqZ4Q7SERhG0WJyRtl0=.cce47aa4-5833-4af0-a795-85701f346973@github.com>
 <225C3AcEAOR7Zd--eHOBiqFHVv6h3Vpqet9TvXM1t08=.a086aa88-bb89-4d2d-9186-9a22eab00db4@github.com>
Message-ID: <fmWDefbI_KASdv0-msappowGKQq4pXcUatMAPxLVc38=.3180367a-f74d-4cbf-8824-a863c6b0fd5a@github.com>

On Wed, 14 Feb 2024 21:13:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: added assert to get_pending_threads; added suggested coverage to test objmonusage003
>
> CHECK_FOR_BAD_RESULTS and ADD_DELAYS_FOR_RACES flags and
> their associated code paths are for temporary debugging only.

@dcubed-ojdk @dholmes-ora
Dan and David, I think, I've addressed all your comments.
Do you have any other concerns? Can you approve it now? Does the RN look okay?

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1973668452

From kevinw at openjdk.org  Fri Mar  1 18:31:42 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Mar 2024 18:31:42 GMT
Subject: RFR: 8327136:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java fails
 on libgraal
In-Reply-To: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
References: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
Message-ID: <vovpAubRjPcGR0xK_f_HY_MzrvTlxSTHc5539OGa0tc=.ca0b7431-dceb-4166-9635-7b949087f92b@github.com>

On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> To account for slightly slower compile times on libgraal + fastdebug + `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.

Sounds good.

One day, somebody among us will implement timeouts that take into account whether there are JVM options like -Xcomp or other factors that slow things down... 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18085#pullrequestreview-1911784742

From dnsimon at openjdk.org  Fri Mar  1 18:56:58 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 1 Mar 2024 18:56:58 GMT
Subject: RFR: 8327136:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java fails
 on libgraal
In-Reply-To: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
References: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
Message-ID: <r-AW1KL6Yf66qMLnBfc8lmtK-n107GC28XPZGlHgy7M=.9548732d-654d-4ea5-998c-80a18ff879e1@github.com>

On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> To account for slightly slower compile times on libgraal + fastdebug + `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/18085#issuecomment-1973749075

From dnsimon at openjdk.org  Fri Mar  1 18:56:59 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 1 Mar 2024 18:56:59 GMT
Subject: Integrated: 8327136:
 javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java fails
 on libgraal
In-Reply-To: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
References: <8aW2AYHXl5A8CWbBxmHqHe1kljS15E80jT9wS3HIEnY=.693b8755-9ef6-4ba5-9df5-0f3efbe69e1a@github.com>
Message-ID: <gbVrc_z7KIwt7pA6klCeVMeLQFrsrjzOn4UlfU0RrXQ=.c2200bdd-19a4-477c-bba2-00a9ebd7f7d0@github.com>

On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> To account for slightly slower compile times on libgraal + fastdebug + `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.

This pull request has now been integrated.

Changeset: 8f0fb27d
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f0fb27decec28f32e4d88341237189ba4a340fb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8327136: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java fails on libgraal

Reviewed-by: never, kevinw

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

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

From cjplummer at openjdk.org  Fri Mar  1 22:00:51 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Mar 2024 22:00:51 GMT
Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves
 created files in the /tmp dir.
In-Reply-To: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
Message-ID: <vAMKKZznWXjjFPbDiEvCStBNsnBEbsNW64uCIGjziLQ=.2d9c99f4-d6c4-4f5a-801a-3662b7d58f96@github.com>

On Fri, 23 Feb 2024 21:55:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> PerfMapTest.java issues the Compiler.perfmap jcmd with a filename argument to write the perfmap to. It does this in 3 different modes. 2 of the modes result in a perfmap file being left in the tmp directory that is not removed after the test executes (and should be removed). The 3rd mode creates the perfmap file in the directory specified by the test.dir property, and is ok to leave the file there. I've added code to delete the /tmp files that are created.
> 
> I did a bit of extra testing by hand. I created `/tmp/perf-<pid>.map` as root. As expected the Files.deleteIfExists() call threw an exception due to the lack of permissions to delete the file. However, I then realized the file had a size of 0, which means the test was not even doing a proper job of testing that the perfrmap jcmd was working. In other words, the test should have failed long before getting to the Files.deleteIfExists(), so I added a size check to make sure it fails when the file is not written to.

The error handling in this test is a real PITA. I just realized that Files.deleteIfExists() should really be in a finally block. But doing so means that if it throws an exception, then any exception that was already thrown during run() is lost. So, for example, let's say you don't have access to the file and it already has contents, but they are not valid for a perfmap file. The "Invalid file format" assert will result in an exception, but this would be lost when Files.deleteIfExists() also throws a permissions exception. The way around this is really ugly:


        try {
            run(new JMXExecutor(), "Compiler.perfmap " + path.toString(), path);
            Files.deleteIfExists(path);
        } catch (Throwable t) {
            t.printStackTrace(System.out);
            Files.deleteIfExists(path);
            throw t;
        }


So if run() passes, we do the deleteIfExists() and allow it to throw an exception if needed (which would cause the test to appropriately fail with this exception). If run() throws an exception, we catch it, print it, call deleteIfExists(), and then rethrow the exception. If deleteIfExists() throws an exception, then that is what the test will exit with, but at least we'll have first printed the exception from run(), so it is not lost. However, if deleteIfExists() doesn't throw an exception, we end up printing the exception thrown by run() twice. Once in this added exception handler, and once by jtreg on test exit. Can't say I like this approach, but I don't have a better solution ATM.

The other choice is what we have now. Don't put deleteIfExists() in a finally block, and don't bother deleting the file if run() throws an exception. The main case where this becomes a problem is if the file is accessible, is written to by the jcmd, but the contents for some reason don't pass the sanity test. The test will appropriate fail, but it will also leave the perfmap file behind. Maybe this is acceptable since it should never happen, and does help keep the test code a lot simpler.

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

PR Comment: https://git.openjdk.org/jdk/pull/17992#issuecomment-1973983886

From sspitsyn at openjdk.org  Fri Mar  1 23:36:06 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Mar 2024 23:36:06 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
Message-ID: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>

Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.

Testing:
 - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
 - ran mach5 tiers 1-6

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

Commit messages:
 - fix trailing space in libInterruptRawMonitor.cpp
 - 8325187: JVMTI GetThreadState says virtual thread is JVMTI_THREAD_STATE_INTERRUPTED when it no longer is

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

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

From lmesnik at openjdk.org  Fri Mar  1 23:49:51 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 1 Mar 2024 23:49:51 GMT
Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves
 created files in the /tmp dir.
In-Reply-To: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
Message-ID: <af8rtlph1Nb9Qux2-1Yc4tFolzVc3qZT6lauVnyhJX8=.96ccd4bf-e553-4eeb-9ae3-2c26e70e8f85@github.com>

On Fri, 23 Feb 2024 21:55:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> PerfMapTest.java issues the Compiler.perfmap jcmd with a filename argument to write the perfmap to. It does this in 3 different modes. 2 of the modes result in a perfmap file being left in the tmp directory that is not removed after the test executes (and should be removed). The 3rd mode creates the perfmap file in the directory specified by the test.dir property, and is ok to leave the file there. I've added code to delete the /tmp files that are created.
> 
> I did a bit of extra testing by hand. I created `/tmp/perf-<pid>.map` as root. As expected the Files.deleteIfExists() call threw an exception due to the lack of permissions to delete the file. However, I then realized the file had a size of 0, which means the test was not even doing a proper job of testing that the perfrmap jcmd was working. In other words, the test should have failed long before getting to the Files.deleteIfExists(), so I added a size check to make sure it fails when the file is not written to.

I thought about execution of   Files.deleteIfExists(path) in the case of test fails, but decided that it is not so important. Also, test always might fail with crash when no finally block is executed. So I am fine with current way.

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

PR Comment: https://git.openjdk.org/jdk/pull/17992#issuecomment-1974089555

From sspitsyn at openjdk.org  Sat Mar  2 00:17:43 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Mar 2024 00:17:43 GMT
Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves
 created files in the /tmp dir.
In-Reply-To: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
Message-ID: <hO5-favvDtAGaGoDBZhzhlt8s2abZa4aqgiH9owWzsI=.6cc2c59d-bbfc-40d2-abfb-8718d64528e0@github.com>

On Fri, 23 Feb 2024 21:55:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> PerfMapTest.java issues the Compiler.perfmap jcmd with a filename argument to write the perfmap to. It does this in 3 different modes. 2 of the modes result in a perfmap file being left in the tmp directory that is not removed after the test executes (and should be removed). The 3rd mode creates the perfmap file in the directory specified by the test.dir property, and is ok to leave the file there. I've added code to delete the /tmp files that are created.
> 
> I did a bit of extra testing by hand. I created `/tmp/perf-<pid>.map` as root. As expected the Files.deleteIfExists() call threw an exception due to the lack of permissions to delete the file. However, I then realized the file had a size of 0, which means the test was not even doing a proper job of testing that the perfrmap jcmd was working. In other words, the test should have failed long before getting to the Files.deleteIfExists(), so I added a size check to make sure it fails when the file is not written to.

Looks good but posted a question.

test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 103:

> 101:         } while(Files.exists(path));
> 102:         run(new JMXExecutor(), "Compiler.perfmap " + path.toString(), path);
> 103:     }

Q: It is not clear why the file is not deleted in this case. Do I miss anything?

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17992#pullrequestreview-1912339995
PR Review Comment: https://git.openjdk.org/jdk/pull/17992#discussion_r1509721128

From cjplummer at openjdk.org  Sat Mar  2 00:46:51 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 2 Mar 2024 00:46:51 GMT
Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves
 created files in the /tmp dir.
In-Reply-To: <hO5-favvDtAGaGoDBZhzhlt8s2abZa4aqgiH9owWzsI=.6cc2c59d-bbfc-40d2-abfb-8718d64528e0@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
 <hO5-favvDtAGaGoDBZhzhlt8s2abZa4aqgiH9owWzsI=.6cc2c59d-bbfc-40d2-abfb-8718d64528e0@github.com>
Message-ID: <UXY0mjYQExrFC4PlBATrSiMuwBW4M7OGKvdoUMz8pa4=.e4b2f08d-d9a4-467c-b784-0664bc717a9d@github.com>

On Sat, 2 Mar 2024 00:14:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>  Q2: Can we use Files.deleteIfExists(path) in the finally block of the run() method instead?

I don't think that changes anything. If run() throws an exception and then Files.deleteIfExists() throws an exception from the finally block, the original exception is lost.

> One more approach is to wrap run() call into the runHelper() method:

Same issue with potentially losing the original exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17992#discussion_r1509758594

From sspitsyn at openjdk.org  Sat Mar  2 01:43:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Mar 2024 01:43:55 GMT
Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves
 created files in the /tmp dir.
In-Reply-To: <UXY0mjYQExrFC4PlBATrSiMuwBW4M7OGKvdoUMz8pa4=.e4b2f08d-d9a4-467c-b784-0664bc717a9d@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
 <hO5-favvDtAGaGoDBZhzhlt8s2abZa4aqgiH9owWzsI=.6cc2c59d-bbfc-40d2-abfb-8718d64528e0@github.com>
 <UXY0mjYQExrFC4PlBATrSiMuwBW4M7OGKvdoUMz8pa4=.e4b2f08d-d9a4-467c-b784-0664bc717a9d@github.com>
Message-ID: <O_9ZU4s62TAxdQx9AdHaYN9HkB4ssl6zTn-LI_3Ywrg=.a925e516-7aae-4fdf-8055-010fdb4945d8@github.com>

On Sat, 2 Mar 2024 00:44:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 103:
>> 
>>> 101:         } while(Files.exists(path));
>>> 102:         run(new JMXExecutor(), "Compiler.perfmap " + path.toString(), path);
>>> 103:     }
>> 
>> Q1: It is not clear why the file is not deleted in this case. Do I miss anything?
>> Q2: Can we use `Files.deleteIfExists(path)` in the `finally block` of the `run()` method instead?
>> 
>> 
>>     public void run(CommandExecutor executor, String cmd, Path path) {
>>        try {
>>            <body of run() method>
>>        } finally {
>>            Files.deleteIfExists(path);
>>        }
>>     }
>> 
>> One more approach is to wrap `run()` call into the `runHelper()` method:
>> 
>>     public void runHelper(CommandExecutor executor, String cmd, Path path) {
>>        try {
>>            run(executor, cmd, path);
>>        } finally {
>>            Files.deleteIfExists(path);
>>        }
>>     }
>
>>  Q2: Can we use Files.deleteIfExists(path) in the finally block of the run() method instead?
> 
> I don't think that changes anything. If run() throws an exception and then Files.deleteIfExists() throws an exception from the finally block, the original exception is lost.
> 
>> One more approach is to wrap run() call into the runHelper() method:
> 
> Same issue with potentially losing the original exception.

Two variants:

    public void runHelper(CommandExecutor executor, String cmd, Path path) {
       try {
           run(executor, cmd, path);
       } catch (Throwable t) {
            t.printStackTrace(System.out);
            throw t;
       } finally {
           Files.deleteIfExists(path);
       }
    }

or

    public void runHelper(CommandExecutor executor, String cmd, Path path) {
       try {
           run(executor, cmd, path);
       } finally {
           try {
              Files.deleteIfExists(path);
           } catch (Throwable t) {
              <print message about exception thrown from deleteIfExists>
              t.printStackTrace(System.out);
           }
       }
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17992#discussion_r1509803616

From cjplummer at openjdk.org  Sat Mar  2 04:35:51 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 2 Mar 2024 04:35:51 GMT
Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves
 created files in the /tmp dir.
In-Reply-To: <O_9ZU4s62TAxdQx9AdHaYN9HkB4ssl6zTn-LI_3Ywrg=.a925e516-7aae-4fdf-8055-010fdb4945d8@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
 <hO5-favvDtAGaGoDBZhzhlt8s2abZa4aqgiH9owWzsI=.6cc2c59d-bbfc-40d2-abfb-8718d64528e0@github.com>
 <UXY0mjYQExrFC4PlBATrSiMuwBW4M7OGKvdoUMz8pa4=.e4b2f08d-d9a4-467c-b784-0664bc717a9d@github.com>
 <O_9ZU4s62TAxdQx9AdHaYN9HkB4ssl6zTn-LI_3Ywrg=.a925e516-7aae-4fdf-8055-010fdb4945d8@github.com>
Message-ID: <N0cnbFgnDU4zra3HUZsOA16drgF5zK-fEKOeOdyxrZs=.69971fe4-9848-4889-9c43-2aa73b576e73@github.com>

On Sat, 2 Mar 2024 01:40:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>>  Q2: Can we use Files.deleteIfExists(path) in the finally block of the run() method instead?
>> 
>> I don't think that changes anything. If run() throws an exception and then Files.deleteIfExists() throws an exception from the finally block, the original exception is lost.
>> 
>>> One more approach is to wrap run() call into the runHelper() method:
>> 
>> Same issue with potentially losing the original exception.
>
> Two variants:
> 
>     public void runHelper(CommandExecutor executor, String cmd, Path path) {
>        try {
>            run(executor, cmd, path);
>        } catch (Throwable t) {
>             t.printStackTrace(System.out);
>             throw t;
>        } finally {
>            Files.deleteIfExists(path);
>        }
>     }
> 
> or
> 
>     public void runHelper(CommandExecutor executor, String cmd, Path path) {
>        try {
>            run(executor, cmd, path);
>        } finally {
>            try {
>               Files.deleteIfExists(path);
>            } catch (Throwable t) {
>               <print message about exception thrown from deleteIfExists>
>               t.printStackTrace(System.out);
>            }
>        }
>     }

The one issue with the first variant is that when run() throws an exception, it will be printed twice, assuming deleteIfExists() does not throw an exception. Basically you either get the exception printed twice, or you get the exception printed once plus whatever exception deleteIfExists() throws also printed (which is ok).

I think your 2nd example will work, but it's kind of confusing because if you got into the finally block via an exception, you then might throw another exception, which is handled in the finally block, and then (implicitly) the original exception is rethrown as you exit the finally block. However, if there was no exception from run() but deleteIfExists() throws an exception, the exception is printed, but does not cause the test to fail. I don't think we want that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17992#discussion_r1509883828

From jpai at openjdk.org  Sat Mar  2 06:23:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 2 Mar 2024 06:23:55 GMT
Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves
 created files in the /tmp dir.
In-Reply-To: <N0cnbFgnDU4zra3HUZsOA16drgF5zK-fEKOeOdyxrZs=.69971fe4-9848-4889-9c43-2aa73b576e73@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
 <hO5-favvDtAGaGoDBZhzhlt8s2abZa4aqgiH9owWzsI=.6cc2c59d-bbfc-40d2-abfb-8718d64528e0@github.com>
 <UXY0mjYQExrFC4PlBATrSiMuwBW4M7OGKvdoUMz8pa4=.e4b2f08d-d9a4-467c-b784-0664bc717a9d@github.com>
 <O_9ZU4s62TAxdQx9AdHaYN9HkB4ssl6zTn-LI_3Ywrg=.a925e516-7aae-4fdf-8055-010fdb4945d8@github.com>
 <N0cnbFgnDU4zra3HUZsOA16drgF5zK-fEKOeOdyxrZs=.69971fe4-9848-4889-9c43-2aa73b576e73@github.com>
Message-ID: <JWe1ya9HTdpRZ8V_xhVkfU_bO48oEXiHCfeUKBdd6uk=.60aafd0b-3fb9-45ff-83bd-80f487e9e266@github.com>

On Sat, 2 Mar 2024 04:33:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Two variants:
>> 
>>     public void runHelper(CommandExecutor executor, String cmd, Path path) {
>>        try {
>>            run(executor, cmd, path);
>>        } catch (Throwable t) {
>>             t.printStackTrace(System.out);
>>             throw t;
>>        } finally {
>>            Files.deleteIfExists(path);
>>        }
>>     }
>> 
>> or
>> 
>>     public void runHelper(CommandExecutor executor, String cmd, Path path) {
>>        try {
>>            run(executor, cmd, path);
>>        } finally {
>>            try {
>>               Files.deleteIfExists(path);
>>            } catch (Throwable t) {
>>               <print message about exception thrown from deleteIfExists>
>>               t.printStackTrace(System.out);
>>            }
>>        }
>>     }
>
> The one issue with the first variant is that when run() throws an exception, it will be printed twice, assuming deleteIfExists() does not throw an exception. Basically you either get the exception printed twice, or you get the exception printed once plus whatever exception deleteIfExists() throws also printed (which is ok).
> 
> I think your 2nd example will work, but it's kind of confusing because if you got into the finally block via an exception, you then might throw another exception, which is handled in the finally block, and then (implicitly) the original exception is rethrown as you exit the finally block. However, if there was no exception from run() but deleteIfExists() throws an exception, the exception is printed, but does not cause the test to fail. I don't think we want that.

Hello Chris, I haven't followed this PR and this is just a drive by comment about the exception handling discussion. In some other areas of our JDK tests, for situations like this, we do the following:


Throwable failure = null;
try {
    run(new JMXExecutor(), "Compiler.perfmap " + path.toString(), path);
} catch (Throwable t) {
    failure = t;
} finally {
    try {
        Files.deleteIfExists(path);
    } catch (IOException ioe) {
        if (failure != null) {
            // add the IOException as a suppressed exception to the original failure
            // and rethrow the original
            failure.addSuppressed(ioe);
            throw failure;
        }
        // no failures in the run(), but deleting the file failed, rethrow this IOException
        throw ioe;
    }
}

This way both the original test failure (if any) as well as the failure in the finally block (if any) are propagated and made available in the failure report.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17992#discussion_r1509896340

From alanb at openjdk.org  Sat Mar  2 08:01:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 2 Mar 2024 08:01:51 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>

On Fri, 1 Mar 2024 23:26:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

src/hotspot/share/runtime/javaThread.cpp line 594:

> 592:       // thread_oop is virtual, clear carrier thread interrupt status as well
> 593:       java_lang_Thread::set_interrupted(threadObj(), false);
> 594:     }

This isn't right for the case that Thread::interrupt it called around the same time.  The interrupt status on both the virtual thread and the carrier need to be kept in sync so the changes here need to work like an up call to VirtualThread.getAndClearInterrupt and use the interrupt lock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1509909644

From ihse at openjdk.org  Sun Mar  3 15:30:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 3 Mar 2024 15:30:55 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <eGE-Yo2mIy9CsBP7uNYcaR0IvQKqejcJW0eq8e2xQ08=.1c3808bd-bca4-4fe4-8bd2-ed752296968e@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

For the record, there is a series of comment posted as Github commit comments. See https://github.com/openjdk/jdk/commit/ac3ce2aa156332fc4e6f33018ff669657ab4b797#commitcomment-139295772.

According to the comments, this PR breaks building hsdis with ccache.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1975197285

From ihse at openjdk.org  Sun Mar  3 15:34:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 3 Mar 2024 15:34:54 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <537eZ4LFh0sfwSpT_HSyXOy5UZQo2H1B8WcxSjI9Ovs=.9d34407c-c8f0-4460-84f7-edc2891c78de@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

@claudionieder

> One last comment. I just discovered, that if I remove the --enable-ccache from the configure command, then it works also with this commit. Hopefully this helps for fixing the issue.

So what you really saying is that this breaks when compiling capstone hsdis on macOS/aarch64 when you have ccache enabled?

It seems more reasonable that this could be a ccache error than a hsdis-with-capstone error. Can you build any normal JDK targets with ccache?

(Also, why are you using ccache? It is highly unclear if that really adds any performance improvements)

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1975198444

From duke at openjdk.org  Sun Mar  3 23:30:51 2024
From: duke at openjdk.org (Claudio Nieder)
Date: Sun, 3 Mar 2024 23:30:51 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <wHcG1NUm5We4Qw1UF-yogB7brRcE3NhdH8TzPBomDgw=.a07db378-a32b-4071-93ac-374d5240e0d0@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

Indeed hsdis or no hsdis does not matter at all. --enable-ccache is broken with this commit in any case. I executed the much simplified script below, which builds once using this commit and once the parent commit. Seems, that with hsdis enabled HSDIS was just the first thing that needed to be compiled. Now it is failing when "Creating support/modules_libs/java.base/server/libjvm.dylib".

Regarding why I use ccache: I frankly didn't time it to see if there is an advantage. I just read in doc/building.md (lines 1517 ff) "The JDK build supports building with ccache when using gcc or clang. Using ccache can radically speed up compilation of native code if you often rebuild the same sources." so I included it in my personal script to build OpenJDK. But I can easily live without using ccache and personally wouldn't mind if OpenJDK stops supporting ccache. 

Below the content of `build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch.cmdline` for this commit ac3ce2aa where you can see the main issue, that the command `/opt/homebrew/bin/ccache /usr/bin/clang` is missing in front of the first compiler option -D__STDC_FORMAT_MACROS. Additionally some environment variables are missing/different.


cd /tmp/ac3ce2aa/jdk && CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=pch_defines -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -pipe -fno-rtti -fno-exceptions -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer -flimit-debug-info -mno-omit-leaf-frame-pointer -mstack-alignment=16 -std=c++14 -DMAC_OS_X_VERSION_MIN_REQUIRED=110000 -mmacosx-version-min=11.00.00 -DLIBC=default -D_ALLBSD_SOURCE -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE -Wall -Wextra -Wformat=2 -Wpointer-arith -Wsign-compare -Wreorder -Wunused-function -Wundef -Wunused-value -Woverloaded-virtual -fPIC -DVM_LITTLE_ENDIAN -D_LP64=1 -arch arm64 -DASSERT -DCHECK_UNHANDLED_OOPS -DTARGET_ARCH_aarch64 -DINCLUDE_SUFFIX_OS=_bsd -DINCLUDE_SUFFIX_CPU=_aarch64 -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc -DAARCH64 -DHOTSPOT_LIB_ARCH='"aarch64"' -DCOMPILER1 -DCOMPILER2 -DDTRACE_ENABLED -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc/adfiles -Isrc/hotspot/share -Isrc/hotspo
 t/os/bsd -Isrc/hotspot/os/posix -Isrc/hotspot/cpu/aarch64 -Isrc/hotspot/os_cpu/bsd_aarch64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc -Isrc/hotspot/share/precompiled -Isrc/hotspot/share/include -Isrc/hotspot/os/posix/include -Ibuild/macosx-aarch64-server-fastdebug/support/modules_include/java.base -Ibuild/macosx-aarch64-server-fastdebug/support/modules_include/java.base/darwin -Isrc/java.base/share/native/libjimage -arch arm64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc/adfiles -Isrc/hotspot/share -Isrc/hotspot/os/bsd -Isrc/hotspot/os/posix -Isrc/hotspot/cpu/aarch64 -Isrc/hotspot/os_cpu/bsd_aarch64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc -g -gdwarf-4 -gdwarf-aranges -Wno-unknown-warning-option -Wno-unused-parameter -Wno-unused -Wno-sometimes-uninitialized -Wno-missing-braces -Wno-delete-non-abstract-non-virtual-dtor -Wno-unknown-pragmas -Wno-tautological-constant-out-of-range-compare -isysroot /Applic
 ations/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk -iframework /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/Library/Frameworks -O3 -x c++-header -c -MMD -MF build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch.d.tmp src/hotspot/share/precompiled/precompiled.hpp -o build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch


and here the content of `build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch.cmdline` for the parent commit bceaed6d


cd /tmp/bceaed6d/jdk && CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=pch_defines,time_macros CCACHE_BASEDIR=/tmp/bceaed6d/jdk/ /opt/homebrew/bin/ccache /usr/bin/clang -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -pipe -fno-rtti -fno-exceptions -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer -flimit-debug-info -mno-omit-leaf-frame-pointer -mstack-alignment=16 -std=c++14 -DMAC_OS_X_VERSION_MIN_REQUIRED=110000 -mmacosx-version-min=11.00.00 -DLIBC=default -D_ALLBSD_SOURCE -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE -Wall -Wextra -Wformat=2 -Wpointer-arith -Wsign-compare -Wreorder -Wunused-function -Wundef -Wunused-value -Woverloaded-virtual -fPIC -DVM_LITTLE_ENDIAN -D_LP64=1 -arch arm64 -DASSERT -DCHECK_UNHANDLED_OOPS -DTARGET_ARCH_aarch64 -DINCLUDE_SUFFIX_OS=_bsd -DINCLUDE_SUFFIX_CPU=_aarch64 -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc -DAARCH64 -DHOTSPOT_LIB_ARCH='"aarch64"' -DCOMPILER1 -DCOMPILER2 -DDTRACE_ENABLED -Ibuild/macosx-aarch64-s
 erver-fastdebug/hotspot/variant-server/gensrc/adfiles -Isrc/hotspot/share -Isrc/hotspot/os/bsd -Isrc/hotspot/os/posix -Isrc/hotspot/cpu/aarch64 -Isrc/hotspot/os_cpu/bsd_aarch64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc -Isrc/hotspot/share/precompiled -Isrc/hotspot/share/include -Isrc/hotspot/os/posix/include -Ibuild/macosx-aarch64-server-fastdebug/support/modules_include/java.base -Ibuild/macosx-aarch64-server-fastdebug/support/modules_include/java.base/darwin -Isrc/java.base/share/native/libjimage -arch arm64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc/adfiles -Isrc/hotspot/share -Isrc/hotspot/os/bsd -Isrc/hotspot/os/posix -Isrc/hotspot/cpu/aarch64 -Isrc/hotspot/os_cpu/bsd_aarch64 -Ibuild/macosx-aarch64-server-fastdebug/hotspot/variant-server/gensrc -g -gdwarf-4 -gdwarf-aranges -Wno-unknown-warning-option -Wno-unused-parameter -Wno-unused -Wno-sometimes-uninitialized -Wno-missing-braces -Wno-delete-non-abstract-non-virtual-dtor 
 -Wno-unknown-pragmas -Wno-tautological-constant-out-of-range-compare -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk -iframework /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/Library/Frameworks -O3 -x c++-header -c -MMD -MF build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch.d.tmp src/hotspot/share/precompiled/precompiled.hpp -o build/macosx-aarch64-server-fastdebug/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.pch


Script used to test


#!/bin/bash

export LANG=en_US
export LC_ALL=en_US

suspectedCommit=ac3ce2aa
preceedingCommit=bceaed6d

function build() {
 bash ./configure --enable-ccache --disable-warnings-as-errors --with-debug-level=fastdebug
 make clean
 make images
}

cd /tmp
rm -rf $preceedingCommit
mkdir $preceedingCommit
cd $preceedingCommit
git clone "https://github.com/openjdk/jdk.git"
cd jdk
git checkout $preceedingCommit
build

cd /tmp
rm -rf $suspectedCommit
mkdir $suspectedCommit
cd $suspectedCommit
git clone "https://github.com/openjdk/jdk.git"
cd jdk
git checkout $suspectedCommit
build

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1975396416

From duke at openjdk.org  Mon Mar  4 00:02:48 2024
From: duke at openjdk.org (Claudio Nieder)
Date: Mon, 4 Mar 2024 00:02:48 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <VVosEvM3nkqv_7fvXj3bkwuqGz5GQq6t-GadFdtX1D4=.d3f7ccf0-9fa3-469d-a504-f1f0dcdc8a81@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

As a side note, I now did time the effect of ccache using the below script. This is the result without ccache


real	3m42.896s
user	20m49.584s
sys	2m56.578s


this is the result with --enable-ccache

real	4m56.290s
user	26m16.230s
sys	5m50.993s


Thus at least on my MacBook Pro M1 using ccache slows down the compilation!

Script

#!/bin/bash

export LANG=en_US
export LC_ALL=en_US

preceedingCommit=bceaed6d

d1=noCCache
d2=ccache

cd /tmp
rm -rf $d1
mkdir $d1
cd $d1
git clone "https://github.com/openjdk/jdk.git"
cd jdk
git checkout $preceedingCommit
bash ./configure --disable-warnings-as-errors --with-debug-level=fastdebug \
  --enable-hsdis-bundling --with-hsdis=capstone
make clean
time make images 2>&1 | tee /tmp/$d1/time.txt

cd /tmp
rm -rf $d2
mkdir $d2
cd $d2
git clone "https://github.com/openjdk/jdk.git"
cd jdk
git checkout $preceedingCommit
bash ./configure --disable-warnings-as-errors --with-debug-level=fastdebug \
  --enable-ccache --enable-hsdis-bundling --with-hsdis=capstone
make clean
time make images 2>&1 | tee /tmp/$d2/time.txt

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1975406744

From dholmes at openjdk.org  Mon Mar  4 02:53:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Mar 2024 02:53:45 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
Message-ID: <TY7ppKdrbwAgALFds3fg851541sGEHYp7OWtszUGEnY=.eb8d919d-c491-4a37-8960-0d6a869d05b6@github.com>

On Fri, 1 Mar 2024 11:50:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename after merge: jvmti_common.h to jvmti_common.hpp

> The notify_waiters has to include all threads waiting to be notified in Object.wait().
> The implementation also includes the threads waiting to re-enter the monitor in Object.wait() which is wrong.

This is not in fact the case so can you please remove this from the problem statement/description above.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1975561224

From dholmes at openjdk.org  Mon Mar  4 03:54:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Mar 2024 03:54:54 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
Message-ID: <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>

On Fri, 1 Mar 2024 11:50:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename after merge: jvmti_common.h to jvmti_common.hpp

Thanks Serguei, this is generally looking good, but I have one main query with the logic, a number of suggestions regarding comments, and a few issues in the new test code.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1489:

> 1487:     assert(mon != nullptr, "must have monitor");
> 1488:     // this object has a heavyweight monitor
> 1489:     nWant = mon->contentions(); // # of threads contending for monitor

Please clarity comment as

// # of threads contending for monitor entry, but not -rentry

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1490:

> 1488:     // this object has a heavyweight monitor
> 1489:     nWant = mon->contentions(); // # of threads contending for monitor
> 1490:     nWait = mon->waiters();     // # of threads in Object.wait()

Please clarify the comment as

// # of threads waiting for notification, or to re-enter monitor, in Object.wait()

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1491:

> 1489:     nWant = mon->contentions(); // # of threads contending for monitor
> 1490:     nWait = mon->waiters();     // # of threads in Object.wait()
> 1491:     wantList =  Threads::get_pending_threads(tlh.list(), nWant + nWait, (address)mon);

Please add a comment

// Get the actual set of threads trying to enter, or re-enter, the monitor.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1505:

> 1503:         // the monitor threads after being notified. Here we are correcting the actual
> 1504:         // number of the waiting threads by excluding those re-entering the monitor.
> 1505:         nWait = i;

Sorry I can't follow the logic here. Why is the whole block not simply:

if (mon != nullptry) {
  // The nWait count may include threads trying to re-enter the monitor, so
  // walk the actual set of waiters to count those actually waiting.
  int count = 0;
  for (ObjectMonitor * waiter = mon->first_waiter(); waiter != nullptr; waiter = mon->next_waiter(waiter)) {
    count++;
  }
}
ret.notify_waiter_count = count;

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1552:

> 1550:         // If the thread was found on the ObjectWaiter list, then
> 1551:         // it has not been notified. This thread can't change the
> 1552:         // state of the monitor so it doesn't need to be suspended.

Not sure why suspension is being mentioned here.

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 31:

> 29:  * DESCRIPTION
> 30:  *     The test checks if the JVMTI function GetObjectMonitorUsage returns
> 31:  *     the expected values for the owner, entry_count, water_count

s/water_count/waiter_count/

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 40:

> 38:  *       - owned object with N waitings to be notified
> 39:  *       - owned object with N waitings to enter, from 0 to N waitings to re-enter,
> 40:  *         from N to 0 waitings to be notified

"waitings" is not grammatically valid. Suggestion: s/waitings/threads waiting/

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 42:

> 40:  *         from N to 0 waitings to be notified
> 41:  *       - all the above scenarios are executed with platform and virtual threads
> 42:  * @requires vm.continuations

Do we really require this?

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 132:

> 130:         // count of threads waiting to re-enter:    0
> 131:         // count of threads waiting to be notified: NUMBER_OF_WAITING_THREADS
> 132:         check(lockCheck, null, 0, // no owner thread

AFAICS you are racing here, as the waiting threads can set `ready` but not yet have called `wait()`. To know for sure they are in `wait()` you need to acquire the monitor before checking (and release it again so that you test the no-owner scenario as intended). But this should probably be done inside `startWaitingThreads`.

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 319:

> 317:                 try {
> 318:                     ready = true;
> 319:                     lockCheck.wait();

Spurious wakeups will break this test. They shouldn't happen but ...

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 65:

> 63: 
> 64: 
> 65: jint  Agent_Initialize(JavaVM *jvm, char *options, void *reserved) {

Nit: there's a double space after jint

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 219:

> 217: }
> 218: 
> 219: } // exnern "C"

typo: exnern -> extern

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

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1913304471
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510543479
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510540981
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510544636
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510548391
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510549323
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510550756
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510551339
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510551516
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510556424
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510553511
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510557225
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510557802

From dholmes at openjdk.org  Mon Mar  4 04:11:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Mar 2024 04:11:51 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>
Message-ID: <k59gvIaIwWwk9OKiW3zXlHGnL6aEh5vV-8toM3HoHfY=.94ea08d5-a331-47bd-8029-346cfa899c6a@github.com>

On Sat, 2 Mar 2024 07:58:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> src/hotspot/share/runtime/javaThread.cpp line 594:
> 
>> 592:       // thread_oop is virtual, clear carrier thread interrupt status as well
>> 593:       java_lang_Thread::set_interrupted(threadObj(), false);
>> 594:     }
> 
> This isn't right for the case that Thread::interrupt it called around the same time.  The interrupt status on both the virtual thread and the carrier need to be kept in sync so the changes here need to work like an up call to VirtualThread.getAndClearInterrupt and use the interrupt lock.

On that note, note that the entire comment block preceding this needs to be updated for virtual threads. And it is far from clear to me how to correctly manage the interrupt state of virtual threads within the VM, when it requires locking and coordination across two threads! Performing a Java upcall to manage this could be very problematic from within ObjectMonitor::wait. I think at the moment pinning resolves this because the carrier thread interrupt status is a proxy for the virtual thread's status, when it is waiting. Once we remove pinning however this gets even more complex. Though without pinning things should also simplify greatly because we should not need to distinguish between the virtual thread and the carrier thread ... but perhaps I'm getting ahead of myself here. But I would hate for us to come up with a solution here and now that has to jump through hoops to make things work, if in the not-do-distant future, removal of pinning make this much simpler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1510567016

From jwaters at openjdk.org  Mon Mar  4 06:44:56 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Mar 2024 06:44:56 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

I'd find it quite sad if we stopped supporting ccache just because it broke after this commit, I know for a fact that quite a few JDK developers do use it (myself included). Regarding the issue itself, I wonder if it's the SetupToolchain changes that has caused this. ccache is collapsed into CC and CXX to my knowledge, which would explain why the ccache cc or ccache c++ command is missing from the command line (substitute cc and c++ for the respective compiler drivers)

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1975838054

From dholmes at openjdk.org  Mon Mar  4 07:13:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Mar 2024 07:13:55 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v4]
In-Reply-To: <FUW7Auwbo5fmBuS6k61jgn9gUBGf7oFZdm_NKq2VYR0=.26b02b4b-3868-4fab-9679-b3de35637d5a@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <FUW7Auwbo5fmBuS6k61jgn9gUBGf7oFZdm_NKq2VYR0=.26b02b4b-3868-4fab-9679-b3de35637d5a@github.com>
Message-ID: <PJNmW1TYGDAzikzsJ5hkR-IKfhOKoKMV36A3oZlB5A4=.d3970c40-c001-4af6-90c7-e67f3d0dd61b@github.com>

On Fri, 1 Mar 2024 11:19:21 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
>> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
>> 
>> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
>> 
>> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> 
>> Testing:
>>  - tested with the mach5 tiers 1-6
>
> 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 four additional commits since the last revision:
> 
>  - Merge
>  - Merge
>  - fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method
>  - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

The main functional fix seems fine.

The JDWP and JDI spec changes seem fine - just a minor nit on wording.

I don't know enough about how the tests work to comment on those.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 941:

> 939:     bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
> 940:     jint state = is_virtual ? JvmtiEnvBase::get_vthread_state(thread_oop, java_thread)
> 941:                             : JvmtiEnvBase::get_thread_state(thread_oop, java_thread);

I've seen this in a couple of your PRs now. It would be nice to have a utility function to get the JVMTI thread state of any java.lang.Thread instance.

src/java.se/share/data/jdwp/jdwp.spec line 1985:

> 1983:         "thread may be waiting to enter the object's monitor, or in "
> 1984:         "java.lang.Object.wait waiting to re-enter the monitor after being "
> 1985:         "notified, interrupted, or timeout."

`timed-out` would be the correct sense here.

src/jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java line 314:

> 312:      * synchronized method, the synchronized statement, or
> 313:      * {@link Object#wait} waiting to re-enter the monitor
> 314:      * after being notified, interrupted, or timeout.

Again `timed-out`.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17944#pullrequestreview-1913493587
PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1510673055
PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1510665704
PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1510666362

From sspitsyn at openjdk.org  Mon Mar  4 09:48:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Mar 2024 09:48:53 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <k59gvIaIwWwk9OKiW3zXlHGnL6aEh5vV-8toM3HoHfY=.94ea08d5-a331-47bd-8029-346cfa899c6a@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>
 <k59gvIaIwWwk9OKiW3zXlHGnL6aEh5vV-8toM3HoHfY=.94ea08d5-a331-47bd-8029-346cfa899c6a@github.com>
Message-ID: <dQY31ZGVZM-qqb6PNCfshQ9yEckO6UlfAWa4dVvuM-k=.5b52964c-58df-4ae2-88e0-48cb83605707@github.com>

On Mon, 4 Mar 2024 04:09:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 594:
>> 
>>> 592:       // thread_oop is virtual, clear carrier thread interrupt status as well
>>> 593:       java_lang_Thread::set_interrupted(threadObj(), false);
>>> 594:     }
>> 
>> This isn't right for the case that Thread::interrupt it called around the same time.  The interrupt status on both the virtual thread and the carrier need to be kept in sync so the changes here need to work like an up call to VirtualThread.getAndClearInterrupt and use the interrupt lock.
>
> On that note, note that the entire comment block preceding this needs to be updated for virtual threads. And it is far from clear to me how to correctly manage the interrupt state of virtual threads within the VM, when it requires locking and coordination across two threads! Performing a Java upcall to manage this could be very problematic from within ObjectMonitor::wait. I think at the moment pinning resolves this because the carrier thread interrupt status is a proxy for the virtual thread's status, when it is waiting. Once we remove pinning however this gets even more complex. Though without pinning things should also simplify greatly because we should not need to distinguish between the virtual thread and the carrier thread ... but perhaps I'm getting ahead of myself here. But I would hate for us to come up with a solution here and now that has to jump through hoops to make things work, if in the not-do-distant future, removal of pinning make this much simpler.

Alan and David, thank you for the comments!
The initial implementation of the `is_iterrupt()` intentionally avoided any synchronization and allowed a potential raises with the concurrent interrupts. Please, see the comment above at lines: `573-587`. It is why David mentioned the need to update the comment. I agree with Alan that that interrupt status of virtual and carrier threads have to be kept in sync. But as we already discussed with Alan before, an upcall to Java does not looks good and can cause some issues on the JDWP side. I'm thinking to model a CAS kind of operation to keep the two interrupt statuses in sync but still need to prove it is going to be safe. Also, there is a question if it worth the complexity.
The need to keep interrupt status in both virtual and carrier threads comes from virtual thread pinning. I believe, there would be no need to keep interrupt status for both threads in the Java object monitors inplementations. AFAICS, then the implementation of the `is_interrupted()` can be kept as it is now. 
So, it looks like a good suggestion to wait for Java object monitors. However, the JDWP related fix depends on this and will need to wait as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1510882826

From sspitsyn at openjdk.org  Mon Mar  4 09:53:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Mar 2024 09:53:55 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v4]
In-Reply-To: <PJNmW1TYGDAzikzsJ5hkR-IKfhOKoKMV36A3oZlB5A4=.d3970c40-c001-4af6-90c7-e67f3d0dd61b@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <FUW7Auwbo5fmBuS6k61jgn9gUBGf7oFZdm_NKq2VYR0=.26b02b4b-3868-4fab-9679-b3de35637d5a@github.com>
 <PJNmW1TYGDAzikzsJ5hkR-IKfhOKoKMV36A3oZlB5A4=.d3970c40-c001-4af6-90c7-e67f3d0dd61b@github.com>
Message-ID: <ufLwZUemf7jV4cj5F-VVRz8Ny7uE3sHiiriGLczBw9U=.c8193f2b-179f-4904-8b0c-ab5568865f97@github.com>

On Mon, 4 Mar 2024 07:06:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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 four additional commits since the last revision:
>> 
>>  - Merge
>>  - Merge
>>  - fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method
>>  - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 941:
> 
>> 939:     bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
>> 940:     jint state = is_virtual ? JvmtiEnvBase::get_vthread_state(thread_oop, java_thread)
>> 941:                             : JvmtiEnvBase::get_thread_state(thread_oop, java_thread);
> 
> I've seen this in a couple of your PRs now. It would be nice to have a utility function to get the JVMTI thread state of any java.lang.Thread instance.

Good suggestion, thanks. Will add.

> src/java.se/share/data/jdwp/jdwp.spec line 1985:
> 
>> 1983:         "thread may be waiting to enter the object's monitor, or in "
>> 1984:         "java.lang.Object.wait waiting to re-enter the monitor after being "
>> 1985:         "notified, interrupted, or timeout."
> 
> `timed-out` would be the correct sense here.

Thank you, David. I was thinking about it but was not sure. Will update it.

> src/jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java line 314:
> 
>> 312:      * synchronized method, the synchronized statement, or
>> 313:      * {@link Object#wait} waiting to re-enter the monitor
>> 314:      * after being notified, interrupted, or timeout.
> 
> Again `timed-out`.

Will fix, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1510890499
PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1510887118
PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1510887956

From sspitsyn at openjdk.org  Mon Mar  4 09:58:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Mar 2024 09:58:56 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
Message-ID: <PqkqPiqWQktdlR9CwE3302zCe1610nj-ZLLtx4NDhEk=.1b3810ca-e6f1-4cbe-a65e-72d082bf11d6@github.com>

On Mon, 4 Mar 2024 03:07:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename after merge: jvmti_common.h to jvmti_common.hpp
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1489:
> 
>> 1487:     assert(mon != nullptr, "must have monitor");
>> 1488:     // this object has a heavyweight monitor
>> 1489:     nWant = mon->contentions(); // # of threads contending for monitor
> 
> Please clarify comment as
> 
> // # of threads contending for monitor entry, but not re-entry
> 
> (Fixed typos - sorry)

Will fix, thanks.

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1490:
> 
>> 1488:     // this object has a heavyweight monitor
>> 1489:     nWant = mon->contentions(); // # of threads contending for monitor
>> 1490:     nWait = mon->waiters();     // # of threads in Object.wait()
> 
> Please clarify the comment as
> 
> // # of threads waiting for notification, or to re-enter monitor, in Object.wait()

Good catch, thanks. Will fix.

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1491:
> 
>> 1489:     nWant = mon->contentions(); // # of threads contending for monitor
>> 1490:     nWait = mon->waiters();     // # of threads in Object.wait()
>> 1491:     wantList =  Threads::get_pending_threads(tlh.list(), nWant + nWait, (address)mon);
> 
> Please add a comment
> 
> // Get the actual set of threads trying to enter, or re-enter, the monitor.

Will add, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510895824
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510894066
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510896692

From sspitsyn at openjdk.org  Mon Mar  4 10:05:47 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Mar 2024 10:05:47 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
Message-ID: <gre_IkSRIfG-bCKaolsGGhR_gOaKwYvWt6cf3_nCnkU=.c3599a60-e112-4e29-a928-cb7390b6c6ce@github.com>

On Mon, 4 Mar 2024 03:20:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename after merge: jvmti_common.h to jvmti_common.hpp
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1505:
> 
>> 1503:         // the monitor threads after being notified. Here we are correcting the actual
>> 1504:         // number of the waiting threads by excluding those re-entering the monitor.
>> 1505:         nWait = i;
> 
> Sorry I can't follow the logic here. Why is the whole block not simply:
> 
> if (mon != nullptry) {
>   // The nWait count may include threads trying to re-enter the monitor, so
>   // walk the actual set of waiters to count those actually waiting.
>   int count = 0;
>   for (ObjectMonitor * waiter = mon->first_waiter(); waiter != nullptr; waiter = mon->next_waiter(waiter)) {
>     count++;
>   }
> }
> ret.notify_waiter_count = count;

Thank you for the suggestion. Let me check this.

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1552:
> 
>> 1550:         // If the thread was found on the ObjectWaiter list, then
>> 1551:         // it has not been notified. This thread can't change the
>> 1552:         // state of the monitor so it doesn't need to be suspended.
> 
> Not sure why suspension is being mentioned here.

This is the original comment. I also do not quite understand it. It is confusing for sure. I can remove it if Dan does not object.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510906350
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510904664

From sspitsyn at openjdk.org  Mon Mar  4 10:12:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Mar 2024 10:12:01 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
Message-ID: <nkfadUboYD0Q9HlfzR8aOBo396nm_I4Sc5qUM5DYIzc=.da320e46-26db-46d6-a7b0-19469677ae59@github.com>

On Mon, 4 Mar 2024 03:41:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename after merge: jvmti_common.h to jvmti_common.hpp
>
> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 132:
> 
>> 130:         // count of threads waiting to re-enter:    0
>> 131:         // count of threads waiting to be notified: NUMBER_OF_WAITING_THREADS
>> 132:         check(lockCheck, null, 0, // no owner thread
> 
> AFAICS you are racing here, as the waiting threads can set `ready` but not yet have called `wait()`. To know for sure they are in `wait()` you need to acquire the monitor before checking (and release it again so that you test the no-owner scenario as intended). But this should probably be done inside `startWaitingThreads`.

Thank you for the comment. Will implement similar approach as in the `startEnteringThreads()`.

> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 319:
> 
>> 317:                 try {
>> 318:                     ready = true;
>> 319:                     lockCheck.wait();
> 
> Spurious wakeups will break this test. They shouldn't happen but ...

Thanks, will check how this can be fixed.

> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 65:
> 
>> 63: 
>> 64: 
>> 65: jint  Agent_Initialize(JavaVM *jvm, char *options, void *reserved) {
> 
> Nit: there's a double space after jint

Will fix, thanks,

> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 219:
> 
>> 217: }
>> 218: 
>> 219: } // exnern "C"
> 
> typo: exnern -> extern

Will fix, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510912362
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510913702
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510909857
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510909512

From sspitsyn at openjdk.org  Mon Mar  4 10:20:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Mar 2024 10:20:56 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
Message-ID: <VduxB0hfkHBQ7rMj237GUPR6xnRVkq8bZ9ReyNAXpCg=.6e3e2447-1369-4ed3-a820-bfd183158de4@github.com>

On Mon, 4 Mar 2024 03:29:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename after merge: jvmti_common.h to jvmti_common.hpp
>
> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 42:
> 
>> 40:  *         from N to 0 waitings to be notified
>> 41:  *       - all the above scenarios are executed with platform and virtual threads
>> 42:  * @requires vm.continuations
> 
> Do we really require this?

Yes, can be removed. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510925088

From sspitsyn at openjdk.org  Mon Mar  4 10:38:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Mar 2024 10:38:55 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
Message-ID: <V1KveJUjn3xmUbCp3aHeHML83ODN1pb4dOu-uMiXB4A=.b55cec1a-7d0a-4f73-af48-d2e3e7d15400@github.com>

On Mon, 4 Mar 2024 03:26:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename after merge: jvmti_common.h to jvmti_common.hpp
>
> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 31:
> 
>> 29:  * DESCRIPTION
>> 30:  *     The test checks if the JVMTI function GetObjectMonitorUsage returns
>> 31:  *     the expected values for the owner, entry_count, water_count
> 
> s/water_count/waiter_count/

Thanks, fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510947433

From sspitsyn at openjdk.org  Mon Mar  4 11:01:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Mar 2024 11:01:46 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
Message-ID: <M6yVG-5ymo5PBh7M6lGYYNqxf5FnO-TPdOp7SeE9bYU=.f9be9f5d-8c87-421a-ad30-4dda90a35632@github.com>

On Mon, 4 Mar 2024 03:28:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename after merge: jvmti_common.h to jvmti_common.hpp
>
> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 40:
> 
>> 38:  *       - owned object with N waitings to be notified
>> 39:  *       - owned object with N waitings to enter, from 0 to N waitings to re-enter,
>> 40:  *         from N to 0 waitings to be notified
> 
> "waitings" is not grammatically valid. Suggestion: s/waitings/threads waiting/

Thanks, fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1510976777

From ihse at openjdk.org  Mon Mar  4 11:30:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Mar 2024 11:30:55 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
Message-ID: <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>

On Mon, 4 Mar 2024 06:42:30 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I wonder if it's the SetupToolchain changes that has caused this. ccache is collapsed into CC and CXX to my knowledge

Yeah, it must have been. Would you like to take a look at it? Otherwise I'll file a bug and fix it. Breaking ccache was an unintended regression, so it needs to be fixed. If we want to drop ccache support it needs to be done explicitly and separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976368808

From jwaters at openjdk.org  Mon Mar  4 11:48:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Mar 2024 11:48:55 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
 <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>
Message-ID: <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>

On Mon, 4 Mar 2024 11:28:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > I wonder if it's the SetupToolchain changes that has caused this. ccache is collapsed into CC and CXX to my knowledge
> 
> Yeah, it must have been. Would you like to take a look at it? Otherwise I'll file a bug and fix it. Breaking ccache was an unintended regression, so it needs to be fixed. If we want to drop ccache support it needs to be done explicitly and separately.

No problem! I do hope that dropping ccache support isn't something that's planned though :(

> Additionally some environment variables are missing/different.

Could I trouble you to mention what exactly was different?

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976398726

From alanb at openjdk.org  Mon Mar  4 11:53:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Mar 2024 11:53:52 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <dQY31ZGVZM-qqb6PNCfshQ9yEckO6UlfAWa4dVvuM-k=.5b52964c-58df-4ae2-88e0-48cb83605707@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>
 <k59gvIaIwWwk9OKiW3zXlHGnL6aEh5vV-8toM3HoHfY=.94ea08d5-a331-47bd-8029-346cfa899c6a@github.com>
 <dQY31ZGVZM-qqb6PNCfshQ9yEckO6UlfAWa4dVvuM-k=.5b52964c-58df-4ae2-88e0-48cb83605707@github.com>
Message-ID: <MpsiIacZsxFNcEoTdWLccaSyCxn1KDQG_5D9SaHseVY=.67808e96-e85f-4eac-a9ca-f59a9d441ba5@github.com>

On Mon, 4 Mar 2024 09:45:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> On that note, note that the entire comment block preceding this needs to be updated for virtual threads. And it is far from clear to me how to correctly manage the interrupt state of virtual threads within the VM, when it requires locking and coordination across two threads! Performing a Java upcall to manage this could be very problematic from within ObjectMonitor::wait. I think at the moment pinning resolves this because the carrier thread interrupt status is a proxy for the virtual thread's status, when it is waiting. Once we remove pinning however this gets even more complex. Though without pinning things should also simplify greatly because we should not need to distinguish between the virtual thread and the carrier thread ... but perhaps I'm getting ahead of myself here. But I would hate for us to come up with a solution here and now that has to jump through hoops to make things work, if in the not-do-distant future, removal of pinning make this much simpler.
>
> Alan and David, thank you for the comments!
> The initial implementation of the `is_iterrupt()` intentionally avoided any synchronization and allowed a potential raises with the concurrent interrupts. Please, see the comment above at lines: `573-587`. It is why David mentioned the need to update the comment. I agree with Alan that that interrupt status of virtual and carrier threads have to be kept in sync. But as we already discussed with Alan before, an upcall to Java does not looks good and can cause some issues on the JDWP side. I'm thinking to model a CAS kind of operation to keep the two interrupt statuses in sync but still need to prove it is going to be safe. Also, there is a question if it worth the complexity.
> The need to keep interrupt status in both virtual and carrier threads comes from virtual thread pinning. I believe, there would be no need to keep interrupt status for both threads in the Java object monitors inplementations. AFAICS, then the implementation of the `is_interrupted()` can be kept as it is now. 
> So, it looks like a good suggestion to wait for Java object monitors. However, the JDWP related fix depends on this and will need to wait as well.

David can correct me, but I think the only cases in the VM where a thread may clear its interrupt status is Thread.interrupted, Thread.sleep, Object.wait, and JVMTI RawMonitorWait.  Thread.interrupted and Thread.sleep are different implementation and not interesting here. Right now, Object.wait does wait on the carrier. If the virtual thread is interrupted while in the monitor's wait set then InterruptedException will be thrown when the thread reenters and the interrupt status of both threads will be cleared at that point (it will have of course have been cleared by the VM too prior to throwing). If something sneaky were to go behind our backs and interrupt the carrier directly then it will be benign for this case but might cause a spurious InterruptedException at other times, say where the mounted  virtual thread were to call Object.wait soon after its carrier was interrupted directly. We've mostly ignored that concern.

For JVMTI RawMonitorWait then it has to coordinate with Thread.interrupt and JVMTI InterruptThread. The latter does do an upcall when the target is a virtual thread so it's the same as Thread.interrupt. So minimally RawMonitorWait will need to disable suspend and and clear the interrupt status of both threads while holding the interrupt lock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1511036065

From simeon.danailov.andreev at gmail.com  Mon Mar  4 12:11:10 2024
From: simeon.danailov.andreev at gmail.com (S A)
Date: Mon, 4 Mar 2024 14:11:10 +0200
Subject: Class loader leaked when ForkJoinPool is used in loaded class, with
 Java 19+
Message-ID: <CACcnpz0cBPegOYFVmAQ0k_Y2XL5Gk=5s1nTi0+6e9KbvPPLFEQ@mail.gmail.com>

Hi all,

after moving our application to Java 21 (up from Java 17), we noticed a
class loader leak. A memory snapshot points to a ProtectionDomain object
held by a ForkJoinWorkerThread, the protection domain holds the class
loader and prevents GC.

To reproduce outside of our application, we use this snippet:

import java.lang.ref.WeakReference;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
import java.nio.file.Paths;
public class TestClassloaderLeak {
    public static void main(String[] args) throws Exception {
        WeakReference<Object> wr = load();
        gc();
        System.out.println("wr=" + wr.get());
    }
    private static void gc() {
        System.gc();
        System.runFinalization();
    }
    private static WeakReference<Object> load() throws Exception {
        URLClassLoader cl = new URLClassLoader(new URL[] { url() },
TestClassloaderLeak.class.getClassLoader());
        WeakReference<Object> wr = new WeakReference<>(cl);
        Class<?> ca = cl.loadClass("A");
        ca.getConstructor(String.class).newInstance("A");
        cl.close();
        return wr;
    }
    private static URL url() throws MalformedURLException {
        return Paths.get("/data/tmp/testleak/lib/").toUri().toURL();
    }
}

import java.util.concurrent.ForkJoinPool;
import java.util.concurrent.ForkJoinTask;
public class A {
    public final String s;
    public A(String s) {
        this.s = s;
        ForkJoinTask<?> task = ForkJoinPool.commonPool().submit(() -> {
System.out.println("A constructor"); });
        try {
            task.get();
        } catch (Exception e) {
            e.printStackTrace(System.out);
        }
    }
}

Place the compiled A.class at the hard-coded location
"/data/tmp/testleak/lib/", then run the main method with JVM flags
"-Xlog:class+unload". Observe that no class is unloaded, which is not the
case if the main() code runs twice, or if the snippet is executed e.g. with
Java 17.

It seems each time ForkJoinPool creates a new ForkJoinWorkerThread from a
loaded class, it is no longer possible to GC the class loader of the class
using ForkJoinPool.

The leak occurs after this commit, with Java 19+:

https://github.com/openjdk/jdk19u/commit/00e6c63cd12e3f92d0c1d007aab4f74915616ffb

What possible workarounds can we use to avoid this problem? Essentially,
our application loads and runs user code. The user changes their code, runs
their code again - we use a new class loader to run the changed code in the
same JVM. We unload the previous class loader, to free up memory and to
avoid problems with hot swapping code (an old version of a loaded class can
cause an error when trying to hot swap the latest loaded version of that
class). So the leaked class loader is giving us trouble.

Best regards and thanks,
Simeon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240304/8098399d/attachment-0001.htm>

From Alan.Bateman at oracle.com  Mon Mar  4 12:15:38 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 4 Mar 2024 12:15:38 +0000
Subject: Class loader leaked when ForkJoinPool is used in loaded class,
 with Java 19+
In-Reply-To: <CACcnpz0cBPegOYFVmAQ0k_Y2XL5Gk=5s1nTi0+6e9KbvPPLFEQ@mail.gmail.com>
References: <CACcnpz0cBPegOYFVmAQ0k_Y2XL5Gk=5s1nTi0+6e9KbvPPLFEQ@mail.gmail.com>
Message-ID: <6e27d7d5-37e5-4881-ba2d-abe2dae470e5@oracle.com>

core-libs-dev is the place to send this.

-Alan

On 04/03/2024 12:11, S A wrote:
> Hi all,
>
> after moving our application to Java 21 (up from Java 17), we noticed 
> a class loader leak. A memory snapshot points to a ProtectionDomain 
> object held by a ForkJoinWorkerThread, the protection domain holds the 
> class loader and prevents GC.
>
> To reproduce outside of our application, we use this snippet:
>
> import java.lang.ref.WeakReference;
> import java.net.MalformedURLException;
> import java.net.URL;
> import java.net.URLClassLoader;
> import java.nio.file.Paths;
> public class TestClassloaderLeak {
> ? ? public static void main(String[] args) throws Exception {
> ? ? ? ? WeakReference<Object> wr = load();
> ? ? ? ? gc();
> ? ? ? ? System.out.println("wr=" + wr.get());
> ? ? }
> ? ? private static void gc() {
> ? ? ? ? System.gc();
> ? ? ? ? System.runFinalization();
> ? ? }
> ? ? private static WeakReference<Object> load() throws Exception {
> ? ? ? ? URLClassLoader cl = new URLClassLoader(new URL[] { url() }, 
> TestClassloaderLeak.class.getClassLoader());
> ? ? ? ? WeakReference<Object> wr = new WeakReference<>(cl);
> ? ? ? ? Class<?> ca = cl.loadClass("A");
> ? ? ? ? ca.getConstructor(String.class).newInstance("A");
> ? ? ? ? cl.close();
> ? ? ? ? return wr;
> ? ? }
> ? ? private static URL url() throws MalformedURLException {
> ? ? ? ? return Paths.get("/data/tmp/testleak/lib/").toUri().toURL();
> ? ? }
> }
>
> import java.util.concurrent.ForkJoinPool;
> import java.util.concurrent.ForkJoinTask;
> public class A {
> ? ? public final String s;
> ? ? public A(String s) {
> ? ? ? ? this.s = s;
> ? ? ? ? ForkJoinTask<?> task = ForkJoinPool.commonPool().submit(() -> 
> { System.out.println("A constructor"); });
> ? ? ? ? try {
> ? ? ? ? ? ? task.get();
> ? ? ? ? } catch (Exception e) {
> ? ? ? ? ? ? e.printStackTrace(System.out);
> ? ? ? ? }
> ? ? }
> }
>
> Place the compiled A.class at the hard-coded location 
> "/data/tmp/testleak/lib/", then run the main method with JVM flags 
> "-Xlog:class+unload". Observe that no class is unloaded, which is not 
> the case if the main() code runs twice, or if the snippet is executed 
> e.g. with Java 17.
>
> It seems each time ForkJoinPool creates a new ForkJoinWorkerThread 
> from a loaded class, it is no longer possible to GC the class loader 
> of the class using ForkJoinPool.
>
> The leak occurs after this commit, with Java 19+:
>
> https://github.com/openjdk/jdk19u/commit/00e6c63cd12e3f92d0c1d007aab4f74915616ffb
>
> What possible workarounds can we use to avoid this problem? 
> Essentially, our application loads and runs user code. The user 
> changes their code, runs their code again - we use a new class loader 
> to run the changed code in the same JVM. We unload the previous class 
> loader, to free up memory and to avoid problems with hot swapping code 
> (an old version of a loaded class can cause an error when trying to 
> hot swap the latest loaded version of that class). So the leaked class 
> loader is giving us trouble.
>
> Best regards and thanks,
> Simeon


From duke at openjdk.org  Mon Mar  4 13:00:54 2024
From: duke at openjdk.org (Claudio Nieder)
Date: Mon, 4 Mar 2024 13:00:54 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
 <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>
 <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>
Message-ID: <Eux5XyKqCklnUrXp8aGIOqapxVKbIbHoRuXwMbPBYnA=.fc99209e-8e2f-4abf-8bab-eb137b920d61@github.com>

On Mon, 4 Mar 2024 11:45:59 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Could I trouble you to mention what exactly was different?

No trouble at all. 

`CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is where I checked out OpenJDK)

`CCACHE_SLOPPINESS` has the value `pch_defines,time_macros` with the working parent commit but just `pch_defines` with this commit. I.e. `CCACHE_SLOPPINESS=pch_defines,time_macros` vs `CCACHE_SLOPPINESS=pch_defines`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976528283

From jwaters at openjdk.org  Mon Mar  4 13:04:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Mar 2024 13:04:55 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <Eux5XyKqCklnUrXp8aGIOqapxVKbIbHoRuXwMbPBYnA=.fc99209e-8e2f-4abf-8bab-eb137b920d61@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
 <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>
 <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>
 <Eux5XyKqCklnUrXp8aGIOqapxVKbIbHoRuXwMbPBYnA=.fc99209e-8e2f-4abf-8bab-eb137b920d61@github.com>
Message-ID: <d16NqTj0wxfYX4lHoWKGG0hKkCFjeWV7mdXfkwzET2A=.835286f5-6ed1-48c1-972e-6ec3c6baeaac@github.com>

On Mon, 4 Mar 2024 12:58:28 GMT, Claudio Nieder <duke at openjdk.org> wrote:

> > Could I trouble you to mention what exactly was different?
> 
> No trouble at all.
> 
> `CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is where I checked out OpenJDK)
> 
> `CCACHE_SLOPPINESS` has the value `pch_defines,time_macros` with the working parent commit but just `pch_defines` with this commit. I.e. `CCACHE_SLOPPINESS=pch_defines,time_macros` vs `CCACHE_SLOPPINESS=pch_defines`.

Thanks! Seems curious to me, off the top of my head I can't seem to discern why these would change, perhaps it's time for a little investigating

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976534197

From kevinw at openjdk.org  Mon Mar  4 13:24:05 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 4 Mar 2024 13:24:05 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v2]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  RMIConnection comments update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/f236ae82..8635a3a5

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

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

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

From alanb at openjdk.org  Mon Mar  4 13:40:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Mar 2024 13:40:54 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v2]
In-Reply-To: <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>
Message-ID: <JJwyAQmjrcxUN1FL8ZM_WZQ5jZdzkr412aleNBKBojU=.d277359c-c9a0-4e5f-9813-f68dea38239d@github.com>

On Mon, 4 Mar 2024 13:24:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RMIConnection comments update

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 126:

> 124:      * @param className The class name of the MBean to be instantiated.
> 125:      * @param name The object name of the MBean. May be null.
> 126:      * @param delegationSubject No longer supported and should be null.

I think this interface will require all methods that take a delegation subject to specify UOE then the subject is not null. Yes, this will invalidate implementations that are outside of the JDK but such implementations need to be updated anyway.

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 158:

> 156:      */
> 157:     @Deprecated(since="21", forRemoval=true)
> 158:     public default MBeanServerConnection getMBeanServerConnection(Subject delegationSubject)

Specifying the UOE in the param description is problematic. I think you want to specify delegationSubject as not used, must be null, then declare UOE as one of the exceptions thrown by the method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1511174715
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1511172106

From ihse at openjdk.org  Mon Mar  4 15:01:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Mar 2024 15:01:58 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
 <YuUVUWRQk3AJj53zCQDi-7Op2CIa4Ggocr-9Z3UsKOc=.c71d5357-aada-478f-bc5c-7606de078fba@github.com>
 <dnMbFCvYXGSs5Ni7dFUa27Kkni32FmnHBe7BbaHF0do=.3acfc35d-b55d-4673-8ab0-22fc97c1aa18@github.com>
 <Px2zDTrFwz08uSLyS-F-lWBRD6xTqkNL64lGLhWL1VE=.ee8820f4-7210-4c7f-a6f5-d97df426d509@github.com>
Message-ID: <eiywV-5D-ligXgz8loKKDINf1BpFgJl9X7dKMSfAuu0=.4ad1ab6e-2dd8-43d4-bc52-ee0e16cd7fda@github.com>

On Mon, 4 Mar 2024 11:45:59 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>  I do hope that dropping ccache support isn't something that's planned though :(

Not really. The benefit of dropping it is quite small, and there might be use cases where it helps.

But I think we should perhaps be more explicit in the documentation that it is not obvious that it helps performance, and encourage testing before enabling it. And perhaps even print a warning in configure if you enable it that you need to check that it helps.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976777022

From kevinw at openjdk.org  Mon Mar  4 15:10:12 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 4 Mar 2024 15:10:12 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v4]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <FpbTvK7G8jFCQiUdhCdnXypCCXh73V09BsyIEf0UhBw=.79c50158-d85c-4939-97cf-7ed34c16409b@github.com>

> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
> 
> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.

Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:

 - Usage correction
 - Help to clarify this is VM inspection.  Comment to relate source to debug.cpp.
 - jcheck trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/cacbca27..1d1e20e2

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

  Stats: 7 lines in 3 files changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655

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

From kevinw at openjdk.org  Mon Mar  4 15:10:12 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 4 Mar 2024 15:10:12 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v4]
In-Reply-To: <E7NTLIsqGIL6L9-q-pHiKUMBEOz8uSafX1A0oWIwCd4=.6419949f-9d87-4cd2-b61b-efb4abd230fc@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <E7NTLIsqGIL6L9-q-pHiKUMBEOz8uSafX1A0oWIwCd4=.6419949f-9d87-4cd2-b61b-efb4abd230fc@github.com>
Message-ID: <gNxoX2ruQSBGk2LfkoNxAv6s3zp-AI6t3I2sRRWl9iY=.c9a7199c-73af-4fa5-8590-45754ad5fd4a@github.com>

On Tue, 27 Feb 2024 01:30:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Usage correction
>>  - Help to clarify this is VM inspection.  Comment to relate source to debug.cpp.
>>  - jcheck trailing whitespace
>
> src/hotspot/share/services/diagnosticCommand.cpp line 1200:
> 
>> 1198: void VMDebugDCmd::find() {
>> 1199:   if (!_arg1.has_value()) {
>> 1200:     output()->print_cr("missing argument");
> 
> I'm thinking if it would be useful to tell what arguments are expected? This is for all cases where the `"missing argument"` message is returned.

Thanks Serguei, have filled in explicit usage instructions when the commands are missing an argument.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1511313428

From mullan at openjdk.org  Mon Mar  4 15:18:59 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:18:59 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: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>

On Tue, 30 Jan 2024 21:58:28 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 69:

> 67:         }
> 68:         private void setPrincipal() {
> 69:             Subject subject = Subject.current();

Why change this to `Subject.current()` if you are requiring the SM to be allowed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511332276

From dfuchs at openjdk.org  Mon Mar  4 15:29:43 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 4 Mar 2024 15:29:43 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v2]
In-Reply-To: <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>
Message-ID: <LfV7zu4_5MpbJ6Q3X04U7NIucsbNr_DHjnD7qXJReBs=.2fddb025-3945-4158-b17c-eda62770802d@github.com>

On Mon, 4 Mar 2024 13:24:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RMIConnection comments update

In addition to Alan's remarks I believe we need new tests to verify the new behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1976841428

From mullan at openjdk.org  Mon Mar  4 15:30:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:30:46 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: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>

On Tue, 30 Jan 2024 21:58:28 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:

> 307:         final Subject s;
> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
> 309:             s = Subject.current();

We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511351340

From mullan at openjdk.org  Mon Mar  4 15:35:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 15:35:48 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: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <2ScdK8KcKlERkLJo7THfkI6UloVwIfWKn-sWF7ZzJsg=.5634f7e1-a6c2-4b19-9829-2fb1129a65c9@github.com>

On Tue, 30 Jan 2024 21:58:28 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

test/jdk/javax/security/auth/Subject/doAs/NestedActions.java line 283:

> 281:     static void readFile(String filename) {
> 282:         System.out.println("ReadFromFileAction: try to read " + filename);
> 283:         Subject subject = Subject.current();

Couldn't we have just left these calling `Subject.getSubject` for now since these tests run with an SM enabled?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511358336

From kevinw at openjdk.org  Mon Mar  4 16:00:57 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 4 Mar 2024 16:00:57 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v3]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <2yxssx9fcD6B3QJSm4fwZ0wHoyq8aLFUIe-p-HscZMM=.08f5c471-9cd9-4ddb-9f3c-013e5adf95f0@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - Update doc comments for RMIConnection.  Additional throw for delegationSubjects array.
 - JMXConnector.getMBeanServer(ds) doc update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/8635a3a5..c607b69a

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

  Stats: 102 lines in 3 files changed: 53 ins; 1 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Mon Mar  4 16:05:59 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 4 Mar 2024 16:05:59 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v2]
In-Reply-To: <JJwyAQmjrcxUN1FL8ZM_WZQ5jZdzkr412aleNBKBojU=.d277359c-c9a0-4e5f-9813-f68dea38239d@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <YgBXJUiO2r4o85w6t_fezRoCKg_fANHEPgyfd2wuBrE=.727adea7-6975-4c3d-907c-0c592af3b852@github.com>
 <JJwyAQmjrcxUN1FL8ZM_WZQ5jZdzkr412aleNBKBojU=.d277359c-c9a0-4e5f-9813-f68dea38239d@github.com>
Message-ID: <LMrfAnzKlNal1uUricpfcovEpzAeWJJP5VytTs2PPiI=.060060eb-f7df-4f62-918a-11173cdd25b2@github.com>

On Mon, 4 Mar 2024 13:37:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   RMIConnection comments update
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 126:
> 
>> 124:      * @param className The class name of the MBean to be instantiated.
>> 125:      * @param name The object name of the MBean. May be null.
>> 126:      * @param delegationSubject No longer supported and should be null.
> 
> I think this interface will require all methods that take a delegation subject to specify UOE when the subject is not null. Yes, this will invalidate implementations that are outside of the JDK but such implementations need to be updated anyway.

Yes, updated.

> src/java.management/share/classes/javax/management/remote/JMXConnector.java line 158:
> 
>> 156:      */
>> 157:     @Deprecated(since="21", forRemoval=true)
>> 158:     public default MBeanServerConnection getMBeanServerConnection(Subject delegationSubject)
> 
> Specifying the UOE in the param description is problematic. I think you want to specify delegationSubject as not used, must be null, then declare UOE as one of the exceptions thrown by the method.

Thanks,  updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1511402928
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1511401561

From stuefe at openjdk.org  Mon Mar  4 16:14:58 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 4 Mar 2024 16:14:58 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v4]
In-Reply-To: <FpbTvK7G8jFCQiUdhCdnXypCCXh73V09BsyIEf0UhBw=.79c50158-d85c-4939-97cf-7ed34c16409b@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <FpbTvK7G8jFCQiUdhCdnXypCCXh73V09BsyIEf0UhBw=.79c50158-d85c-4939-97cf-7ed34c16409b@github.com>
Message-ID: <2OMHOChdtaw7cWj82Q8-9wK2B_rcWspH33c_lhwlyKM=.0a7881cc-e79d-464f-bbac-04b9ca788945@github.com>

On Mon, 4 Mar 2024 15:10:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>> 
>> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.
>
> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Usage correction
>  - Help to clarify this is VM inspection.  Comment to relate source to debug.cpp.
>  - jcheck trailing whitespace

Of the sub commands given in the CSR:


events        HotSpot JVM Event log
threads       Thread list
find ADDRESS  Describe an address given by the argument
findclass CLASS_PATTERN FLAGS   
findmethod CLASS_PATTERN METHOD_PATTERN FLAGS

1) `events` is redundant (we have VM.events, and events are printed as part of VM.info)
2) `threads` is handled by Thread.info
3) I am still puzzled about `find`. This is to ask a running VM about an arbitrary address. But how do you get such an address? Usually only via debugging. Then I am already attached with a system debugger. Under which circumstances would this be needed? Can you give a usage example?
4) and 5) shared some overlap with VM.classes, VM.class_hierarchy, VM.metaspace and various Compiler.xx commands. 

I am mostly worried about adding such a low-level debug command to jcmd. Especially in such a vague umbrella form. Experiences show that these commands get extended easily, often without CSR. So its an open door for feature creep. 

I mostly worry about unforeseen security consequences, especially if jcmd reach is extended across machine boundaries. Weighted against that, the benefits seem a bit slim to me. Again, real-world use cases would help.

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1976941359

From mullan at openjdk.org  Mon Mar  4 16:22:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 16:22:51 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: <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
Message-ID: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>

On Tue, 30 Jan 2024 21:58:28 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix MBeanServerFileAccessController, more test in SM

src/java.base/share/classes/javax/security/auth/Subject.java line 112:

> 110:  *
> 111:  * <p><b><a id="sm-allowed">These methods behave differently depending on
> 112:  * whether a security manager is allowed or disallowed</a></b>:

Suggest linking "a security manager is allowed or disallowed" to `SecurityManager.html#set-security-manager`.

src/java.base/share/classes/javax/security/auth/Subject.java line 120:

> 118:  * {@code getSubject(AccessControlContext)} method.
> 119: *  <li>If a security manager is not allowed, which means it
> 120:  * {@linkplain System#setSecurityManager is not set and not allowed to be set

I think `SecurityManager.html#set-security-manager` is a better (more informative) link. Also, not sure why it is linked here but not in the "If a security manager is allowed" paragraph. If you link it in the first sentence ("These methods behave differently ...) then you probably only need one link and don't need this link.

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 27:

> 25:  * @test
> 26:  * @bug 8296244
> 27:  * @enablePreview

Can you add a comment as to why `enablePreview` is needed? (Assume it is for `StructuredTaskScope`.)

test/jdk/javax/security/auth/Subject/Compat.java line 34:

> 32: /*
> 33:  * @test
> 34:  * @run main/othervm -Djava.security.manager=allow Compat

Missing `@summary` and `@bug`.

test/jdk/javax/security/auth/Subject/UnsupportedSV.java line 59:

> 57: 
> 58:         // TODO: Still has no way to reject the following code.
> 59:         // Here, AccessController::getContext returns a plan ACC without

typo: s/plan/plain/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511419716
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511424024
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511380094
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511393254
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511366395

From duke at openjdk.org  Mon Mar  4 16:36:57 2024
From: duke at openjdk.org (Claudio Nieder)
Date: Mon, 4 Mar 2024 16:36:57 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <vBRE5ItRzRSFWymd8ajaSQHPOX4Lhc_8LFN-nGfcJ0Q=.81ab56fb-41c6-426d-846e-09fab6258f8b@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

One little side note, I tried now also on a Linux x86 system and saw the same issue, so it is not limited to macOS or aarch64.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1976999445

From dchuyko at openjdk.org  Mon Mar  4 17:36:19 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Mon, 4 Mar 2024 17:36:19 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v28]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <AEmOLo23NPx183Fifc6dP6-rYHNdudfvHTHwX1ncQtw=.547146a9-f52c-43f0-b4cb-9ae3ddd23773@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 46 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
 - 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
 - ... and 36 more: https://git.openjdk.org/jdk/compare/59529a92...a4578277

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

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=27
  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  Mon Mar  4 19:38:52 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 4 Mar 2024 19:38:52 GMT
Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves
 created files in the /tmp dir.
In-Reply-To: <JWe1ya9HTdpRZ8V_xhVkfU_bO48oEXiHCfeUKBdd6uk=.60aafd0b-3fb9-45ff-83bd-80f487e9e266@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
 <hO5-favvDtAGaGoDBZhzhlt8s2abZa4aqgiH9owWzsI=.6cc2c59d-bbfc-40d2-abfb-8718d64528e0@github.com>
 <UXY0mjYQExrFC4PlBATrSiMuwBW4M7OGKvdoUMz8pa4=.e4b2f08d-d9a4-467c-b784-0664bc717a9d@github.com>
 <O_9ZU4s62TAxdQx9AdHaYN9HkB4ssl6zTn-LI_3Ywrg=.a925e516-7aae-4fdf-8055-010fdb4945d8@github.com>
 <N0cnbFgnDU4zra3HUZsOA16drgF5zK-fEKOeOdyxrZs=.69971fe4-9848-4889-9c43-2aa73b576e73@github.com>
 <JWe1ya9HTdpRZ8V_xhVkfU_bO48oEXiHCfeUKBdd6uk=.60aafd0b-3fb9-45ff-83bd-80f487e9e266@github.com>
Message-ID: <HD8mpLU8MkIrFi8TgPYBggPLC2vjCxrvobzuaOzCDME=.1db5364f-94de-4141-8b01-d5edd2ddccb4@github.com>

On Sat, 2 Mar 2024 06:21:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The one issue with the first variant is that when run() throws an exception, it will be printed twice, assuming deleteIfExists() does not throw an exception. Basically you either get the exception printed twice, or you get the exception printed once plus whatever exception deleteIfExists() throws also printed (which is ok).
>> 
>> I think your 2nd example will work, but it's kind of confusing because if you got into the finally block via an exception, you then might throw another exception, which is handled in the finally block, and then (implicitly) the original exception is rethrown as you exit the finally block. However, if there was no exception from run() but deleteIfExists() throws an exception, the exception is printed, but does not cause the test to fail. I don't think we want that.
>
> Hello Chris, I haven't followed this PR and this is just a drive by comment about the exception handling discussion. In some other areas of our JDK tests, for situations like this, we do the following:
> 
> 
> Throwable failure = null;
> try {
>     run(new JMXExecutor(), "Compiler.perfmap " + path.toString(), path);
> } catch (Throwable t) {
>     failure = t;
> } finally {
>     try {
>         Files.deleteIfExists(path);
>     } catch (IOException ioe) {
>         if (failure != null) {
>             // add the IOException as a suppressed exception to the original failure
>             // and rethrow the original
>             failure.addSuppressed(ioe);
>             throw failure;
>         }
>         // no failures in the run(), but deleting the file failed, rethrow this IOException
>         throw ioe;
>     }
> }
> 
> This way both the original test failure (if any) as well as the failure in the finally block (if any) are propagated and made available in the failure report.

Hi Jai. I think that solves all the functional requirements, but now we've turned two easily understood lines of code (calling run() and deleteIfExists()) into what you have above. I'm not so sure it is worth it. I refer back to Leonid's comment above on this topic:

> I thought about execution of Files.deleteIfExists(path) in the case of test fails, but decided that it is not so important. Also, test always might fail with crash when no finally block is executed. So I am fine with current way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17992#discussion_r1511697784

From weijun at openjdk.org  Mon Mar  4 19:54:45 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 19:54:45 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: <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
Message-ID: <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>

On Mon, 4 Mar 2024 15:28:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:
> 
>> 307:         final Subject s;
>> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>> 309:             s = Subject.current();
> 
> We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.

I was not exactly sure if we will support this functionality. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511716084

From mullan at openjdk.org  Mon Mar  4 19:59:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Mar 2024 19:59:46 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: <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
Message-ID: <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>

On Mon, 4 Mar 2024 19:51:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java line 309:
>> 
>>> 307:         final Subject s;
>>> 308:         if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) {
>>> 309:             s = Subject.current();
>> 
>> We may not want to call `Subject.current()` here, as this may imply that we will support this functionality even if an SM is not enabled.
>
> I was not exactly sure if we will support this functionality. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.

I think we need @kevinjwalls or @dfuch to help advise on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511721920

From weijun at openjdk.org  Mon Mar  4 20:33:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:33:54 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: <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <Qk9Fs0YGj8mJ0sQgZy7ZSyTzUYolOaNUtczWc6rPcEA=.f7b62d65-2393-404d-bb42-73bb254585be@github.com>
Message-ID: <e65Omm5EaxnZ_Q4ymvpwK0kafK6AWDhLAJDUqPzhEvc=.a8badc5d-0ce1-4302-94bc-f03e9920326d@github.com>

On Mon, 4 Mar 2024 15:15:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 69:
> 
>> 67:         }
>> 68:         private void setPrincipal() {
>> 69:             Subject subject = Subject.current();
> 
> Why change this to `Subject.current()` if you are requiring the SM to be allowed?

When SM is allowed, `Subject.current()` is equivalent to `Subject.getSubject(AccessController.getContext())`. I can revert the change.

> test/jdk/javax/security/auth/Subject/UnsupportedSV.java line 59:
> 
>> 57: 
>> 58:         // TODO: Still has no way to reject the following code.
>> 59:         // Here, AccessController::getContext returns a plan ACC without
> 
> typo: s/plan/plain/

Yes.

> test/jdk/javax/security/auth/Subject/doAs/NestedActions.java line 283:
> 
>> 281:     static void readFile(String filename) {
>> 282:         System.out.println("ReadFromFileAction: try to read " + filename);
>> 283:         Subject subject = Subject.current();
> 
> Couldn't we have just left these calling `Subject.getSubject` for now since these tests run with an SM enabled?

Yes, we can.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511755373
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511756265
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511755860

From weijun at openjdk.org  Mon Mar  4 20:39:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:39:54 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: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
Message-ID: <AWOnbHXGoCGZKp0Ecva-eQU-Yf9hn6mdPmp1qVThatU=.dfb9494c-31fb-410b-bab5-d27e314144eb@github.com>

On Mon, 4 Mar 2024 15:47:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8296244
>> 27:  * @enablePreview
> 
> Can you add a comment as to why `enablePreview` is needed? (Assume it is for `StructuredTaskScope`.)

OK.

> test/jdk/javax/security/auth/Subject/Compat.java line 34:
> 
>> 32: /*
>> 33:  * @test
>> 34:  * @run main/othervm -Djava.security.manager=allow Compat
> 
> Missing `@summary` and `@bug`.

Will Add.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511760021
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511761591

From weijun at openjdk.org  Mon Mar  4 20:49:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 20:49:54 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: <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <jMiCya3Z8SYt75sAOWhzxk-zsFXC4rsxiJ06yDEbuP0=.eaf21d2d-a4e5-48d8-bd14-b4c914c627df@github.com>
Message-ID: <xQbhbPkhHusDyyQ8zlwv0Xr3CZvYyP5aKVWOR4llj4s=.9bcccc3f-b7c7-4b59-b7b9-b8bd2427af9e@github.com>

On Mon, 4 Mar 2024 16:17:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix MBeanServerFileAccessController, more test in SM
>
> src/java.base/share/classes/javax/security/auth/Subject.java line 120:
> 
>> 118:  * {@code getSubject(AccessControlContext)} method.
>> 119: *  <li>If a security manager is not allowed, which means it
>> 120:  * {@linkplain System#setSecurityManager is not set and not allowed to be set
> 
> I think `SecurityManager.html#set-security-manager` is a better (more informative) link. Also, not sure why it is linked here but not in the "If a security manager is allowed" paragraph. If you link it in the first sentence ("These methods behave differently ...) then you probably only need one link and don't need this link.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1511771517

From weijun at openjdk.org  Mon Mar  4 21:54:13 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Mar 2024 21:54:13 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v4]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <9_c9PpQBHzo6FdR5aaSQ_qCCwrd2yGr1CNsGdj6HDjk=.84620353-2d09-4599-8a05-b3b2f08ab855@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:

  revert some test changes, spec change for subject

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/8f270d09..e57f7250

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

  Stats: 44 lines in 6 files changed: 18 ins; 3 del; 23 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 cjplummer at openjdk.org  Mon Mar  4 21:59:51 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 4 Mar 2024 21:59:51 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <MpsiIacZsxFNcEoTdWLccaSyCxn1KDQG_5D9SaHseVY=.67808e96-e85f-4eac-a9ca-f59a9d441ba5@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>
 <k59gvIaIwWwk9OKiW3zXlHGnL6aEh5vV-8toM3HoHfY=.94ea08d5-a331-47bd-8029-346cfa899c6a@github.com>
 <dQY31ZGVZM-qqb6PNCfshQ9yEckO6UlfAWa4dVvuM-k=.5b52964c-58df-4ae2-88e0-48cb83605707@github.com>
 <MpsiIacZsxFNcEoTdWLccaSyCxn1KDQG_5D9SaHseVY=.67808e96-e85f-4eac-a9ca-f59a9d441ba5@github.com>
Message-ID: <Arag9v5qmsXlDZzyMo2v1BN3k35CqrBdSgj7VZYjGzk=.ecdc3938-0722-4577-a845-1e401e654df9@github.com>

On Mon, 4 Mar 2024 11:51:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alan and David, thank you for the comments!
>> The initial implementation of the `is_iterrupt()` intentionally avoided any synchronization and allowed a potential raises with the concurrent interrupts. Please, see the comment above at lines: `573-587`. It is why David mentioned the need to update the comment. I agree with Alan that that interrupt status of virtual and carrier threads have to be kept in sync. But as we already discussed with Alan before, an upcall to Java does not looks good and can cause some issues on the JDWP side. I'm thinking to model a CAS kind of operation to keep the two interrupt statuses in sync but still need to prove it is going to be safe. Also, there is a question if it worth the complexity.
>> The need to keep interrupt status in both virtual and carrier threads comes from virtual thread pinning. I believe, there would be no need to keep interrupt status for both threads in the Java object monitors inplementations. AFAICS, then the implementation of the `is_interrupted()` can be kept as it is now. 
>> So, it looks like a good suggestion to wait for Java object monitors. However, the JDWP related fix depends on this and will need to wait as well.
>
> David can correct me, but I think the only cases in the VM where a thread may clear its interrupt status is Thread.interrupted, Thread.sleep, Object.wait, and JVMTI RawMonitorWait.  Thread.interrupted and Thread.sleep are different implementation and not interesting here. Right now, Object.wait does wait on the carrier. If the virtual thread is interrupted while in the monitor's wait set then InterruptedException will be thrown when the thread reenters and the interrupt status of both threads will be cleared at that point (it will have of course have been cleared by the VM too prior to throwing). If something sneaky were to go behind our backs and interrupt the carrier directly then it will be benign for this case but might cause a spurious InterruptedException at other times, say where the mounted  virtual thread were to call Object.wait soon after its carrier was interrupted directly. We've mostly ignored that concern.
> 
> For JVMTI RawMonitorWait then it has to coordinate with Thread.interrupt and JVMTI InterruptThread. The latter does do an upcall when the target is a virtual thread so it's the same as Thread.interrupt. So minimally RawMonitorWait will need to disable suspend and and clear the interrupt status of both threads while holding the interrupt lock.

>  So, it looks like a good suggestion to wait for Java object monitors. However, the JDWP related fix depends on this and will need to wait as well.

I tried my debug agent fixes without any fix in place for this problem and I'm not seeing any failures. I think it is because as I stated in the CR for this PR:

> However, a subsequent call to GetThreadState returns with the JVMTI_THREAD_STATE_INTERRUPTED bit set. Even so, the JVM does in fact properly consider the thread not to be interrupted. A 2nd call to RawMonitorWait does properly wait rather than immediately return with JVMTI_ERROR_INTERRUPT.

So when the debug agent gets interrupted during the RawMonitorWait and then re-enters RawMonitorWait, there is no issue. However, I also noted in the CR:

>  And one more thing to add is that at the java level calling Thread.isInterrupted() does return true for the virtual thread even though it should not. 

My test does check Thread.isInterrupted(), so there is the potential for it to get the wrong answer. However, this is done in the InterruptedException catch clause, and the java level interrupted flag is being cleared when the exception is raised, thus no problem here either.

So it turns out the only reason I found this issue is because I was seeing many different issues with the debug agent's interrupt handling, and noted this JVMTI issue while trying to debug the debug agent issues. But it turns out it probably was never causing problems for the debug agent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1511849420

From kevinw at openjdk.org  Mon Mar  4 22:05:44 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 4 Mar 2024 22:05:44 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v4]
In-Reply-To: <FpbTvK7G8jFCQiUdhCdnXypCCXh73V09BsyIEf0UhBw=.79c50158-d85c-4939-97cf-7ed34c16409b@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <FpbTvK7G8jFCQiUdhCdnXypCCXh73V09BsyIEf0UhBw=.79c50158-d85c-4939-97cf-7ed34c16409b@github.com>
Message-ID: <hqlZRRY2Mas1k7q_SX6Z2safGNAlUp8ZXJe1sRqpiyU=.63f2e4e4-5a89-4484-bf6b-f875f82ae3df@github.com>

On Mon, 4 Mar 2024 15:10:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>> 
>> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.
>
> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Usage correction
>  - Help to clarify this is VM inspection.  Comment to relate source to debug.cpp.
>  - jcheck trailing whitespace

Hi Thomas @tstuefe -

Security concerns certainly needed some thought. We have remote access to DiagnosticCommands over JMX.  I don't see a particular need for that for this command.  I think it was keeping the DCmd flagged as hidden that hides it from the list of dcmds available in that way.  So we have the attach api controls using local user identity, as we do for everything else.

Yes, "events" is not that useful, I should remove it.  I was taking the useful parts of debug.cpp, and although the events were in VM.info, I had missed that since your JDK-8224600, VM.events is its own command now!

Thread.print with stacks, vs "VM.debug threads" which is just a thread list, so you have e.g. JavaThread*, name, native id, stack range.

"find": Usage at the moment, would likely be MessageBoxOnError, and a native debugger to get the native stacktrace and parameters that include an object reference you care about.  It might be other jcmds if e.g. events capture a relevant problematic pointer, but likely it involves a native debugger.
Using jcmd behaves better, showing the output where you run jcmd, not in the VM's current output as the debug.cpp utils do.
Native debugger syntax to call abritrary functions can be awkward, particularly on Windows, so the jcmd should be a better experience.

This might be more compelling in post-mortem usage.  Am working on that.  i.e. jcmd on a core file.  But I am saying it offers some value today.

The class/method finders, I've heard some enthusiasm for their inclusion.  We don't want to encourage overlap but yes we do have some overlapping jcmds.


This is an umbrella but I don't think it's vague. VMDebugDcmd is for inspecting VM state.  It's inspired by debug.cpp utilities, does not need to implement all of them, but does aim to make them more accessible (I will assert that they are not well known, which is hard to prove.)

Do we have a problem with jcmd feature creep?  If anything has crept too far it can be addressed. Looks like the DCmd classes have approximately doubled since jdk8u but this looks like growth in a good way.

Thanks
Kevin

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1977543469

From cjplummer at openjdk.org  Mon Mar  4 22:12:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 4 Mar 2024 22:12:53 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <sM3Lv8t9-5wTdQg37h5ZJ4iOEfJ9Wfj8SQcEdDuHgXY=.2cb40b60-1d87-48b5-ad34-6d1628aa70e3@github.com>

On Fri, 1 Mar 2024 23:26:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Changes requested by cjplummer (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor/libInterruptRawMonitor.cpp line 32:

> 30: static jvmtiEnv *jvmti = nullptr;
> 31: 
> 32: static void check_thread_state(JNIEnv *jni, int check_idx) {

The name of this function could be better since it only checks that the state is not interrupted. Maybe check_thread_not_interrupt().

test/hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor/libInterruptRawMonitor.cpp line 36:

> 34: 
> 35:   LOG("check #%d: Thread State: (0x%x) %s\n", check_idx, state, TranslateState(state));
> 36:   if (state & JVMTI_THREAD_STATE_INTERRUPTED) {

Should explicitly check `!= 0`

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

PR Review: https://git.openjdk.org/jdk/pull/18093#pullrequestreview-1915444251
PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1511855890
PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1511857152

From sspitsyn at openjdk.org  Mon Mar  4 23:37:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Mar 2024 23:37:52 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <MpsiIacZsxFNcEoTdWLccaSyCxn1KDQG_5D9SaHseVY=.67808e96-e85f-4eac-a9ca-f59a9d441ba5@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>
 <k59gvIaIwWwk9OKiW3zXlHGnL6aEh5vV-8toM3HoHfY=.94ea08d5-a331-47bd-8029-346cfa899c6a@github.com>
 <dQY31ZGVZM-qqb6PNCfshQ9yEckO6UlfAWa4dVvuM-k=.5b52964c-58df-4ae2-88e0-48cb83605707@github.com>
 <MpsiIacZsxFNcEoTdWLccaSyCxn1KDQG_5D9SaHseVY=.67808e96-e85f-4eac-a9ca-f59a9d441ba5@github.com>
Message-ID: <3z2olsODWm-OpIbAWRm0R9GuEhEICKGXciavBJry-W8=.6df1c332-879b-41e1-b7d8-277e1c9475bd@github.com>

On Mon, 4 Mar 2024 11:51:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Alan and David, thank you for the comments!
>> The initial implementation of the `is_iterrupt()` intentionally avoided any synchronization and allowed a potential raises with the concurrent interrupts. Please, see the comment above at lines: `573-587`. It is why David mentioned the need to update the comment. I agree with Alan that that interrupt status of virtual and carrier threads have to be kept in sync. But as we already discussed with Alan before, an upcall to Java does not looks good and can cause some issues on the JDWP side. I'm thinking to model a CAS kind of operation to keep the two interrupt statuses in sync but still need to prove it is going to be safe. Also, there is a question if it worth the complexity.
>> The need to keep interrupt status in both virtual and carrier threads comes from virtual thread pinning. I believe, there would be no need to keep interrupt status for both threads in the Java object monitors inplementations. AFAICS, then the implementation of the `is_interrupted()` can be kept as it is now. 
>> So, it looks like a good suggestion to wait for Java object monitors. However, the JDWP related fix depends on this and will need to wait as well.
>
> David can correct me, but I think the only cases in the VM where a thread may clear its interrupt status is Thread.interrupted, Thread.sleep, Object.wait, and JVMTI RawMonitorWait.  Thread.interrupted and Thread.sleep are different implementation and not interesting here. Right now, Object.wait does wait on the carrier. If the virtual thread is interrupted while in the monitor's wait set then InterruptedException will be thrown when the thread reenters and the interrupt status of both threads will be cleared at that point (it will have of course have been cleared by the VM too prior to throwing). If something sneaky were to go behind our backs and interrupt the carrier directly then it will be benign for this case but might cause a spurious InterruptedException at other times, say where the mounted  virtual thread were to call Object.wait soon after its carrier was interrupted directly. We've mostly ignored that concern.
> 
> For JVMTI RawMonitorWait then it has to coordinate with Thread.interrupt and JVMTI InterruptThread. The latter does do an upcall when the target is a virtual thread so it's the same as Thread.interrupt. So minimally RawMonitorWait will need to disable suspend and and clear the interrupt status of both threads while holding the interrupt lock.

@AlanBateman said:
> So minimally RawMonitorWait will need to disable suspend and and clear the interrupt status of both threads while holding the interrupt lock.

If we do it with a Java upcall to the `VirtualThread.getAndClearInterrupt()` then we also have to skip the JVMTI events, AFAIK, as it is not a good idea to post the JVMTI events recursively. This is going to touch many spots in the `jvmtiExport.cpp`. Otherwise, I do not see how to hold the interruptLock from the VM side. Any advices?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1511933508

From cjplummer at openjdk.org  Tue Mar  5 00:56:48 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 5 Mar 2024 00:56:48 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <3z2olsODWm-OpIbAWRm0R9GuEhEICKGXciavBJry-W8=.6df1c332-879b-41e1-b7d8-277e1c9475bd@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>
 <k59gvIaIwWwk9OKiW3zXlHGnL6aEh5vV-8toM3HoHfY=.94ea08d5-a331-47bd-8029-346cfa899c6a@github.com>
 <dQY31ZGVZM-qqb6PNCfshQ9yEckO6UlfAWa4dVvuM-k=.5b52964c-58df-4ae2-88e0-48cb83605707@github.com>
 <MpsiIacZsxFNcEoTdWLccaSyCxn1KDQG_5D9SaHseVY=.67808e96-e85f-4eac-a9ca-f59a9d441ba5@github.com>
 <3z2olsODWm-OpIbAWRm0R9GuEhEICKGXciavBJry-W8=.6df1c332-879b-41e1-b7d8-277e1c9475bd@github.com>
Message-ID: <odJIrpk9yw5LuQ1tgR9ESe-tknC0lnAu0jSsglBxMQI=.7254fcd0-c13f-41b3-bebe-56e8c427bcd4@github.com>

On Mon, 4 Mar 2024 23:35:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> AFAIK, as it is not a good idea to post the JVMTI events recursively

We already do. When the debug agent is handling a JVMTI event and RawMonitorWait is interrupted, that results in the debug agent later on calling InterrtupThread before exiting the event handler. For virtual threads that results in an upcall to Thread.interrupt(), and therefore the potential for a JVMTI event to be triggered (and that is exactly what happens frequently in the com/sun/jdi/InterruptHang.java test). At least in that case the debug agent is somewhat in control of the situation because it is just doing "cleanup" before exiting the event handler. For example, no locks are being held. Having RawMonitorWait do a java upcall sounds a potential big can of worms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1511989552

From sspitsyn at openjdk.org  Tue Mar  5 01:10:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 01:10:53 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <odJIrpk9yw5LuQ1tgR9ESe-tknC0lnAu0jSsglBxMQI=.7254fcd0-c13f-41b3-bebe-56e8c427bcd4@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>
 <k59gvIaIwWwk9OKiW3zXlHGnL6aEh5vV-8toM3HoHfY=.94ea08d5-a331-47bd-8029-346cfa899c6a@github.com>
 <dQY31ZGVZM-qqb6PNCfshQ9yEckO6UlfAWa4dVvuM-k=.5b52964c-58df-4ae2-88e0-48cb83605707@github.com>
 <MpsiIacZsxFNcEoTdWLccaSyCxn1KDQG_5D9SaHseVY=.67808e96-e85f-4eac-a9ca-f59a9d441ba5@github.com>
 <3z2olsODWm-OpIbAWRm0R9GuEhEICKGXciavBJry-W8=.6df1c332-879b-41e1-b7d8-277e1c9475bd@github.com>
 <odJIrpk9yw5LuQ1tgR9ESe-tknC0lnAu0jSsglBxMQI=.7254fcd0-c13f-41b3-bebe-56e8c427bcd4@github.com>
Message-ID: <V5kfSPLAdFGmcNXyZeikvrDMB43rDSrmxGXp3KY4KMI=.9d84a7f1-d2c1-41dd-a44d-d2db9e7816bd@github.com>

On Tue, 5 Mar 2024 00:54:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> @AlanBateman said:
>>> So minimally RawMonitorWait will need to disable suspend and and clear the interrupt status of both threads while holding the interrupt lock.
>> 
>> If we do it with a Java upcall to the `VirtualThread.getAndClearInterrupt()` then we also have to skip the JVMTI events, AFAIK, as it is not a good idea to post the JVMTI events recursively. This is going to touch many spots in the `jvmtiExport.cpp`. Otherwise, I do not see how to hold the interruptLock from the VM side. Any advices?
>
>> AFAIK, as it is not a good idea to post the JVMTI events recursively
> 
> We already do. When the debug agent is handling a JVMTI event and RawMonitorWait is interrupted, that results in the debug agent later on calling InterrtupThread before exiting the event handler. For virtual threads that results in an upcall to Thread.interrupt(), and therefore the potential for a JVMTI event to be triggered (and that is exactly what happens frequently in the com/sun/jdi/InterruptHang.java test). At least in that case the debug agent is somewhat in control of the situation because it is just doing "cleanup" before exiting the event handler. For example, no locks are being held. Having RawMonitorWait do a java upcall sounds a potential big can of worms.

Thank you for sharing this, Chris. It sounds like we need to introduce a mechanism to temporarily hide the JVMTI events. The question is if it is worth the complexity we add with it, especially if it is used just in a couple of cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1511997287

From sspitsyn at openjdk.org  Tue Mar  5 01:48:48 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 01:48:48 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <gre_IkSRIfG-bCKaolsGGhR_gOaKwYvWt6cf3_nCnkU=.c3599a60-e112-4e29-a928-cb7390b6c6ce@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
 <gre_IkSRIfG-bCKaolsGGhR_gOaKwYvWt6cf3_nCnkU=.c3599a60-e112-4e29-a928-cb7390b6c6ce@github.com>
Message-ID: <kfdJFxrDStj8AWs8vsj2o_kIxB3HyDXlfkYgjH3Y2tI=.0e6f990e-ed3c-4cb5-be3e-1fea38b1218f@github.com>

On Mon, 4 Mar 2024 10:02:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1552:
>> 
>>> 1550:         // If the thread was found on the ObjectWaiter list, then
>>> 1551:         // it has not been notified. This thread can't change the
>>> 1552:         // state of the monitor so it doesn't need to be suspended.
>> 
>> Not sure why suspension is being mentioned here.
>
> This is the original comment. I also do not quite understand it. It is confusing for sure. I can remove it if Dan does not object.

Removed this statement from the comment. Will restore in a case of Dan's objection.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1512020517

From jpai at openjdk.org  Tue Mar  5 01:51:45 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Mar 2024 01:51:45 GMT
Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves
 created files in the /tmp dir.
In-Reply-To: <HD8mpLU8MkIrFi8TgPYBggPLC2vjCxrvobzuaOzCDME=.1db5364f-94de-4141-8b01-d5edd2ddccb4@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
 <hO5-favvDtAGaGoDBZhzhlt8s2abZa4aqgiH9owWzsI=.6cc2c59d-bbfc-40d2-abfb-8718d64528e0@github.com>
 <UXY0mjYQExrFC4PlBATrSiMuwBW4M7OGKvdoUMz8pa4=.e4b2f08d-d9a4-467c-b784-0664bc717a9d@github.com>
 <O_9ZU4s62TAxdQx9AdHaYN9HkB4ssl6zTn-LI_3Ywrg=.a925e516-7aae-4fdf-8055-010fdb4945d8@github.com>
 <N0cnbFgnDU4zra3HUZsOA16drgF5zK-fEKOeOdyxrZs=.69971fe4-9848-4889-9c43-2aa73b576e73@github.com>
 <JWe1ya9HTdpRZ8V_xhVkfU_bO48oEXiHCfeUKBdd6uk=.60aafd0b-3fb9-45ff-83bd-80f487e9e266@github.com>
 <HD8mpLU8MkIrFi8TgPYBggPLC2vjCxrvobzuaOzCDME=.1db5364f-94de-4141-8b01-d5edd2ddccb4@github.com>
Message-ID: <zJ2jenxLcQAagSe2ERgxsv3VQL61GPxWCnWknPu8h2U=.91a52f6a-6a00-4e90-b040-3e49a297bc30@github.com>

On Mon, 4 Mar 2024 19:35:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hello Chris, I haven't followed this PR and this is just a drive by comment about the exception handling discussion. In some other areas of our JDK tests, for situations like this, we do the following:
>> 
>> 
>> Throwable failure = null;
>> try {
>>     run(new JMXExecutor(), "Compiler.perfmap " + path.toString(), path);
>> } catch (Throwable t) {
>>     failure = t;
>> } finally {
>>     try {
>>         Files.deleteIfExists(path);
>>     } catch (IOException ioe) {
>>         if (failure != null) {
>>             // add the IOException as a suppressed exception to the original failure
>>             // and rethrow the original
>>             failure.addSuppressed(ioe);
>>             throw failure;
>>         }
>>         // no failures in the run(), but deleting the file failed, rethrow this IOException
>>         throw ioe;
>>     }
>> }
>> 
>> This way both the original test failure (if any) as well as the failure in the finally block (if any) are propagated and made available in the failure report.
>
> Hi Jai. I think that solves all the functional requirements, but now we've turned two easily understood lines of code (calling run() and deleteIfExists()) into what you have above. I'm not so sure it is worth it. I refer back to Leonid's comment above on this topic:
> 
>> I thought about execution of Files.deleteIfExists(path) in the case of test fails, but decided that it is not so important. Also, test always might fail with crash when no finally block is executed. So I am fine with current way.

Hello Chris,
> Hi Jai. I think that solves all the functional requirements, but now we've turned two easily understood lines of code (calling run() and deleteIfExists()) into what you have above. 

I agree. 

> I'm not so sure it is worth it. I refer back to Leonid's comment above on this topic:
> 
> > I thought about execution of Files.deleteIfExists(path) in the case of test fails, but decided that it is not so important. Also, test always might fail with crash when no finally block is executed. So I am fine with current way.

What Leonid suggests looks fine to me and keeps things simple.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17992#discussion_r1512022330

From amenkov at openjdk.org  Tue Mar  5 02:24:50 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 5 Mar 2024 02:24:50 GMT
Subject: RFR: JDK-8326898: NSK tests should listen on loopback addresses
 only [v2]
In-Reply-To: <0S05fii4BnVxmQZnEC2qOSmrTzAtyZTvYlblSDeNiKg=.99d7c8b1-8144-47dc-9e03-5e447b283a58@github.com>
References: <0S05fii4BnVxmQZnEC2qOSmrTzAtyZTvYlblSDeNiKg=.99d7c8b1-8144-47dc-9e03-5e447b283a58@github.com>
Message-ID: <n3hQXBuq0zkKL4xe0npHwe0pCXFxD4Ol9U7o1wpeozg=.c21969de-1636-4ab7-a6fd-fad59e6f3c57@github.com>

> Many NSK tests create socket channel for test/target interprocess communication.
> The change updates server side to listen only on loopback interface.
> 
> Testing - all tests that use then functionality:
>  - test/hotspot/jtreg/vmTestbase/nsk/jdb, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/aod, test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  SocketIOPipe.createClientIOPipe and getTestHost()/getDebugeeHost()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18053/files
  - new: https://git.openjdk.org/jdk/pull/18053/files/8d204ba7..719e2e65

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

  Stats: 17 lines in 5 files changed: 1 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/18053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18053/head:pull/18053

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

From amenkov at openjdk.org  Tue Mar  5 02:37:52 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 5 Mar 2024 02:37:52 GMT
Subject: RFR: JDK-8326898: NSK tests should listen on loopback addresses
 only [v2]
In-Reply-To: <n3hQXBuq0zkKL4xe0npHwe0pCXFxD4Ol9U7o1wpeozg=.c21969de-1636-4ab7-a6fd-fad59e6f3c57@github.com>
References: <0S05fii4BnVxmQZnEC2qOSmrTzAtyZTvYlblSDeNiKg=.99d7c8b1-8144-47dc-9e03-5e447b283a58@github.com>
 <n3hQXBuq0zkKL4xe0npHwe0pCXFxD4Ol9U7o1wpeozg=.c21969de-1636-4ab7-a6fd-fad59e6f3c57@github.com>
Message-ID: <-NJhOgBAGurPlTkjVu45r7hUPHju4Qr8P9zeszx-LBE=.3becba90-a5d2-4b50-9103-dd23c81a387c@github.com>

On Tue, 5 Mar 2024 02:24:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Many NSK tests create socket channel for test/target interprocess communication.
>> The change updates server side to listen only on loopback interface.
>> 
>> Testing - all tests that use then functionality:
>>  - test/hotspot/jtreg/vmTestbase/nsk/jdb, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/aod, test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SocketIOPipe.createClientIOPipe and getTestHost()/getDebugeeHost()

Updated connecting side of the IOPipe
Also fixed DebugeeArgumentHandler.getTestHost() (DebugeeArgumentHandler.getDebugeeHost() uses the value) to return empty string.
getTestHost()/getDebugeeHost() are used in some scenarios:
- to create arguments for listening debugee (in the case `":<port>"` is passed, so debugee listens on loopback address);
- to connect to a socket (then InetAddress.getByName returns loockback address).

All tests that use then functionality pass

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

PR Comment: https://git.openjdk.org/jdk/pull/18053#issuecomment-1977837845

From sspitsyn at openjdk.org  Tue Mar  5 03:40:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 03:40:04 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v22]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <MqG0WJIaRZngeD4pdElLllp3nRheZGyGzj7qP1ep39c=.ff71b9b6-c073-4443-9127-6a987a150114@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: addressed more comments on the fix and new test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/b449f04a..ccf9484f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=20-21

  Stats: 69 lines in 3 files changed: 39 ins; 4 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

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

From sspitsyn at openjdk.org  Tue Mar  5 04:17:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 04:17:57 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v5]
In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
Message-ID: <t7K1xNIXIJ9ZDWkazRFAwZw_j3gHH-zmYo-tqAUZADY=.451711a7-c2c0-4a46-9238-b092d01b8fec@github.com>

> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
> 
> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
> 
> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
> 
> Testing:
>  - tested with the mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: replaced timed with timed-out in JDWP and JDI spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17944/files
  - new: https://git.openjdk.org/jdk/pull/17944/files/1a3d1c19..c30655a3

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

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

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

From sspitsyn at openjdk.org  Tue Mar  5 04:17:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 04:17:58 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v4]
In-Reply-To: <FUW7Auwbo5fmBuS6k61jgn9gUBGf7oFZdm_NKq2VYR0=.26b02b4b-3868-4fab-9679-b3de35637d5a@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <FUW7Auwbo5fmBuS6k61jgn9gUBGf7oFZdm_NKq2VYR0=.26b02b4b-3868-4fab-9679-b3de35637d5a@github.com>
Message-ID: <3Y6fAWEDaxZrANXhwysEVXghraID8dLL5rA9-QlC_7M=.7e9d75d0-0a97-407f-9329-802416b53c0e@github.com>

On Fri, 1 Mar 2024 11:19:21 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
>> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
>> 
>> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
>> 
>> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> 
>> Testing:
>>  - tested with the mach5 tiers 1-6
>
> 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 four additional commits since the last revision:
> 
>  - Merge
>  - Merge
>  - fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method
>  - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

David, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/17944#issuecomment-1977937253

From sspitsyn at openjdk.org  Tue Mar  5 04:17:59 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 04:17:59 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v4]
In-Reply-To: <ufLwZUemf7jV4cj5F-VVRz8Ny7uE3sHiiriGLczBw9U=.c8193f2b-179f-4904-8b0c-ab5568865f97@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <FUW7Auwbo5fmBuS6k61jgn9gUBGf7oFZdm_NKq2VYR0=.26b02b4b-3868-4fab-9679-b3de35637d5a@github.com>
 <PJNmW1TYGDAzikzsJ5hkR-IKfhOKoKMV36A3oZlB5A4=.d3970c40-c001-4af6-90c7-e67f3d0dd61b@github.com>
 <ufLwZUemf7jV4cj5F-VVRz8Ny7uE3sHiiriGLczBw9U=.c8193f2b-179f-4904-8b0c-ab5568865f97@github.com>
Message-ID: <nN3sfuWHth0jYJ4hD_nhcFfvpbkvS4Ruitlp72bAlDw=.9c35ac59-7cb6-4b1b-9542-852e8aa8153e@github.com>

On Mon, 4 Mar 2024 09:49:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/java.se/share/data/jdwp/jdwp.spec line 1985:
>> 
>>> 1983:         "thread may be waiting to enter the object's monitor, or in "
>>> 1984:         "java.lang.Object.wait waiting to re-enter the monitor after being "
>>> 1985:         "notified, interrupted, or timeout."
>> 
>> `timed-out` would be the correct sense here.
>
> Thank you, David. I was thinking about it but was not sure. Will update it.

Fixed now. Also, updated CSR and RN.

>> src/jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java line 314:
>> 
>>> 312:      * synchronized method, the synchronized statement, or
>>> 313:      * {@link Object#wait} waiting to re-enter the monitor
>>> 314:      * after being notified, interrupted, or timeout.
>> 
>> Again `timed-out`.
>
> Will fix, thanks.

Fixed now. Also, updated CSR and RN.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1512112147
PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1512112210

From david.holmes at oracle.com  Tue Mar  5 05:38:06 2024
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Mar 2024 15:38:06 +1000
Subject: AttachListener bsd differences
In-Reply-To: <CADo2k6t734mivgR6muX+5Rd+CTK=0hLUvU+zba=xfPP7UbNgww@mail.gmail.com>
References: <CADo2k6t734mivgR6muX+5Rd+CTK=0hLUvU+zba=xfPP7UbNgww@mail.gmail.com>
Message-ID: <5720cd8a-5ce9-44db-87e3-867f79c00a88@oracle.com>

Hi Sonia,

Adding serviceability and Alan Bateman ...

On 5/03/2024 2:35 am, Sonia Zaldana Calles wrote:
> Hi folks,
> 
> 
> I?m working on JDK-8324683 [0].
> 
> 
> I?m hoping to unify the code for attachListener_<os>.cpp for posix 
> platforms.
> 
> 
> While reviewing linux against bsd, I noted a difference in 
> AttachListener::is_init_trigger().
> 
> 
> Both linux and AIX implementations, first try ?<current 
> dir>/.attach<pid>? and failing that, attempt ?/tmp/.attach<pid>?.? [1][2]
> 
> 
> On the other hand, bsd doesn?t attempt ?/tmp/.attach<pid>? [3].

I think you meant it doesn't attempt <current dir>/.attach<pid>

> 
> I have been trying to do a bit of digging to see if this disparity was 
> intentional but I have found that this change precedes the MacOS port, 
> so I?m having trouble coming to a conclusion.

Looking at the history here:

https://hg.openjdk.org/macosx-port/macosx-port/hotspot/log/407770c31c18/src/os/bsd/vm/attachListener_bsd.cpp

The very first load of the file did check the current directory too:

https://hg.openjdk.org/macosx-port/macosx-port/hotspot/rev/be94a5de4d32

but that was removed in the very next upload (though they never fixed 
the comment preceding the code):

https://hg.openjdk.org/macosx-port/macosx-port/hotspot/rev/9f1dd0b1d28c

To know why you would have to ask the person that did it I'm afraid.

> I was wondering if perhaps anyone on this list could shed some light on 
> this matter and whether it would be acceptable to do the alternate path 
> on BSD too.

The init trigger mechanism was added by Alan under:

https://bugs.openjdk.org/browse/JDK-6272307

I get the sense that having the well-known file in the working directory 
was actually a bit of an anachronism. That may be why the macOS folk 
didn't bother with it (speculation on my part). AIX simply copied the 
Linux code.

Whether it would be okay/harmless/safe to have macOS/BSD also check 
there I really can't say. I'm not sure if we have code that would ever 
write the file to the target cwd these days? Hopefully Alan or current 
serviceability folk can say more.

Cheers,
David
-----

> 
> Thanks for your help,
> 
> Sonia
> 
> 
> 
> [0] https://bugs.openjdk.org/browse/JDK-8324683 
> <https://bugs.openjdk.org/browse/JDK-8324683>
> 
> [1] 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/attachListener_linux.cpp#L521C3-L529C4 <https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/attachListener_linux.cpp#L521C3-L529C4>
> 
> [2] 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/attachListener_aix.cpp#L551C2-L559C4 <https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/attachListener_aix.cpp#L551C2-L559C4>
> 
> [3] 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/bsd/attachListener_bsd.cpp#L520C2-L522C4 <https://github.com/openjdk/jdk/blob/master/src/hotspot/os/bsd/attachListener_bsd.cpp#L520C2-L522C4>
> 
> -- 
> Sonia Zalda?a Calles
> Software Engineer, OpenJDK
> Red Hat

From sspitsyn at openjdk.org  Tue Mar  5 06:09:47 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 06:09:47 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <sM3Lv8t9-5wTdQg37h5ZJ4iOEfJ9Wfj8SQcEdDuHgXY=.2cb40b60-1d87-48b5-ad34-6d1628aa70e3@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <sM3Lv8t9-5wTdQg37h5ZJ4iOEfJ9Wfj8SQcEdDuHgXY=.2cb40b60-1d87-48b5-ad34-6d1628aa70e3@github.com>
Message-ID: <dEvmmlCTqUt8TaoCzuLD6pOKk5F2sQKLSL23I1WHPg0=.37818492-2db9-48cc-8ad8-056f787fb770@github.com>

On Mon, 4 Mar 2024 22:04:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor/libInterruptRawMonitor.cpp line 32:
> 
>> 30: static jvmtiEnv *jvmti = nullptr;
>> 31: 
>> 32: static void check_thread_state(JNIEnv *jni, int check_idx) {
> 
> The name of this function could be better since it only checks that the state is not interrupted. Maybe check_thread_not_interrupt().

Thank you. Updated as suggested.

> test/hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor/libInterruptRawMonitor.cpp line 36:
> 
>> 34: 
>> 35:   LOG("check #%d: Thread State: (0x%x) %s\n", check_idx, state, TranslateState(state));
>> 36:   if (state & JVMTI_THREAD_STATE_INTERRUPTED) {
> 
> Should explicitly check `!= 0`

Thanks, fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1512178943
PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1512179056

From sspitsyn at openjdk.org  Tue Mar  5 06:16:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 06:16:04 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <3YXFxQb_MUwpkmENa_qlqo8PybAiu4PtUEbRIA1bGRo=.4e6a7c95-4ecf-4332-ab40-118b035a27c1@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: addressed a couple of comments on new test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/bb920ccb..b365ede4

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

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

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

From sspitsyn at openjdk.org  Tue Mar  5 06:18:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 06:18:56 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v6]
In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
Message-ID: <twQAI4lvg-TCvx28XJNwiMkk2RagakH-GZQE-1Bl0_Q=.c6c9694f-0eda-4fb3-a395-16dce774ec03@github.com>

> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
> 
> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
> 
> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
> 
> Testing:
>  - tested with the mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: added new internal function JvmtiEnvBase::get_thread_or_vthread_state

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17944/files
  - new: https://git.openjdk.org/jdk/pull/17944/files/c30655a3..9b69af50

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

  Stats: 24 lines in 3 files changed: 14 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17944/head:pull/17944

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

From dholmes at openjdk.org  Tue Mar  5 06:48:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Mar 2024 06:48:52 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v22]
In-Reply-To: <MqG0WJIaRZngeD4pdElLllp3nRheZGyGzj7qP1ep39c=.ff71b9b6-c073-4443-9127-6a987a150114@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <MqG0WJIaRZngeD4pdElLllp3nRheZGyGzj7qP1ep39c=.ff71b9b6-c073-4443-9127-6a987a150114@github.com>
Message-ID: <4XAkV4CDJUTXFeKCCkAQlD_HntnLWwd_AqcTEMowS4k=.f5d2572f-3061-4a56-bf9d-e97bda57e3a0@github.com>

On Tue, 5 Mar 2024 03:40:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed more comments on the fix and new test

Updates look good. A couple of minor commenst.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1507:

> 1505:     nWait = 0;
> 1506:     for (ObjectWaiter* waiter = mon->first_waiter();
> 1507:          waiter != nullptr && (nWait == 0 || waiter != mon->first_waiter());

Sorry I do not understand the logic of this line. `waiters` is just a linked-list of `ObjectWaiter`s so all we need to do is traverse it and count the number of elements.

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 36:

> 34:  *       - unowned object without any waiting threads
> 35:  *       - unowned object with threads waiting to be notified
> 36:  *       - owned object without any waiting threads

You could say "threads waiting" in all cases - it looks odd to reverse it for two cases.

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

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1915963487
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1512195706
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1512197846

From dholmes at openjdk.org  Tue Mar  5 07:09:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Mar 2024 07:09:48 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
In-Reply-To: <3YXFxQb_MUwpkmENa_qlqo8PybAiu4PtUEbRIA1bGRo=.4e6a7c95-4ecf-4332-ab40-118b035a27c1@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <3YXFxQb_MUwpkmENa_qlqo8PybAiu4PtUEbRIA1bGRo=.4e6a7c95-4ecf-4332-ab40-118b035a27c1@github.com>
Message-ID: <GV2jDl4FfOu8UWRCY7PR3P2MzHUViygzQjEebJhvDX4=.c179ee19-a32d-4cc3-91a1-949532f2548b@github.com>

On Tue, 5 Mar 2024 06:16:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed a couple of comments on new test

I have to say that I don't understand how the behaviour of `RawMonitorWait` is any different to `ObjectMonitor::wait` when it comes to the use of the `is_interrupted(true)`.  ??? Is it simply that because we are in native code and we can immediately query the actual thread state that we can observe when the carrier and virtual thread states are transiently different?

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1978090675

From sspitsyn at openjdk.org  Tue Mar  5 07:43:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 07:43:46 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v4]
In-Reply-To: <ufLwZUemf7jV4cj5F-VVRz8Ny7uE3sHiiriGLczBw9U=.c8193f2b-179f-4904-8b0c-ab5568865f97@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <FUW7Auwbo5fmBuS6k61jgn9gUBGf7oFZdm_NKq2VYR0=.26b02b4b-3868-4fab-9679-b3de35637d5a@github.com>
 <PJNmW1TYGDAzikzsJ5hkR-IKfhOKoKMV36A3oZlB5A4=.d3970c40-c001-4af6-90c7-e67f3d0dd61b@github.com>
 <ufLwZUemf7jV4cj5F-VVRz8Ny7uE3sHiiriGLczBw9U=.c8193f2b-179f-4904-8b0c-ab5568865f97@github.com>
Message-ID: <zynN5l20DChVYuJZpVxZE5ERdDvAbNIaioUcnm7HJbw=.68068611-8813-42c2-808d-1800512c42c3@github.com>

On Mon, 4 Mar 2024 09:51:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 941:
>> 
>>> 939:     bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
>>> 940:     jint state = is_virtual ? JvmtiEnvBase::get_vthread_state(thread_oop, java_thread)
>>> 941:                             : JvmtiEnvBase::get_thread_state(thread_oop, java_thread);
>> 
>> I've seen this in a couple of your PRs now. It would be nice to have a utility function to get the JVMTI thread state of any java.lang.Thread instance.
>
> Good suggestion, thanks. Will add.

Added now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1512266627

From alanb at openjdk.org  Tue Mar  5 07:49:44 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Mar 2024 07:49:44 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
In-Reply-To: <V5kfSPLAdFGmcNXyZeikvrDMB43rDSrmxGXp3KY4KMI=.9d84a7f1-d2c1-41dd-a44d-d2db9e7816bd@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>
 <k59gvIaIwWwk9OKiW3zXlHGnL6aEh5vV-8toM3HoHfY=.94ea08d5-a331-47bd-8029-346cfa899c6a@github.com>
 <dQY31ZGVZM-qqb6PNCfshQ9yEckO6UlfAWa4dVvuM-k=.5b52964c-58df-4ae2-88e0-48cb83605707@github.com>
 <MpsiIacZsxFNcEoTdWLccaSyCxn1KDQG_5D9SaHseVY=.67808e96-e85f-4eac-a9ca-f59a9d441ba5@github.com>
 <3z2olsODWm-OpIbAWRm0R9GuEhEICKGXciavBJry-W8=.6df1c332-879b-41e1-b7d8-277e1c9475bd@github.com>
 <odJIrpk9yw5LuQ1tgR9ESe-tknC0lnAu0jSsglBxMQI=.7254fcd0-c13f-41b3-bebe-56e8c427bcd4@github.com>
 <V5kfSPLAdFGmcNXyZeikvrDMB43rDSrmxGXp3KY4KMI=.9d84a7f1-d2c1-41dd-a44d-d2db9e7816bd@github.com>
Message-ID: <lHnYhR5cyBiAszKsWv5BdoiyCAQdWpcmy3GFXd5t5QE=.4ba9f484-7313-481e-a350-efc3fe4fd934@github.com>

On Tue, 5 Mar 2024 01:06:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> AFAIK, as it is not a good idea to post the JVMTI events recursively
>> 
>> We already do. When the debug agent is handling a JVMTI event and RawMonitorWait is interrupted, that results in the debug agent later on calling InterrtupThread before exiting the event handler. For virtual threads that results in an upcall to Thread.interrupt(), and therefore the potential for a JVMTI event to be triggered (and that is exactly what happens frequently in the com/sun/jdi/InterruptHang.java test). At least in that case the debug agent is somewhat in control of the situation because it is just doing "cleanup" before exiting the event handler. For example, no locks are being held. Having RawMonitorWait do a java upcall sounds a potential big can of worms.
>
> Thank you for sharing this, Chris. It sounds like we need to introduce a mechanism to temporarily hide the JVMTI events. The question is if it is worth the complexity we add with it, especially if it is used just in a couple of cases.

> If we do it with a Java upcall to the `VirtualThread.getAndClearInterrupt()` then we also have to skip the JVMTI events, AFAIK, as it is not a good idea to post the JVMTI events recursively. 

I meant it would need to use ObjectLocker to hold the lock in the VM when changing both fields. It should only need to do this for RawMonitorWait at this time. For Object.wait, the clearing of the interrupt status is done in the Java code, something that will change once Object.wait changes to freeze/unmount when not pinned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1512274259

From mdoerr at openjdk.org  Tue Mar  5 08:51:00 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 5 Mar 2024 08:51:00 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v28]
In-Reply-To: <s9R8RSGvi_zc-cbNdJDe3fK1XNDZsvizFZ3E8rV6Hns=.f78773be-5146-4c95-ad8c-6456d02f5213@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <s9R8RSGvi_zc-cbNdJDe3fK1XNDZsvizFZ3E8rV6Hns=.f78773be-5146-4c95-ad8c-6456d02f5213@github.com>
Message-ID: <AAFBpj2gnfVOUmrXMKubX_mPfiK6UVNJOrDshcWRmrg=.cf34ea12-ffcd-49c2-a05c-7f380335280e@github.com>

On Tue, 27 Feb 2024 08:31:15 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:
> 
>   indendt

jdk21u is only open for critical backports and requires special approval. Please backport it to jdk21u-dev. What about jdk22u?

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

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

From sspitsyn at openjdk.org  Tue Mar  5 08:58:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 08:58:52 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v22]
In-Reply-To: <4XAkV4CDJUTXFeKCCkAQlD_HntnLWwd_AqcTEMowS4k=.f5d2572f-3061-4a56-bf9d-e97bda57e3a0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <MqG0WJIaRZngeD4pdElLllp3nRheZGyGzj7qP1ep39c=.ff71b9b6-c073-4443-9127-6a987a150114@github.com>
 <4XAkV4CDJUTXFeKCCkAQlD_HntnLWwd_AqcTEMowS4k=.f5d2572f-3061-4a56-bf9d-e97bda57e3a0@github.com>
Message-ID: <bmW0pAoszAMHZIK56cZV2qSipSDJd3-TKQsIbIjqGK8=.57a09305-a46f-4423-bfff-d7f1d2b8fb49@github.com>

On Tue, 5 Mar 2024 06:30:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed more comments on the fix and new test
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1507:
> 
>> 1505:     nWait = 0;
>> 1506:     for (ObjectWaiter* waiter = mon->first_waiter();
>> 1507:          waiter != nullptr && (nWait == 0 || waiter != mon->first_waiter());
> 
> Sorry I do not understand the logic of this line. `waiters` is just a linked-list of `ObjectWaiter`s so all we need to do is traverse it and count the number of elements.

The loop is endless without this extra condition, so we are getting a test execution timeout.
The `waiters` seems to be `circular doubly linked list` as we can see below:

inline void ObjectMonitor::AddWaiter(ObjectWaiter* node) {
  assert(node != nullptr, "should not add null node");
  assert(node->_prev == nullptr, "node already in list");
  assert(node->_next == nullptr, "node already in list");
  // put node at end of queue (circular doubly linked list)
  if (_WaitSet == nullptr) {
    _WaitSet = node;
    node->_prev = node;
    node->_next = node;
  } else {
    ObjectWaiter* head = _WaitSet;
    ObjectWaiter* tail = head->_prev;
    assert(tail->_next == head, "invariant check");
    tail->_next = node;
    head->_prev = node;
    node->_next = head;
    node->_prev = tail;
  }
}

I'll make sure nothing is missed and check the old code again.

> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 36:
> 
>> 34:  *       - unowned object without any waiting threads
>> 35:  *       - unowned object with threads waiting to be notified
>> 36:  *       - owned object without any waiting threads
> 
> You could say "threads waiting" in all cases - it looks odd to reverse it for two cases.

Thanks, updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1512386413
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1512391923

From sspitsyn at openjdk.org  Tue Mar  5 09:06:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 09:06:55 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v22]
In-Reply-To: <bmW0pAoszAMHZIK56cZV2qSipSDJd3-TKQsIbIjqGK8=.57a09305-a46f-4423-bfff-d7f1d2b8fb49@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <MqG0WJIaRZngeD4pdElLllp3nRheZGyGzj7qP1ep39c=.ff71b9b6-c073-4443-9127-6a987a150114@github.com>
 <4XAkV4CDJUTXFeKCCkAQlD_HntnLWwd_AqcTEMowS4k=.f5d2572f-3061-4a56-bf9d-e97bda57e3a0@github.com>
 <bmW0pAoszAMHZIK56cZV2qSipSDJd3-TKQsIbIjqGK8=.57a09305-a46f-4423-bfff-d7f1d2b8fb49@github.com>
Message-ID: <5lsZBFSbWmDQVJe9tGr2Rll00SWkbU7HBuRpEC_-Duo=.167e62b6-ca47-4a93-b8ad-7c22b379221d@github.com>

On Tue, 5 Mar 2024 08:53:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1507:
>> 
>>> 1505:     nWait = 0;
>>> 1506:     for (ObjectWaiter* waiter = mon->first_waiter();
>>> 1507:          waiter != nullptr && (nWait == 0 || waiter != mon->first_waiter());
>> 
>> Sorry I do not understand the logic of this line. `waiters` is just a linked-list of `ObjectWaiter`s so all we need to do is traverse it and count the number of elements.
>
> The loop is endless without this extra condition, so we are getting a test execution timeout.
> The `waiters` seems to be `circular doubly linked list` as we can see below:
> 
> inline void ObjectMonitor::AddWaiter(ObjectWaiter* node) {
>   assert(node != nullptr, "should not add null node");
>   assert(node->_prev == nullptr, "node already in list");
>   assert(node->_next == nullptr, "node already in list");
>   // put node at end of queue (circular doubly linked list)
>   if (_WaitSet == nullptr) {
>     _WaitSet = node;
>     node->_prev = node;
>     node->_next = node;
>   } else {
>     ObjectWaiter* head = _WaitSet;
>     ObjectWaiter* tail = head->_prev;
>     assert(tail->_next == head, "invariant check");
>     tail->_next = node;
>     head->_prev = node;
>     node->_next = head;
>     node->_prev = tail;
>   }
> }
> 
> I'll make sure nothing is missed and check the old code again.

Okay. Now I see why the old code did not have endless loops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1512409266

From kevinw at openjdk.org  Tue Mar  5 10:18:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 10:18:13 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v5]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <_6ZQgiScRo9M38WnJCN_ok9h1E7M1sOv2kDVH5LuMk0=.849346c4-539d-440b-915b-392f756f9849@github.com>

> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
> 
> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.

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

  Remove unnecessary 'events' subcommand.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/1d1e20e2..6ba1c909

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

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

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

From ihse at openjdk.org  Tue Mar  5 10:55:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Mar 2024 10:55:01 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v28]
In-Reply-To: <AAFBpj2gnfVOUmrXMKubX_mPfiK6UVNJOrDshcWRmrg=.cf34ea12-ffcd-49c2-a05c-7f380335280e@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <s9R8RSGvi_zc-cbNdJDe3fK1XNDZsvizFZ3E8rV6Hns=.f78773be-5146-4c95-ad8c-6456d02f5213@github.com>
 <AAFBpj2gnfVOUmrXMKubX_mPfiK6UVNJOrDshcWRmrg=.cf34ea12-ffcd-49c2-a05c-7f380335280e@github.com>
Message-ID: <_1kK6WNrzAFFQItw0g4AMjdSKrGdrKVphWPFwt3Z-MI=.ef30ed38-7918-4243-bd86-3c0dc2f501af@github.com>

On Tue, 5 Mar 2024 08:48:15 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   indendt
>
> jdk21u is only open for critical backports and requires special approval. Please backport it to jdk21u-dev.
> What about jdk22u?
> `/backport` commands should be used in commits, not in closed PRs.
> Not sure if it works without Committer privileges.

@TheRealMDoerr FYI, `/backport` works in PRs as well as commits since some time ago... In fact, I would recommend it as the better way to create a backport, now that it exists.

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

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

From kevinw at openjdk.org  Tue Mar  5 10:56:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 10:56:18 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v6]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <02-ViHO9eFjPH1qXYTI8WZ4-PXV6IMwoJvjRraZtU3s=.4785648f-44c1-4dea-a9b1-19d053042359@github.com>

> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
> 
> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.

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

  Show description if unknown subcommand.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/6ba1c909..98a46d09

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

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

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

From kevinw at openjdk.org  Tue Mar  5 11:31:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 11:31:13 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v7]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <cwk2OYW86sV22aA4SGRbGHiYv8_Xtcn8pqhMbJXumgk=.195513d1-0500-4710-865e-7d8cc76ad1da@github.com>

> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
> 
> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.

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

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/98a46d09..3f566649

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=05-06

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

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

From kevinw at openjdk.org  Tue Mar  5 11:39:48 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 11:39:48 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: <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
Message-ID: <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>

On Mon, 4 Mar 2024 19:57:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I was not exactly sure if we will support this functionality when there is no SM. The class name has `AccessControler` and the method names use `checkAccess`, but they actually do not always depend on security manager.
>
> I think we need @kevinjwalls or @dfuch to help advise on this.

Right, this does not depend on the SM.   All we need to do is get the Subject.
This method implements the basic monitor (readonly) and control (readwrite) access.
accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1512676642

From stuefe at openjdk.org  Tue Mar  5 14:02:49 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 5 Mar 2024 14:02:49 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v4]
In-Reply-To: <hqlZRRY2Mas1k7q_SX6Z2safGNAlUp8ZXJe1sRqpiyU=.63f2e4e4-5a89-4484-bf6b-f875f82ae3df@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <FpbTvK7G8jFCQiUdhCdnXypCCXh73V09BsyIEf0UhBw=.79c50158-d85c-4939-97cf-7ed34c16409b@github.com>
 <hqlZRRY2Mas1k7q_SX6Z2safGNAlUp8ZXJe1sRqpiyU=.63f2e4e4-5a89-4484-bf6b-f875f82ae3df@github.com>
Message-ID: <SiZJ8Hgp7DtwOrkODk0CtzJQiCtxD7G14DfV_xjLDQs=.5973cd75-a510-4195-b46e-8a01c8b4b409@github.com>

On Mon, 4 Mar 2024 22:02:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Usage correction
>>  - Help to clarify this is VM inspection.  Comment to relate source to debug.cpp.
>>  - jcheck trailing whitespace
>
> Hi Thomas @tstuefe -
> 
> Security concerns certainly needed some thought. We have remote access to DiagnosticCommands over JMX.  I don't see a particular need for that for this command.  I think it was keeping the DCmd flagged as hidden that hides it from the list of dcmds available in that way.  So we have the attach api controls using local user identity, as we do for everything else.
> 
> Yes, "events" is not that useful, I should remove it.  I was taking the useful parts of debug.cpp, and although the events were in VM.info, I had missed that since your JDK-8224600, VM.events is its own command now!
> 
> Thread.print with stacks, vs "VM.debug threads" which is just a thread list, so you have e.g. JavaThread*, name, native id, stack range.
> 
> "find": Usage at the moment, would likely be MessageBoxOnError, and a native debugger to get the native stacktrace and parameters that include an object reference you care about.  It might be other jcmds if e.g. events capture a relevant problematic pointer, but likely it involves a native debugger.
> Using jcmd behaves better, showing the output where you run jcmd, not in the VM's current output as the debug.cpp utils do.
> Native debugger syntax to call abritrary functions can be awkward, particularly on Windows, so the jcmd should be a better experience.
> 
> This might be more compelling in post-mortem usage.  Am working on that.  i.e. jcmd on a core file.  But I am saying it offers some value today.
> 
> The class/method finders, I've heard some enthusiasm for their inclusion.  We don't want to encourage overlap but yes we do have some overlapping jcmds.
> 
> 
> This is an umbrella but I don't think it's vague. VMDebugDcmd is for inspecting VM state.  It's inspired by debug.cpp utilities, does not need to implement all of them, but does aim to make them more accessible (I will assert that they are not well known, which is hard to prove.)
> 
> Do we have a problem with jcmd feature creep?  If anything has crept too far it can be addressed. Looks like the DCmd classes have approximately doubled since jdk8u but this looks like growth in a good way.
> 
> Thanks
> Kevin

Hi Kevin, @kevinjwalls ,

thank you for your explanations. Please find answers inline.

> Security concerns certainly needed some thought. We have remote access to DiagnosticCommands over JMX. I don't see a particular need for that for this command. I think it was keeping the DCmd flagged as hidden that hides it from the list of dcmds available in that way. So we have the attach api controls using local user identity, as we do for everything else.
> 
> Yes, "events" is not that useful, I should remove it. I was taking the useful parts of debug.cpp, and although the events were in VM.info, I had missed that since your JDK-8224600, VM.events is its own command now!
> 
> Thread.print with stacks, vs "VM.debug threads" which is just a thread list, so you have e.g. JavaThread*, name, native id, stack range.
> 
> "find": Usage at the moment, would likely be MessageBoxOnError, and a native debugger to get the native stacktrace and parameters that include an object reference you care about. It might be other jcmds if e.g. events capture a relevant problematic pointer, but likely it involves a native debugger. Using jcmd behaves better, showing the output where you run jcmd, not in the VM's current output as the debug.cpp utils do. Native debugger syntax to call abritrary functions can be awkward, particularly on Windows, so the jcmd should be a better experience.

I remain sceptic here, because in my experience, once you start poking at the JVM innards at this level, I guess you will be quickly at the limit of what this command can do for you and need to attach a debugger anyway.

Could this be an own command, e,g, `VM.inspect`, and possibly limited to debug VMs? Do we really need this feature in production?

> 
> This might be more compelling in post-mortem usage. Am working on that. i.e. jcmd on a core file. But I am saying it offers some value today.

Don't we have jhsdb for that?

> 
> The class/method finders, I've heard some enthusiasm for their inclusion. We don't want to encourage overlap but yes we do have some overlapping jcmds.

Yeah, I can see this being useful.

> 
> This is an umbrella but I don't think it's vague. VMDebugDcmd is for inspecting VM state. It's inspired by debug.cpp utilities, does not need to implement all of them, but does aim to make them more accessible (I will assert that they are not well known, which is hard to prove.)
> 
> Do we have a problem with jcmd feature creep? If anything has crept too far it can be addressed. Looks like the DCmd classes have approximately doubled since jdk8u but this looks like growth in a good way.
> 

Normally, we have either single-use commands or commands grouped roughly by the area they belong to. VM.metaspace is a command for various metaspace-related diagnostics. There is no clear policy guarding the form of jcmds, so its already a bit of a mess. E.g. VM.info would be a cross-topic outlier, albeit a very useful one.

VM.debug would introduce a command orthogonal to the usual grouping-by-topic. Is VM.debug, in its class-showing capacity, more "debug" than the class-related commands, including VM.metaspace, we already have? Adding new class-illuminating features should happen now here, instead of adding a new VM.class_xxx command? 

Thanks, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1978836319

From weijun at openjdk.org  Tue Mar  5 14:46:47 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 14:46: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: <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
Message-ID: <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>

On Tue, 5 Mar 2024 11:36:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I think we need @kevinjwalls or @dfuch to help advise on this.
>
> Right, this does not depend on the SM.   All we need to do is get the Subject.
> This method implements the basic monitor (readonly) and control (readwrite) access.
> accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.

Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1512951092

From weijun at openjdk.org  Tue Mar  5 14:58:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 14:58:25 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v5]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <5fLmCMsDfb6akv1964_z9y8a4ccxmXaLJVjNiU5Khvs=.69025b5e-374e-4ae2-9db8-d27580a10345@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 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 eight additional commits since the last revision:

 - Merge branch 'master' into 8296244
 - revert some test changes, spec change for subject
 - fix MBeanServerFileAccessController, more test in SM
 - JMX needs SM
 - Resolve Alan's comments
 - remove exe bits
 - remove x bit
 - the patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/e57f7250..2b55b171

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

  Stats: 97308 lines in 3235 files changed: 46912 ins; 26097 del; 24299 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 kevinw at openjdk.org  Tue Mar  5 16:51:46 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 5 Mar 2024 16:51:46 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: <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
Message-ID: <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>

On Tue, 5 Mar 2024 14:44:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Right, this does not depend on the SM.   All we need to do is get the Subject.
>> This method implements the basic monitor (readonly) and control (readwrite) access.
>> accessMap maps identity String to Access, and the checkAccess() method here will check the Subject by using of its Principal names as keys in that map.
>
> Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.

Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java

(That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
https://github.com/openjdk/jdk/pull/18025 )

makeClient in RMIJRMPServerImpl creates RMIConnectionImpl

..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1513164360

From lmesnik at openjdk.org  Tue Mar  5 18:18:47 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 5 Mar 2024 18:18:47 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
In-Reply-To: <3YXFxQb_MUwpkmENa_qlqo8PybAiu4PtUEbRIA1bGRo=.4e6a7c95-4ecf-4332-ab40-118b035a27c1@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <3YXFxQb_MUwpkmENa_qlqo8PybAiu4PtUEbRIA1bGRo=.4e6a7c95-4ecf-4332-ab40-118b035a27c1@github.com>
Message-ID: <XFKK2BuGPbvZODuy1AcAGtvdXjPw7YSPlxac1THHeC8=.9e2af3b8-ade9-4aa9-a7ae-ab15a088225d@github.com>

On Tue, 5 Mar 2024 06:16:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed a couple of comments on new test

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor/InterruptRawMonitor.java line 51:

> 49:         System.out.println(thread);
> 50:         thread.start();
> 51:         Thread.sleep(2000);

I think it would be better to check 'thread' status or the same monitor  to sync instead of sleep.  The sleep is always looks suspect, especially when intermittent failure happens. 
Also, it helps to save 2 seconds.

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

PR Review: https://git.openjdk.org/jdk/pull/18093#pullrequestreview-1917793041
PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1513292890

From lmesnik at openjdk.org  Tue Mar  5 19:07:52 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 5 Mar 2024 19:07:52 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v6]
In-Reply-To: <twQAI4lvg-TCvx28XJNwiMkk2RagakH-GZQE-1Bl0_Q=.c6c9694f-0eda-4fb3-a395-16dce774ec03@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <twQAI4lvg-TCvx28XJNwiMkk2RagakH-GZQE-1Bl0_Q=.c6c9694f-0eda-4fb3-a395-16dce774ec03@github.com>
Message-ID: <EG5hOBRRFH50nYc9dO17Ngww9lxkmvT-YAVnkPnNhe4=.eaa607d1-4eb8-47ed-8b11-9246d078b222@github.com>

On Tue, 5 Mar 2024 06:18:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
>> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
>> 
>> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
>> 
>> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> 
>> Testing:
>>  - tested with the mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: added new internal function JvmtiEnvBase::get_thread_or_vthread_state

The test changes look good, need just small doc update.
The jvmti test  serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon01/contmon01.java 
is correct and don't check wait monitors.
I wonder if it makes sense to add test which verify that thread waiting in Object.wait() is not included into the result.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads004a.java line 106:

> 104:                 display("entered and notifyAll: synchronized (lockingObject) {}");
> 105:                 lockingObject.notifyAll();
> 106: 

Please update test documentation in TestDescription. line:
     - An object with threads waiting in Object.wait(long) method.
 should be updated/or another one added.

test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/CurrentContendedMonitor/curcontmonitor001a.java line 88:

> 86:             // ensure that tested thread is waiting for monitor object
> 87:             synchronized (TestedClass.thread.monitor) {
> 88:                 TestedClass.thread.monitor.notifyAll();

You need to update test documentation in TestDescription.java to explicitly say that test not "waiting" but exit from wait and waiting for monitor (contended).

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17944#pullrequestreview-1917844453
PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1513326686
PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1513323999

From larry.cable at oracle.com  Tue Mar  5 19:39:29 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Tue, 5 Mar 2024 11:39:29 -0800
Subject: AttachListener bsd differences
In-Reply-To: <5720cd8a-5ce9-44db-87e3-867f79c00a88@oracle.com>
References: <CADo2k6t734mivgR6muX+5Rd+CTK=0hLUvU+zba=xfPP7UbNgww@mail.gmail.com>
 <5720cd8a-5ce9-44db-87e3-867f79c00a88@oracle.com>
Message-ID: <f3a75f78-a805-4f93-8d65-de70b041600f@oracle.com>

looking at the "attacher" code in jdk.attach it certainly does not 
appear to attempt to "attach" via cwd, so I would say that the 
"attachee" code to check this is redundant, unless there is a backwards 
compatibility/interoperability issue that requires this where
an early JDK "attacher" might attempt to rendezvous via cwd...

Rgds

- Larry

p.s also "littering" arbitrary directories with .attach files seems 
"rude" :)


On 3/4/24 9:38 PM, David Holmes wrote:
> Hi Sonia,
>
> Adding serviceability and Alan Bateman ...
>
> On 5/03/2024 2:35 am, Sonia Zaldana Calles wrote:
>> Hi folks,
>>
>>
>> I?m working on JDK-8324683 [0].
>>
>>
>> I?m hoping to unify the code for attachListener_<os>.cpp for posix 
>> platforms.
>>
>>
>> While reviewing linux against bsd, I noted a difference in 
>> AttachListener::is_init_trigger().
>>
>>
>> Both linux and AIX implementations, first try ?<current 
>> dir>/.attach<pid>? and failing that, attempt ?/tmp/.attach<pid>?.? 
>> [1][2]
>>
>>
>> On the other hand, bsd doesn?t attempt ?/tmp/.attach<pid>? [3].
>
> I think you meant it doesn't attempt <current dir>/.attach<pid>
>
>>
>> I have been trying to do a bit of digging to see if this disparity 
>> was intentional but I have found that this change precedes the MacOS 
>> port, so I?m having trouble coming to a conclusion.
>
> Looking at the history here:
>
> https://hg.openjdk.org/macosx-port/macosx-port/hotspot/log/407770c31c18/src/os/bsd/vm/attachListener_bsd.cpp 
>
>
> The very first load of the file did check the current directory too:
>
> https://hg.openjdk.org/macosx-port/macosx-port/hotspot/rev/be94a5de4d32
>
> but that was removed in the very next upload (though they never fixed 
> the comment preceding the code):
>
> https://hg.openjdk.org/macosx-port/macosx-port/hotspot/rev/9f1dd0b1d28c
>
> To know why you would have to ask the person that did it I'm afraid.
>
>> I was wondering if perhaps anyone on this list could shed some light 
>> on this matter and whether it would be acceptable to do the alternate 
>> path on BSD too.
>
> The init trigger mechanism was added by Alan under:
>
> https://bugs.openjdk.org/browse/JDK-6272307
>
> I get the sense that having the well-known file in the working 
> directory was actually a bit of an anachronism. That may be why the 
> macOS folk didn't bother with it (speculation on my part). AIX simply 
> copied the Linux code.
>
> Whether it would be okay/harmless/safe to have macOS/BSD also check 
> there I really can't say. I'm not sure if we have code that would ever 
> write the file to the target cwd these days? Hopefully Alan or current 
> serviceability folk can say more.
>
> Cheers,
> David
> -----
>
>>
>> Thanks for your help,
>>
>> Sonia
>>
>>
>>
>> [0] https://bugs.openjdk.org/browse/JDK-8324683 
>> <https://bugs.openjdk.org/browse/JDK-8324683>
>>
>> [1] 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/attachListener_linux.cpp#L521C3-L529C4 
>> <https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/attachListener_linux.cpp#L521C3-L529C4> 
>>
>>
>> [2] 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/attachListener_aix.cpp#L551C2-L559C4 
>> <https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/attachListener_aix.cpp#L551C2-L559C4> 
>>
>>
>> [3] 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/bsd/attachListener_bsd.cpp#L520C2-L522C4 
>> <https://github.com/openjdk/jdk/blob/master/src/hotspot/os/bsd/attachListener_bsd.cpp#L520C2-L522C4> 
>>
>>
>> -- 
>> Sonia Zalda?a Calles
>> Software Engineer, OpenJDK
>> Red Hat


From sspitsyn at openjdk.org  Tue Mar  5 19:43:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 19:43:46 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
In-Reply-To: <XFKK2BuGPbvZODuy1AcAGtvdXjPw7YSPlxac1THHeC8=.9e2af3b8-ade9-4aa9-a7ae-ab15a088225d@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <3YXFxQb_MUwpkmENa_qlqo8PybAiu4PtUEbRIA1bGRo=.4e6a7c95-4ecf-4332-ab40-118b035a27c1@github.com>
 <XFKK2BuGPbvZODuy1AcAGtvdXjPw7YSPlxac1THHeC8=.9e2af3b8-ade9-4aa9-a7ae-ab15a088225d@github.com>
Message-ID: <DfKlqtbSNPXBALbKl9tbfh799CIE7yTZ7wIOrkINHtE=.b84ea25e-8454-4bfe-939b-b000537209a1@github.com>

On Tue, 5 Mar 2024 18:16:03 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed a couple of comments on new test
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor/InterruptRawMonitor.java line 51:
> 
>> 49:         System.out.println(thread);
>> 50:         thread.start();
>> 51:         Thread.sleep(2000);
> 
> I think it would be better to check 'thread' status or the same monitor  to sync instead of sleep.  The sleep is always looks suspect, especially when intermittent failure happens. 
> Also, it helps to save 2 seconds.

Will implement this suggestion, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1513397834

From coleenp at openjdk.org  Tue Mar  5 19:50:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 5 Mar 2024 19:50:10 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
Message-ID: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>

This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.

Passes tier1-4.

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

Commit messages:
 - 8308745: ObjArrayKlass::allocate_objArray_klass may call into java while holding a lock

Changes: https://git.openjdk.org/jdk/pull/17739/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17739&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308745
  Stats: 167 lines in 11 files changed: 87 ins; 47 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/17739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17739/head:pull/17739

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

From coleenp at openjdk.org  Tue Mar  5 19:50:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 5 Mar 2024 19:50:10 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
Message-ID: <4txhdBn1XABNVZaKM87JCepatOS9Hf4DekJiTwazPL4=.2de6834f-dfdc-4342-a311-46a13071cf55@github.com>

On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
> 
> Passes tier1-4.

Thanks for looking at this WIP.

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

PR Review: https://git.openjdk.org/jdk/pull/17739#pullrequestreview-1876761135

From dholmes at openjdk.org  Tue Mar  5 19:50:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Mar 2024 19:50:10 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
Message-ID: <Yfq_3Ck_wSM-svTCqv07NDMNSTL1x7FzBWbdy7VHXc4=.f4feab82-b205-4392-80b9-58594c257542@github.com>

On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
> 
> Passes tier1-4.

src/hotspot/share/classfile/classLoaderData.cpp line 412:

> 410:   // To call this, one must have the MultiArray_lock held, but the _klasses list still has lock free reads.
> 411:   assert_locked_or_safepoint(MultiArray_lock);
> 412: 

Do we no longer hold the lock or are you just missing the API to assert it is held?

src/hotspot/share/oops/arrayKlass.cpp line 141:

> 139:           ObjArrayKlass::allocate_objArray_klass(class_loader_data(), dim + 1, this, CHECK_NULL);
> 140:       // use 'release' to pair with lock-free load
> 141:       release_set_higher_dimension(ak);

Why has this code changed? I only expected to see the lock changed.

src/hotspot/share/prims/jvmtiExport.cpp line 3151:

> 3149:   if (MultiArray_lock->owner() == thread) {
> 3150:     return false;
> 3151:   }

So the recursive nature of the lock now means we don't have to bail out here - right?

src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp line 107:

> 105:     // To get a consistent list of classes we need MultiArray_lock to ensure
> 106:     // array classes aren't created.
> 107:     MutexLocker ma(MultiArray_lock);

Unclear why this is no longer the case.

src/hotspot/share/runtime/recursiveLock.cpp line 45:

> 43:     _recursions++;
> 44:     assert(_recursions == 1, "should be");
> 45:     Atomic::release_store(&_owner, current); // necessary?

No release necessary. The only thing written since the sem.wait is recursions and it is only  updated or needed by the owning thread.

src/hotspot/share/runtime/recursiveLock.cpp line 54:

> 52:   _recursions--;
> 53:   if (_recursions == 0) {
> 54:     Atomic::release_store(&_owner, (Thread*)nullptr); // necessary?

No release necessary.

src/hotspot/share/runtime/recursiveLock.hpp line 33:

> 31: // There are also no checks that the recursive lock is not held when going to Java or to JNI, like
> 32: // other JVM mutexes have.  This should be used only for cases where the alternatives with all the
> 33: // nice safety features don't work.

Mention that it does interact with safepoints properly for JavaThreads

src/hotspot/share/runtime/recursiveLock.hpp line 45:

> 43:   void unlock(Thread* current);
> 44: };
> 45: 

Should expose a `holdsLock` method to allow use in assertions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1483613181
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1483614823
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1483623614
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1483624460
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1483608746
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1483609712
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1483610648
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1483612492

From coleenp at openjdk.org  Tue Mar  5 19:50:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 5 Mar 2024 19:50:11 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <Yfq_3Ck_wSM-svTCqv07NDMNSTL1x7FzBWbdy7VHXc4=.f4feab82-b205-4392-80b9-58594c257542@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <Yfq_3Ck_wSM-svTCqv07NDMNSTL1x7FzBWbdy7VHXc4=.f4feab82-b205-4392-80b9-58594c257542@github.com>
Message-ID: <Td6Vb-fKD4Plbvua_mqfz4LiNNiEy4YE0E9LAsEmqJk=.43f1bdfb-830f-489b-b69e-ad9fa32bb43e@github.com>

On Thu, 8 Feb 2024 21:30:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-4.
>
> src/hotspot/share/classfile/classLoaderData.cpp line 412:
> 
>> 410:   // To call this, one must have the MultiArray_lock held, but the _klasses list still has lock free reads.
>> 411:   assert_locked_or_safepoint(MultiArray_lock);
>> 412: 
> 
> Do we no longer hold the lock or are you just missing the API to assert it is held?

We no longer hold the lock in the callers to iterate through CLD::_klasses list.  It was never needed.  CLD::_klasses has iterators that are lock free (atomics)

> src/hotspot/share/oops/arrayKlass.cpp line 141:
> 
>> 139:           ObjArrayKlass::allocate_objArray_klass(class_loader_data(), dim + 1, this, CHECK_NULL);
>> 140:       // use 'release' to pair with lock-free load
>> 141:       release_set_higher_dimension(ak);
> 
> Why has this code changed? I only expected to see the lock changed.

The assert is dumb, leftover from when we didn't have C++ types (only klassOop).  Of course it's an objArrayKlass, that's its type!  The higher dimension should be set in the constructor of ObjArrayKlass.  Every version of this change, I move this assignment there.

> src/hotspot/share/prims/jvmtiExport.cpp line 3151:
> 
>> 3149:   if (MultiArray_lock->owner() == thread) {
>> 3150:     return false;
>> 3151:   }
> 
> So the recursive nature of the lock now means we don't have to bail out here - right?

Yes.  If it were only the JNI upcall that was broken while holding the MultiArray_lock, I think I could have used this same approach.  Unfortunately, its also throwing OOM for metaspace and for Java heap :(

> src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp line 107:
> 
>> 105:     // To get a consistent list of classes we need MultiArray_lock to ensure
>> 106:     // array classes aren't created.
>> 107:     MutexLocker ma(MultiArray_lock);
> 
> Unclear why this is no longer the case.

CLD::_klasses list is iterated through lock free with atomics. Older code used to iterate through the system dictionary which only had InstanceKlasses and then used to iterate through the arrays in InstanceKlass::_array_klasses.  Which required the MultiArray_lock protecting it.  There used to be an array_klasses_do() function.   Now all the klasses are in the CLD::_klasses list and traversed atomically.

> src/hotspot/share/runtime/recursiveLock.cpp line 45:
> 
>> 43:     _recursions++;
>> 44:     assert(_recursions == 1, "should be");
>> 45:     Atomic::release_store(&_owner, current); // necessary?
> 
> No release necessary. The only thing written since the sem.wait is recursions and it is only  updated or needed by the owning thread.

ok thanks.

> src/hotspot/share/runtime/recursiveLock.cpp line 54:
> 
>> 52:   _recursions--;
>> 53:   if (_recursions == 0) {
>> 54:     Atomic::release_store(&_owner, (Thread*)nullptr); // necessary?
> 
> No release necessary.

ok, thanks.

> src/hotspot/share/runtime/recursiveLock.hpp line 33:
> 
>> 31: // There are also no checks that the recursive lock is not held when going to Java or to JNI, like
>> 32: // other JVM mutexes have.  This should be used only for cases where the alternatives with all the
>> 33: // nice safety features don't work.
> 
> Mention that it does interact with safepoints properly for JavaThreads

Added a comment.

> src/hotspot/share/runtime/recursiveLock.hpp line 45:
> 
>> 43:   void unlock(Thread* current);
>> 44: };
>> 45: 
> 
> Should expose a `holdsLock` method to allow use in assertions.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1487056926
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1487058194
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1487060684
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1487062202
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1487063071
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1487063156
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1492431178
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1492430934

From coleenp at openjdk.org  Tue Mar  5 19:50:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 5 Mar 2024 19:50:11 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <Td6Vb-fKD4Plbvua_mqfz4LiNNiEy4YE0E9LAsEmqJk=.43f1bdfb-830f-489b-b69e-ad9fa32bb43e@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <Yfq_3Ck_wSM-svTCqv07NDMNSTL1x7FzBWbdy7VHXc4=.f4feab82-b205-4392-80b9-58594c257542@github.com>
 <Td6Vb-fKD4Plbvua_mqfz4LiNNiEy4YE0E9LAsEmqJk=.43f1bdfb-830f-489b-b69e-ad9fa32bb43e@github.com>
Message-ID: <2Z8YrflN2HIPhBO8JocpEQz6CEmjROczFOznVQbToeY=.3ba2e364-e48e-46ea-9db6-d9fe9725b553@github.com>

On Tue, 13 Feb 2024 02:07:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/arrayKlass.cpp line 141:
>> 
>>> 139:           ObjArrayKlass::allocate_objArray_klass(class_loader_data(), dim + 1, this, CHECK_NULL);
>>> 140:       // use 'release' to pair with lock-free load
>>> 141:       release_set_higher_dimension(ak);
>> 
>> Why has this code changed? I only expected to see the lock changed.
>
> The assert is dumb, leftover from when we didn't have C++ types (only klassOop).  Of course it's an objArrayKlass, that's its type!  The higher dimension should be set in the constructor of ObjArrayKlass.  Every version of this change, I move this assignment there.

Changing this like this makes it more similar to the InstanceKlass::array_klass function in structure, and there was unnecessary { } scopes in both and an unnecessary ResourceMark.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1487058776

From weijun at openjdk.org  Tue Mar  5 19:56:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 19:56:58 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@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:

  revert changes to MBeanServerFileAccessController.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/2b55b171..80810b54

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

  Stats: 14 lines in 1 file changed: 0 ins; 5 del; 9 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 Mar  5 19:56:58 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Mar 2024 19:56:58 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: <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
 <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
Message-ID: <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>

On Tue, 5 Mar 2024 16:49:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Do you know where the subject is set? If it's set by a `doAs` call then it will co-operate with `current()` no matter if SM is allowed. I tried to search in the whole module and cannot find a `doAs` call. If it is also through `SubjectDomainCombiner` then it only works with SM.
>
> Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
> 
> (That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
> https://github.com/openjdk/jdk/pull/18025 )
> 
> makeClient in RMIJRMPServerImpl creates RMIConnectionImpl
> 
> ..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.

I see that in `RMIConnectionImpl.java` it is stored inside an `AccessControlContext`, and there are `doPrivileged` calls on this ACC to pass the subject into an action. So, even if there might be no SM but the subject will never be bound to a thread using a scoped value.

I?ll revert the change then, and this code must have SM allowed to run correctly. If user runs it with SM disabled, at least they will see an UOE instead of letting `current()` silently returns a null.

Ultimately, if we want it working after SM, we should update `RMIConnectionImpl` and rewrite the ACC-related code to using `Subject.callAs`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1513410552

From sspitsyn at openjdk.org  Tue Mar  5 20:00:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 20:00:46 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
In-Reply-To: <GV2jDl4FfOu8UWRCY7PR3P2MzHUViygzQjEebJhvDX4=.c179ee19-a32d-4cc3-91a1-949532f2548b@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <3YXFxQb_MUwpkmENa_qlqo8PybAiu4PtUEbRIA1bGRo=.4e6a7c95-4ecf-4332-ab40-118b035a27c1@github.com>
 <GV2jDl4FfOu8UWRCY7PR3P2MzHUViygzQjEebJhvDX4=.c179ee19-a32d-4cc3-91a1-949532f2548b@github.com>
Message-ID: <8-kKWOygYShBAJ5oMVxcOdAYaY2CVqquGDOXJWJz8BI=.589e927a-3416-40ab-b645-c30626b7335d@github.com>

On Tue, 5 Mar 2024 07:07:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I have to say that I don't understand how the behaviour of `RawMonitorWait` is any different to `ObjectMonitor::wait` when it comes to the use of the is_interrupted(true). ??? Is it simply that because we are in native code and we can immediately query the actual thread state that we can observe when the carrier and virtual thread states are transiently different?

The behavior of `ObjectMonitor::wait` and `RawMonitorWait` is different.
The `Object.wait()` throws the `InterruptedException` if it was interrupted. The `RawMonitorWait` clears the thread `interrupt status` and returns the error code `JVMTI_ERROR_INTERRUPT`.

Also, I guess, Alan partially answered this question here:
> For `Object.wait`, the clearing of the interrupt status is done in the Java code, something that will change once `Object.wait` changes to `freeze/unmount` when not pinned.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1979528696

From sspitsyn at openjdk.org  Tue Mar  5 20:10:47 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Mar 2024 20:10:47 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
In-Reply-To: <lHnYhR5cyBiAszKsWv5BdoiyCAQdWpcmy3GFXd5t5QE=.4ba9f484-7313-481e-a350-efc3fe4fd934@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <fb0xFB6jgks98PRh-kF6xHjD6uq32FGI2yB-3KpWWng=.ad7fdecb-e6f8-4c2d-b508-fa8d1a23419c@github.com>
 <k59gvIaIwWwk9OKiW3zXlHGnL6aEh5vV-8toM3HoHfY=.94ea08d5-a331-47bd-8029-346cfa899c6a@github.com>
 <dQY31ZGVZM-qqb6PNCfshQ9yEckO6UlfAWa4dVvuM-k=.5b52964c-58df-4ae2-88e0-48cb83605707@github.com>
 <MpsiIacZsxFNcEoTdWLccaSyCxn1KDQG_5D9SaHseVY=.67808e96-e85f-4eac-a9ca-f59a9d441ba5@github.com>
 <3z2olsODWm-OpIbAWRm0R9GuEhEICKGXciavBJry-W8=.6df1c332-879b-41e1-b7d8-277e1c9475bd@github.com>
 <odJIrpk9yw5LuQ1tgR9ESe-tknC0lnAu0jSsglBxMQI=.7254fcd0-c13f-41b3-bebe-56e8c427bcd4@github.com>
 <V5kfSPLAdFGmcNXyZeikvrDMB43rDSrmxGXp3KY4KMI=.9d84a7f1-d2c1-41dd-a44d-d2db9e7816bd@github.com>
 <lHnYhR5cyBiAszKsWv5BdoiyCAQdWpcmy3GFXd5t5QE=.4ba9f484-7313-481e-a350-efc3fe4fd934@github.com>
Message-ID: <5XZnZvKTB4GVCrACy-CPOpO_PixnzVNRsoDr9v_55aQ=.06666eba-a19c-4813-944c-52f9478a214b@github.com>

On Tue, 5 Mar 2024 07:47:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thank you for sharing this, Chris. It sounds like we need to introduce a mechanism to temporarily hide the JVMTI events. The question is if it is worth the complexity we add with it, especially if it is used just in a couple of cases.
>
>> If we do it with a Java upcall to the `VirtualThread.getAndClearInterrupt()` then we also have to skip the JVMTI events, AFAIK, as it is not a good idea to post the JVMTI events recursively. 
> 
> I meant it would need to use ObjectLocker to hold the lock in the VM when changing both fields. It should only need to do this for RawMonitorWait at this time. For Object.wait, the clearing of the interrupt status is done in the Java code, something that will change once Object.wait changes to freeze/unmount when not pinned.

Got it. Thank you, Alan.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1513425638

From cjplummer at openjdk.org  Tue Mar  5 21:34:46 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 5 Mar 2024 21:34:46 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
In-Reply-To: <8-kKWOygYShBAJ5oMVxcOdAYaY2CVqquGDOXJWJz8BI=.589e927a-3416-40ab-b645-c30626b7335d@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <3YXFxQb_MUwpkmENa_qlqo8PybAiu4PtUEbRIA1bGRo=.4e6a7c95-4ecf-4332-ab40-118b035a27c1@github.com>
 <GV2jDl4FfOu8UWRCY7PR3P2MzHUViygzQjEebJhvDX4=.c179ee19-a32d-4cc3-91a1-949532f2548b@github.com>
 <8-kKWOygYShBAJ5oMVxcOdAYaY2CVqquGDOXJWJz8BI=.589e927a-3416-40ab-b645-c30626b7335d@github.com>
Message-ID: <stT-xm9Af3iCqCXzz5ZkrsZwKqEbu0sARSIinGwrOMU=.fc96644d-12d3-42ae-9027-e9c8617aecf9@github.com>

On Tue, 5 Mar 2024 19:57:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The Object.wait() throws the InterruptedException if it was interrupted.

And clears the interrupted status, just like RawMonitorWait.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1979670426

From cjplummer at openjdk.org  Tue Mar  5 22:08:47 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 5 Mar 2024 22:08:47 GMT
Subject: RFR: 8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves
 created files in the /tmp dir.
In-Reply-To: <zJ2jenxLcQAagSe2ERgxsv3VQL61GPxWCnWknPu8h2U=.91a52f6a-6a00-4e90-b040-3e49a297bc30@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
 <hO5-favvDtAGaGoDBZhzhlt8s2abZa4aqgiH9owWzsI=.6cc2c59d-bbfc-40d2-abfb-8718d64528e0@github.com>
 <UXY0mjYQExrFC4PlBATrSiMuwBW4M7OGKvdoUMz8pa4=.e4b2f08d-d9a4-467c-b784-0664bc717a9d@github.com>
 <O_9ZU4s62TAxdQx9AdHaYN9HkB4ssl6zTn-LI_3Ywrg=.a925e516-7aae-4fdf-8055-010fdb4945d8@github.com>
 <N0cnbFgnDU4zra3HUZsOA16drgF5zK-fEKOeOdyxrZs=.69971fe4-9848-4889-9c43-2aa73b576e73@github.com>
 <JWe1ya9HTdpRZ8V_xhVkfU_bO48oEXiHCfeUKBdd6uk=.60aafd0b-3fb9-45ff-83bd-80f487e9e266@github.com>
 <HD8mpLU8MkIrFi8TgPYBggPLC2vjCxrvobzuaOzCDME=.1db5364f-94de-4141-8b01-d5edd2ddccb4@github.com>
 <zJ2jenxLcQAagSe2ERgxsv3VQL61GPxWCnWknPu8h2U=.91a52f6a-6a00-4e90-b040-3e49a297bc30@github.com>
Message-ID: <dSxY4bYqHS6AaEMXrG4ezpN_9qdVGM4A0cz-iuXlkdw=.446764e5-b957-49ca-a8f5-4eca72184c1e@github.com>

On Tue, 5 Mar 2024 01:48:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi Jai. I think that solves all the functional requirements, but now we've turned two easily understood lines of code (calling run() and deleteIfExists()) into what you have above. I'm not so sure it is worth it. I refer back to Leonid's comment above on this topic:
>> 
>>> I thought about execution of Files.deleteIfExists(path) in the case of test fails, but decided that it is not so important. Also, test always might fail with crash when no finally block is executed. So I am fine with current way.
>
> Hello Chris,
>> Hi Jai. I think that solves all the functional requirements, but now we've turned two easily understood lines of code (calling run() and deleteIfExists()) into what you have above. 
> 
> I agree. 
> 
>> I'm not so sure it is worth it. I refer back to Leonid's comment above on this topic:
>> 
>> > I thought about execution of Files.deleteIfExists(path) in the case of test fails, but decided that it is not so important. Also, test always might fail with crash when no finally block is executed. So I am fine with current way.
> 
> What Leonid suggests looks fine to me and keeps things simple.

Ok. I think then I'll just push this PR in its current form.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17992#discussion_r1513556350

From cjplummer at openjdk.org  Tue Mar  5 22:09:50 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 5 Mar 2024 22:09:50 GMT
Subject: RFR: 8324868: debug agent does not properly handle interrupts of a
 virtual thread [v2]
In-Reply-To: <IoMgMfJeIP6Tp3qBqEVxuyAleMRBBsZpgKoybWrU7o4=.3b09572e-d731-4f91-91ce-9ad3fd4b86aa@github.com>
References: <VrbUMLScozKhqXew9izxE2JkM0hsos6_QcO0STXVGzk=.f5f1e451-57bc-498d-80c9-75a96d86e86a@github.com>
 <IoMgMfJeIP6Tp3qBqEVxuyAleMRBBsZpgKoybWrU7o4=.3b09572e-d731-4f91-91ce-9ad3fd4b86aa@github.com>
Message-ID: <iCIjijyxpqftpIE9htOrImbUikkDQVD02whIfntnL8U=.dea0110c-a891-4d82-b17b-c4937f6b747d@github.com>

On Wed, 28 Feb 2024 22:10:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fix numerous debug agent issues and testing deficiencies related to Thread.interrupt(). As a first read you should look at the description in the CR. More details in first comment below.
>> 
>> Also, this PR is dependent on the fix for [JDK-8325187](https://bugs.openjdk.org/browse/JDK-8325187). The test might generate GHA failures in the meantime.
>> 
>> Tested with all svc tier1, tier2, and tier5 tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feed back. fix up some comments.

Can I get a 2nd review please? Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/17989#issuecomment-1979718522

From dholmes at openjdk.org  Tue Mar  5 23:13:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Mar 2024 23:13:47 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
In-Reply-To: <8-kKWOygYShBAJ5oMVxcOdAYaY2CVqquGDOXJWJz8BI=.589e927a-3416-40ab-b645-c30626b7335d@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <3YXFxQb_MUwpkmENa_qlqo8PybAiu4PtUEbRIA1bGRo=.4e6a7c95-4ecf-4332-ab40-118b035a27c1@github.com>
 <GV2jDl4FfOu8UWRCY7PR3P2MzHUViygzQjEebJhvDX4=.c179ee19-a32d-4cc3-91a1-949532f2548b@github.com>
 <8-kKWOygYShBAJ5oMVxcOdAYaY2CVqquGDOXJWJz8BI=.589e927a-3416-40ab-b645-c30626b7335d@github.com>
Message-ID: <W--ojcR7QJ-3BT-vatSBStr0K0jQ5vYIysAe3u1HOd0=.10ac4468-ec34-4a08-bfe7-4b86c5dc0283@github.com>

On Tue, 5 Mar 2024 19:57:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The behavior of ObjectMonitor::wait and RawMonitorWait is different.
The Object.wait() throws the InterruptedException if it was interrupted. The RawMonitorWait clears the thread interrupt status and returns the error code JVMTI_ERROR_INTERRUPT.

That is not a significant/relevant difference as far as I can see. They both call `thread->is_interrupted(true)`.

> For Object.wait, the clearing of the interrupt status is done in the Java code, 

Okay so that is where the carrier and virtual thread states get back in sync, and that is what is missing in the `RawMonitorWait` case. The proposed fix/change to `is_interrupted` is what threw me as that is the wrong place to make a change because it affects both cases. What is missing is an upcall from `RawMonitorWait` to some Java code to do the same job as the `Object.wait` Java code does.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1979794228

From dlong at openjdk.org  Tue Mar  5 23:15:49 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 5 Mar 2024 23:15:49 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
Message-ID: <wFiNhfhX4_3TWDeBFcUCxoxx70-rqBOieNBD36mtL-4=.8709f464-cd31-4fc1-a4d3-8870692b5534@github.com>

On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
> 
> Passes tier1-7.

Is the caller always a JavaThread?  I'm wondering if your new recursive lock class could use the existing ObjectMonitor.  I thought David asked the same question, but I can't find it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17739#issuecomment-1979796523

From sspitsyn at openjdk.org  Wed Mar  6 00:40:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Mar 2024 00:40:52 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v6]
In-Reply-To: <EG5hOBRRFH50nYc9dO17Ngww9lxkmvT-YAVnkPnNhe4=.eaa607d1-4eb8-47ed-8b11-9246d078b222@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <twQAI4lvg-TCvx28XJNwiMkk2RagakH-GZQE-1Bl0_Q=.c6c9694f-0eda-4fb3-a395-16dce774ec03@github.com>
 <EG5hOBRRFH50nYc9dO17Ngww9lxkmvT-YAVnkPnNhe4=.eaa607d1-4eb8-47ed-8b11-9246d078b222@github.com>
Message-ID: <LiAIG66tltTZ7cl4w5tX8tLZdu8E_Fk_tI5qGkBhnlE=.478e3487-2ac7-429f-9604-e319b6d3f2b6@github.com>

On Tue, 5 Mar 2024 18:39:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: added new internal function JvmtiEnvBase::get_thread_or_vthread_state
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/waitingThreads/waitingthreads004a.java line 106:
> 
>> 104:                 display("entered and notifyAll: synchronized (lockingObject) {}");
>> 105:                 lockingObject.notifyAll();
>> 106: 
> 
> Please update test documentation in TestDescription. line:
>      - An object with threads waiting in Object.wait(long) method.
>  should be updated/or another one added.

Thanks, updated `TestDescription.java` now.

> test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/CurrentContendedMonitor/curcontmonitor001a.java line 88:
> 
>> 86:             // ensure that tested thread is waiting for monitor object
>> 87:             synchronized (TestedClass.thread.monitor) {
>> 88:                 TestedClass.thread.monitor.notifyAll();
> 
> You need to update test documentation in TestDescription.java to explicitly say that test not "waiting" but exit from wait and waiting for monitor (contended).

Thanks, updated `TestDescription.java` now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1513663234
PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1513663121

From sspitsyn at openjdk.org  Wed Mar  6 01:07:59 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Mar 2024 01:07:59 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v7]
In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
Message-ID: <iZjJBSJ9aNhRzF9nnCVtHjE7GmDaThettbURm0px9QY=.22184e8e-d260-4ee9-954f-51e4dc63952e@github.com>

> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
> 
> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
> 
> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
> 
> Testing:
>  - tested with the mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: updated test desciption for two modified tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17944/files
  - new: https://git.openjdk.org/jdk/pull/17944/files/9b69af50..289f6ff7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=05-06

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

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

From sspitsyn at openjdk.org  Wed Mar  6 06:28:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Mar 2024 06:28:01 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v3]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <RKVAkU2ufC11bSiV4JGSvLhI4n06z2DQlJ-njHtF12c=.36d86b6f-1ed1-49fc-9bb2-e55b63a3c1bd@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: improved sync in new test InterruptRawMonitor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/b365ede4..1e72452b

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

  Stats: 40 lines in 2 files changed: 20 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18093/head:pull/18093

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

From dholmes at openjdk.org  Wed Mar  6 07:00:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Mar 2024 07:00:48 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <wFiNhfhX4_3TWDeBFcUCxoxx70-rqBOieNBD36mtL-4=.8709f464-cd31-4fc1-a4d3-8870692b5534@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <wFiNhfhX4_3TWDeBFcUCxoxx70-rqBOieNBD36mtL-4=.8709f464-cd31-4fc1-a4d3-8870692b5534@github.com>
Message-ID: <SW-k3vvjhJVimVXX1Rb7KC0tpuQjvZQmLQJENmGcqvs=.0dbd94cc-c516-40be-bc11-6e38d8be0d8d@github.com>

On Tue, 5 Mar 2024 23:13:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>  I'm wondering if your new recursive lock class could use the existing ObjectMonitor.

There has been a drive to remove `ObjectLocker` from the C++ code due to the negative impact on Loom. Also not sure what existing `ObjectMonitor` you are referring to. ??

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

PR Comment: https://git.openjdk.org/jdk/pull/17739#issuecomment-1980207637

From sspitsyn at openjdk.org  Wed Mar  6 09:04:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Mar 2024 09:04:18 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v4]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <dO5UnCtsfQu2yiYC3RsMtqJFT-fjXWymYScFiDJQwms=.1a729713-461a-4427-a58b-c135dba53ee4@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: added ObjectLocker of interruptLock for sync

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/1e72452b..064d8225

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

  Stats: 35 lines in 3 files changed: 15 ins; 18 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18093/head:pull/18093

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

From sspitsyn at openjdk.org  Wed Mar  6 09:06:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Mar 2024 09:06:46 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v3]
In-Reply-To: <RKVAkU2ufC11bSiV4JGSvLhI4n06z2DQlJ-njHtF12c=.36d86b6f-1ed1-49fc-9bb2-e55b63a3c1bd@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <RKVAkU2ufC11bSiV4JGSvLhI4n06z2DQlJ-njHtF12c=.36d86b6f-1ed1-49fc-9bb2-e55b63a3c1bd@github.com>
Message-ID: <_rT9gNkxef1OovaFd7C-HZaXFQlwrR4uwBiVsM5JdGI=.0273bf40-14ac-45cb-b5f7-2057be8aea33@github.com>

On Wed, 6 Mar 2024 06:28:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: improved sync in new test InterruptRawMonitor

Added `ObjectLocker` of the `interruptLock` for sync to the `JavaThread::is_interrupted()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1980391743

From sspitsyn at openjdk.org  Wed Mar  6 09:14:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Mar 2024 09:14:18 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  removed trailing spaces in javaClasses.cpp and libInterruptRawMonitor.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/064d8225..b99fad54

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

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

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

From alanb at openjdk.org  Wed Mar  6 09:29:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 09:29:49 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
Message-ID: <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>

On Wed, 6 Mar 2024 09:14:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed trailing spaces in javaClasses.cpp and libInterruptRawMonitor.cpp

src/hotspot/share/runtime/javaThread.cpp line 573:

> 571: 
> 572:   Handle thread_h(current, vthread_or_thread());
> 573:   ObjectLocker lock(Handle(current, java_lang_Thread::interrupt_lock(thread_h())), current);

For this version then I assume you should limit it when its a virtual thread and when clear_interrupted is true.

Also need to think through if Object.wait will need to be changed as part of this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1514126817

From mbaesken at openjdk.org  Wed Mar  6 09:30:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Mar 2024 09:30:54 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
Message-ID: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>

We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

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

Commit messages:
 - JDK-8327444

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

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

From sspitsyn at openjdk.org  Wed Mar  6 09:38:09 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Mar 2024 09:38:09 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v6]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <x0sXzd913YGSqET1-vQctQVfJDN5im9-L6misnm702w=.55999aa7-6ac8-4ef2-bf71-fe7f422a6dbb@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  reordered JavaThread::is_interrupted code to use lock when needed only

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/b99fad54..2a483b6f

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

  Stats: 12 lines in 1 file changed: 8 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18093/head:pull/18093

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

From sspitsyn at openjdk.org  Wed Mar  6 09:38:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Mar 2024 09:38:10 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
 <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>
Message-ID: <_pbD7dEcZ0wjCfut2WEz5az3y11jhazNQp_8Ekje-Wg=.67400067-5142-49f0-bcfa-f40f77f6fe1c@github.com>

On Wed, 6 Mar 2024 09:27:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed trailing spaces in javaClasses.cpp and libInterruptRawMonitor.cpp
>
> src/hotspot/share/runtime/javaThread.cpp line 573:
> 
>> 571: 
>> 572:   Handle thread_h(current, vthread_or_thread());
>> 573:   ObjectLocker lock(Handle(current, java_lang_Thread::interrupt_lock(thread_h())), current);
> 
> For this version then I assume you should limit it when its a virtual thread and when clear_interrupted is true.
> 
> Also need to think through if Object.wait will need to be changed as part of this.

Thanks, I'm already working on it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1514137662

From sspitsyn at openjdk.org  Wed Mar  6 10:44:15 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Mar 2024 10:44:15 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v7]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <k5owBPcnzaYY2iH8zUGANmzDOSY0XZs8-Rgj0Q2Nf9k=.dac4df23-5ea1-4d19-abf2-67cd35b88e07@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  optimize holding the interruptLock in JavaThread::is_interrupted

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/2a483b6f..db3149dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=05-06

  Stats: 34 lines in 1 file changed: 26 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18093/head:pull/18093

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

From sspitsyn at openjdk.org  Wed Mar  6 10:44:16 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Mar 2024 10:44:16 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <_pbD7dEcZ0wjCfut2WEz5az3y11jhazNQp_8Ekje-Wg=.67400067-5142-49f0-bcfa-f40f77f6fe1c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
 <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>
 <_pbD7dEcZ0wjCfut2WEz5az3y11jhazNQp_8Ekje-Wg=.67400067-5142-49f0-bcfa-f40f77f6fe1c@github.com>
Message-ID: <Kcx6SoNcp1C3-GTk8hHhLVWshuHKM9TRE5DN62_Zgeo=.4167311f-0f85-4424-9b77-d152ed43726f@github.com>

On Wed, 6 Mar 2024 09:34:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 573:
>> 
>>> 571: 
>>> 572:   Handle thread_h(current, vthread_or_thread());
>>> 573:   ObjectLocker lock(Handle(current, java_lang_Thread::interrupt_lock(thread_h())), current);
>> 
>> For this version then I assume you should limit it when its a virtual thread and when clear_interrupted is true.
>> 
>> Also need to think through if Object.wait will need to be changed as part of this.
>
> Thanks, I'm already working on it.

Fixed as suggested by Alan.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1514240306

From gli at openjdk.org  Wed Mar  6 11:00:45 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 6 Mar 2024 11:00:45 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <CEkugr_uiWOQVlTh-FSsLj6fdUX5OYfruGxJYRgSGJA=.9dcff5f4-f18d-454f-8bfd-ee6c2785780d@github.com>

On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

Looks good. Nice refactor.

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

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1919422137

From kevinw at openjdk.org  Wed Mar  6 11:42:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Mar 2024 11:42:18 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v4]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <qEdJCGr1AJ87uEfYrRMVws2D-H1_2CNMhTLKdjt-HuQ=.678ceb67-61fd-419f-8425-39cc318f1483@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  Test that SubjectDelegation is refused.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/c607b69a..19ace691

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

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

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

From kevinw at openjdk.org  Wed Mar  6 11:46:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Mar 2024 11:46:16 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v4]
In-Reply-To: <qEdJCGr1AJ87uEfYrRMVws2D-H1_2CNMhTLKdjt-HuQ=.678ceb67-61fd-419f-8425-39cc318f1483@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <qEdJCGr1AJ87uEfYrRMVws2D-H1_2CNMhTLKdjt-HuQ=.678ceb67-61fd-419f-8425-39cc318f1483@github.com>
Message-ID: <mM7_KUEuTf9wJBwCPIrHOCAE9u1iaT1QqxM7-xLICKQ=.68403f6d-2669-4a75-8c67-0ce0ae9faf14@github.com>

On Wed, 6 Mar 2024 11:42:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test that SubjectDelegation is refused.

Added a test to ensure  jmxc.getMBeanServerConnection(delegationSubject) throws UnsupportedOperationException.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1980688614

From kevinw at openjdk.org  Wed Mar  6 11:46:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Mar 2024 11:46:16 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v5]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  Test specifically that UOE is thrown.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/19ace691..c5256c3f

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

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

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

From kevinw at openjdk.org  Wed Mar  6 12:29:47 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 6 Mar 2024 12:29:47 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v7]
In-Reply-To: <cwk2OYW86sV22aA4SGRbGHiYv8_Xtcn8pqhMbJXumgk=.195513d1-0500-4710-865e-7d8cc76ad1da@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <cwk2OYW86sV22aA4SGRbGHiYv8_Xtcn8pqhMbJXumgk=.195513d1-0500-4710-865e-7d8cc76ad1da@github.com>
Message-ID: <RK_OFLjdFKuWy7lGt-Dr77GiQZQ03MskVkzPSH-3xy0=.a5915ae8-8e5d-46d8-9e52-7b49b8594ce5@github.com>

On Tue, 5 Mar 2024 11:31:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>> 
>> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Hi,

> once you start poking at the JVM innards at this level, I guess you will be quickly at the limit of what this command can do for you and need to attach a debugger anyway.

I think we all expect a collection of features in the toolbox.  This jcmd will not remove the need for a native debugger.  I do think that the JVM should be in charge of decoding its own internals, and the built-in tools that do that should be more accessible.


> Could this be an own command, e,g, VM.inspect, and possibly limited to debug VMs? 

Yes, could be VM.find or VM.inspect.  I liked the grouping into VM.debug, they have some common features:

a conceptual group, tools that you might want to call alongside another debugger
origins in debug.cpp utils (which are still there)
"debug" label may discourage casual users from experimenting
require UnlockDiagnosticVMOptions common

..but I'm not emotionally connected to the name or the group.  I appreciate the feedback.

As noted, there is no rule for jcmd grouping.  VM.info yes is an example that doesn't fit one particular category, find/inspect is certainly another.

(If you find existing jcmds a mess, feel free to suggest changes as appropriate.)


> Do we really need this feature in production?

Yes I am saying this should be in all builds.  It's not only debug builds that people debug, or reproduce problems with. 


> Don't we have jhsdb for that? [core file/minidump handling]

We have jhsdb and the SA tools in general.  These have ongoing maintenance issues, the game of catch up as the VM changes is not solved.  We need to have options.  I will find a different place to propose that alternative in detail.


I'll wait and see if there's any other input on the naming... 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1980761622

From stuefe at openjdk.org  Wed Mar  6 12:56:47 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 6 Mar 2024 12:56:47 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v7]
In-Reply-To: <cwk2OYW86sV22aA4SGRbGHiYv8_Xtcn8pqhMbJXumgk=.195513d1-0500-4710-865e-7d8cc76ad1da@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <cwk2OYW86sV22aA4SGRbGHiYv8_Xtcn8pqhMbJXumgk=.195513d1-0500-4710-865e-7d8cc76ad1da@github.com>
Message-ID: <pMJYDt9EMbLbWUYrRBbeqcC4-4b38XOC0DymhZb9ByE=.c75ab172-58dc-4bcc-93c8-307255bc0254@github.com>

On Tue, 5 Mar 2024 11:31:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>> 
>> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Hi Kevin,

> 
> (If you find existing jcmds a mess, feel free to suggest changes as appropriate.)

you touch on a problem here, and why I think adding commands should be done more carefully (and I am guilty of adding commands too). 

Once these commands are rolled out, they find themselves in blogs, knowledge bases, scripts that are reused for different JDK releases, and so on. It is difficult to change them post-release. That is why good names are important.

Cheers, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-1980807020

From coleenp at openjdk.org  Wed Mar  6 13:01:50 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Mar 2024 13:01:50 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <wFiNhfhX4_3TWDeBFcUCxoxx70-rqBOieNBD36mtL-4=.8709f464-cd31-4fc1-a4d3-8870692b5534@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <wFiNhfhX4_3TWDeBFcUCxoxx70-rqBOieNBD36mtL-4=.8709f464-cd31-4fc1-a4d3-8870692b5534@github.com>
Message-ID: <f3pkIbhxDmvSuue2fzZVZzkxb0hHrRYXLQ4vVD1EiIU=.d01f8c7a-8a15-41f1-92c3-36cebc992718@github.com>

On Tue, 5 Mar 2024 23:13:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> Is the caller always a JavaThread?  I'm wondering if your new recursive lock class could use the existing ObjectMonitor.  I thought David asked the same question, but I can't find it.

@dean-long An ObjectLocker on the mirror oop for InstanceKlass might work for this but as @dholmes-ora said we've been trying to purge the ObjectLocker code from the C++ code because it's complicated by the Java Object monitor project.  The JOM project may throw exceptions from the ObjectLocker constructor or destructor and the C++ code doesn't currently know what to do.  We removed the ObjectLockers around class linking and some JVMTI cases.  There are some in class loading but with a small amount of work, they can be removed also. 

The caller is always a JavaThread, some lockers are at a safepoint for traversal but the multi-arrays are only created by JavaThreads.

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

PR Comment: https://git.openjdk.org/jdk/pull/17739#issuecomment-1980812019

From alanb at openjdk.org  Wed Mar  6 14:15:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 14:15:48 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>

On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

src/java.base/share/native/libjava/jni_util.h line 243:

> 241:   } while((_result == -1) && (errno == EINTR)); \
> 242: } while(0)
> 243: 

jni_util.h is for all platforms so not the right place for a Unix specific macro. We need think where the right place for this, might have to introduce a jni_util_md.h.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514555111

From mbaesken at openjdk.org  Wed Mar  6 14:27:48 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Mar 2024 14:27:48 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
In-Reply-To: <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>
Message-ID: <KQDgT3k0z72vniisOS6gizowgL0CrDnQXjRKxXoqyZI=.296a6952-f7c2-45fb-b3aa-491b9218830a@github.com>

On Wed, 6 Mar 2024 14:13:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> src/java.base/share/native/libjava/jni_util.h line 243:
> 
>> 241:   } while((_result == -1) && (errno == EINTR)); \
>> 242: } while(0)
>> 243: 
> 
> jni_util.h is for all platforms so not the right place for a Unix specific macro. We need think where the right place for this, might have to introduce a jni_util_md.h.

We could maybe also use the existing  https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h  - what do you think ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514574059

From alanb at openjdk.org  Wed Mar  6 14:35:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 14:35:46 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
In-Reply-To: <KQDgT3k0z72vniisOS6gizowgL0CrDnQXjRKxXoqyZI=.296a6952-f7c2-45fb-b3aa-491b9218830a@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <Ebeo7DMUdrRf6UH0n-Cim7NAsIkJoHvXzckFY-SXnZ0=.54393b54-c000-4559-b9dd-234814e33605@github.com>
 <KQDgT3k0z72vniisOS6gizowgL0CrDnQXjRKxXoqyZI=.296a6952-f7c2-45fb-b3aa-491b9218830a@github.com>
Message-ID: <BVmjS3qMP7guv_LjBz9fvwLS6JAmt2GX_00IGe-_7-w=.3b422e7b-1d0a-4ff7-9e4f-eae6879e44b2@github.com>

On Wed, 6 Mar 2024 14:25:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We could maybe also use the existing https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h - what do you think ?

jni_md.h goes into the JDK run-time image (for jni.h to include) so I don't think we should be changing that.  jni_util.* is JDK internal so I think we're just missing a platform dependent include file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514586726

From mbaesken at openjdk.org  Wed Mar  6 15:45:16 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Mar 2024 15:45:16 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v2]
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

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

  introduce unix jni_util_md.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18132/files
  - new: https://git.openjdk.org/jdk/pull/18132/files/014ab1fd..f30a189d

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

  Stats: 68 lines in 19 files changed: 52 ins; 7 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18132/head:pull/18132

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

From alanb at openjdk.org  Wed Mar  6 15:51:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 15:51:46 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v2]
In-Reply-To: <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>
Message-ID: <gbcvNHbdZIZURVYAL-Ee04PxjM2jQSXNSJF7Wharufc=.407fd08e-ebc5-4571-aca4-b4dc32bda90d@github.com>

On Wed, 6 Mar 2024 15:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   introduce unix jni_util_md.h

src/java.base/aix/native/libnio/ch/Pollset.c line 29:

> 27: #include "jni.h"
> 28: #include "jni_util.h"
> 29: #include "jni_util_md.h"

When I suggested jni_util_md.h then I meant create one for Unix and another for Windows, then have jni_util.h include it. This will avoid needing to add an include to all these files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514724921

From mbaesken at openjdk.org  Wed Mar  6 16:08:45 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Mar 2024 16:08:45 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v2]
In-Reply-To: <gbcvNHbdZIZURVYAL-Ee04PxjM2jQSXNSJF7Wharufc=.407fd08e-ebc5-4571-aca4-b4dc32bda90d@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <MIlY_vcnlexjQPyj-3QebzJFNVwuW4VqOXUfByIelsQ=.797ed305-e37b-4b49-a317-abc68a85e155@github.com>
 <gbcvNHbdZIZURVYAL-Ee04PxjM2jQSXNSJF7Wharufc=.407fd08e-ebc5-4571-aca4-b4dc32bda90d@github.com>
Message-ID: <k8YDbMN1Y1cM_HIgm6gqsdDDDXXQEgSDDWd98ZfhjEk=.869ed36b-dcd5-477c-9e96-db6aa1817ed5@github.com>

On Wed, 6 Mar 2024 15:49:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   introduce unix jni_util_md.h
>
> src/java.base/aix/native/libnio/ch/Pollset.c line 29:
> 
>> 27: #include "jni.h"
>> 28: #include "jni_util.h"
>> 29: #include "jni_util_md.h"
> 
> When I suggested jni_util_md.h then I meant create one for Unix and another for Windows, then have jni_util.h include it. This will avoid needing to add an include to all these files.

I considered this too,  but the one on Windows would be empty for now -> looks a bit strange . But I can do it why not .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514752727

From mbaesken at openjdk.org  Wed Mar  6 16:30:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Mar 2024 16:30:23 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

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

  Introduce windows jni_util_md.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18132/files
  - new: https://git.openjdk.org/jdk/pull/18132/files/f30a189d..2930075d

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

  Stats: 24 lines in 19 files changed: 1 ins; 22 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18132/head:pull/18132

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

From clanger at openjdk.org  Wed Mar  6 17:21:50 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 6 Mar 2024 17:21:50 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce windows jni_util_md.h

Looks good to me modulo a few license year things...

src/java.base/macosx/native/libnio/ch/KQueue.c line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved.

Here you only change the license year?

src/java.base/share/native/libjava/jni_util.h line 30:

> 28: 
> 29: #include "jni.h"
> 30: #include "jni_util_md.h"

This file needs copyright year update

src/java.base/unix/native/libjava/childproc.h line 75:

> 73: #define FAIL_FILENO (STDERR_FILENO + 1)
> 74: 
> 75: /* TODO: Refactor. */

Copyright year update missing.

src/java.base/unix/native/libnio/ch/nio_util.h line 34:

> 32: #include <sys/un.h>
> 33: 
> 34: #define RESTARTABLE(_cmd, _result) do { \

Copyright year update

src/java.base/unix/native/libnio/fs/UnixFileSystem.c line 38:

> 36: #include "sun_nio_fs_UnixFileSystem.h"
> 37: 
> 38: #define RESTARTABLE(_cmd, _result) do { \

Copyright year update

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

Changes requested by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1920355323
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514867262
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514873505
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514876266
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514878580
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1514878995

From alanb at openjdk.org  Wed Mar  6 18:59:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Mar 2024 18:59:46 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v7]
In-Reply-To: <k5owBPcnzaYY2iH8zUGANmzDOSY0XZs8-Rgj0Q2Nf9k=.dac4df23-5ea1-4d19-abf2-67cd35b88e07@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <k5owBPcnzaYY2iH8zUGANmzDOSY0XZs8-Rgj0Q2Nf9k=.dac4df23-5ea1-4d19-abf2-67cd35b88e07@github.com>
Message-ID: <s8kqxrFlw5VsufQf3BH1_9lxwjB52RIRwn7DxtZY6Nk=.4b0a4d20-f31b-4c73-b3cf-957708d48d07@github.com>

On Wed, 6 Mar 2024 10:44:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize holding the interruptLock in JavaThread::is_interrupted

I think the updated implementation looks right. I think you can drop the catch of InterruptedException in Object.wait now. Easy to check this by running test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java as it has tests for interrupting Object.wait.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1981574037

From dlong at openjdk.org  Wed Mar  6 23:11:55 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Mar 2024 23:11:55 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
Message-ID: <RAMKzBgWvs2JTW_joTMEuOvHWx3k6MhJ9gNcJG9HuN8=.a360e552-2cd9-4a98-acc4-29e8e642b0d1@github.com>

On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
> 
> Passes tier1-7.

OK, that makes sense about loom and JOM.

src/hotspot/share/runtime/mutex.cpp line 537:

> 535:     // can be called by jvmti by VMThread.
> 536:     if (current->is_Java_thread()) {
> 537:       _sem.wait_with_safepoint_check(JavaThread::cast(current));

Why not use PlatformMutex + OSThreadWaitState instead of a semaphore?

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

PR Comment: https://git.openjdk.org/jdk/pull/17739#issuecomment-1982008253
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515269443

From bpb at openjdk.org  Wed Mar  6 23:17:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Mar 2024 23:17:56 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <fhQS5gSfJY97afRfza4rCgMmYn5PgFCn5R-0kzh9cEw=.940f0924-03be-49f0-878f-d2724c164e59@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce windows jni_util_md.h

src/java.base/unix/native/libnio/ch/Net.c line 2:

> 1: /*
> 2:  * Copyright (c) 2001, 2024, Oracle and/or its affiliates. All rights reserved.

Is the year change needed as it looks like nothing was changed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515273416

From coleenp at openjdk.org  Wed Mar  6 23:49:54 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Mar 2024 23:49:54 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <RAMKzBgWvs2JTW_joTMEuOvHWx3k6MhJ9gNcJG9HuN8=.a360e552-2cd9-4a98-acc4-29e8e642b0d1@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <RAMKzBgWvs2JTW_joTMEuOvHWx3k6MhJ9gNcJG9HuN8=.a360e552-2cd9-4a98-acc4-29e8e642b0d1@github.com>
Message-ID: <NZxFuFl_4enns4p0Ww_0ZB8jBEPD2JzCdZlV2wjVfvE=.1be4405a-587b-43aa-88d6-91f67dce1491@github.com>

On Wed, 6 Mar 2024 23:09:34 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> src/hotspot/share/runtime/mutex.cpp line 537:
> 
>> 535:     // can be called by jvmti by VMThread.
>> 536:     if (current->is_Java_thread()) {
>> 537:       _sem.wait_with_safepoint_check(JavaThread::cast(current));
> 
> Why not use PlatformMutex + OSThreadWaitState instead of a semaphore?

Semaphore seemed simpler (?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515294583

From cjplummer at openjdk.org  Thu Mar  7 00:04:56 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 7 Mar 2024 00:04:56 GMT
Subject: Integrated: 8325532: serviceability/dcmd/compiler/PerfMapTest.java
 leaves created files in the /tmp dir.
In-Reply-To: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
References: <wrSc1inqco8gtbq6Cf0Dl3evCOBS_FGzzJaeHGMFu6w=.0f9b3c4f-10cb-44c0-bb58-542e490098eb@github.com>
Message-ID: <Ss6rK9KeNBItr6E6JZD39Sj1sBYR9Ea0SGSXGGSzbfc=.6cfdb718-a1ca-4097-9e02-5de4ed563fdc@github.com>

On Fri, 23 Feb 2024 21:55:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> PerfMapTest.java issues the Compiler.perfmap jcmd with a filename argument to write the perfmap to. It does this in 3 different modes. 2 of the modes result in a perfmap file being left in the tmp directory that is not removed after the test executes (and should be removed). The 3rd mode creates the perfmap file in the directory specified by the test.dir property, and is ok to leave the file there. I've added code to delete the /tmp files that are created.
> 
> I did a bit of extra testing by hand. I created `/tmp/perf-<pid>.map` as root. As expected the Files.deleteIfExists() call threw an exception due to the lack of permissions to delete the file. However, I then realized the file had a size of 0, which means the test was not even doing a proper job of testing that the perfrmap jcmd was working. In other words, the test should have failed long before getting to the Files.deleteIfExists(), so I added a size check to make sure it fails when the file is not written to.

This pull request has now been integrated.

Changeset: ddcd6dec
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ddcd6dece9ef9c8700bc3f8f5dc7a5405fe55a70
Stats:     11 lines in 1 file changed: 8 ins; 0 del; 3 mod

8325532: serviceability/dcmd/compiler/PerfMapTest.java leaves created files in the /tmp dir.

Reviewed-by: amenkov, kevinw, lmesnik, sspitsyn

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

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

From sspitsyn at openjdk.org  Thu Mar  7 00:13:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Mar 2024 00:13:56 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v8]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <Da0Ld-qa1oBc_gZndo3Duo6B36IwNejZ7OCyKM2Tzh4=.cec564fa-fed1-4a79-9c19-aa6e92fd2368@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: dropped the catch of InterruptedException in Object.wait

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/db3149dc..923a3ff5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=06-07

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

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

From sspitsyn at openjdk.org  Thu Mar  7 00:13:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Mar 2024 00:13:57 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v7]
In-Reply-To: <s8kqxrFlw5VsufQf3BH1_9lxwjB52RIRwn7DxtZY6Nk=.4b0a4d20-f31b-4c73-b3cf-957708d48d07@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <k5owBPcnzaYY2iH8zUGANmzDOSY0XZs8-Rgj0Q2Nf9k=.dac4df23-5ea1-4d19-abf2-67cd35b88e07@github.com>
 <s8kqxrFlw5VsufQf3BH1_9lxwjB52RIRwn7DxtZY6Nk=.4b0a4d20-f31b-4c73-b3cf-957708d48d07@github.com>
Message-ID: <pUH8XVZ3NgBjGpbktZFQ6hH4Q00R3c6ZEsCBINm_ZHs=.dbaca8df-887b-4459-b565-d0c579d69050@github.com>

On Wed, 6 Mar 2024 18:56:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think you can drop the catch of InterruptedException in Object.wait now. Easy to check this by running test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java as it has tests for interrupting Object.wait.

Thanks. Fixed now. Tested with the `test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1982080510

From dlong at openjdk.org  Thu Mar  7 00:18:56 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 7 Mar 2024 00:18:56 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <NZxFuFl_4enns4p0Ww_0ZB8jBEPD2JzCdZlV2wjVfvE=.1be4405a-587b-43aa-88d6-91f67dce1491@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <RAMKzBgWvs2JTW_joTMEuOvHWx3k6MhJ9gNcJG9HuN8=.a360e552-2cd9-4a98-acc4-29e8e642b0d1@github.com>
 <NZxFuFl_4enns4p0Ww_0ZB8jBEPD2JzCdZlV2wjVfvE=.1be4405a-587b-43aa-88d6-91f67dce1491@github.com>
Message-ID: <cPiOcc2Q37gzF8mwASvpHu7gOTZ5moH_i45pMlrqYk4=.b90c9a52-f42e-48c0-bbfe-788c69e4d520@github.com>

On Wed, 6 Mar 2024 23:47:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutex.cpp line 537:
>> 
>>> 535:     // can be called by jvmti by VMThread.
>>> 536:     if (current->is_Java_thread()) {
>>> 537:       _sem.wait_with_safepoint_check(JavaThread::cast(current));
>> 
>> Why not use PlatformMutex + OSThreadWaitState instead of a semaphore?
>
> Semaphore seemed simpler (?)

OK.  It's a good thing HotSpot doesn't need to worry about priority-inheritance for mutexes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515314037

From dlong at openjdk.org  Thu Mar  7 00:22:56 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 7 Mar 2024 00:22:56 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
Message-ID: <gK1NN7KhU2qWw6C6jA0IJTeMkF7IoopVEGr4hZnzecs=.a100c018-63eb-4ee1-afb5-08a5222a0748@github.com>

On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
> 
> Passes tier1-7.

src/hotspot/share/oops/arrayKlass.cpp line 135:

> 133:     ResourceMark rm(THREAD);
> 134:     {
> 135:       // Ensure atomic creation of higher dimensions

Isn't this comment still useful?

src/hotspot/share/oops/arrayKlass.cpp line 144:

> 142:         ObjArrayKlass* ak =
> 143:           ObjArrayKlass::allocate_objArray_klass(class_loader_data(), dim + 1, this, CHECK_NULL);
> 144:         ak->set_lower_dimension(this);

Would it be useful to assert that the lower dimension has been set?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515322667
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515323404

From sspitsyn at openjdk.org  Thu Mar  7 00:29:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Mar 2024 00:29:53 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v2]
In-Reply-To: <W--ojcR7QJ-3BT-vatSBStr0K0jQ5vYIysAe3u1HOd0=.10ac4468-ec34-4a08-bfe7-4b86c5dc0283@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <3YXFxQb_MUwpkmENa_qlqo8PybAiu4PtUEbRIA1bGRo=.4e6a7c95-4ecf-4332-ab40-118b035a27c1@github.com>
 <GV2jDl4FfOu8UWRCY7PR3P2MzHUViygzQjEebJhvDX4=.c179ee19-a32d-4cc3-91a1-949532f2548b@github.com>
 <8-kKWOygYShBAJ5oMVxcOdAYaY2CVqquGDOXJWJz8BI=.589e927a-3416-40ab-b645-c30626b7335d@github.com>
 <W--ojcR7QJ-3BT-vatSBStr0K0jQ5vYIysAe3u1HOd0=.10ac4468-ec34-4a08-bfe7-4b86c5dc0283@github.com>
Message-ID: <eV_SyRkVFyz6_gKdOw6B1Y-5wP1hrzS6OMVv_qMd_rw=.c2b0b941-ed67-4fcb-b38c-3eab8233374e@github.com>

On Tue, 5 Mar 2024 23:11:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay so that is where the carrier and virtual thread states get back in sync, and that is what is missing in the `RawMonitorWait` case. The proposed fix/change to `is_interrupted` is what threw me as that is the wrong place to make a change because it affects both cases. What is missing is an upcall from `RawMonitorWait` to some Java code to do the same job as the `Object.wait` Java code does.

There was a duplication in the `Object.wait` which has been just removed.
Please, see the incremental update 07: [Full](https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=07) - [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=06-07) ([923a3ff5](https://git.openjdk.org/jdk/pull/18093/files/923a3ff580cfc4d0a68775e5f849b63c691b8eb3)).
Now, both `Object.wait` and `RawMonitorWait` clear the interrupt status with the `JavaThread::is_interrupted()` only.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1982105087

From dlong at openjdk.org  Thu Mar  7 00:34:57 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 7 Mar 2024 00:34:57 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
Message-ID: <PhO7c_K0l1KCTPrHw8YGi2VVNhySlk7VFEsRAgjFTLM=.82dc67b3-646b-4fab-bcb6-79f9833bf512@github.com>

On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
> 
> Passes tier1-7.

src/hotspot/share/oops/instanceKlass.cpp line 2765:

> 2763:     // To get a consistent list of classes we need MultiArray_lock to ensure
> 2764:     // array classes aren't observed while they are being restored.
> 2765:     MutexLocker ml(MultiArray_lock);

Doesn't this revert JDK-8274338?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515330292

From dlong at openjdk.org  Thu Mar  7 00:39:56 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 7 Mar 2024 00:39:56 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
Message-ID: <7p3I5oGNwzuUK3dMUapit_wKX3uMQo3H9FxGzEAiaOQ=.c9b2f9c5-d473-42ee-bb63-9de3f37515d3@github.com>

On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
> 
> Passes tier1-7.

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17739#pullrequestreview-1921100707

From dholmes at openjdk.org  Thu Mar  7 00:56:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Mar 2024 00:56:55 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <cPiOcc2Q37gzF8mwASvpHu7gOTZ5moH_i45pMlrqYk4=.b90c9a52-f42e-48c0-bbfe-788c69e4d520@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <RAMKzBgWvs2JTW_joTMEuOvHWx3k6MhJ9gNcJG9HuN8=.a360e552-2cd9-4a98-acc4-29e8e642b0d1@github.com>
 <NZxFuFl_4enns4p0Ww_0ZB8jBEPD2JzCdZlV2wjVfvE=.1be4405a-587b-43aa-88d6-91f67dce1491@github.com>
 <cPiOcc2Q37gzF8mwASvpHu7gOTZ5moH_i45pMlrqYk4=.b90c9a52-f42e-48c0-bbfe-788c69e4d520@github.com>
Message-ID: <jzf_9tWx8SbLUycXupdxMiy9sqoL_k9bPSzM8K8s2Lo=.3643dd28-8c0a-4baa-ae3e-a654a287162c@github.com>

On Thu, 7 Mar 2024 00:16:39 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Semaphore seemed simpler (?)
>
> OK.  It's a good thing HotSpot doesn't need to worry about priority-inheritance for mutexes.

Semaphore seems simpler/cleaner and ready to use.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515343108

From coleenp at openjdk.org  Thu Mar  7 01:38:56 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Mar 2024 01:38:56 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v2]
In-Reply-To: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
Message-ID: <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>

> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
> 
> Passes tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Dean's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17739/files
  - new: https://git.openjdk.org/jdk/pull/17739/files/3625e6cc..d64aa560

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

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

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

From coleenp at openjdk.org  Thu Mar  7 01:38:57 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Mar 2024 01:38:57 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v2]
In-Reply-To: <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
Message-ID: <jN-LrTYTVJiC0wg-PY1mnQLEUg2huh14XciWTT9T9ZQ=.afbf8393-8ecb-4b67-ab4b-1b2f706c2041@github.com>

On Thu, 7 Mar 2024 01:35:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dean's comments.

Thanks for your review Dean.  I've retested tier1 with the changes and will send it for more.  Thank you for finding the CDS bug in my change.

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

PR Review: https://git.openjdk.org/jdk/pull/17739#pullrequestreview-1921122133

From coleenp at openjdk.org  Thu Mar  7 01:38:58 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Mar 2024 01:38:58 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v2]
In-Reply-To: <gK1NN7KhU2qWw6C6jA0IJTeMkF7IoopVEGr4hZnzecs=.a100c018-63eb-4ee1-afb5-08a5222a0748@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <gK1NN7KhU2qWw6C6jA0IJTeMkF7IoopVEGr4hZnzecs=.a100c018-63eb-4ee1-afb5-08a5222a0748@github.com>
Message-ID: <lfW4bfV3fkCoRcNkzbhkOxICEXmUljKhtLeTegD4x8I=.f4cbc162-e7f2-4521-bdcd-228b4ba1fa15@github.com>

On Thu, 7 Mar 2024 00:18:53 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dean's comments.
>
> src/hotspot/share/oops/arrayKlass.cpp line 135:
> 
>> 133:     ResourceMark rm(THREAD);
>> 134:     {
>> 135:       // Ensure atomic creation of higher dimensions
> 
> Isn't this comment still useful?

Yes, it's a useful comment, readded.

> src/hotspot/share/oops/arrayKlass.cpp line 144:
> 
>> 142:         ObjArrayKlass* ak =
>> 143:           ObjArrayKlass::allocate_objArray_klass(class_loader_data(), dim + 1, this, CHECK_NULL);
>> 144:         ak->set_lower_dimension(this);
> 
> Would it be useful to assert that the lower dimension has been set?

Yes, added.

> src/hotspot/share/oops/instanceKlass.cpp line 2765:
> 
>> 2763:     // To get a consistent list of classes we need MultiArray_lock to ensure
>> 2764:     // array classes aren't observed while they are being restored.
>> 2765:     MutexLocker ml(MultiArray_lock);
> 
> Doesn't this revert JDK-8274338?

You're right. I didn't believe my own comment when I removed this.  Thank you for pointing out the bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515346198
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515346716
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515349878

From coleenp at openjdk.org  Thu Mar  7 01:38:58 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Mar 2024 01:38:58 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v2]
In-Reply-To: <jzf_9tWx8SbLUycXupdxMiy9sqoL_k9bPSzM8K8s2Lo=.3643dd28-8c0a-4baa-ae3e-a654a287162c@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <RAMKzBgWvs2JTW_joTMEuOvHWx3k6MhJ9gNcJG9HuN8=.a360e552-2cd9-4a98-acc4-29e8e642b0d1@github.com>
 <NZxFuFl_4enns4p0Ww_0ZB8jBEPD2JzCdZlV2wjVfvE=.1be4405a-587b-43aa-88d6-91f67dce1491@github.com>
 <cPiOcc2Q37gzF8mwASvpHu7gOTZ5moH_i45pMlrqYk4=.b90c9a52-f42e-48c0-bbfe-788c69e4d520@github.com>
 <jzf_9tWx8SbLUycXupdxMiy9sqoL_k9bPSzM8K8s2Lo=.3643dd28-8c0a-4baa-ae3e-a654a287162c@github.com>
Message-ID: <vVukpnGLA8atz4OQ8-H_Rfpz9kUNW0etJcGdHNf9Nt8=.60e8b025-cfde-470a-b092-f1434cdc95f4@github.com>

On Thu, 7 Mar 2024 00:54:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> OK.  It's a good thing HotSpot doesn't need to worry about priority-inheritance for mutexes.
>
> Semaphore seems simpler/cleaner and ready to use.

It's such a rare race and unusual condition that we could execute more Java code, that I started out with just a shared bit.  Then David suggested a semaphore that obeys the safepoint protocol, which seems a lot better.  I've literally skimmed over OSThreadWaitState.  It looks like Semaphore::wait_with_a_safepoint_check() uses it.  I still don't know why it exists:


// Note: the ThreadState is legacy code and is not correctly implemented.
// Uses of ThreadState need to be replaced by the state in the JavaThread.

enum ThreadState {


Does a PlatformMutex handle priority-inheritance? It still feels like it would be overkill for this usage.  I hope this RecursiveLocker does not become more widely used, where we would have to replace the simple implementation with something more difficult.  We should discourage further use when possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515364466

From dholmes at openjdk.org  Thu Mar  7 01:47:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Mar 2024 01:47:03 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v2]
In-Reply-To: <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
Message-ID: <CGpzg8uCUn5gtXjh33-6OFwqX_TL4mHxk1HK1eHcumE=.f3c863f9-e0ba-47b4-b341-4b5b4b69f2bf@github.com>

On Thu, 7 Mar 2024 01:38:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dean's comments.

src/hotspot/share/oops/instanceKlass.cpp line 1552:

> 1550:     RecursiveLocker rl(MultiArray_lock, THREAD);
> 1551: 
> 1552:     // This thread is the creator.

This thread may not be the creator. The original comment was more apt - we typically say something like "Check if another thread beat us to it."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515371571

From dlong at openjdk.org  Thu Mar  7 02:11:01 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 7 Mar 2024 02:11:01 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v2]
In-Reply-To: <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
Message-ID: <wup8GpJtKeDHicNMIZ-jlZHa7SGF6agCNDupxbnDDTo=.4237683a-ef42-4eea-8165-c7d674beb5ea@github.com>

On Thu, 7 Mar 2024 01:38:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dean's comments.

> Does a PlatformMutex handle priority-inheritance?

It would depend on the OS and the mutex impementation.  You can ignore my comment.  It was from long ago trying to put Java on top of a real-time OS.

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

PR Comment: https://git.openjdk.org/jdk/pull/17739#issuecomment-1982207873

From dholmes at openjdk.org  Thu Mar  7 02:50:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Mar 2024 02:50:58 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v2]
In-Reply-To: <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
Message-ID: <MsxA3zqqyXgHE5Eiu7JR0oFRtn2HXLpTBtYoME5nnpo=.98fef7da-80e8-4a03-955e-b2fabe027d23@github.com>

On Thu, 7 Mar 2024 01:38:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dean's comments.

This looks good to me. Thanks for working through the details with me.

src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp line 121:

> 119:   {
> 120:     // To get a consistent list of classes we need MultiArray_lock to ensure
> 121:     // array classes aren't created during this walk. This walks through the

Just curious but how can walking the set of classes trigger creation of array classes?

src/hotspot/share/runtime/mutexLocker.hpp line 335:

> 333: 
> 334: // Instance of a RecursiveLock that may be held through Java heap allocation, which may include calls to Java,
> 335: // and JNI event notification for resource exhausted for metaspace or heap.

s/exhausted/exhaustion/

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17739#pullrequestreview-1921323899
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515402581
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1515406082

From gli at openjdk.org  Thu Mar  7 03:02:57 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 7 Mar 2024 03:02:57 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce windows jni_util_md.h

src/java.base/aix/native/libnio/ch/Pollset.c line 3:

> 1: /*
> 2:  * Copyright (c) 2008, 2024, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2012, 2024 SAP SE. All rights reserved.

It seems you only need to update the copyright of the company you work for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515417217

From dholmes at openjdk.org  Thu Mar  7 06:47:56 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Mar 2024 06:47:56 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <Kcx6SoNcp1C3-GTk8hHhLVWshuHKM9TRE5DN62_Zgeo=.4167311f-0f85-4424-9b77-d152ed43726f@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
 <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>
 <_pbD7dEcZ0wjCfut2WEz5az3y11jhazNQp_8Ekje-Wg=.67400067-5142-49f0-bcfa-f40f77f6fe1c@github.com>
 <Kcx6SoNcp1C3-GTk8hHhLVWshuHKM9TRE5DN62_Zgeo=.4167311f-0f85-4424-9b77-d152ed43726f@github.com>
Message-ID: <nc1GdDFdlBgC9TRyb4RrwRCrL306Kk_F5oj7y8nR18U=.3c183cb5-357c-4d79-b417-da414f74cfc9@github.com>

On Wed, 6 Mar 2024 10:41:21 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thanks, I'm already working on it.
>
> Fixed as suggested by Alan.
> 
>> Also need to think through if Object.wait will need to be changed as part of this.
> 
> Still need to look at this.

Use of `ObjectLocker` here will introduce a new pinning point for Loom. We have been removing as many uses of `ObjectLocker` as we can. I also think this will need to be moved back to Java code when the pinning currently inherent in calling `Object.wait` is addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1515622346

From dholmes at openjdk.org  Thu Mar  7 07:22:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Mar 2024 07:22:54 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>
Message-ID: <LPxrrBwmvcpd0QUkK47rzsO_6wypyyApj2f0dIMWpd0=.ff1251b8-8488-45c1-82d9-d097a65ac2f1@github.com>

On Thu, 7 Mar 2024 03:00:11 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Introduce windows jni_util_md.h
>
> src/java.base/aix/native/libnio/ch/Pollset.c line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2024, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (c) 2012, 2024 SAP SE. All rights reserved.
> 
> It seems you only need to update the copyright of the company you work for.

Oracle requests/requires that the Oracle copyright always be updated when a file is modified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515660944

From alanb at openjdk.org  Thu Mar  7 07:30:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Mar 2024 07:30:54 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v8]
In-Reply-To: <Da0Ld-qa1oBc_gZndo3Duo6B36IwNejZ7OCyKM2Tzh4=.cec564fa-fed1-4a79-9c19-aa6e92fd2368@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <Da0Ld-qa1oBc_gZndo3Duo6B36IwNejZ7OCyKM2Tzh4=.cec564fa-fed1-4a79-9c19-aa6e92fd2368@github.com>
Message-ID: <gtUbjk1RjunnXuEDzHvRxe-wJ221dGVotiLWRvO8LYo=.ec8b9c8b-bde8-4b22-8ad5-256efe34c48d@github.com>

On Thu, 7 Mar 2024 00:13:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: dropped the catch of InterruptedException in Object.wait

Can you check if vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/TestDescription.java is passing now? That test is a bit annoying in that it fails every time we touch j.l.Object so you might have to update BI04/bi04t002/newclass02/java.base/java/lang/Object.java  again.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1982739813

From gli at openjdk.org  Thu Mar  7 07:32:53 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 7 Mar 2024 07:32:53 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <LPxrrBwmvcpd0QUkK47rzsO_6wypyyApj2f0dIMWpd0=.ff1251b8-8488-45c1-82d9-d097a65ac2f1@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <oX6EYI-_kwL6cpVmIjI15XsjQChiRmmKRERem602NOs=.4f482be2-a6e8-4314-b6d2-5a7b9bb426dc@github.com>
 <LPxrrBwmvcpd0QUkK47rzsO_6wypyyApj2f0dIMWpd0=.ff1251b8-8488-45c1-82d9-d097a65ac2f1@github.com>
Message-ID: <3Oc7Dtnp_h7ivbUNx3RvJI1ltC3elMhB6V8Jijp2k_0=.d3081a47-6f3b-4051-8baa-a7254be58293@github.com>

On Thu, 7 Mar 2024 07:20:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Oracle requests/requires that the Oracle copyright always be updated when a file is modified.

Got it. Thanks for your explanation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515672685

From alanb at openjdk.org  Thu Mar  7 08:11:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Mar 2024 08:11:05 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
Message-ID: <DRwaTWXKHaZpCPwakxAS43VPX7feAcGHkDO581GbYHY=.fe96ffab-a5bf-450c-a0c6-04f44df7f2d6@github.com>

On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce windows jni_util_md.h

Latest version looks good to me. As have been pointed out, there at least 2 files where the copyright header was updated but there are no changes, I assume left over from previous iterations. I assume the RESTARTABLE-close in libattach/VirtualMachineImpl.c will be tracked as a separate issue.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1921724534

From mbaesken at openjdk.org  Thu Mar  7 08:16:26 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Mar 2024 08:16:26 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v4]
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

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

  adjust COPYRIGHT year info

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18132/files
  - new: https://git.openjdk.org/jdk/pull/18132/files/2930075d..25a65a71

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

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

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

From mbaesken at openjdk.org  Thu Mar  7 08:16:26 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Mar 2024 08:16:26 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
Message-ID: <9srUL7ZFMpINp-3Ub6V1mN5RYsiwkPxsQZnET_9sBVk=.3a051bf1-cc2f-47cb-b2f3-d220f32a91ce@github.com>

On Wed, 6 Mar 2024 17:14:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Introduce windows jni_util_md.h
>
> src/java.base/share/native/libjava/jni_util.h line 30:
> 
>> 28: 
>> 29: #include "jni.h"
>> 30: #include "jni_util_md.h"
> 
> This file needs copyright year update

Agree, updated !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515719458

From mbaesken at openjdk.org  Thu Mar  7 08:16:26 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Mar 2024 08:16:26 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v4]
In-Reply-To: <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <O78oQpVBZv_opVceFKAXUSiRuj8yxnLsQ1TFXSgs3mY=.121012bd-f183-4b36-b30f-6c06c2d3ce92@github.com>
Message-ID: <5LGbdPzlc3oIQ3TGaN5iglmGa5MCt5YnJzLvE7KUu6s=.b2a22f10-8331-4f15-8a2d-affbef828876@github.com>

On Wed, 6 Mar 2024 17:16:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust COPYRIGHT year info
>
> src/java.base/unix/native/libjava/childproc.h line 75:
> 
>> 73: #define FAIL_FILENO (STDERR_FILENO + 1)
>> 74: 
>> 75: /* TODO: Refactor. */
> 
> Copyright year update missing.

Thanks, I updated this too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515719859

From alanb at openjdk.org  Thu Mar  7 08:44:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Mar 2024 08:44:53 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <nc1GdDFdlBgC9TRyb4RrwRCrL306Kk_F5oj7y8nR18U=.3c183cb5-357c-4d79-b417-da414f74cfc9@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
 <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>
 <_pbD7dEcZ0wjCfut2WEz5az3y11jhazNQp_8Ekje-Wg=.67400067-5142-49f0-bcfa-f40f77f6fe1c@github.com>
 <Kcx6SoNcp1C3-GTk8hHhLVWshuHKM9TRE5DN62_Zgeo=.4167311f-0f85-4424-9b77-d152ed43726f@github.com>
 <nc1GdDFdlBgC9TRyb4RrwRCrL306Kk_F5oj7y8nR18U=.3c183cb5-357c-4d79-b417-da414f74cfc9@github.com>
Message-ID: <q0cikB2x4zIywyrGtJHWpiN3d_vLrmNUHmpGHwnw7-o=.415bfd3f-575d-40b5-9230-3300f7c7334a@github.com>

On Thu, 7 Mar 2024 06:45:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fixed as suggested by Alan.
>> 
>>> Also need to think through if Object.wait will need to be changed as part of this.
>> 
>> Still need to look at this.
>
> Use of `ObjectLocker` here will introduce a new pinning point for Loom. We have been removing as many uses of `ObjectLocker` as we can. I also think this will need to be moved back to Java code when the pinning currently inherent in calling `Object.wait` is addressed.

Yes, and it may be that once Object.wait is implemented that we can remove the need to propagate the interrupt status (there are some TBDs here).

I think the change here is okay for now but we still have the choice of limiting the change to just JVMTI RawMonitorWait.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1515760599

From mbaesken at openjdk.org  Thu Mar  7 08:54:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Mar 2024 08:54:54 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v3]
In-Reply-To: <DRwaTWXKHaZpCPwakxAS43VPX7feAcGHkDO581GbYHY=.fe96ffab-a5bf-450c-a0c6-04f44df7f2d6@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <OdkL16fwPJjd646zGYrAdD5cbIzt2FOUo74p3oIjDco=.00a0bf65-5e74-47ac-abe0-587ddfe82ec3@github.com>
 <DRwaTWXKHaZpCPwakxAS43VPX7feAcGHkDO581GbYHY=.fe96ffab-a5bf-450c-a0c6-04f44df7f2d6@github.com>
Message-ID: <YhcFIomZE7c7bxw3SqUp2wOkKUZOBq1CnJriSGgjcFg=.dfa9f18c-51f3-47e1-b88c-caabbe2d7a3f@github.com>

On Thu, 7 Mar 2024 08:08:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Latest version looks good to me. As have been pointed out, there at least 2 files where the copyright header was updated but there are no changes, I assume left over from previous iterations. I assume the RESTARTABLE-close in libattach/VirtualMachineImpl.c will be tracked as a separate issue.


Yes  this was from the commit iterations.
The RESTARTABLE-close issue will be tracked here 
https://bugs.openjdk.org/browse/JDK-8327468
8327468: Do not restart close if errno is EINTR [macOS/linux]

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18132#issuecomment-1982996784

From clanger at openjdk.org  Thu Mar  7 09:48:56 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 7 Mar 2024 09:48:56 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v4]
In-Reply-To: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
Message-ID: <okOd6cZT8f3vs6OvAfShpYuA_m1jny4FP-pNRjFJBDY=.d45787d7-5344-4d08-bb9a-19f1645526fd@github.com>

On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust COPYRIGHT year info

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1921955570

From dfuchs at openjdk.org  Thu Mar  7 10:12:55 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 7 Mar 2024 10:12:55 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: <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <3ySnI0NZpH6i6x4JbDPDrIJaFePx-Mgq6twkYcHcqko=.7032ca22-e9cf-4d8c-a195-e3c400bc088c@github.com>
 <wu6uHXJjN-66m06qVHNqRRTaJ8NX5Mups193Z800AkM=.adf1be8d-77e9-488b-81ca-bc72b5d16959@github.com>
 <pJq6s2XXmq-TMVBeYbZnU-HehXl79iKKJF8fwdP0P_c=.6c4cf31d-c3e9-43f3-a0b1-9ddbaf857788@github.com>
 <ibbTL5fpkBFUfI-oEgDNT0l-28QN9uRI4ntKwdr16cY=.b837f46f-a67d-42c6-9867-a943f9873228@github.com>
 <xFRHu2XDIxsDV1ZR8mzMzDq03yzmwPNV0Tr8NmHdipQ=.0f82a29f-3c68-4b78-bd81-de12593fa843@github.com>
 <KIU-IGF0iOYGmlR2e8C6cufy1RXaZ51p6dxKSRwVesY=.06c583ca-6405-4573-a718-63d65f968b74@github.com>
 <2jyg43cu37BIpEd0OspCrs_gU-9iMhniio4PKKbKPcs=.e58097fb-6862-4c8c-a3d0-718a8c922ea4@github.com>
 <Rf00XyI4Ej8WywKSqmFr5m2Z7_8YYj-m8J283B9xqOo=.6ede92b1-b9ef-4189-847b-da56e2943bb5@github.com>
Message-ID: <o903TWvm-n5rqeKURwyNYxtab9UPMSrTwyMUgLWBk-A=.31cb42ae-4aa2-43fc-bb4e-27b00b6ba891@github.com>

On Tue, 5 Mar 2024 19:53:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Subject is stored in the RMIConnectionImpl: src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> 
>> (That is complicated by SubjectDelegation, which we deprecated for removal.  I have the PR out to remove it:
>> https://github.com/openjdk/jdk/pull/18025 )
>> 
>> makeClient in RMIJRMPServerImpl creates RMIConnectionImpl
>> 
>> ..and RMIServerImpl.java has a doNewClient method calling that.  This is what takes a Credentials Object and deals withJMXAuthenticator to get an authenticated Subject.  None of this requires the SM.
>
> I see that in `RMIConnectionImpl.java` it is stored inside an `AccessControlContext`, and there are `doPrivileged` calls on this ACC to pass the subject into an action. So, even if there might be no SM but the subject will never be bound to a thread using a scoped value.
> 
> I?ll revert the change then, and this code must have SM allowed to run correctly. If user runs it with SM disabled, at least they will see an UOE instead of letting `current()` silently returns a null.
> 
> Ultimately, if we want it working after SM, we should update `RMIConnectionImpl` and rewrite the ACC-related code to using `Subject.callAs`.

Yes - the JMX implementation stores and retrieve subjects in the AccessControlContext and then uses doPrivileged. Subject.doAs is not used in the JMX implementation.

There are two different uses of Subject in JMX: 

1. one is a simplified role-based authentication/authorization at the default agent level. 
2. The other one is a permission check where different subjects can be granted different privileges in the policy file. 

The latter will go away since the SM is going away, but needs to be preserved until then.
The former we want to keep and needs to keep working (by changing the code to use callAs) even after the SM is gone.

Subject delegation allows an authenticated subject (1. above) to perform actions on behalf of a delegation subject, where the privileged granted by 2. are the intersection of the privileges of the two subjects.
@kevinjwalls is currently working on removing subject delegation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1515896397

From dholmes at openjdk.org  Thu Mar  7 12:06:59 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Mar 2024 12:06:59 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v4]
In-Reply-To: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
Message-ID: <zlGKCDnKizB8QBmTV4zoyB_Tu2sc6eAlaz8t7Wg09lc=.c3015b98-4071-48fc-85d9-d816b0945420@github.com>

On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust COPYRIGHT year info

LGTM. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1922263102

From coleenp at openjdk.org  Thu Mar  7 13:21:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Mar 2024 13:21:09 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v3]
In-Reply-To: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
Message-ID: <goJid3L6AZr13DB48ZATsWrCm7bRWVW7zUc7odaprMU=.384ff8e6-a2b3-489a-9949-443745e4d658@github.com>

> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
> 
> Passes tier1-7.

Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:

 - Missed a word.
 - David's comment fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17739/files
  - new: https://git.openjdk.org/jdk/pull/17739/files/d64aa560..88fd6f13

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

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

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

From coleenp at openjdk.org  Thu Mar  7 13:21:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Mar 2024 13:21:10 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v2]
In-Reply-To: <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
Message-ID: <BooJ7lhe0F6YzsBYI5tkkkI9ZL9g3wHkWVWKDAZsqCE=.d1dfef83-459d-49dd-b23a-1dda62cef68b@github.com>

On Thu, 7 Mar 2024 01:38:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dean's comments.

David, thank you for your discussion while fixing this problem.

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

PR Review: https://git.openjdk.org/jdk/pull/17739#pullrequestreview-1922394063

From coleenp at openjdk.org  Thu Mar  7 13:21:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Mar 2024 13:21:10 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v2]
In-Reply-To: <CGpzg8uCUn5gtXjh33-6OFwqX_TL4mHxk1HK1eHcumE=.f3c863f9-e0ba-47b4-b341-4b5b4b69f2bf@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <T1sKMAiTqHyv_3NTRRM0n7TlvKnNbh7l_NOTyC9Xp4w=.1cfb7db1-6ee0-421b-ae53-a42b7952b44e@github.com>
 <CGpzg8uCUn5gtXjh33-6OFwqX_TL4mHxk1HK1eHcumE=.f3c863f9-e0ba-47b4-b341-4b5b4b69f2bf@github.com>
Message-ID: <1nz_mknyZvGdeVoetWZvFXsagFjJ0p5odDt-Rf_C4pc=.1b9598ef-0b61-4e00-8522-8ad797f1e685@github.com>

On Thu, 7 Mar 2024 01:44:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dean's comments.
>
> src/hotspot/share/oops/instanceKlass.cpp line 1552:
> 
>> 1550:     RecursiveLocker rl(MultiArray_lock, THREAD);
>> 1551: 
>> 1552:     // This thread is the creator.
> 
> This thread may not be the creator. The original comment was more apt - we typically say something like "Check if another thread beat us to it."

Fixed.

    // Check if another thread created the array klass while we were waiting for the lock.

> src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp line 121:
> 
>> 119:   {
>> 120:     // To get a consistent list of classes we need MultiArray_lock to ensure
>> 121:     // array classes aren't created during this walk. This walks through the
> 
> Just curious but how can walking the set of classes trigger creation of array classes?

It can't.  I'll reword that comment so it's clearer, with just a couple of words.

    // To get a consistent list of classes we need MultiArray_lock to ensure
    // array classes aren't created by another thread this walk. This walks through the
    // InstanceKlass::_array_klasses links.

edit: added "during" to "by another thread during this walk"

> src/hotspot/share/runtime/mutexLocker.hpp line 335:
> 
>> 333: 
>> 334: // Instance of a RecursiveLock that may be held through Java heap allocation, which may include calls to Java,
>> 335: // and JNI event notification for resource exhausted for metaspace or heap.
> 
> s/exhausted/exhaustion/

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1516126218
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1516128248
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1516130552

From coleenp at openjdk.org  Thu Mar  7 13:21:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Mar 2024 13:21:10 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v3]
In-Reply-To: <vVukpnGLA8atz4OQ8-H_Rfpz9kUNW0etJcGdHNf9Nt8=.60e8b025-cfde-470a-b092-f1434cdc95f4@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <RAMKzBgWvs2JTW_joTMEuOvHWx3k6MhJ9gNcJG9HuN8=.a360e552-2cd9-4a98-acc4-29e8e642b0d1@github.com>
 <NZxFuFl_4enns4p0Ww_0ZB8jBEPD2JzCdZlV2wjVfvE=.1be4405a-587b-43aa-88d6-91f67dce1491@github.com>
 <cPiOcc2Q37gzF8mwASvpHu7gOTZ5moH_i45pMlrqYk4=.b90c9a52-f42e-48c0-bbfe-788c69e4d520@github.com>
 <jzf_9tWx8SbLUycXupdxMiy9sqoL_k9bPSzM8K8s2Lo=.3643dd28-8c0a-4baa-ae3e-a654a287162c@github.com>
 <vVukpnGLA8atz4OQ8-H_Rfpz9kUNW0etJcGdHNf9Nt8=.60e8b025-cfde-470a-b092-f1434cdc95f4@github.com>
Message-ID: <TZCbb4qKlz6o5a9vWwRKyQE_lFkdseLmLAjTbM1ueak=.12e175fd-e157-4856-90b9-d8c809cb0fed@github.com>

On Thu, 7 Mar 2024 01:31:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Semaphore seems simpler/cleaner and ready to use.
>
> It's such a rare race and unusual condition that we could execute more Java code, that I started out with just a shared bit.  Then David suggested a semaphore that obeys the safepoint protocol, which seems a lot better.  I've literally skimmed over OSThreadWaitState.  It looks like Semaphore::wait_with_a_safepoint_check() uses it.  I still don't know why it exists:
> 
> 
> // Note: the ThreadState is legacy code and is not correctly implemented.
> // Uses of ThreadState need to be replaced by the state in the JavaThread.
> 
> enum ThreadState {
> 
> 
> Does a PlatformMutex handle priority-inheritance? It still feels like it would be overkill for this usage.  I hope this RecursiveLocker does not become more widely used, where we would have to replace the simple implementation with something more difficult.  We should discourage further use when possible.

Thanks for your last comment because I was worried there's a lot of other code I should know about.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1516129405

From bpb at openjdk.org  Thu Mar  7 17:34:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Mar 2024 17:34:57 GMT
Subject: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
 [v4]
In-Reply-To: <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
 <yC18JVuWa8vayw52AIlJxKxACD8hyt7_VUa7bKZXNJg=.e64733a4-6655-4f09-bf29-497677fdc3fe@github.com>
Message-ID: <aCwdTOl0-rkQj9VyYVBDEaZ5D3PJut6U2vy07APIWoU=.bed1e600-78d7-4d26-8231-3a39d079aa93@github.com>

On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust COPYRIGHT year info

+1

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18132#pullrequestreview-1923092889

From mullan at openjdk.org  Thu Mar  7 20:00:52 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 7 Mar 2024 20:00:52 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v5]
In-Reply-To: <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
Message-ID: <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>

On Wed, 6 Mar 2024 11:46:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test specifically that UOE is thrown.

Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1984324717

From mullan at openjdk.org  Thu Mar  7 20:04:56 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 7 Mar 2024 20:04:56 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v5]
In-Reply-To: <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
Message-ID: <HelxRioowIY-SM3wJQ2aZR7znw3qkVOqM59Ph45zZcw=.4c210e57-4808-44fc-880d-128649f49406@github.com>

On Wed, 6 Mar 2024 11:46:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test specifically that UOE is thrown.

Are there remaining tests that test the JMX fine grained permissions feature w/o depending on subject delegation?

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1984329809

From mullan at openjdk.org  Thu Mar  7 21:26:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 7 Mar 2024 21:26:55 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v5]
In-Reply-To: <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
Message-ID: <bL9_pIDwNbViasMDCsl14OzxPmWTHT5-Q0dsJC48czk=.bd9083af-29bf-4f69-9575-f6e26db8e727@github.com>

On Wed, 6 Mar 2024 11:46:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test specifically that UOE is thrown.

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 153:

> 151:      *
> 152:      * @exception UnsupportedOperationException if a non-null delegationSubject
> 153:      * is specifed. Subject Delegation has been removed.

Typo: s/specifed/specified/

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 158:

> 156:      * and is only useful in conjunction with other APIs which are deprecated and
> 157:      * subject to removal in a future release. Consequently, this method is also
> 158:      * deprecated and subject to removal. There is no replacement.

Maybe you want to change this text to be more direct here that subject delegation is no longer supported and what this method now does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1516758560
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1516761404

From fparain at openjdk.org  Thu Mar  7 21:53:00 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 7 Mar 2024 21:53:00 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v3]
In-Reply-To: <goJid3L6AZr13DB48ZATsWrCm7bRWVW7zUc7odaprMU=.384ff8e6-a2b3-489a-9949-443745e4d658@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <goJid3L6AZr13DB48ZATsWrCm7bRWVW7zUc7odaprMU=.384ff8e6-a2b3-489a-9949-443745e4d658@github.com>
Message-ID: <5QOZjKj7BrbeWDGgXDHbS3q75P5VEoC7wEcJVHRlzxM=.b24266e1-9490-4351-a876-afb3a54840e7@github.com>

On Thu, 7 Mar 2024 13:21:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Missed a word.
>  - David's comment fixes.

LGTM

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

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17739#pullrequestreview-1923623357

From kevinw at openjdk.org  Thu Mar  7 22:00:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Mar 2024 22:00:13 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v6]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <adgnE1ZwtDKKxv_AEH3wcVmAcRZVFBF-aKZtq1Kx-KU=.dac68066-409a-472d-a7d7-67e108401845@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:

 - Clarify deprecation comment.
 - typo
 - Remove additional passing of delegatedSubject in ClientListenerInfo and ClientNotifForwarder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/c5256c3f..4beae2f2

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

  Stats: 54 lines in 5 files changed: 0 ins; 25 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Thu Mar  7 22:00:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Mar 2024 22:00:14 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v5]
In-Reply-To: <bL9_pIDwNbViasMDCsl14OzxPmWTHT5-Q0dsJC48czk=.bd9083af-29bf-4f69-9575-f6e26db8e727@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
 <bL9_pIDwNbViasMDCsl14OzxPmWTHT5-Q0dsJC48czk=.bd9083af-29bf-4f69-9575-f6e26db8e727@github.com>
Message-ID: <kD8e-HZecg9BYp10rEq45WNOntqqaMb0ovaNZzt171A=.a71a117f-89d2-4961-8bce-2d186063bd15@github.com>

On Thu, 7 Mar 2024 20:07:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test specifically that UOE is thrown.
>
> src/java.management/share/classes/javax/management/remote/JMXConnector.java line 153:
> 
>> 151:      *
>> 152:      * @exception UnsupportedOperationException if a non-null delegationSubject
>> 153:      * is specifed. Subject Delegation has been removed.
> 
> Typo: s/specifed/specified/

got it thanks.

> src/java.management/share/classes/javax/management/remote/JMXConnector.java line 158:
> 
>> 156:      * and is only useful in conjunction with other APIs which are deprecated and
>> 157:      * subject to removal in a future release. Consequently, this method is also
>> 158:      * deprecated and subject to removal. There is no replacement.
> 
> Maybe you want to change this text to be more direct here that subject delegation is no longer supported and what this method now does.

Yes, that should be updated, the feature is gone with this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1516884990
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1516885582

From amenkov at openjdk.org  Fri Mar  8 02:59:22 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 8 Mar 2024 02:59:22 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record component
 annotation fails with CFE
Message-ID: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>

RecordComponent class has _attributes_count field.
The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
The fix updates ClassFileParser to calculate correct attributes_count.

Testing: 
- tier1,tier2,hs-tier5-svc;
 - redefineClasses/retransformClasses tests:
   - test/jdk/java/lang/instrument
   - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

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

Commit messages:
 - fix

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

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

From jiangli at openjdk.org  Fri Mar  8 03:02:54 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 8 Mar 2024 03:02:54 GMT
Subject: RFR: 8327645: Serial heap dump should not consume double amount of
 disk space [v2]
In-Reply-To: <1ZEoS1SowIyIioc8fxo_0XUkzz99UzIUAXnwtcztzOI=.ef955266-b117-42b3-8c2b-34241872f167@github.com>
References: <w0s7BM73-cxeWAZz9s42cfLgJPMafLsWfQhnlZ4pakk=.bafbcb0f-94c9-41bd-9226-71979a76800a@github.com>
 <1ZEoS1SowIyIioc8fxo_0XUkzz99UzIUAXnwtcztzOI=.ef955266-b117-42b3-8c2b-34241872f167@github.com>
Message-ID: <3fiUAlW66lkYA1vMQTjx7Q4Hna4TgZRERLbocb81ORQ=.8fc52410-e9d5-4c22-b834-88cb7571967f@github.com>

On Fri, 8 Mar 2024 02:35:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this fix to make serial heap dump only write to a single file?
>> We highly appreciate the work in https://bugs.openjdk.org/browse/JDK-8306441. However, many of our customers still need to use serial heap dump, as they have limited disk space and need to dump to a network socket.
>> 
>> Tested:
>> Stress tested with a fastdebug build with tests in `hotspot/jtreg/serviceability/dcmd/gc/HeapDump*`.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix failure under -XX:+UseSerialGC

The change seems reasonable and avoids some of the extra file overhead in the serial case.

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

PR Review: https://git.openjdk.org/jdk/pull/18160#pullrequestreview-1923942056

From amenkov at openjdk.org  Fri Mar  8 03:37:52 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 8 Mar 2024 03:37:52 GMT
Subject: RFR: 8327645: Serial heap dump should not consume double amount of
 disk space [v2]
In-Reply-To: <1ZEoS1SowIyIioc8fxo_0XUkzz99UzIUAXnwtcztzOI=.ef955266-b117-42b3-8c2b-34241872f167@github.com>
References: <w0s7BM73-cxeWAZz9s42cfLgJPMafLsWfQhnlZ4pakk=.bafbcb0f-94c9-41bd-9226-71979a76800a@github.com>
 <1ZEoS1SowIyIioc8fxo_0XUkzz99UzIUAXnwtcztzOI=.ef955266-b117-42b3-8c2b-34241872f167@github.com>
Message-ID: <vDKRtHPvFaf5up48R-fpclw6VZaqnB5V7K34SVNURFM=.e76d2d59-eac4-4cbe-823c-2a82074d5448@github.com>

On Fri, 8 Mar 2024 02:35:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this fix to make serial heap dump only write to a single file?
>> We highly appreciate the work in https://bugs.openjdk.org/browse/JDK-8306441. However, many of our customers still need to use serial heap dump, as they have limited disk space and need to dump to a network socket.
>> 
>> Tested:
>> Stress tested with a fastdebug build with tests in `hotspot/jtreg/serviceability/dcmd/gc/HeapDump*`.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix failure under -XX:+UseSerialGC

Heap dumper was switched to always use segments by [JDK-8299426](https://bugs.openjdk.org/browse/JDK-8299426) / [JDK-8321565](https://bugs.openjdk.org/browse/JDK-8321565).
I suppose your fix will cause broken heapdump if there are some unmounted virtual threads.
You can try to run test/hotspot/jtreg/serviceability/jvmti/vthread/HeapDump/VThreadInHeapDump.java

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

PR Comment: https://git.openjdk.org/jdk/pull/18160#issuecomment-1984984146

From sspitsyn at openjdk.org  Fri Mar  8 05:58:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Mar 2024 05:58:53 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v8]
In-Reply-To: <gtUbjk1RjunnXuEDzHvRxe-wJ221dGVotiLWRvO8LYo=.ec8b9c8b-bde8-4b22-8ad5-256efe34c48d@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <Da0Ld-qa1oBc_gZndo3Duo6B36IwNejZ7OCyKM2Tzh4=.cec564fa-fed1-4a79-9c19-aa6e92fd2368@github.com>
 <gtUbjk1RjunnXuEDzHvRxe-wJ221dGVotiLWRvO8LYo=.ec8b9c8b-bde8-4b22-8ad5-256efe34c48d@github.com>
Message-ID: <xtNrQkP5FJs82Pw6_RaEgTgA2S_xJTcKcEVws4skxP8=.6a18c10b-1957-4332-a55e-f2ae5f2d6c7a@github.com>

On Thu, 7 Mar 2024 07:28:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you check if vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/TestDescription.java is passing now? That test is a bit annoying in that it fails every time we touch j.l.Object so you might have to update BI04/bi04t002/newclass02/java.base/java/lang/Object.java again.

Checked, it is passed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1985083927

From sspitsyn at openjdk.org  Fri Mar  8 06:05:09 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Mar 2024 06:05:09 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v8]
In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
Message-ID: <hNZSzjrksXootBKftj2muuBknJcwndfjhT38cXG4spc=.abb01112-a555-488f-a293-9ae77ad1ed88@github.com>

> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
> 
> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
> 
> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
> 
> Testing:
>  - tested with the mach5 tiers 1-6

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 eight additional commits since the last revision:

 - Merge
 - review: updated test desciption for two modified tests
 - review: added new internal function JvmtiEnvBase::get_thread_or_vthread_state
 - review: replaced timed with timed-out in JDWP and JDI spec
 - Merge
 - Merge
 - fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method
 - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17944/files
  - new: https://git.openjdk.org/jdk/pull/17944/files/289f6ff7..ce8ae8a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=06-07

  Stats: 79955 lines in 822 files changed: 6246 ins; 71952 del; 1757 mod
  Patch: https://git.openjdk.org/jdk/pull/17944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17944/head:pull/17944

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

From sspitsyn at openjdk.org  Fri Mar  8 06:11:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Mar 2024 06:11:23 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v23]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge
 - review: minor tweak in test description of ObjectMonitorUsage.java
 - review: addressed more comments on the fix and new test
 - rename after merge: jvmti_common.h to jvmti_common.hpp
 - Merge
 - review: update comment in threads.hpp
 - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
 - resolve merge conflict for deleted file objmonusage003.cpp
 - fix a typo in libObjectMonitorUsage.cpp
 - fix potential sync gap in the test ObjectMonitorUsage
 - ... and 16 more: https://git.openjdk.org/jdk/compare/de428daf...b97b8205

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

Changes: https://git.openjdk.org/jdk/pull/17680/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=22
  Stats: 1161 lines in 15 files changed: 722 ins; 390 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

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

From sspitsyn at openjdk.org  Fri Mar  8 06:14:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Mar 2024 06:14:11 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v9]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <Wb_qs6wgpRg6ECyfu2_QHUF1T7RjZofKsWo4_qGcHug=.7c79d5a8-531b-4ba4-b4d7-60c9aa0d04ca@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

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 10 additional commits since the last revision:

 - Merge
 - review: dropped the catch of InterruptedException in Object.wait
 - optimize holding the interruptLock in JavaThread::is_interrupted
 - reordered JavaThread::is_interrupted code to use lock when needed only
 - removed trailing spaces in javaClasses.cpp and libInterruptRawMonitor.cpp
 - review: added ObjectLocker of interruptLock for sync
 - review: improved sync in new test InterruptRawMonitor
 - review: addressed a couple of comments on new test
 - fix trailing space in libInterruptRawMonitor.cpp
 - 8325187: JVMTI GetThreadState says virtual thread is JVMTI_THREAD_STATE_INTERRUPTED when it no longer is

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/923a3ff5..df3b6383

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=07-08

  Stats: 79955 lines in 822 files changed: 6246 ins; 71952 del; 1757 mod
  Patch: https://git.openjdk.org/jdk/pull/18093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18093/head:pull/18093

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

From dholmes at openjdk.org  Fri Mar  8 06:19:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Mar 2024 06:19:58 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v3]
In-Reply-To: <goJid3L6AZr13DB48ZATsWrCm7bRWVW7zUc7odaprMU=.384ff8e6-a2b3-489a-9949-443745e4d658@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <goJid3L6AZr13DB48ZATsWrCm7bRWVW7zUc7odaprMU=.384ff8e6-a2b3-489a-9949-443745e4d658@github.com>
Message-ID: <1rt397QolNEaI0Eixy7hupwNKI2-7Ioz9KvmNCkRs5Y=.fb1b903e-fc48-4ea1-ac1e-4f55fed7f54e@github.com>

On Thu, 7 Mar 2024 13:21:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Missed a word.
>  - David's comment fixes.

Marked as reviewed by dholmes (Reviewer).

src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp line 121:

> 119:   {
> 120:     // To get a consistent list of classes we need MultiArray_lock to ensure
> 121:     // array classes aren't created by another thread during this walk. This walks through the

Thanks for clarifying, though I'm not sure why would care given the set of classes could have changed by the time we return them anyway.

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

PR Review: https://git.openjdk.org/jdk/pull/17739#pullrequestreview-1924097971
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1517209655

From dholmes at openjdk.org  Fri Mar  8 06:23:56 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Mar 2024 06:23:56 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <q0cikB2x4zIywyrGtJHWpiN3d_vLrmNUHmpGHwnw7-o=.415bfd3f-575d-40b5-9230-3300f7c7334a@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
 <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>
 <_pbD7dEcZ0wjCfut2WEz5az3y11jhazNQp_8Ekje-Wg=.67400067-5142-49f0-bcfa-f40f77f6fe1c@github.com>
 <Kcx6SoNcp1C3-GTk8hHhLVWshuHKM9TRE5DN62_Zgeo=.4167311f-0f85-4424-9b77-d152ed43726f@github.com>
 <nc1GdDFdlBgC9TRyb4RrwRCrL306Kk_F5oj7y8nR18U=.3c183cb5-357c-4d79-b417-da414f74cfc9@github.com>
 <q0cikB2x4zIywyrGtJHWpiN3d_vLrmNUHmpGHwnw7-o=.415bfd3f-575d-40b5-9230-3300f7c7334a@github.com>
Message-ID: <SVchHmqu4zpZr56j26tpZAP2j4_97Jy3PksTix7p3bE=.11550706-58dc-480a-95f1-76a68f4a48d9@github.com>

On Thu, 7 Mar 2024 08:42:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Use of `ObjectLocker` here will introduce a new pinning point for Loom. We have been removing as many uses of `ObjectLocker` as we can. I also think this will need to be moved back to Java code when the pinning currently inherent in calling `Object.wait` is addressed.
>
> Yes, and it may be that once Object.wait is implemented that we can remove the need to propagate the interrupt status (there are some TBDs here).
> 
> I think the change here is okay for now but we still have the choice of limiting the change to just JVMTI RawMonitorWait.

Personally I'd prefer to see changes limited to just JVMTI `RawMonitorWait`. That minimises the risk of any unintended consequences from making the change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1517212478

From alanb at openjdk.org  Fri Mar  8 07:12:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Mar 2024 07:12:53 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v8]
In-Reply-To: <xtNrQkP5FJs82Pw6_RaEgTgA2S_xJTcKcEVws4skxP8=.6a18c10b-1957-4332-a55e-f2ae5f2d6c7a@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <Da0Ld-qa1oBc_gZndo3Duo6B36IwNejZ7OCyKM2Tzh4=.cec564fa-fed1-4a79-9c19-aa6e92fd2368@github.com>
 <gtUbjk1RjunnXuEDzHvRxe-wJ221dGVotiLWRvO8LYo=.ec8b9c8b-bde8-4b22-8ad5-256efe34c48d@github.com>
 <xtNrQkP5FJs82Pw6_RaEgTgA2S_xJTcKcEVws4skxP8=.6a18c10b-1957-4332-a55e-f2ae5f2d6c7a@github.com>
Message-ID: <PXc2Cm6XjQacjmQ-g9o2d91Ow-5MQyE4GLDb7idHGzA=.242905af-e27b-4de6-afba-428ecd98dd3a@github.com>

On Fri, 8 Mar 2024 05:56:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > Can you check if vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/TestDescription.java is passing now? That test is a bit annoying in that it fails every time we touch j.l.Object so you might have to update BI04/bi04t002/newclass02/java.base/java/lang/Object.java again.
> 
> Checked, it is passed now.

Can you look at? That test has a copy of Object.java so needs to be updated every time we touch Object.java. It's an annoying tax and I hope there is a JBS issue to replace that test.  In this case, it will be benign because the instrumented version will just clear the interrupt status of both threads twice, but at the same time, it will be out of sync with Object.wait.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1985153918

From mbaesken at openjdk.org  Fri Mar  8 08:34:01 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 8 Mar 2024 08:34:01 GMT
Subject: Integrated: JDK-8327444: simplify RESTARTABLE macro usage in JDK
 codebase
In-Reply-To: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
References: <oukR1mHe6gQyfrc0HryLQrHCFjCE8OqZoG0B0vF5jYs=.43bf68d4-1cee-4ce2-bf69-54ca38a4d985@github.com>
Message-ID: <bAbzLLRP89_PJUmeQMuGg37Djvavu4QQ1k94VFDHUUU=.a08c190a-9c3c-429f-af8f-ddca2e471161@github.com>

On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We define the RESTARTABLE macro again and again at a lot of places in the JDK native codebase. This could be centralized to avoid repeating it again and again !

This pull request has now been integrated.

Changeset: fb4610e6
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb4610e6b7a339d0a95a99d6e113e3ddda291561
Stats:     185 lines in 18 files changed: 69 ins; 106 del; 10 mod

8327444: simplify RESTARTABLE macro usage in JDK codebase

Reviewed-by: gli, clanger, alanb, dholmes, bpb

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

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

From manc at openjdk.org  Fri Mar  8 09:53:57 2024
From: manc at openjdk.org (Man Cao)
Date: Fri, 8 Mar 2024 09:53:57 GMT
Subject: RFR: 8327645: Serial heap dump should not consume double amount of
 disk space [v2]
In-Reply-To: <vDKRtHPvFaf5up48R-fpclw6VZaqnB5V7K34SVNURFM=.e76d2d59-eac4-4cbe-823c-2a82074d5448@github.com>
References: <w0s7BM73-cxeWAZz9s42cfLgJPMafLsWfQhnlZ4pakk=.bafbcb0f-94c9-41bd-9226-71979a76800a@github.com>
 <1ZEoS1SowIyIioc8fxo_0XUkzz99UzIUAXnwtcztzOI=.ef955266-b117-42b3-8c2b-34241872f167@github.com>
 <vDKRtHPvFaf5up48R-fpclw6VZaqnB5V7K34SVNURFM=.e76d2d59-eac4-4cbe-823c-2a82074d5448@github.com>
Message-ID: <cb50aZPAVkrAbTjiupDjtaW2IFY3yarpAfHhQgpTooo=.70cc9c83-9a68-4b69-b802-ead14587ead2@github.com>

On Fri, 8 Mar 2024 03:35:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix failure under -XX:+UseSerialGC
>
> Heap dumper was switched to always use segments by [JDK-8299426](https://bugs.openjdk.org/browse/JDK-8299426) / [JDK-8321565](https://bugs.openjdk.org/browse/JDK-8321565).
> I suppose your fix will cause broken heapdump if there are some unmounted virtual threads.
> You can try to run test/hotspot/jtreg/serviceability/jvmti/vthread/HeapDump/VThreadInHeapDump.java

@alexmenkov Thank you for the quick feedback. I can reproduce the failure with VThreadInHeapDump.java and `-XX:ActiveProcessorCount=1`. The problem seems that the writer cannot write HPROF_FRAME and HPROF_TRACE records in the middle of dumping an HPROF_HEAP_DUMP/HPROF_HEAP_DUMP_SEGMENT, so it resorts to a separate global writer.

Do we really need to keep all the HPROF_FRAME and HPROF_TRACE records located together? If not, two possible solutions are:
1. Keep track of all unmounted vthread oops, and dump their stack traces after finishing the HPROF_HEAP_DUMP_SEGMENT.
2. Write an HPROF_HEAP_DUMP_END, dump the vthread's stack trace, then start another HPROF_HEAP_DUMP_SEGMENT.

First approach seems resulting in a more organized heap dump. In any case, we probably only need to do this for serial heap dump. Parallel heap dump could keep using the current approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/18160#issuecomment-1985383273

From mbaesken at openjdk.org  Fri Mar  8 10:17:13 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 8 Mar 2024 10:17:13 GMT
Subject: RFR: JDK-8327468: Do not restart close if errno is EINTR [macOS/linux]
Message-ID: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>

There are a number of places remaining in the linux/macOS native JDK codebase where we use the RESTARTABLE macro with close, but this is unwanted on Linux/macOS.

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

Commit messages:
 - JDK-8327468

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

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

From kevinw at openjdk.org  Fri Mar  8 10:22:55 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 8 Mar 2024 10:22:55 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v5]
In-Reply-To: <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
 <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>
Message-ID: <LdiC1iOnUOOy4ZMjrzxyQUudv67BRB9PhzvHUCf5FCo=.b4de5198-089b-4ed4-991e-590a033d5a17@github.com>

On Thu, 7 Mar 2024 19:58:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.

No, nothing uses SubjectDelegationPermission.  That can be deprecated.

> Are there remaining tests that test the JMX fine grained permissions feature w/o depending on subject delegation?

Yes there are some tests other than those changed here, which use MBeanPermission in policies and become irrelevant post-SM.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1985429423

From alanb at openjdk.org  Fri Mar  8 10:27:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Mar 2024 10:27:53 GMT
Subject: RFR: JDK-8327468: Do not restart close if errno is EINTR
 [macOS/linux]
In-Reply-To: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
References: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
Message-ID: <JuUExTBhr29_fnh89atKoz58a3exTci0jKGdPtGbwgs=.224e4967-b3bc-4516-8575-a13e2c169b3f@github.com>

On Fri, 8 Mar 2024 10:12:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a number of places remaining in the linux/macOS native JDK codebase where we use the RESTARTABLE macro with close, but this is unwanted on Linux/macOS.

src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c line 200:

> 198:     if (res == -1) {
> 199:         JNU_ThrowIOExceptionWithLastError(env, "close");
> 200:     }

I assume it would be better to not stop when errno is EINTR. If there is a profiler or some other tool firing signals at threads then there isn't anything that can be done here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18164#discussion_r1517532415

From mbaesken at openjdk.org  Fri Mar  8 12:14:52 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 8 Mar 2024 12:14:52 GMT
Subject: RFR: JDK-8327468: Do not restart close if errno is EINTR
 [macOS/linux]
In-Reply-To: <JuUExTBhr29_fnh89atKoz58a3exTci0jKGdPtGbwgs=.224e4967-b3bc-4516-8575-a13e2c169b3f@github.com>
References: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
 <JuUExTBhr29_fnh89atKoz58a3exTci0jKGdPtGbwgs=.224e4967-b3bc-4516-8575-a13e2c169b3f@github.com>
Message-ID: <AlmDWCunDXJSZvl1emA6Lwsb4Maaea0K6E97Q7a2XtM=.8b6d6fcf-c411-4cc4-8582-0044254f4875@github.com>

On Fri, 8 Mar 2024 10:24:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There are a number of places remaining in the linux/macOS native JDK codebase where we use the RESTARTABLE macro with close, but this is unwanted on Linux/macOS.
>
> src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c line 200:
> 
>> 198:     if (res == -1) {
>> 199:         JNU_ThrowIOExceptionWithLastError(env, "close");
>> 200:     }
> 
> I assume it would be better to not throw when errno is EINTR. If there is a profiler or some other tool firing signals at threads then there isn't anything that can be done here.

Should I just ignore the result / return code of close and avoid throwing an exception completely ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18164#discussion_r1517639119

From sspitsyn at openjdk.org  Fri Mar  8 13:18:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Mar 2024 13:18:54 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v8]
In-Reply-To: <PXc2Cm6XjQacjmQ-g9o2d91Ow-5MQyE4GLDb7idHGzA=.242905af-e27b-4de6-afba-428ecd98dd3a@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <Da0Ld-qa1oBc_gZndo3Duo6B36IwNejZ7OCyKM2Tzh4=.cec564fa-fed1-4a79-9c19-aa6e92fd2368@github.com>
 <gtUbjk1RjunnXuEDzHvRxe-wJ221dGVotiLWRvO8LYo=.ec8b9c8b-bde8-4b22-8ad5-256efe34c48d@github.com>
 <xtNrQkP5FJs82Pw6_RaEgTgA2S_xJTcKcEVws4skxP8=.6a18c10b-1957-4332-a55e-f2ae5f2d6c7a@github.com>
 <PXc2Cm6XjQacjmQ-g9o2d91Ow-5MQyE4GLDb7idHGzA=.242905af-e27b-4de6-afba-428ecd98dd3a@github.com>
Message-ID: <693Ya3ssjSTya9Z-O00-k9ILzyNKJTtZCMolTaBxTbI=.01e61799-ee1e-4bff-a718-bc9a43606994@github.com>

On Fri, 8 Mar 2024 07:09:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you look at it again? That test has a copy of `Object.java` so needs to be updated every time we touch `Object.java`. It's an annoying tax and I hope there is a JBS issue to replace that test. In this case, it will be benign because the instrumented version will just clear the interrupt status of both threads twice, but at the same time, it will be out of sync with `Object.wait`.

This test is passing with removed the `Object.wait catch (InterruptedException e) block` in the test (instrumented version?) version of the `Object.java`.

I'm thinking if it makes sense to restore the removed `catch (InterruptedException e)`  block in `src/java.base/share/classes/java/lang/Object.java`. It will make David more happy, and also remove a potential issue with the test `vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002`. Clearing the interrupt status twice does not looks that bad.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1985676250

From coleenp at openjdk.org  Fri Mar  8 13:31:02 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Mar 2024 13:31:02 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v3]
In-Reply-To: <goJid3L6AZr13DB48ZATsWrCm7bRWVW7zUc7odaprMU=.384ff8e6-a2b3-489a-9949-443745e4d658@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <goJid3L6AZr13DB48ZATsWrCm7bRWVW7zUc7odaprMU=.384ff8e6-a2b3-489a-9949-443745e4d658@github.com>
Message-ID: <ykQdZA4uEp2JS3gtJ5vxw3gChWzYG7kFgiBb3hD37o0=.ced58e86-497a-458b-8e75-9558d6022203@github.com>

On Thu, 7 Mar 2024 13:21:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Missed a word.
>  - David's comment fixes.

Thank you for reviewing, Dean, David and Fred.

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

PR Comment: https://git.openjdk.org/jdk/pull/17739#issuecomment-1985694821

From coleenp at openjdk.org  Fri Mar  8 13:31:03 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Mar 2024 13:31:03 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock [v3]
In-Reply-To: <1rt397QolNEaI0Eixy7hupwNKI2-7Ioz9KvmNCkRs5Y=.fb1b903e-fc48-4ea1-ac1e-4f55fed7f54e@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
 <goJid3L6AZr13DB48ZATsWrCm7bRWVW7zUc7odaprMU=.384ff8e6-a2b3-489a-9949-443745e4d658@github.com>
 <1rt397QolNEaI0Eixy7hupwNKI2-7Ioz9KvmNCkRs5Y=.fb1b903e-fc48-4ea1-ac1e-4f55fed7f54e@github.com>
Message-ID: <2z1SHVNOF932nnHMAHkho9I5kQBT8ACK34-VxpbrmoQ=.2edd34b1-3249-4843-80c6-9b0052fcb28c@github.com>

On Fri, 8 Mar 2024 06:17:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Missed a word.
>>  - David's comment fixes.
>
> src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp line 121:
> 
>> 119:   {
>> 120:     // To get a consistent list of classes we need MultiArray_lock to ensure
>> 121:     // array classes aren't created by another thread during this walk. This walks through the
> 
> Thanks for clarifying, though I'm not sure why would care given the set of classes could have changed by the time we return them anyway.

I think in this case, we might find an ObjArrayKlass without the mirror since the Klass is added to the higher_dimension links before the mirror is created.  The lock keeps them both together.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1517716370

From coleenp at openjdk.org  Fri Mar  8 13:31:03 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Mar 2024 13:31:03 GMT
Subject: Integrated: 8308745: ObjArrayKlass::allocate_objArray_klass may call
 into java while holding a lock
In-Reply-To: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
References: <xBcUCxBAG89Ff-y64tg1uiR1bSKXg-ICi13TRxlMglc=.b5a3b91a-bdc4-46d5-bcb9-140cf002e7d2@github.com>
Message-ID: <6P09sTiNw7qF79ZSIn6fOlMFmFMwMXDM_vNahXuTUew=.fc116878-87a3-4d9a-8bfa-8ca7cfc41632@github.com>

On Tue, 6 Feb 2024 22:59:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
> 
> Passes tier1-7.

This pull request has now been integrated.

Changeset: 1877a487
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1877a4879598356b777742fe80bdd5fa77ca8e8d
Stats:     165 lines in 11 files changed: 87 ins; 43 del; 35 mod

8308745: ObjArrayKlass::allocate_objArray_klass may call into java while holding a lock

Reviewed-by: dlong, dholmes, fparain

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

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

From amenkov at openjdk.org  Fri Mar  8 19:32:53 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 8 Mar 2024 19:32:53 GMT
Subject: RFR: 8327645: Serial heap dump should not consume double amount of
 disk space [v2]
In-Reply-To: <1ZEoS1SowIyIioc8fxo_0XUkzz99UzIUAXnwtcztzOI=.ef955266-b117-42b3-8c2b-34241872f167@github.com>
References: <w0s7BM73-cxeWAZz9s42cfLgJPMafLsWfQhnlZ4pakk=.bafbcb0f-94c9-41bd-9226-71979a76800a@github.com>
 <1ZEoS1SowIyIioc8fxo_0XUkzz99UzIUAXnwtcztzOI=.ef955266-b117-42b3-8c2b-34241872f167@github.com>
Message-ID: <YXgR6v9mPpcmF1HJLj0vezz5dw3ikwUZ8P2X7E49_fo=.b5ebed60-4796-43c3-a8cf-d34886fa2022@github.com>

On Fri, 8 Mar 2024 02:35:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this fix to make serial heap dump only write to a single file?
>> We highly appreciate the work in https://bugs.openjdk.org/browse/JDK-8306441. However, many of our customers still need to use serial heap dump, as they have limited disk space and need to dump to a network socket.
>> 
>> Tested:
>> Stress tested with a fastdebug build with tests in `hotspot/jtreg/serviceability/dcmd/gc/HeapDump*`.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix failure under -XX:+UseSerialGC

Right, global writer is used to write HPROF_FRAME/HPROF_TRACE records when unmounted VT is found in the heap.
The spec does not require HPROF_FRAME/HPROF_TRACE to be in the beginning. Main concern here is compatibility as we don't control external hprof tools.
Solution #2 looks better to me.
It does not require extra memory to track unmounted VT (we may have millions) and it can prevent compatibility problem if we first write HPROF_FRAME/HPROF_TRACE records and then HPROF_GC_ROOT_THREAD_OBJ and stack reference subrecords which refer to the HPROF_TRACE

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

PR Comment: https://git.openjdk.org/jdk/pull/18160#issuecomment-1986286463

From sspitsyn at openjdk.org  Fri Mar  8 19:49:00 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Mar 2024 19:49:00 GMT
Subject: Integrated: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly
In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
Message-ID: <xTIZ_h8OCGPdwAAuDJfZD3136IZ-FztPKre3jYGl_SE=.58df8eee-3d7c-4962-888a-c7e3ba1e186f@github.com>

On Wed, 21 Feb 2024 10:28:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
> 
> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
> 
> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
> 
> Testing:
>  - tested with the mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 33aa4b26
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33aa4b26b190927241a81fd1cba6fe262a5b1da0
Stats:     73 lines in 10 files changed: 41 ins; 15 del; 17 mod

8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

Reviewed-by: dholmes, lmesnik

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

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

From lmesnik at openjdk.org  Fri Mar  8 20:38:37 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 8 Mar 2024 20:38:37 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of othervm
Message-ID: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>

vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
This fix updates tests to run debugger as driver to optimize execution time.
The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
Tested by running all tests, with '-Xcomp' and virtual thread test factory.

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

Commit messages:
 - tests updated to use driver.

Changes: https://git.openjdk.org/jdk/pull/18174/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18174&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327704
  Stats: 7439 lines in 2084 files changed: 2794 ins; 228 del; 4417 mod
  Patch: https://git.openjdk.org/jdk/pull/18174.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18174/head:pull/18174

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

From weijun at openjdk.org  Fri Mar  8 22:07:03 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Mar 2024 22:07:03 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v6]
In-Reply-To: <adgnE1ZwtDKKxv_AEH3wcVmAcRZVFBF-aKZtq1Kx-KU=.dac68066-409a-472d-a7d7-67e108401845@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <adgnE1ZwtDKKxv_AEH3wcVmAcRZVFBF-aKZtq1Kx-KU=.dac68066-409a-472d-a7d7-67e108401845@github.com>
Message-ID: <rS5w4MROThlrUOyDhecx5MGgu9NMPJSBqzbxWJ5w9ng=.b4942665-0c60-40fb-8bbd-e84c70abaf55@github.com>

On Thu, 7 Mar 2024 22:00:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Clarify deprecation comment.
>  - typo
>  - Remove additional passing of delegatedSubject in ClientListenerInfo and ClientNotifForwarder

src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java line 2:

> 1: /*
> 2:  * Copyright (c) 2002, 2024 Oracle and/or its affiliates. All rights reserved.

Missing `,` after 2024.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1518357791

From lmesnik at openjdk.org  Fri Mar  8 22:59:46 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 8 Mar 2024 22:59:46 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v2]
In-Reply-To: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
Message-ID: <s5SIJiG722csPFmQtJSvS5kglrOWC6l2OxWBP1_PPBY=.f0247aaa-c6ea-41cb-b7d5-23533b4bdb8a@github.com>

> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
> This fix updates tests to run debugger as driver to optimize execution time.
> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
> Tested by running all tests, with '-Xcomp' and virtual thread test factory.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  don't classpath if set by test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18174/files
  - new: https://git.openjdk.org/jdk/pull/18174/files/3c6eb52a..ce7bbb56

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

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

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

From cjplummer at openjdk.org  Sat Mar  9 02:31:57 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 9 Mar 2024 02:31:57 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v2]
In-Reply-To: <s5SIJiG722csPFmQtJSvS5kglrOWC6l2OxWBP1_PPBY=.f0247aaa-c6ea-41cb-b7d5-23533b4bdb8a@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <s5SIJiG722csPFmQtJSvS5kglrOWC6l2OxWBP1_PPBY=.f0247aaa-c6ea-41cb-b7d5-23533b4bdb8a@github.com>
Message-ID: <vJlg59eGB6sMwRMj0WnbZwwBG9E27xdgqW3bilid7AE=.272f0b11-ffc3-4d59-943a-dfd740a0c720@github.com>

On Fri, 8 Mar 2024 22:59:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't classpath if set by test.

If you missed removing a System.exit(), what would the symptoms be if called?

Can you give us examples of before and after failure modes?

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-1986698767

From gli at openjdk.org  Sat Mar  9 04:35:56 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 9 Mar 2024 04:35:56 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <wJkJ2qFwd6o2UrZ2sA1pGmj9J2uHj_fa3TmmrkE80zQ=.7e76b080-600b-4eb6-947e-358bd6c57eb6@github.com>

On Fri, 8 Mar 2024 02:54:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> The fix updates ClassFileParser to calculate correct attributes_count.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 27:

> 25:  * @test
> 26:  * @bug 8315575
> 27:  * @summary test that records with invisible annotation can be retfansformed

Typo `retfansformed`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1518468461

From lmesnik at openjdk.org  Sat Mar  9 04:36:52 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 9 Mar 2024 04:36:52 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v2]
In-Reply-To: <vJlg59eGB6sMwRMj0WnbZwwBG9E27xdgqW3bilid7AE=.272f0b11-ffc3-4d59-943a-dfd740a0c720@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <s5SIJiG722csPFmQtJSvS5kglrOWC6l2OxWBP1_PPBY=.f0247aaa-c6ea-41cb-b7d5-23533b4bdb8a@github.com>
 <vJlg59eGB6sMwRMj0WnbZwwBG9E27xdgqW3bilid7AE=.272f0b11-ffc3-4d59-943a-dfd740a0c720@github.com>
Message-ID: <Z3HlpdqI9TKAmRLuF-8OBV80b7LlHDgQwOQuo8BaJBA=.5287af67-4251-40a5-a613-8f835dada551@github.com>

On Sat, 9 Mar 2024 02:29:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you missed removing a System.exit(), what would the symptoms be if called?
> 
> Can you give us examples of before and after failure modes?

The test which is executed as driver and call System.exit() fails with following message:

Debuggee's process finished with status: 95

TEST RESULT: Error. Agent communication error: java.io.EOFException; check console log for any additional details

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-1986725983

From lmesnik at openjdk.org  Sat Mar  9 05:27:43 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 9 Mar 2024 05:27:43 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
Message-ID: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>

> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
> This fix updates tests to run debugger as driver to optimize execution time.
> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
> Tested by running all tests, with '-Xcomp' and virtual thread test factory.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  reverted failing tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18174/files
  - new: https://git.openjdk.org/jdk/pull/18174/files/ce7bbb56..01258fb1

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

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

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

From dholmes at openjdk.org  Mon Mar 11 02:24:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Mar 2024 02:24:58 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v23]
In-Reply-To: <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
Message-ID: <te5h118J3ogdOkIVqldKlvL0OWyQF7nT-qNJcZy3Ws8=.86d6ad2d-02c8-4798-a413-d338095d04e0@github.com>

On Fri, 8 Mar 2024 06:11:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge
>  - review: minor tweak in test description of ObjectMonitorUsage.java
>  - review: addressed more comments on the fix and new test
>  - rename after merge: jvmti_common.h to jvmti_common.hpp
>  - Merge
>  - review: update comment in threads.hpp
>  - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
>  - resolve merge conflict for deleted file objmonusage003.cpp
>  - fix a typo in libObjectMonitorUsage.cpp
>  - fix potential sync gap in the test ObjectMonitorUsage
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/de428daf...b97b8205

Looks good. Thanks.

Sorry it has taken me so long to work through this one. It seemed so simple when I filed the bug :)

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1926797746

From dholmes at openjdk.org  Mon Mar 11 02:24:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Mar 2024 02:24:58 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v22]
In-Reply-To: <5lsZBFSbWmDQVJe9tGr2Rll00SWkbU7HBuRpEC_-Duo=.167e62b6-ca47-4a93-b8ad-7c22b379221d@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <MqG0WJIaRZngeD4pdElLllp3nRheZGyGzj7qP1ep39c=.ff71b9b6-c073-4443-9127-6a987a150114@github.com>
 <4XAkV4CDJUTXFeKCCkAQlD_HntnLWwd_AqcTEMowS4k=.f5d2572f-3061-4a56-bf9d-e97bda57e3a0@github.com>
 <bmW0pAoszAMHZIK56cZV2qSipSDJd3-TKQsIbIjqGK8=.57a09305-a46f-4423-bfff-d7f1d2b8fb49@github.com>
 <5lsZBFSbWmDQVJe9tGr2Rll00SWkbU7HBuRpEC_-Duo=.167e62b6-ca47-4a93-b8ad-7c22b379221d@github.com>
Message-ID: <_uXZSNczXm2ODdcowDzJZleDqNWUL6o97XAX10pWnBA=.9641d2c4-2738-422a-b882-0c3c9b408ad1@github.com>

On Tue, 5 Mar 2024 09:04:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The loop is endless without this extra condition, so we are getting a test execution timeout.
>> The `waiters` seems to be `circular doubly linked list` as we can see below:
>> 
>> inline void ObjectMonitor::AddWaiter(ObjectWaiter* node) {
>>   assert(node != nullptr, "should not add null node");
>>   assert(node->_prev == nullptr, "node already in list");
>>   assert(node->_next == nullptr, "node already in list");
>>   // put node at end of queue (circular doubly linked list)
>>   if (_WaitSet == nullptr) {
>>     _WaitSet = node;
>>     node->_prev = node;
>>     node->_next = node;
>>   } else {
>>     ObjectWaiter* head = _WaitSet;
>>     ObjectWaiter* tail = head->_prev;
>>     assert(tail->_next == head, "invariant check");
>>     tail->_next = node;
>>     head->_prev = node;
>>     node->_next = head;
>>     node->_prev = tail;
>>   }
>> }
>> 
>> I'll make sure nothing is missed and check the old code again.
>
> Okay. Now I see why the old code did not have endless loops.

Apologies I should have checked the code - I'd forgotten the list is circular to avoid needing an explicit tail pointer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1519058800

From dholmes at openjdk.org  Mon Mar 11 02:24:59 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Mar 2024 02:24:59 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <nkfadUboYD0Q9HlfzR8aOBo396nm_I4Sc5qUM5DYIzc=.da320e46-26db-46d6-a7b0-19469677ae59@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
 <nkfadUboYD0Q9HlfzR8aOBo396nm_I4Sc5qUM5DYIzc=.da320e46-26db-46d6-a7b0-19469677ae59@github.com>
Message-ID: <GdyqukXze9zAL5bV_8ZezA5jyked4uv_ugwRY8PNhdg=.0bd1f690-a2a0-46fc-8263-485c65b8bde5@github.com>

On Mon, 4 Mar 2024 10:09:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 319:
>> 
>>> 317:                 try {
>>> 318:                     ready = true;
>>> 319:                     lockCheck.wait();
>> 
>> Spurious wakeups will break this test. They shouldn't happen but ...
>
> I have an idea how to fix it but it will add extra complexity. Not sure it is worth it.
> It is possible to identify there was a spurious wakeup and invalidate the sub-test result in such a case.
> Not sure if it is important to rerun the sub-test then.
> What do you think?

Sorry I missed this response. I can't see a way to address spurious wakeups in this case as it needs to be a per-thread flag (so that each thread knows it was notified) but you don't know which thread will be notified in any given call to `notify()`. I also can't see how you can detect a spurious wakeup in this code. If they happen then a subtest may fail due to an unexpected number of re-entering threads.
I think we will just have to see how stable the test is in practice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1519071056

From dholmes at openjdk.org  Mon Mar 11 04:55:53 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Mar 2024 04:55:53 GMT
Subject: RFR: JDK-8327468: Do not restart close if errno is EINTR
 [macOS/linux]
In-Reply-To: <AlmDWCunDXJSZvl1emA6Lwsb4Maaea0K6E97Q7a2XtM=.8b6d6fcf-c411-4cc4-8582-0044254f4875@github.com>
References: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
 <JuUExTBhr29_fnh89atKoz58a3exTci0jKGdPtGbwgs=.224e4967-b3bc-4516-8575-a13e2c169b3f@github.com>
 <AlmDWCunDXJSZvl1emA6Lwsb4Maaea0K6E97Q7a2XtM=.8b6d6fcf-c411-4cc4-8582-0044254f4875@github.com>
Message-ID: <pJrFDLPsCXgKZmNGN3Zoq_IbAXRepoDshiQVzJmSAec=.1feca5cc-f0cb-489a-8065-342ba5d455db@github.com>

On Fri, 8 Mar 2024 12:12:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c line 200:
>> 
>>> 198:     if (res == -1) {
>>> 199:         JNU_ThrowIOExceptionWithLastError(env, "close");
>>> 200:     }
>> 
>> I assume it would be better to not throw when errno is EINTR. If there is a profiler or some other tool firing signals at threads then there isn't anything that can be done here.
>
> Should I just ignore the result / return code of close and avoid throwing an exception completely ?

I would just ignore any error on close in this case and treat it as a best-effort attempt at closing the fd. The close could be successful even if an error is reported; conversely if a signal-based profiler is used (whether they use SA_RESTART or not) we don't want the profiler's actions to cause application/library exceptions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18164#discussion_r1519155640

From dholmes at openjdk.org  Mon Mar 11 05:04:53 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Mar 2024 05:04:53 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <odz4iicW8tjcJLV9hwjVvYhpnKLlVmEJk1O8Z_XSiFA=.4cde3ead-25ca-449e-af31-3bb8ffea34f9@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

> There is not need to start debugger in the separate process for each test.

I don't think I agree with that. Don't we want to have the debugger in a well known initial state for each test?

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-1987638497

From mbaesken at openjdk.org  Mon Mar 11 08:50:09 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 11 Mar 2024 08:50:09 GMT
Subject: RFR: JDK-8327468: Do not restart close if errno is EINTR
 [macOS/linux] [v2]
In-Reply-To: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
References: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
Message-ID: <ehBGokTt4vhU1VIwrMdhRie1r06Aylqr9XM0NO-q0mo=.6bb86b9d-e762-4ecc-b5d4-aaddcc605e39@github.com>

> There are a number of places remaining in the linux/macOS native JDK codebase where we use the RESTARTABLE macro with close, but this is unwanted on Linux/macOS.

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

  do not throw exception on close error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18164/files
  - new: https://git.openjdk.org/jdk/pull/18164/files/32d05ccd..7ed2cc07

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

  Stats: 19 lines in 2 files changed: 0 ins; 16 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18164.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18164/head:pull/18164

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

From mbaesken at openjdk.org  Mon Mar 11 09:03:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 11 Mar 2024 09:03:54 GMT
Subject: RFR: JDK-8327468: Do not restart close if errno is EINTR
 [macOS/linux] [v2]
In-Reply-To: <ehBGokTt4vhU1VIwrMdhRie1r06Aylqr9XM0NO-q0mo=.6bb86b9d-e762-4ecc-b5d4-aaddcc605e39@github.com>
References: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
 <ehBGokTt4vhU1VIwrMdhRie1r06Aylqr9XM0NO-q0mo=.6bb86b9d-e762-4ecc-b5d4-aaddcc605e39@github.com>
Message-ID: <CHXU-R3-gtFTOP6c7vXovkodJeMz6u8tV2rWpQdRwvU=.e3beea6c-32f3-4385-8a7d-26a68a76d885@github.com>

On Mon, 11 Mar 2024 08:50:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a number of places remaining in the linux/macOS native JDK codebase where we use the RESTARTABLE macro with close, but this is unwanted on Linux/macOS.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not throw exception on close error

Looks like the return code of close is mostly (98-99 % ?) ignored in the JDK codebase.  So probably we should follow for now the usual approach in this PR too.
Btw. there are some places in the codebase where the return code of close is checked/handled e.g. 
https://github.com/openjdk/jdk/blob/f2b5ffdb8ea3c766f14bab1dfd7c3865cffa2ce8/src/java.base/unix/native/libnet/SdpSupport.c#L109

or

https://github.com/openjdk/jdk/blob/f2b5ffdb8ea3c766f14bab1dfd7c3865cffa2ce8/src/java.base/unix/native/libnio/ch/UnixDispatcher.c#L37

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

PR Comment: https://git.openjdk.org/jdk/pull/18164#issuecomment-1987915306

From kevinw at openjdk.org  Mon Mar 11 10:09:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 11 Mar 2024 10:09:28 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  (C) oops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/4beae2f2..f5794c43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=05-06

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

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

From kevinw at openjdk.org  Mon Mar 11 10:09:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 11 Mar 2024 10:09:28 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v6]
In-Reply-To: <rS5w4MROThlrUOyDhecx5MGgu9NMPJSBqzbxWJ5w9ng=.b4942665-0c60-40fb-8bbd-e84c70abaf55@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <adgnE1ZwtDKKxv_AEH3wcVmAcRZVFBF-aKZtq1Kx-KU=.dac68066-409a-472d-a7d7-67e108401845@github.com>
 <rS5w4MROThlrUOyDhecx5MGgu9NMPJSBqzbxWJ5w9ng=.b4942665-0c60-40fb-8bbd-e84c70abaf55@github.com>
Message-ID: <VXmdmfOrYPTU2BcKx1rT5Ew-CcOoXXT32baSOI7Fvi8=.7721c2af-2ebe-4e2e-a737-d69655f37b5c@github.com>

On Fri, 8 Mar 2024 22:04:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Missing `,` after 2024.

oops, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1519459149

From sspitsyn at openjdk.org  Mon Mar 11 10:26:59 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 11 Mar 2024 10:26:59 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v23]
In-Reply-To: <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
Message-ID: <72l1Ns-4YP_MMpGTjK-jTuakSs2-G4HuntRfrgc3Ls0=.85d5c80c-8db4-4d7d-a798-f7050cddfa2c@github.com>

On Fri, 8 Mar 2024 06:11:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge
>  - review: minor tweak in test description of ObjectMonitorUsage.java
>  - review: addressed more comments on the fix and new test
>  - rename after merge: jvmti_common.h to jvmti_common.hpp
>  - Merge
>  - review: update comment in threads.hpp
>  - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
>  - resolve merge conflict for deleted file objmonusage003.cpp
>  - fix a typo in libObjectMonitorUsage.cpp
>  - fix potential sync gap in the test ObjectMonitorUsage
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/de428daf...b97b8205

> Sorry I missed this response. I can't see a way to address spurious wakeups in this case as it needs to be a per-thread flag (so that each thread knows it was notified) but you don't know which thread will be notified in any given call to notify(). I also can't see how you can detect a spurious wakeup in this code. If they happen then a subtest may fail due to an unexpected number of re-entering threads. I think we will just have to see how stable the test is in practice.

Okay, thanks! Let's see if we ever encounter any spurious wakeup in this test.

Than you a lot for thorough review, David!

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1988074775
PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1988076636

From dfuchs at openjdk.org  Mon Mar 11 16:32:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 11 Mar 2024 16:32:18 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v5]
In-Reply-To: <LdiC1iOnUOOy4ZMjrzxyQUudv67BRB9PhzvHUCf5FCo=.b4de5198-089b-4ed4-991e-590a033d5a17@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
 <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>
 <LdiC1iOnUOOy4ZMjrzxyQUudv67BRB9PhzvHUCf5FCo=.b4de5198-089b-4ed4-991e-590a033d5a17@github.com>
Message-ID: <3wr96ORHqThVPL-jv9eLazPROui87Muw2kgfQ9nJh3k=.9482f911-64d2-48cf-87a2-48718e30b857@github.com>

On Fri, 8 Mar 2024 10:20:36 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.

No issue with deprecation. I guess it can be removed once `java.security.Policy` is removed?

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1988693902

From lmesnik at openjdk.org  Mon Mar 11 16:32:20 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 11 Mar 2024 16:32:20 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <OCjKqCYmp4gLLC5fGio8WYYaAWyy6hcVKnbM5Q_HDZo=.b5d55366-17e9-4e63-b5a3-16aa7d010d52@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

That's a good question. 
Each test creates a new connector, starts new vm process with debugee and launch com.sun.jdi.VirtualMachine. I expect that it should be fine to run all of them in same vm. We are already use the same mode for com/sun/jdi jdk regression tests.
Moreover, it should be a bug if we can't run all these tests in the same vm process.

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-1988761928

From dfuchs at openjdk.org  Mon Mar 11 17:25:55 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 11 Mar 2024 17:25:55 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
Message-ID: <cXTbBh8OpL4uifNpTGkTWpJX-lv699_dloHdfVQf6no=.898d62b5-6331-487b-a81a-a6af1a7715b8@github.com>

On Mon, 11 Mar 2024 10:09:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C) oops

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java line 618:

> 616:                 throw new SecurityException("Subject Delegation has been removed.");
> 617:             }
> 618:         }

Can't this constructor be removed? It's a private inner class so we should be able to throw before calling that constructor?

test/jdk/javax/management/remote/mandatory/notif/DeadListenerTest.java line 78:

> 76:         cs.start();
> 77:         JMXServiceURL addr = cs.getAddress();
> 78:         assertTrue("Expected no connections in new connector server", rmiServer.connections.isEmpty());

Changes to this file seem unrelated to the removal of the feature - could you confirm that they were intended (no issue if they were intended).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520108369
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520127466

From dcubed at openjdk.org  Mon Mar 11 17:40:02 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 11 Mar 2024 17:40:02 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v23]
In-Reply-To: <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
Message-ID: <GyQFbPZfbvtWsC50h0dTsxoRtzLJxX89aCD6zuNvQNE=.bb18f7f7-adbb-4677-a78f-c442fa477909@github.com>

On Fri, 8 Mar 2024 06:11:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge
>  - review: minor tweak in test description of ObjectMonitorUsage.java
>  - review: addressed more comments on the fix and new test
>  - rename after merge: jvmti_common.h to jvmti_common.hpp
>  - Merge
>  - review: update comment in threads.hpp
>  - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
>  - resolve merge conflict for deleted file objmonusage003.cpp
>  - fix a typo in libObjectMonitorUsage.cpp
>  - fix potential sync gap in the test ObjectMonitorUsage
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/de428daf...b97b8205

I last reviewed v02 of this PR so I've jumped forward to the full v22 webrev. It may take
me a bit of time to redo this review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1989046765

From sgehwolf at openjdk.org  Mon Mar 11 17:45:06 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Mar 2024 17:45:06 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container
Message-ID: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>

Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:


[0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present


This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:


java -XshowSettings:system --version
Operating System Metrics:
    Provider: cgroupv1
    System not containerized.
openjdk 23-internal 2024-09-17
OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)


The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.

Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.

Testing:

- [x] GHA (risc-v failure seems infra related)
- [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
- [x] Some manual testing using cri-o

Thoughts?

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

Commit messages:
 - jcheck fixes
 - Fix tests
 - Implement Metrics.isContainerized()
 - Some clean-up
 - Drop cgroups testing on plain Linux
 - Implement fall-back logic for non-ro controller mounts
 - Make find_ro static and local to compilation unit
 - 8261242: [Linux] OSContainer::is_containerized() returns true

Changes: https://git.openjdk.org/jdk/pull/18201/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8261242
  Stats: 360 lines in 20 files changed: 258 ins; 78 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/18201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18201/head:pull/18201

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

From mchung at openjdk.org  Mon Mar 11 18:05:56 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Mar 2024 18:05:56 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
Message-ID: <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>

On Mon, 11 Mar 2024 10:09:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C) oops

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 126:

> 124:      * @param className The class name of the MBean to be instantiated.
> 125:      * @param name The object name of the MBean. May be null.
> 126:      * @param delegationSubject No longer supported and should be null.

I think it can be simplified to:

Suggestion:

     * @param delegationSubject must be {@code null}.


I see no need to mention this feature no longer supported as no one is using and will use this feature.

Same comment applies to all methods that take `delegationSubject`.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 157:

> 155:      * @throws IOException if a general communication exception occurred.
> 156:      * @throws UnsupportedOperationException if a non-null delegationSubject
> 157:      * is specified. Subject Delegation has been removed.

This can be simplified to:

Suggestion:

     * @throws UnsupportedOperationException if {@code delegationSubject} is non-null


Same comment applies to all methods that take `delegationSubject`.

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 139:

> 137:     /**
> 138:      * <p>This method remains for compatibility reasons, but has no more meaning
> 139:      * than {@link #getMBeanServerConnection()}.

Suggestion:

     * <p>This method is equivalent to calling {@link #getMBeanServerConnection()}.

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 142:

> 140:      *
> 141:      * @param delegationSubject must be null, since the removal of the
> 142:      * Subject Delegation feature.

Suggestion:

     * @param delegationSubject must be {@code null}

src/java.management/share/classes/javax/management/remote/JMXConnector.java line 153:

> 151:      *
> 152:      * @exception UnsupportedOperationException if a non-null delegationSubject
> 153:      * is specified. Subject Delegation has been removed.

Suggestion:

     * @exception UnsupportedOperationException if {@code delegationSubject} is non-null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520188392
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520183154
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520165902
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520166471
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520170490

From cjplummer at openjdk.org  Mon Mar 11 18:13:56 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 11 Mar 2024 18:13:56 GMT
Subject: RFR: 8324868: debug agent does not properly handle interrupts of a
 virtual thread [v2]
In-Reply-To: <IoMgMfJeIP6Tp3qBqEVxuyAleMRBBsZpgKoybWrU7o4=.3b09572e-d731-4f91-91ce-9ad3fd4b86aa@github.com>
References: <VrbUMLScozKhqXew9izxE2JkM0hsos6_QcO0STXVGzk=.f5f1e451-57bc-498d-80c9-75a96d86e86a@github.com>
 <IoMgMfJeIP6Tp3qBqEVxuyAleMRBBsZpgKoybWrU7o4=.3b09572e-d731-4f91-91ce-9ad3fd4b86aa@github.com>
Message-ID: <AMtKkfHjPhe0NuN5rYBAF4340r7MlBvyf3BGjiTb1LA=.7ddd207f-4bcc-49a1-9712-3e68219dcf1e@github.com>

On Wed, 28 Feb 2024 22:10:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fix numerous debug agent issues and testing deficiencies related to Thread.interrupt(). As a first read you should look at the description in the CR. More details in first comment below.
>> 
>> Also, this PR is dependent on the fix for [JDK-8325187](https://bugs.openjdk.org/browse/JDK-8325187). The test might generate GHA failures in the meantime.
>> 
>> Tested with all svc tier1, tier2, and tier5 tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feed back. fix up some comments.

Ping! Still looking for a 2nd review. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17989#issuecomment-1989123306

From sspitsyn at openjdk.org  Mon Mar 11 18:10:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 11 Mar 2024 18:10:58 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <GdyqukXze9zAL5bV_8ZezA5jyked4uv_ugwRY8PNhdg=.0bd1f690-a2a0-46fc-8263-485c65b8bde5@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
 <nkfadUboYD0Q9HlfzR8aOBo396nm_I4Sc5qUM5DYIzc=.da320e46-26db-46d6-a7b0-19469677ae59@github.com>
 <GdyqukXze9zAL5bV_8ZezA5jyked4uv_ugwRY8PNhdg=.0bd1f690-a2a0-46fc-8263-485c65b8bde5@github.com>
Message-ID: <mtDpXdjUHboGAKaqCT3SqCH49ZkUzh-YB7WzYEI2JAI=.12ba563e-d225-48bb-b27b-c072484da10e@github.com>

On Mon, 11 Mar 2024 02:18:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I have an idea how to fix it but it will add extra complexity. Not sure it is worth it.
>> It is possible to identify there was a spurious wakeup and invalidate the sub-test result in such a case.
>> Not sure if it is important to rerun the sub-test then.
>> What do you think?
>
> Sorry I missed this response. I can't see a way to address spurious wakeups in this case as it needs to be a per-thread flag (so that each thread knows it was notified) but you don't know which thread will be notified in any given call to `notify()`. I also can't see how you can detect a spurious wakeup in this code. If they happen then a subtest may fail due to an unexpected number of re-entering threads.
> I think we will just have to see how stable the test is in practice.

Okay, thanks! I'll add some diagnostic code to catch spurious wakups.
Let's see if we ever encounter any spurious wakeup in this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520204046

From amenkov at openjdk.org  Mon Mar 11 18:28:50 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 11 Mar 2024 18:28:50 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v2]
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <alzCvsdVPHUjKvKXJ6UoYOvZ2rUUNjoJsHpUq3fQ-Ew=.e359b6e2-02c0-4438-8934-535202d5152d@github.com>

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> The fix updates ClassFileParser to calculate correct attributes_count.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18161/files
  - new: https://git.openjdk.org/jdk/pull/18161/files/5f1d0116..1ad6997d

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

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

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

From dfuchs at openjdk.org  Mon Mar 11 18:45:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 11 Mar 2024 18:45:18 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
Message-ID: <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>

On Mon, 11 Mar 2024 17:56:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (C) oops
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 126:
> 
>> 124:      * @param className The class name of the MBean to be instantiated.
>> 125:      * @param name The object name of the MBean. May be null.
>> 126:      * @param delegationSubject No longer supported and should be null.
> 
> I think it can be simplified to:
> 
> Suggestion:
> 
>      * @param delegationSubject must be {@code null}.
> 
> 
> I see no need to mention this feature no longer supported as no one is using and will use this feature.
> 
> Same comment applies to all methods that take `delegationSubject`.

I was wondering if we should add a note at the class-level API documentation to say that subject delegation has been removed (or is no longer supported), and that methods will throw UOE if a non-null delegation subject is passed. It is otherwise strange to see a parameter that must be null. It could be worthwhile to mention it just once, at the class-level API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520260840

From dfuchs at openjdk.org  Mon Mar 11 18:53:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 11 Mar 2024 18:53:15 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
 <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>
Message-ID: <pQrsuvbQ8JnvEI17nHEG_yb_7AECk-SujOc_YOj7CaI=.d741cb3f-5753-408a-a903-994d469f9216@github.com>

On Mon, 11 Mar 2024 18:39:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 126:
>> 
>>> 124:      * @param className The class name of the MBean to be instantiated.
>>> 125:      * @param name The object name of the MBean. May be null.
>>> 126:      * @param delegationSubject No longer supported and should be null.
>> 
>> I think it can be simplified to:
>> 
>> Suggestion:
>> 
>>      * @param delegationSubject must be {@code null}.
>> 
>> 
>> I see no need to mention this feature no longer supported as no one is using and will use this feature.
>> 
>> Same comment applies to all methods that take `delegationSubject`.
>
> I was wondering if we should add a note at the class-level API documentation to say that subject delegation has been removed (or is no longer supported), and that methods will throw UOE if a non-null delegation subject is passed. It is otherwise strange to see a parameter that must be null. It could be worthwhile to mention it just once, at the class-level API.

Maybe mention there too that the delegationSubject parameter is kept for interoperability with older remote clients.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520271921

From dcubed at openjdk.org  Mon Mar 11 18:56:29 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 11 Mar 2024 18:56:29 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <mtDpXdjUHboGAKaqCT3SqCH49ZkUzh-YB7WzYEI2JAI=.12ba563e-d225-48bb-b27b-c072484da10e@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
 <nkfadUboYD0Q9HlfzR8aOBo396nm_I4Sc5qUM5DYIzc=.da320e46-26db-46d6-a7b0-19469677ae59@github.com>
 <GdyqukXze9zAL5bV_8ZezA5jyked4uv_ugwRY8PNhdg=.0bd1f690-a2a0-46fc-8263-485c65b8bde5@github.com>
 <mtDpXdjUHboGAKaqCT3SqCH49ZkUzh-YB7WzYEI2JAI=.12ba563e-d225-48bb-b27b-c072484da10e@github.com>
Message-ID: <WqyTpQK8VneIYfCLAnRB9bvQvxJq-0-8uXf_YihLjb0=.671b1d50-0e99-48f6-9f83-7153a5f22b6c@github.com>

On Mon, 11 Mar 2024 18:08:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Sorry I missed this response. I can't see a way to address spurious wakeups in this case as it needs to be a per-thread flag (so that each thread knows it was notified) but you don't know which thread will be notified in any given call to `notify()`. I also can't see how you can detect a spurious wakeup in this code. If they happen then a subtest may fail due to an unexpected number of re-entering threads.
>> I think we will just have to see how stable the test is in practice.
>
> Okay, thanks! I'll add some diagnostic code to catch spurious wakups.
> Let's see if we ever encounter any spurious wakeup in this test.

I think some sort of comment needs to be added here to document
the possibility of this code path being affect by a spurious wakeup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520260059

From dcubed at openjdk.org  Mon Mar 11 18:56:28 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 11 Mar 2024 18:56:28 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v23]
In-Reply-To: <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
Message-ID: <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>

On Fri, 8 Mar 2024 06:11:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge
>  - review: minor tweak in test description of ObjectMonitorUsage.java
>  - review: addressed more comments on the fix and new test
>  - rename after merge: jvmti_common.h to jvmti_common.hpp
>  - Merge
>  - review: update comment in threads.hpp
>  - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
>  - resolve merge conflict for deleted file objmonusage003.cpp
>  - fix a typo in libObjectMonitorUsage.cpp
>  - fix potential sync gap in the test ObjectMonitorUsage
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/de428daf...b97b8205

Thumbs up on the v22 version of this change. Of course, I'm assuming
that the updated tests pass and that there are no new failures in the
usual Mach5 testing.

Sorry for the delay in getting back to this review. A combination of
vacation following by illness delayed me getting back to this PR.

Please note that I did not try to compare the (deleted) objmonusage003
version of the test with the (new) ObjectMonitorUsage version. I didn't
think that would be useful.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1483:

> 1481:   markWord mark = hobj->mark();
> 1482:   ResourceMark rm(current_thread);
> 1483:   GrowableArray<JavaThread*>* wantList = nullptr;

Thanks for refactoring `JvmtiEnvBase::get_object_monitor_usage()` to
be much more clear. It was difficult to review in GitHub so I switched to
the webrev frames view so that I could scroll the two sides back and forth
and determine equivalence.

src/hotspot/share/runtime/threads.cpp line 1186:

> 1184: 
> 1185: #if INCLUDE_JVMTI
> 1186: // Get count Java threads that are waiting to enter or re-enter the specified monitor.

nit typo: s/count Java/count of Java/

src/hotspot/share/runtime/threads.hpp line 134:

> 132:   static unsigned print_threads_compiling(outputStream* st, char* buf, int buflen, bool short_form = false);
> 133: 
> 134:   // Get count Java threads that are waiting to enter or re-enter the specified monitor.

nit typo: s/count Java/count of Java/

Also this file needs a copyright year update.

test/hotspot/jtreg/TEST.quick-groups line 972:

> 970:   vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java \
> 971:   vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage002/TestDescription.java \
> 972:   vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/TestDescription.java \

This file needs a copyright year update.

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 79:

> 77:     waits_to_be_notified--;
> 78:   }
> 79: }

I like these for getting rid of the raciness of knowing when a thread is blocked
on contention, finished entering, blocked on wait or finished waiting. Nice!

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 202:

> 200:     LOG("(%d) notify_waiter_count expected: %d, actually: %d\n",
> 201:         check_idx, notifyWaiterCount, inf.notify_waiter_count);
> 202:     result = STATUS_FAILED;

Please consider prefixing these LOG output lines with "FAILED:" so that it
is easier to identify the log output where failure info is shown.

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 215:

> 213:   if (tested_monitor != nullptr) {
> 214:     jni->DeleteGlobalRef(tested_monitor);
> 215:   }

Since this is at the beginning of `setTestedMonitor` does it mean that we "leak"
the last global ref?

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java line 46:

> 44:  * @library /vmTestbase
> 45:  *          /test/lib
> 46:  * @run main/othervm/native -agentlib:objmonusage001=printdump nsk.jvmti.GetObjectMonitorUsage.objmonusage001

I only included this `=printdump` for debug when I was updating the test.
You don't have to keep it.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1928679264
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520200433
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520203806
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520208119
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520213205
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520271891
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520264870
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520266194
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520235253

From mchung at openjdk.org  Mon Mar 11 19:27:13 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Mar 2024 19:27:13 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <pQrsuvbQ8JnvEI17nHEG_yb_7AECk-SujOc_YOj7CaI=.d741cb3f-5753-408a-a903-994d469f9216@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
 <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>
 <pQrsuvbQ8JnvEI17nHEG_yb_7AECk-SujOc_YOj7CaI=.d741cb3f-5753-408a-a903-994d469f9216@github.com>
Message-ID: <n2gelGktTFdQGm7OWlv7j_45foPwmqV6S0DQ2z1FiRs=.6de8e9a2-7635-412a-a446-cfeb013fa15d@github.com>

On Mon, 11 Mar 2024 18:49:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I was wondering if we should add a note at the class-level API documentation to say that subject delegation has been removed (or is no longer supported), and that methods will throw UOE if a non-null delegation subject is passed. It is otherwise strange to see a parameter that must be null. It could be worthwhile to mention it just once, at the class-level API.
>
> Maybe mention there too that the delegationSubject parameter is kept for interoperability with older remote clients.

It's a good suggestion.   Something like this:

All methods that take a `Subject` parameter will throw UOE if called with a non-null subject delegation.  JMX subject delegation feature is no longer supported.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1520310935

From dcubed at openjdk.org  Mon Mar 11 19:36:20 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 11 Mar 2024 19:36:20 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v8]
In-Reply-To: <hNZSzjrksXootBKftj2muuBknJcwndfjhT38cXG4spc=.abb01112-a555-488f-a293-9ae77ad1ed88@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <hNZSzjrksXootBKftj2muuBknJcwndfjhT38cXG4spc=.abb01112-a555-488f-a293-9ae77ad1ed88@github.com>
Message-ID: <TS0s6GKqoPfSe4IxTcWRT29g3RmL8-w8p4Lq1FyM6rM=.c12b4d82-47bf-41d3-9bba-5de27d4249c8@github.com>

On Fri, 8 Mar 2024 06:05:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
>> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
>> 
>> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
>> 
>> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> 
>> Testing:
>>  - tested with the mach5 tiers 1-6
>
> 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 eight additional commits since the last revision:
> 
>  - Merge
>  - review: updated test desciption for two modified tests
>  - review: added new internal function JvmtiEnvBase::get_thread_or_vthread_state
>  - review: replaced timed with timed-out in JDWP and JDI spec
>  - Merge
>  - Merge
>  - fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method
>  - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

Thumbs up. I'm not sure how I missed reviewing this change so
I did a post-integration review.

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

PR Review: https://git.openjdk.org/jdk/pull/17944#pullrequestreview-1928978384

From dcubed at openjdk.org  Mon Mar 11 19:39:23 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 11 Mar 2024 19:39:23 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v8]
In-Reply-To: <hNZSzjrksXootBKftj2muuBknJcwndfjhT38cXG4spc=.abb01112-a555-488f-a293-9ae77ad1ed88@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <hNZSzjrksXootBKftj2muuBknJcwndfjhT38cXG4spc=.abb01112-a555-488f-a293-9ae77ad1ed88@github.com>
Message-ID: <0U6ldrYqLu2-H3Lzx35FxXgY9fb7FH3GqFts2bVFWeo=.a9f4488b-47a0-4194-bf76-c917571d6b6b@github.com>

On Fri, 8 Mar 2024 06:05:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
>> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
>> 
>> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
>> 
>> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> 
>> Testing:
>>  - tested with the mach5 tiers 1-6
>
> 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 eight additional commits since the last revision:
> 
>  - Merge
>  - review: updated test desciption for two modified tests
>  - review: added new internal function JvmtiEnvBase::get_thread_or_vthread_state
>  - review: replaced timed with timed-out in JDWP and JDI spec
>  - Merge
>  - Merge
>  - fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method
>  - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

I looked at the commit and it appears that not all copyright years got fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17944#issuecomment-1989283515

From mullan at openjdk.org  Mon Mar 11 21:08:13 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 11 Mar 2024 21:08:13 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v5]
In-Reply-To: <3wr96ORHqThVPL-jv9eLazPROui87Muw2kgfQ9nJh3k=.9482f911-64d2-48cf-87a2-48718e30b857@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
 <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>
 <LdiC1iOnUOOy4ZMjrzxyQUudv67BRB9PhzvHUCf5FCo=.b4de5198-089b-4ed4-991e-590a033d5a17@github.com>
 <3wr96ORHqThVPL-jv9eLazPROui87Muw2kgfQ9nJh3k=.9482f911-64d2-48cf-87a2-48718e30b857@github.com>
Message-ID: <JXJhm2lXQ4NzKEGMxNarDvxrfKELy7yVhROF-gOO9I0=.aa209286-fdc2-4327-848b-b3ab498c9f83@github.com>

On Mon, 11 Mar 2024 15:19:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.
> 
> No issue with deprecation. I guess it can be removed once `java.security.Policy` is removed?

Yes, or to be more precise, when the `JavaPolicy` implementation of `java.security.Policy` is removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1989444321

From amenkov at openjdk.org  Mon Mar 11 23:46:13 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 11 Mar 2024 23:46:13 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v2]
In-Reply-To: <wJkJ2qFwd6o2UrZ2sA1pGmj9J2uHj_fa3TmmrkE80zQ=.7e76b080-600b-4eb6-947e-358bd6c57eb6@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <wJkJ2qFwd6o2UrZ2sA1pGmj9J2uHj_fa3TmmrkE80zQ=.7e76b080-600b-4eb6-947e-358bd6c57eb6@github.com>
Message-ID: <eW7cRKS52y2QZKLkkpYXwzB3jo01XdwFFRWWGnO_uH4=.81ca26f9-3386-4f0b-bc72-c2983216e7a0@github.com>

On Sat, 9 Mar 2024 03:29:26 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8315575
>> 27:  * @summary test that records with invisible annotation can be retfansformed
> 
> Typo `retfansformed`.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1520552930

From sspitsyn at openjdk.org  Tue Mar 12 01:52:29 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 01:52:29 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v24]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <hmpXBIFAsMktGm6LWfej-4qR_67Z0vTOGKG4GXkCkQg=.3990bb51-f784-4b5a-8062-f572421fd02c@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  improved new test: added wakeup warning; polished test ouput

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/b97b8205..94ebf725

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=22-23

  Stats: 61 lines in 2 files changed: 45 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

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

From sspitsyn at openjdk.org  Tue Mar 12 01:58:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 01:58:21 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v23]
In-Reply-To: <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
 <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
Message-ID: <vkpAP04puwdOwlQ6TsKPvfgQsrLRm4BK_FhwlOXuNEQ=.2b61d824-d49b-4878-a74f-324d7fb42b10@github.com>

On Mon, 11 Mar 2024 18:08:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Merge
>>  - review: minor tweak in test description of ObjectMonitorUsage.java
>>  - review: addressed more comments on the fix and new test
>>  - rename after merge: jvmti_common.h to jvmti_common.hpp
>>  - Merge
>>  - review: update comment in threads.hpp
>>  - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
>>  - resolve merge conflict for deleted file objmonusage003.cpp
>>  - fix a typo in libObjectMonitorUsage.cpp
>>  - fix potential sync gap in the test ObjectMonitorUsage
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/de428daf...b97b8205
>
> src/hotspot/share/runtime/threads.cpp line 1186:
> 
>> 1184: 
>> 1185: #if INCLUDE_JVMTI
>> 1186: // Get count Java threads that are waiting to enter or re-enter the specified monitor.
> 
> nit typo: s/count Java/count of Java/

Thanks, fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520714780

From sspitsyn at openjdk.org  Tue Mar 12 02:07:24 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 02:07:24 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v23]
In-Reply-To: <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
 <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
Message-ID: <hplXbM5BgoaNhI7fSmxl7A1uTT9s6ofLbHr6ioBQp34=.3db8756f-d3b0-481c-95bc-ffbb6a7bcbf6@github.com>

On Mon, 11 Mar 2024 18:05:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Merge
>>  - review: minor tweak in test description of ObjectMonitorUsage.java
>>  - review: addressed more comments on the fix and new test
>>  - rename after merge: jvmti_common.h to jvmti_common.hpp
>>  - Merge
>>  - review: update comment in threads.hpp
>>  - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
>>  - resolve merge conflict for deleted file objmonusage003.cpp
>>  - fix a typo in libObjectMonitorUsage.cpp
>>  - fix potential sync gap in the test ObjectMonitorUsage
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/de428daf...b97b8205
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1483:
> 
>> 1481:   markWord mark = hobj->mark();
>> 1482:   ResourceMark rm(current_thread);
>> 1483:   GrowableArray<JavaThread*>* wantList = nullptr;
> 
> Thanks for refactoring `JvmtiEnvBase::get_object_monitor_usage()` to
> be much more clear. It was difficult to review in GitHub so I switched to
> the webrev frames view so that I could scroll the two sides back and forth
> and determine equivalence.

Good!

> src/hotspot/share/runtime/threads.hpp line 134:
> 
>> 132:   static unsigned print_threads_compiling(outputStream* st, char* buf, int buflen, bool short_form = false);
>> 133: 
>> 134:   // Get count Java threads that are waiting to enter or re-enter the specified monitor.
> 
> nit typo: s/count Java/count of Java/
> 
> Also this file needs a copyright year update.

Thanks, fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520721501
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520722461

From sspitsyn at openjdk.org  Tue Mar 12 02:07:24 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 02:07:24 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v22]
In-Reply-To: <_uXZSNczXm2ODdcowDzJZleDqNWUL6o97XAX10pWnBA=.9641d2c4-2738-422a-b882-0c3c9b408ad1@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <MqG0WJIaRZngeD4pdElLllp3nRheZGyGzj7qP1ep39c=.ff71b9b6-c073-4443-9127-6a987a150114@github.com>
 <4XAkV4CDJUTXFeKCCkAQlD_HntnLWwd_AqcTEMowS4k=.f5d2572f-3061-4a56-bf9d-e97bda57e3a0@github.com>
 <bmW0pAoszAMHZIK56cZV2qSipSDJd3-TKQsIbIjqGK8=.57a09305-a46f-4423-bfff-d7f1d2b8fb49@github.com>
 <5lsZBFSbWmDQVJe9tGr2Rll00SWkbU7HBuRpEC_-Duo=.167e62b6-ca47-4a93-b8ad-7c22b379221d@github.com>
 <_uXZSNczXm2ODdcowDzJZleDqNWUL6o97XAX10pWnBA=.9641d2c4-2738-422a-b882-0c3c9b408ad1@github.com>
Message-ID: <ofFxvGb-HbVu2fqA7WNu0xr8d2ltVgXJ2dsAzqW7EVk=.0d0356ee-67e7-4c4f-afa1-dc24a5e99ec9@github.com>

On Mon, 11 Mar 2024 01:53:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Okay. Now I see why the old code did not have endless loops.
>
> Apologies I should have checked the code - I'd forgotten the list is circular to avoid needing an explicit tail pointer.

Okay, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520719906

From sspitsyn at openjdk.org  Tue Mar 12 02:07:25 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 02:07:25 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v24]
In-Reply-To: <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
 <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
Message-ID: <b3qykqCPQQKd529OB4fbrLjBAoqiTJBHCBR1-Qpk94Y=.aba7a1c4-830e-4965-a008-1e10a245d17f@github.com>

On Mon, 11 Mar 2024 18:14:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improved new test: added wakeup warning; polished test ouput
>
> test/hotspot/jtreg/TEST.quick-groups line 972:
> 
>> 970:   vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java \
>> 971:   vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage002/TestDescription.java \
>> 972:   vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/TestDescription.java \
> 
> This file needs a copyright year update.

Thanks, fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520723644

From sspitsyn at openjdk.org  Tue Mar 12 02:07:26 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 02:07:26 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v21]
In-Reply-To: <WqyTpQK8VneIYfCLAnRB9bvQvxJq-0-8uXf_YihLjb0=.671b1d50-0e99-48f6-9f83-7153a5f22b6c@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <hU3hGOSQBElACXP5XPHTXsKo4wfWgJlKu4kDk92xgT0=.5fb57117-0f75-4a2f-bd14-1170ae764669@github.com>
 <S5WyjJM1ZHNGtmc96jhYKIjhClOmVM9mtWgGkH2ZTnM=.4f651b8d-5922-4676-8b70-551eec40876a@github.com>
 <nkfadUboYD0Q9HlfzR8aOBo396nm_I4Sc5qUM5DYIzc=.da320e46-26db-46d6-a7b0-19469677ae59@github.com>
 <GdyqukXze9zAL5bV_8ZezA5jyked4uv_ugwRY8PNhdg=.0bd1f690-a2a0-46fc-8263-485c65b8bde5@github.com>
 <mtDpXdjUHboGAKaqCT3SqCH49ZkUzh-YB7WzYEI2JAI=.12ba563e-d225-48bb-b27b-c072484da10e@github.com>
 <WqyTpQK8VneIYfCLAnRB9bvQvxJq-0-8uXf_YihLjb0=.671b1d50-0e99-48f6-9f83-7153a5f22b6c@github.com>
Message-ID: <77pfDJrhxZa6RsNkDXdcHvdfUGd7alHVMd1sZnEJYI8=.b837e747-d824-4949-afef-49447c913e2f@github.com>

On Mon, 11 Mar 2024 18:38:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Okay, thanks! I'll add some diagnostic code to catch spurious wakups.
>> Let's see if we ever encounter any spurious wakeup in this test.
>
> I think some sort of comment needs to be added here to document
> the possibility of this code path being affect by a spurious wakeup.

Thanks. I've added both a comment and also some spurious wakeup detection with a warning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520719450

From sspitsyn at openjdk.org  Tue Mar 12 02:10:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 02:10:21 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v23]
In-Reply-To: <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
 <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
Message-ID: <Ic6Jq2KSjn_Z-LYIYNpsQ0_2qMFkZh0GKQ-NsA8R8co=.a2bfd3ee-2c1f-4e73-b074-18b072535725@github.com>

On Mon, 11 Mar 2024 18:43:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Merge
>>  - review: minor tweak in test description of ObjectMonitorUsage.java
>>  - review: addressed more comments on the fix and new test
>>  - rename after merge: jvmti_common.h to jvmti_common.hpp
>>  - Merge
>>  - review: update comment in threads.hpp
>>  - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
>>  - resolve merge conflict for deleted file objmonusage003.cpp
>>  - fix a typo in libObjectMonitorUsage.cpp
>>  - fix potential sync gap in the test ObjectMonitorUsage
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/de428daf...b97b8205
>
> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 202:
> 
>> 200:     LOG("(%d) notify_waiter_count expected: %d, actually: %d\n",
>> 201:         check_idx, notifyWaiterCount, inf.notify_waiter_count);
>> 202:     result = STATUS_FAILED;
> 
> Please consider prefixing these LOG output lines with "FAILED:" so that it
> is easier to identify the log output where failure info is shown.

Good suggestion. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520726685

From sspitsyn at openjdk.org  Tue Mar 12 02:16:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 02:16:23 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v23]
In-Reply-To: <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
 <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
Message-ID: <24RgaSSfkMJk3SYQ6LZDCQToWvafNxhv44AgM_5Wlbk=.5b8b2051-8952-436f-a451-32e12b5b9b05@github.com>

On Mon, 11 Mar 2024 18:44:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Merge
>>  - review: minor tweak in test description of ObjectMonitorUsage.java
>>  - review: addressed more comments on the fix and new test
>>  - rename after merge: jvmti_common.h to jvmti_common.hpp
>>  - Merge
>>  - review: update comment in threads.hpp
>>  - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
>>  - resolve merge conflict for deleted file objmonusage003.cpp
>>  - fix a typo in libObjectMonitorUsage.cpp
>>  - fix potential sync gap in the test ObjectMonitorUsage
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/de428daf...b97b8205
>
> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 215:
> 
>> 213:   if (tested_monitor != nullptr) {
>> 214:     jni->DeleteGlobalRef(tested_monitor);
>> 215:   }
> 
> Since this is at the beginning of `setTestedMonitor` does it mean that we "leak"
> the last global ref?

Thank you for the check. There is no leak of the last global ref because there is always this call at the end of each sub-test: `setTestedMonitor(null)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520733090

From sspitsyn at openjdk.org  Tue Mar 12 02:19:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 02:19:22 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v23]
In-Reply-To: <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <HQ4S8BjqlD-Va0H4Y5BIE3Lswugv43H6lpGc7ADf9zw=.85e027ff-cc1c-4437-b4ad-881b87456acd@github.com>
 <y4VVUW5C6kanHNTbK92m0n6I7L4hNiUrJ8xS89EI3BU=.2189755e-6b01-412c-9232-9c0d8c046e31@github.com>
Message-ID: <lwm8bNeOhnVvMQB_N0llEJrM0vZw5Kwydj8RfpN5q6E=.21349a5f-8320-477d-b28d-2255c8524b05@github.com>

On Mon, 11 Mar 2024 18:23:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Merge
>>  - review: minor tweak in test description of ObjectMonitorUsage.java
>>  - review: addressed more comments on the fix and new test
>>  - rename after merge: jvmti_common.h to jvmti_common.hpp
>>  - Merge
>>  - review: update comment in threads.hpp
>>  - fix deadlock with carrier threads starvation in ObjectMonitorUsage test
>>  - resolve merge conflict for deleted file objmonusage003.cpp
>>  - fix a typo in libObjectMonitorUsage.cpp
>>  - fix potential sync gap in the test ObjectMonitorUsage
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/de428daf...b97b8205
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java line 46:
> 
>> 44:  * @library /vmTestbase
>> 45:  *          /test/lib
>> 46:  * @run main/othervm/native -agentlib:objmonusage001=printdump nsk.jvmti.GetObjectMonitorUsage.objmonusage001
> 
> I only included this `=printdump` for debug when I was updating the test.
> You don't have to keep it.

Thanks, removed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520736552

From amenkov at openjdk.org  Tue Mar 12 02:20:13 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 12 Mar 2024 02:20:13 GMT
Subject: RFR: 8324868: debug agent does not properly handle interrupts of a
 virtual thread [v2]
In-Reply-To: <IoMgMfJeIP6Tp3qBqEVxuyAleMRBBsZpgKoybWrU7o4=.3b09572e-d731-4f91-91ce-9ad3fd4b86aa@github.com>
References: <VrbUMLScozKhqXew9izxE2JkM0hsos6_QcO0STXVGzk=.f5f1e451-57bc-498d-80c9-75a96d86e86a@github.com>
 <IoMgMfJeIP6Tp3qBqEVxuyAleMRBBsZpgKoybWrU7o4=.3b09572e-d731-4f91-91ce-9ad3fd4b86aa@github.com>
Message-ID: <B5wvwGONInxQ0tskg1Wn9ujBCWUYBJsN87aQMXXHjZw=.1216a8d8-ce65-4cbf-a96a-2690d3c6725d@github.com>

On Wed, 28 Feb 2024 22:10:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fix numerous debug agent issues and testing deficiencies related to Thread.interrupt(). As a first read you should look at the description in the CR. More details in first comment below.
>> 
>> Also, this PR is dependent on the fix for [JDK-8325187](https://bugs.openjdk.org/browse/JDK-8325187). The test might generate GHA failures in the meantime.
>> 
>> Tested with all svc tier1, tier2, and tier5 tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feed back. fix up some comments.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17989#pullrequestreview-1929968175

From sspitsyn at openjdk.org  Tue Mar 12 02:31:43 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 02:31:43 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v25]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <KwPLg2X01mDvoyek-h9V-eDF1xPUrGvHU23Gau0nHzw=.74d762d5-eec8-44dd-9eee-1dfc1e61d31f@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: addressed minor comments, updated a couple of copyright headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/94ebf725..94f30f16

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=23-24

  Stats: 13 lines in 6 files changed: 2 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

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

From sspitsyn at openjdk.org  Tue Mar 12 03:40:19 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 03:40:19 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v25]
In-Reply-To: <KwPLg2X01mDvoyek-h9V-eDF1xPUrGvHU23Gau0nHzw=.74d762d5-eec8-44dd-9eee-1dfc1e61d31f@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <KwPLg2X01mDvoyek-h9V-eDF1xPUrGvHU23Gau0nHzw=.74d762d5-eec8-44dd-9eee-1dfc1e61d31f@github.com>
Message-ID: <RPjhUY69BlRHgRKO1FvIOvJThGE5W7jlwo68ss8dko8=.fa9e0881-7aca-47c3-8c65-757164a86319@github.com>

On Tue, 12 Mar 2024 02:31:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed minor comments, updated a couple of copyright headers

Thank you for review, Dan! I believe, all you comments have been addressed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1990070280

From dholmes at openjdk.org  Tue Mar 12 05:23:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Mar 2024 05:23:21 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v25]
In-Reply-To: <KwPLg2X01mDvoyek-h9V-eDF1xPUrGvHU23Gau0nHzw=.74d762d5-eec8-44dd-9eee-1dfc1e61d31f@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <KwPLg2X01mDvoyek-h9V-eDF1xPUrGvHU23Gau0nHzw=.74d762d5-eec8-44dd-9eee-1dfc1e61d31f@github.com>
Message-ID: <nylk8DcdckcZjx9BIbPxB23eYgHTiZYH0CUIc1Vc9k4=.421e8a2e-2cc8-408b-8e87-964d64798fc8@github.com>

On Tue, 12 Mar 2024 02:31:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed minor comments, updated a couple of copyright headers

Changes requested by dholmes (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 352:

> 350:                     wokeupCount++;
> 351:                     if (!notifiedAll && notifiedCount < wokeupCount) {
> 352:                         wasSpuriousWakeup = true;

This doesn't work. First as you've realized you cannot detect a spurious wakeup when notifyAll is used. But second the `notifiedCount` is incremented on each `notify` whilst the monitor lock is still held - as it must be. So no `wait` can return until the monitor is unlocked. So unless the spurious wakeup occurs before the monitor is acquired at line 254, all notifications must be completed before even a spurious wakeup can cause `wait()` to return - at which point `notifiedCount` must equal ` NUMBER_OF_WAITING_THREADS` which can never be < `wokeupCount`.
Given you can only detect one very specific case of a spurious wakeup, all this extra logic is just adding to the complexity and giving a false impression about what is being checked. To detect actual spurious wakeups here you need to be able to track when each thread was chosen by a `notify()` and there is no means to do that.

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

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1930117927
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1520862516

From dholmes at openjdk.org  Tue Mar 12 06:00:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Mar 2024 06:00:13 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <POQtVrIj3J-M5o-1oyM-dRUh69mz17aH_0J6q-nzXqg=.2d006969-918d-4d39-bc8b-dc196ff5c8a7@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

But if one test has a problem and messes up the debugger won't that kill the rest of the tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-1990703702

From dholmes at openjdk.org  Tue Mar 12 06:15:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Mar 2024 06:15:13 GMT
Subject: RFR: JDK-8327468: Do not restart close if errno is EINTR
 [macOS/linux] [v2]
In-Reply-To: <ehBGokTt4vhU1VIwrMdhRie1r06Aylqr9XM0NO-q0mo=.6bb86b9d-e762-4ecc-b5d4-aaddcc605e39@github.com>
References: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
 <ehBGokTt4vhU1VIwrMdhRie1r06Aylqr9XM0NO-q0mo=.6bb86b9d-e762-4ecc-b5d4-aaddcc605e39@github.com>
Message-ID: <4i9T5MUuyja0DlvB5c2qV98D5wA1qvRFh-NDVSaAIiw=.dc389d58-7e96-4aa4-a660-235aae2c9cf7@github.com>

On Mon, 11 Mar 2024 08:50:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a number of places remaining in the linux/macOS native JDK codebase where we use the RESTARTABLE macro with close, but this is unwanted on Linux/macOS.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not throw exception on close error

This seems fine to me, but pleasure ensure someone from serviceability also approves it.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18164#pullrequestreview-1930182294

From dholmes at openjdk.org  Tue Mar 12 06:18:14 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Mar 2024 06:18:14 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <JIJGboCWnzDHqWiQ8dGL6V6Yi-PmosYyKDQv3vs4Sx4=.3449b3da-7bdf-4ac4-842c-a4fb22c47e6a@github.com>

On Mon, 11 Mar 2024 11:57:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

GC folk should be reviewing this not runtime.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1990784653

From mbaesken at openjdk.org  Tue Mar 12 07:50:13 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Mar 2024 07:50:13 GMT
Subject: RFR: JDK-8327468: Do not restart close if errno is EINTR
 [macOS/linux] [v2]
In-Reply-To: <4i9T5MUuyja0DlvB5c2qV98D5wA1qvRFh-NDVSaAIiw=.dc389d58-7e96-4aa4-a660-235aae2c9cf7@github.com>
References: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
 <ehBGokTt4vhU1VIwrMdhRie1r06Aylqr9XM0NO-q0mo=.6bb86b9d-e762-4ecc-b5d4-aaddcc605e39@github.com>
 <4i9T5MUuyja0DlvB5c2qV98D5wA1qvRFh-NDVSaAIiw=.dc389d58-7e96-4aa4-a660-235aae2c9cf7@github.com>
Message-ID: <Z6BQIVXWkfzZnF4ekqB1pQ6AMIBvua_qJHqUJT9K3d0=.338dd97f-b04a-4dc2-845c-f90ea601bae4@github.com>

On Tue, 12 Mar 2024 06:12:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems fine to me, but please ensure someone from serviceability also approves it.
> 

Hi David, thanks for the review !
Someone from Serviceability Group  interested to comment/review ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18164#issuecomment-1990969018

From yyang at openjdk.org  Tue Mar 12 08:04:20 2024
From: yyang at openjdk.org (Yi Yang)
Date: Tue, 12 Mar 2024 08:04:20 GMT
Subject: RFR: 8327864: Support segmented heap dump for HotSpotDiagnosticMXBean
Message-ID: <qshguvc5YqLBPpMaLJtQ14WiLVvInkulNf5pHY6tgSc=.2af0d959-7d6b-4bbc-9bb5-64236559972a@github.com>

We've received feedback from users of cloud APM platform wanting the new version of the JDK to allow the HotSpotDiagnosticMXBean.dumpHeap underpinnings to reduce STW time using sgemented heapdump. Supporting segmented heapdump for mxbean is a reasonable requirement and adds little additional complexity, both in terms of maintainability and understanding.

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

Commit messages:
 - 8327864: Support segmented heap dump for HotSpotDiagnosticMXBean

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

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

From stefank at openjdk.org  Tue Mar 12 08:25:13 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 12 Mar 2024 08:25:13 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set
In-Reply-To: <JIJGboCWnzDHqWiQ8dGL6V6Yi-PmosYyKDQv3vs4Sx4=.3449b3da-7bdf-4ac4-842c-a4fb22c47e6a@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <JIJGboCWnzDHqWiQ8dGL6V6Yi-PmosYyKDQv3vs4Sx4=.3449b3da-7bdf-4ac4-842c-a4fb22c47e6a@github.com>
Message-ID: <kfyf0hVdRjVG3HyYoJ9GvBV2LOUwKuLAEPtFO6MWslQ=.a08b61e3-d59a-45ac-ab9e-f216fd043135@github.com>

On Tue, 12 Mar 2024 06:15:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

> GC folk should be reviewing this not runtime.

I don't fully agree with that. How these serviceability tools work, and their interfaces, are usually not something that we GC devs are directly responsible for. This change could be reviewed by any HotSpot developer that has a stake in the hprof tooling.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1991019456

From sspitsyn at openjdk.org  Tue Mar 12 08:54:45 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 08:54:45 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v25]
In-Reply-To: <nylk8DcdckcZjx9BIbPxB23eYgHTiZYH0CUIc1Vc9k4=.421e8a2e-2cc8-408b-8e87-964d64798fc8@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <KwPLg2X01mDvoyek-h9V-eDF1xPUrGvHU23Gau0nHzw=.74d762d5-eec8-44dd-9eee-1dfc1e61d31f@github.com>
 <nylk8DcdckcZjx9BIbPxB23eYgHTiZYH0CUIc1Vc9k4=.421e8a2e-2cc8-408b-8e87-964d64798fc8@github.com>
Message-ID: <fuQ4I88u15S8YhpWUjdQkMnYp4sO6-xPR_EfdxqJ8rQ=.48ff8a15-9557-4acd-8038-fe3d23ddb477@github.com>

On Tue, 12 Mar 2024 05:13:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed minor comments, updated a couple of copyright headers
>
> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 352:
> 
>> 350:                     wokeupCount++;
>> 351:                     if (!notifiedAll && notifiedCount < wokeupCount) {
>> 352:                         wasSpuriousWakeup = true;
> 
> This doesn't work. First as you've realized you cannot detect a spurious wakeup when notifyAll is used. But second the `notifiedCount` is incremented on each `notify` whilst the monitor lock is still held - as it must be. So no `wait` can return until the monitor is unlocked. So unless the spurious wakeup occurs before the monitor is acquired at line 254, all notifications must be completed before even a spurious wakeup can cause `wait()` to return - at which point `notifiedCount` must equal ` NUMBER_OF_WAITING_THREADS` which can never be < `wokeupCount`.
> Given you can only detect one very specific case of a spurious wakeup, all this extra logic is just adding to the complexity and giving a false impression about what is being checked. To detect actual spurious wakeups here you need to be able to track when each thread was chosen by a `notify()` and there is no means to do that.

You are right, thanks!
Removed the incorrect spurious wakeup detection code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1521073727

From sspitsyn at openjdk.org  Tue Mar 12 08:58:25 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 08:58:25 GMT
Subject: Integrated: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <VfyvS1werk2qkD4cfs_hJ3wJhiblizTuB0OCeLaPfgM=.0e8a6077-3a40-4a7e-b33c-0ef86a829163@github.com>

On Fri, 2 Feb 2024 00:44:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

This pull request has now been integrated.

Changeset: b92440f9
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b92440f9b1f41643bf9649ca192e405a9d6c026a
Stats:     1180 lines in 15 files changed: 741 ins; 390 del; 49 mod

8247972: incorrect implementation of JVM TI GetObjectMonitorUsage

Reviewed-by: dcubed, lmesnik

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

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

From sspitsyn at openjdk.org  Tue Mar 12 08:54:45 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Mar 2024 08:54:45 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v26]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <F_qa0B9PTuu7dBRMD96XS-kMgeY9wfemMBZPE1UB6OQ=.90d72978-d155-4b61-933c-87ecdb4087ec@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: removed incorrect spurious wakeup detection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/94f30f16..effd0c17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=24-25

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

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

From kevinw at openjdk.org  Tue Mar 12 11:10:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 11:10:13 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <Ou9MNwyOMF_BH-C8RxQtsKj4JaCGewe-b7zbxYjCF7U=.122d80d2-ae3d-48a6-8c3c-eae1976075d3@github.com>

On Mon, 11 Mar 2024 11:57:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

-XX:HeapDumpPath was introduced by -XX:+HeapDumpOnOutOfMemoryError for its use.

globals.hpp documents HeapDumpPath as relating to HeapDumpOnOutOfMemoryError (so that will need changing if this change is happening).

It does look useful to use HeapDumpPath as the default for jcmd, although maybe there's some confusion possible if you're already relying on it for OOM dumps.

jcmd GC.heap_dump has the overwrite flag.
OOM dumping in HeapDumper::dump_heap(bool oome) has a sequence number.

Can it be specified how these will interact? 8-)
Does overwrite mean you don't want to increase sequence number (but we already increased it last iteration)... 


I like splitting out alloc_and_create_heapdump_pathname() as this is already a large part of dump_heap.
Should the comment say, "caller must free the returned pointer".

HeapDumper::dump_to_heapdump_path
This new name makes less sense to me, as we already use heapdump path, but maybe you need it to avoid the dcmd having to work out the final filename. 8-)

Does dump_to_heapdump_path() not print the ("Dumping heap to %s ...", path) message?  That seems important when the user isn't specifying it directly.

But the policy questions probably important to confirm before worrying about those and any other code comments.

A test would not be a bad thing. 8-)

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

PR Review: https://git.openjdk.org/jdk/pull/18190#pullrequestreview-1930752683

From kevinw at openjdk.org  Tue Mar 12 11:25:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 11:25:16 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <cXTbBh8OpL4uifNpTGkTWpJX-lv699_dloHdfVQf6no=.898d62b5-6331-487b-a81a-a6af1a7715b8@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <cXTbBh8OpL4uifNpTGkTWpJX-lv699_dloHdfVQf6no=.898d62b5-6331-487b-a81a-a6af1a7715b8@github.com>
Message-ID: <ICJ6vtsVloyYNwNCdUa3BEsE2kDHUrjCcs4vHV6lJSU=.cb8cf980-3f16-401b-96bf-94002a0c9395@github.com>

On Mon, 11 Mar 2024 17:22:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (C) oops
>
> test/jdk/javax/management/remote/mandatory/notif/DeadListenerTest.java line 78:
> 
>> 76:         cs.start();
>> 77:         JMXServiceURL addr = cs.getAddress();
>> 78:         assertTrue("Expected no connections in new connector server", rmiServer.connections.isEmpty());
> 
> Changes to this file seem unrelated to the removal of the feature - could you confirm that they were intended (no issue if they were intended).

Yes, they were intentional, should have made that clear.  I had a failure from this test at some point, and the assert message made no sense to me.
e.g. "New value of count1 == 1" is shown, but that's what was expected and not what was seen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1521290618

From kevinw at openjdk.org  Tue Mar 12 11:52:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 11:52:33 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v8]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <Tq5M_UqTrOYCjALmd1QKMOwiHsclnmK8QdZEMkBsDTo=.fdbf79c8-e573-469c-af6c-87210374af1f@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

Kevin Walls 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 16 additional commits since the last revision:

 - Remove unnecessary constructor in private class
 - Merge remote-tracking branch 'upstream/master' into 8326666_SubjectDelegation_remove
 - (C) oops
 - Clarify deprecation comment.
 - typo
 - Remove additional passing of delegatedSubject in ClientListenerInfo and ClientNotifForwarder
 - Test specifically that UOE is thrown.
 - Test that SubjectDelegation is refused.
 - Update doc comments for RMIConnection.  Additional throw for delegationSubjects array.
 - JMXConnector.getMBeanServer(ds) doc update
 - ... and 6 more: https://git.openjdk.org/jdk/compare/df1aab1c...7ae77376

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/f5794c43..7ae77376

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=06-07

  Stats: 98336 lines in 2041 files changed: 16429 ins; 75917 del; 5990 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Tue Mar 12 11:52:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 11:52:34 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <cXTbBh8OpL4uifNpTGkTWpJX-lv699_dloHdfVQf6no=.898d62b5-6331-487b-a81a-a6af1a7715b8@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <cXTbBh8OpL4uifNpTGkTWpJX-lv699_dloHdfVQf6no=.898d62b5-6331-487b-a81a-a6af1a7715b8@github.com>
Message-ID: <fprDm0QjuRxXIQ9pqwsk8XzxaHK6WzvG8IeoMhbDfMM=.ee24bf4a-440d-4e5a-bda4-804dc3fe65fd@github.com>

On Mon, 11 Mar 2024 17:10:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (C) oops
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java line 618:
> 
>> 616:                 throw new SecurityException("Subject Delegation has been removed.");
>> 617:             }
>> 618:         }
> 
> Can't this constructor be removed? It's a private inner class so we should be able to throw before calling that constructor?

Yes that can disappear with no impact.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1521324287

From mbaesken at openjdk.org  Tue Mar 12 12:11:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Mar 2024 12:11:12 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <Z0G-iJkDjnUx_xPEPwvvZaoeiSiYjl8HOw7ugkfu7iQ=.6525a30a-d7d5-496c-9492-f7026685520a@github.com>

On Mon, 11 Mar 2024 11:57:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

Hi Kevin, thanks for the comments.

> globals.hpp documents HeapDumpPath as relating to HeapDumpOnOutOfMemoryError

Yes true, probably we have to adjust the related text.
What do you think about this 

old  "When HeapDumpOnOutOfMemoryError is on,"
new "When HeapDumpOnOutOfMemoryError is on or a heap dump is trigger by jcmd GC.heap_dump  without specifying a path,"

?

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1991504498

From mbaesken at openjdk.org  Tue Mar 12 12:16:15 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Mar 2024 12:16:15 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set
In-Reply-To: <Ou9MNwyOMF_BH-C8RxQtsKj4JaCGewe-b7zbxYjCF7U=.122d80d2-ae3d-48a6-8c3c-eae1976075d3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <Ou9MNwyOMF_BH-C8RxQtsKj4JaCGewe-b7zbxYjCF7U=.122d80d2-ae3d-48a6-8c3c-eae1976075d3@github.com>
Message-ID: <mXDS-ywsaq9RsAt6soex_gAV4RRdKlTjcJLpYWl9TU4=.1a432de3-b0ca-4155-9796-294a5c919c4c@github.com>

On Tue, 12 Mar 2024 11:08:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>jcmd GC.heap_dump has the overwrite flag.
>OOM dumping in HeapDumper::dump_heap(bool oome) has a sequence number.

There is (with this patch) still just one sequence number and it is incremented by all invocations of alloc_and_create_heapdump_pathname.

>I like splitting out alloc_and_create_heapdump_pathname() as this is already a large part of dump_heap.
> Should the comment say, "caller must free the returned pointer".

Agree, I will adjust the comment.

(and btw regarding your comment on a test, yes I agree there should be a separate test or at least an adjustment/addition to the existing tests)

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1991510708
PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1991514153

From mbaesken at openjdk.org  Tue Mar 12 12:22:41 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Mar 2024 12:22:41 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v2]
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <tm8wZB-vPfuSoyzWnxW6RI9A7FGkT6ucKB_iicwR4Ss=.d1ede645-f03a-4a34-b9f1-0b86fe7fec06@github.com>

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

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

  alloc_and_create_heapdump_pathname adjust comment about freeing the returned  pointer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18190/files
  - new: https://git.openjdk.org/jdk/pull/18190/files/116c0572..e335d9ee

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

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

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

From mbaesken at openjdk.org  Tue Mar 12 12:39:14 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Mar 2024 12:39:14 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v2]
In-Reply-To: <Ou9MNwyOMF_BH-C8RxQtsKj4JaCGewe-b7zbxYjCF7U=.122d80d2-ae3d-48a6-8c3c-eae1976075d3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <Ou9MNwyOMF_BH-C8RxQtsKj4JaCGewe-b7zbxYjCF7U=.122d80d2-ae3d-48a6-8c3c-eae1976075d3@github.com>
Message-ID: <cImx26-eAAF8Ic3oCagPwSAjnqv0Xl_q8UYFtpQb1z0=.456b69bc-b3e4-459f-b16f-cde06a103bf8@github.com>

On Tue, 12 Mar 2024 11:08:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>Does dump_to_heapdump_path() not print the ("Dumping heap to %s ...", path) message? 
>That seems important when the user isn't specifying it directly.

The path is already printed, here is an example (the JVM with pid 219447 was started with` -XX:HeapDumpPath=...  `).

images/jdk/bin/jcmd  219447 GC.heap_dump
219447:
Dumping heap to /mydir/test/dumpdir/dydumpfile ...
Heap dump file created [3757116 bytes in 0.046 secs]

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1991554323

From kevinw at openjdk.org  Tue Mar 12 12:53:15 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 12:53:15 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v2]
In-Reply-To: <cImx26-eAAF8Ic3oCagPwSAjnqv0Xl_q8UYFtpQb1z0=.456b69bc-b3e4-459f-b16f-cde06a103bf8@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <Ou9MNwyOMF_BH-C8RxQtsKj4JaCGewe-b7zbxYjCF7U=.122d80d2-ae3d-48a6-8c3c-eae1976075d3@github.com>
 <cImx26-eAAF8Ic3oCagPwSAjnqv0Xl_q8UYFtpQb1z0=.456b69bc-b3e4-459f-b16f-cde06a103bf8@github.com>
Message-ID: <z38mpGQlOrwQcv-GPILFKT7sH64BgjxSbgEpoyUc_4s=.7849af27-f26b-4b07-8486-f9af902a16f5@github.com>

On Tue, 12 Mar 2024 12:36:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The path is already printed, here is an example (the JVM with pid 219447 was started with`-XX:HeapDumpPath=... `).

yes of course, when the new method calls dump(), thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1991580343

From kevinw at openjdk.org  Tue Mar 12 13:30:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 13:30:13 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v2]
In-Reply-To: <mXDS-ywsaq9RsAt6soex_gAV4RRdKlTjcJLpYWl9TU4=.1a432de3-b0ca-4155-9796-294a5c919c4c@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <Ou9MNwyOMF_BH-C8RxQtsKj4JaCGewe-b7zbxYjCF7U=.122d80d2-ae3d-48a6-8c3c-eae1976075d3@github.com>
 <mXDS-ywsaq9RsAt6soex_gAV4RRdKlTjcJLpYWl9TU4=.1a432de3-b0ca-4155-9796-294a5c919c4c@github.com>
Message-ID: <7Pfnmvol2fcjW4KJFXD81dTcLh-ryp-SlH3Dg6c1bV0=.45d82a3b-614d-406a-8795-4b91d5c8f579@github.com>

On Tue, 12 Mar 2024 12:12:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > jcmd GC.heap_dump has the overwrite flag.
> > OOM dumping in HeapDumper::dump_heap(bool oome) has a sequence number.
> 
> There is (with this patch) still just one sequence number and it is incremented by all invocations of alloc_and_create_heapdump_pathname.

Right, I was trying to say that previously, sequence numbers were only used by OOM dumping, and now jcmd invocation can use them, if you have it using HeapDumpPath.  (But it can't when using a specified filename, that might be a point of confusion.)

HeapDumpOnOutOfMemoryError dumping never overwrites as I read it.  That make sense as it could overwrite existing dumps if an OOM happens, and means a sequence of dumps should all have the same origin.

Invoked from jcmd with HeapDumpPath and -overwrite, can you can overwrite part of a sequence.
That's not necessarily wrong, and may not be serious enough to refuse -overwrite when using HeapDumpPath, but we want to find a way of making things clear (I was not going to suggest separate sequence numbers... 8-) )

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1991651689

From mbaesken at openjdk.org  Tue Mar 12 13:34:13 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 12 Mar 2024 13:34:13 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v2]
In-Reply-To: <7Pfnmvol2fcjW4KJFXD81dTcLh-ryp-SlH3Dg6c1bV0=.45d82a3b-614d-406a-8795-4b91d5c8f579@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <Ou9MNwyOMF_BH-C8RxQtsKj4JaCGewe-b7zbxYjCF7U=.122d80d2-ae3d-48a6-8c3c-eae1976075d3@github.com>
 <mXDS-ywsaq9RsAt6soex_gAV4RRdKlTjcJLpYWl9TU4=.1a432de3-b0ca-4155-9796-294a5c919c4c@github.com>
 <7Pfnmvol2fcjW4KJFXD81dTcLh-ryp-SlH3Dg6c1bV0=.45d82a3b-614d-406a-8795-4b91d5c8f579@github.com>
Message-ID: <SyANAjDPJYXd7y1LGccDBPd31ERnj0qOfHxt-n-90Wo=.b94bc2b5-6542-4c89-bf17-6ea25f693fe6@github.com>

On Tue, 12 Mar 2024 13:27:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>That's not necessarily wrong, and may not be serious enough to refuse -overwrite when using HeapDumpPath, but we want to
>find a way of making things clear (I was not going to suggest separate sequence numbers... 8-) )

Thanks for clarifying, maybe we have to describe/document this at some place (comment? or jcmd help ?) .

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1991661956

From kevinw at openjdk.org  Tue Mar 12 15:24:17 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 15:24:17 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
Message-ID: <RvuQ-iLHMjTtlcVgv3jK88Rnd9UAHVfPCLWoNa47Tzw=.97bfbeac-88bf-4a64-83d4-f89a1d64f90f@github.com>

On Mon, 11 Mar 2024 17:49:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (C) oops
>
> src/java.management/share/classes/javax/management/remote/JMXConnector.java line 139:
> 
>> 137:     /**
>> 138:      * <p>This method remains for compatibility reasons, but has no more meaning
>> 139:      * than {@link #getMBeanServerConnection()}.
> 
> Suggestion:
> 
>      * <p>This method is equivalent to calling {@link #getMBeanServerConnection()}.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1521667592

From kevinw at openjdk.org  Tue Mar 12 15:41:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 15:41:18 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <n2gelGktTFdQGm7OWlv7j_45foPwmqV6S0DQ2z1FiRs=.6de8e9a2-7635-412a-a446-cfeb013fa15d@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
 <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>
 <pQrsuvbQ8JnvEI17nHEG_yb_7AECk-SujOc_YOj7CaI=.d741cb3f-5753-408a-a903-994d469f9216@github.com>
 <n2gelGktTFdQGm7OWlv7j_45foPwmqV6S0DQ2z1FiRs=.6de8e9a2-7635-412a-a446-cfeb013fa15d@github.com>
Message-ID: <IJmShi6HhRYg8D4BkP1-SD7KdJT0dMkIw0OZAPBIijA=.eeb537e6-15ca-41b2-b50c-1adbbf35dad2@github.com>

On Mon, 11 Mar 2024 19:24:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Maybe mention there too that the delegationSubject parameter is kept for interoperability with older remote clients.
>
> It's a good suggestion.   Something like this:
> 
> All methods that take a `Subject` parameter will throw UOE if called with a non-null subject delegation.  JMX subject delegation feature is no longer supported.

OK sure -- didn't want to make the individual delegationSubject mentions too terse, but if there is some earlier text then that could be OK...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1521699619

From dchuyko at openjdk.org  Tue Mar 12 15:53:39 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Tue, 12 Mar 2024 15:53:39 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v29]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <IxvZvwtkIvtjZucyIz3Am0MCT15z37dMIfgR2v3tykk=.0aee7ef9-b6d7-4dea-9c6d-31c2d164859d@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 47 commits:

 - Resolved master conflicts
 - 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
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - ... and 37 more: https://git.openjdk.org/jdk/compare/782206bc...ff39ac12

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

Changes: https://git.openjdk.org/jdk/pull/14111/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=28
  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 mullan at openjdk.org  Tue Mar 12 19:10:16 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Mar 2024 19:10:16 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
Message-ID: <leVNLEnlMOT_Q12vSYN1zBocFXWkf2eoJQrj_GYXqTs=.74126c7c-6afb-483b-98e2-f8666849c3da@github.com>

On Tue, 5 Mar 2024 19:56:58 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MBeanServerFileAccessController.java

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 55:

> 53:         Subject.callAs(subject, () -> check(0, Subject.current(), "Duke"));
> 54: 
> 55:         // Observable in the same thread in ACC mode, but not in the SV mode

Should this comment actually say "Observable in a new platform thread in ACC mode, but not in the SV mode".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1521991975

From kevinw at openjdk.org  Tue Mar 12 19:43:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 19:43:26 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v9]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <67d24Poc0p9A6LKZMcbuMVn6Xq7ve2hvsyEhVbwiR6U=.e0a54f63-6b91-48f0-b7dc-ddb83068cb7a@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  Javadoc update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/7ae77376..15717fbe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=07-08

  Stats: 89 lines in 2 files changed: 5 ins; 33 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Tue Mar 12 19:43:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 19:43:26 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v7]
In-Reply-To: <IJmShi6HhRYg8D4BkP1-SD7KdJT0dMkIw0OZAPBIijA=.eeb537e6-15ca-41b2-b50c-1adbbf35dad2@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <GzuAWLDduGcdXU_XcQdhg1XtdORyYxx61xoPhN-JSD8=.17e9beaf-3209-425e-8e3c-fc35330a7ad2@github.com>
 <2oXoak3S6yJE6kBNnbCS9lz5a1Lw5-oZgnykaj55CPY=.f7ae3564-e1e0-405e-8608-11ba7bae533c@github.com>
 <59nYs6yt8gYjt3O1eiBck3l2H56K3FCbg8oukYBx1aU=.b1bae0bf-d709-4456-80aa-0a2c97e3f051@github.com>
 <pQrsuvbQ8JnvEI17nHEG_yb_7AECk-SujOc_YOj7CaI=.d741cb3f-5753-408a-a903-994d469f9216@github.com>
 <n2gelGktTFdQGm7OWlv7j_45foPwmqV6S0DQ2z1FiRs=.6de8e9a2-7635-412a-a446-cfeb013fa15d@github.com>
 <IJmShi6HhRYg8D4BkP1-SD7KdJT0dMkIw0OZAPBIijA=.eeb537e6-15ca-41b2-b50c-1adbbf35dad2@github.com>
Message-ID: <WX6w0AC6OuBXo3iJfG0LIZ6uPVPdRzAFZpULuY7xuRI=.66dc7225-565e-49f5-b307-7e42c77511a0@github.com>

On Tue, 12 Mar 2024 15:38:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> It's a good suggestion.   Something like this:
>> 
>> All methods that take a `Subject` parameter will throw UOE if called with a non-null subject delegation.  JMX subject delegation feature is no longer supported.
>
> OK sure -- didn't want to make the individual delegationSubject mentions too terse, but if there is some earlier text then that could be OK...

Thanks, updating with those changes. Additionally, in JMXConnector I'm removing the text "Calling this method is equivalent to calling getMBSC(null)..." as that is pointless, and possibly misleading now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1522024836

From kevinw at openjdk.org  Tue Mar 12 19:58:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Mar 2024 19:58:24 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v10]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <5MCgY2p_D4NXKr71Tv_E0uqg9Y8WpQe0LMrFTGjaJUg=.c5f16c93-3c3b-4606-a351-425d4e8bb99f@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/15717fbe..a3e09e90

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=08-09

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

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

From amenkov at openjdk.org  Tue Mar 12 20:11:18 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 12 Mar 2024 20:11:18 GMT
Subject: RFR: JDK-8326898: NSK tests should listen on loopback addresses
 only [v2]
In-Reply-To: <n3hQXBuq0zkKL4xe0npHwe0pCXFxD4Ol9U7o1wpeozg=.c21969de-1636-4ab7-a6fd-fad59e6f3c57@github.com>
References: <0S05fii4BnVxmQZnEC2qOSmrTzAtyZTvYlblSDeNiKg=.99d7c8b1-8144-47dc-9e03-5e447b283a58@github.com>
 <n3hQXBuq0zkKL4xe0npHwe0pCXFxD4Ol9U7o1wpeozg=.c21969de-1636-4ab7-a6fd-fad59e6f3c57@github.com>
Message-ID: <yVACjYhr0dZ9BR44239pNAa4HrYcXtFpZo65bzL7iY8=.2502f6c1-4c89-4d43-9468-7ff7cc656fef@github.com>

On Tue, 5 Mar 2024 02:24:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Many NSK tests create socket channel for test/target interprocess communication.
>> The change updates server side to listen only on loopback interface.
>> 
>> Testing - all tests that use then functionality:
>>  - test/hotspot/jtreg/vmTestbase/nsk/jdb, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/aod, test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SocketIOPipe.createClientIOPipe and getTestHost()/getDebugeeHost()

Can I get re-review of the fix please

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

PR Comment: https://git.openjdk.org/jdk/pull/18053#issuecomment-1992492815

From cjplummer at openjdk.org  Tue Mar 12 20:57:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Mar 2024 20:57:35 GMT
Subject: RFR: 8324868: debug agent does not properly handle interrupts of a
 virtual thread [v3]
In-Reply-To: <VrbUMLScozKhqXew9izxE2JkM0hsos6_QcO0STXVGzk=.f5f1e451-57bc-498d-80c9-75a96d86e86a@github.com>
References: <VrbUMLScozKhqXew9izxE2JkM0hsos6_QcO0STXVGzk=.f5f1e451-57bc-498d-80c9-75a96d86e86a@github.com>
Message-ID: <iWta_LU3Ix6UOQnr3NiqZxXA5VuGjqixoy8hgkaskyU=.129f405d-4f27-4591-8155-16e1be84fb4d@github.com>

> Fix numerous debug agent issues and testing deficiencies related to Thread.interrupt(). As a first read you should look at the description in the CR. More details in first comment below.
> 
> Also, this PR is dependent on the fix for [JDK-8325187](https://bugs.openjdk.org/browse/JDK-8325187). The test might generate GHA failures in the meantime.
> 
> Tested with all svc tier1, tier2, and tier5 tests.

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

 - Merge branch 'master' into 8324868_interrupt
   Merge with master branch
 - review feed back. fix up some comments.
 - Undo some test changes that were suppose to be temporary
 - Improved debug agent thread interrupt handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17989/files
  - new: https://git.openjdk.org/jdk/pull/17989/files/0ba5b0ff..5958d34a

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

  Stats: 98923 lines in 2067 files changed: 16605 ins; 76233 del; 6085 mod
  Patch: https://git.openjdk.org/jdk/pull/17989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17989/head:pull/17989

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

From cjplummer at openjdk.org  Tue Mar 12 20:57:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Mar 2024 20:57:36 GMT
Subject: RFR: 8324868: debug agent does not properly handle interrupts of a
 virtual thread [v2]
In-Reply-To: <IoMgMfJeIP6Tp3qBqEVxuyAleMRBBsZpgKoybWrU7o4=.3b09572e-d731-4f91-91ce-9ad3fd4b86aa@github.com>
References: <VrbUMLScozKhqXew9izxE2JkM0hsos6_QcO0STXVGzk=.f5f1e451-57bc-498d-80c9-75a96d86e86a@github.com>
 <IoMgMfJeIP6Tp3qBqEVxuyAleMRBBsZpgKoybWrU7o4=.3b09572e-d731-4f91-91ce-9ad3fd4b86aa@github.com>
Message-ID: <uRfz-j_vdiReaJ_q2vZu_ZiOKp5OIaPErbcHVl2ESPg=.da3f56a9-2632-4ea0-ba59-839ee739c838@github.com>

On Wed, 28 Feb 2024 22:10:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fix numerous debug agent issues and testing deficiencies related to Thread.interrupt(). As a first read you should look at the description in the CR. More details in first comment below.
>> 
>> Also, this PR is dependent on the fix for [JDK-8325187](https://bugs.openjdk.org/browse/JDK-8325187). The test might generate GHA failures in the meantime.
>> 
>> Tested with all svc tier1, tier2, and tier5 tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feed back. fix up some comments.

Thanks for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/17989#issuecomment-1992556643

From cjplummer at openjdk.org  Tue Mar 12 20:57:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Mar 2024 20:57:36 GMT
Subject: Integrated: 8324868: debug agent does not properly handle interrupts
 of a virtual thread
In-Reply-To: <VrbUMLScozKhqXew9izxE2JkM0hsos6_QcO0STXVGzk=.f5f1e451-57bc-498d-80c9-75a96d86e86a@github.com>
References: <VrbUMLScozKhqXew9izxE2JkM0hsos6_QcO0STXVGzk=.f5f1e451-57bc-498d-80c9-75a96d86e86a@github.com>
Message-ID: <A95YunxgYYysoA4ZjF9mqNAqazF0sOLwoW9lYER0YCQ=.2b494dc9-5e5d-414d-9bd0-9a36cf4b3907@github.com>

On Fri, 23 Feb 2024 19:06:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix numerous debug agent issues and testing deficiencies related to Thread.interrupt(). As a first read you should look at the description in the CR. More details in first comment below.
> 
> Also, this PR is dependent on the fix for [JDK-8325187](https://bugs.openjdk.org/browse/JDK-8325187). The test might generate GHA failures in the meantime.
> 
> Tested with all svc tier1, tier2, and tier5 tests.

This pull request has now been integrated.

Changeset: 966a42f9
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/966a42f9b39840ab9eab6dc3cdc6fdd69abf9873
Stats:     303 lines in 3 files changed: 177 ins; 62 del; 64 mod

8324868: debug agent does not properly handle interrupts of a virtual thread

Reviewed-by: sspitsyn, amenkov

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

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

From amenkov at openjdk.org  Wed Mar 13 01:02:50 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 13 Mar 2024 01:02:50 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> Also annotations can be changed (added/removed) by class redefinition.
> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  removed attributes_count from RecordComponent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18161/files
  - new: https://git.openjdk.org/jdk/pull/18161/files/1ad6997d..f82e432a

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

  Stats: 24 lines in 4 files changed: 3 ins; 14 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/18161.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18161/head:pull/18161

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

From sspitsyn at openjdk.org  Wed Mar 13 04:06:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 04:06:12 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
Message-ID: <6rZ8jD99Sio4nAMAoRH7DJRjibsYam_DBJcv3xSQ1Es=.5a172281-1a61-472f-b583-d16dadf06d7a@github.com>

On Wed, 13 Mar 2024 01:02:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
>> Also annotations can be changed (added/removed) by class redefinition.
>> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
>> 
>> Testing: 
>> - tier1,tier2,hs-tier5-svc;
>>  - redefineClasses/retransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed attributes_count from RecordComponent

Could you, please, update the CR with your analysis and conclusion about a root cause?

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

PR Comment: https://git.openjdk.org/jdk/pull/18161#issuecomment-1993402337

From sspitsyn at openjdk.org  Wed Mar 13 04:41:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 04:41:13 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
Message-ID: <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>

On Wed, 13 Mar 2024 01:02:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
>> Also annotations can be changed (added/removed) by class redefinition.
>> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
>> 
>> Testing: 
>> - tier1,tier2,hs-tier5-svc;
>>  - redefineClasses/retransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed attributes_count from RecordComponent

This looks good in general.
I've posted a couple of minor requests.
Aside of the fix itself...
It is interesting that if an invisible attribute of a `RecordComponent` was not ignored because the `PreserveAllAnnotations` is enabled then it the `JvmtiClassFileReconstituter` treats it as a visible attribute. Not sure, if we should treat it as a bug.

Marked as reviewed by sspitsyn (Reviewer).

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 516:

> 514:                         + component->annotations() != nullptr ? 1 : 0
> 515:                         + component->type_annotations() != nullptr ? 1 : 0;
> 516:     write_u2(attributes_count);

Nit: I would suggest to define this function in the `RecordComponent` class:
  u2 attributes_count() const {
     u2 attributes_count =  generic_signature_index() != 0 ? 1 : 0
                                      + annotations() != nullptr ? 1 : 0
                                      + type_annotations() != nullptr ? 1 : 0;
     return attributes_count;
  }

test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 96:

> 94:         {
> 95:             log("Test: retransform to null");
> 96:             retransform(null);

Q: Could you add a comment why it is needed?

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18161#pullrequestreview-1933129468
PR Review: https://git.openjdk.org/jdk/pull/18161#pullrequestreview-1933147886
PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1522481272
PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1522494266

From sspitsyn at openjdk.org  Wed Mar 13 07:46:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 07:46:18 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v29]
In-Reply-To: <IxvZvwtkIvtjZucyIz3Am0MCT15z37dMIfgR2v3tykk=.0aee7ef9-b6d7-4dea-9c6d-31c2d164859d@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
 <IxvZvwtkIvtjZucyIz3Am0MCT15z37dMIfgR2v3tykk=.0aee7ef9-b6d7-4dea-9c6d-31c2d164859d@github.com>
Message-ID: <Vy661u_BkXOeDibHaqTa2Tf9FyjGrw-nJvSow3dfBpU=.a0d39b50-51e8-45c2-818f-2a6f751303c0@github.com>

On Tue, 12 Mar 2024 15:53:39 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> 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...
>
> Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:
> 
>  - Resolved master conflicts
>  - 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
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - ... and 37 more: https://git.openjdk.org/jdk/compare/782206bc...ff39ac12

src/hotspot/share/ci/ciEnv.cpp line 1144:

> 1142: 
> 1143:       if (entry_bci == InvocationEntryBci) {
> 1144:         if (TieredCompilation) {

Just a naive question. Why this check has been removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1522682325

From sspitsyn at openjdk.org  Wed Mar 13 07:51:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 07:51:18 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v29]
In-Reply-To: <IxvZvwtkIvtjZucyIz3Am0MCT15z37dMIfgR2v3tykk=.0aee7ef9-b6d7-4dea-9c6d-31c2d164859d@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
 <IxvZvwtkIvtjZucyIz3Am0MCT15z37dMIfgR2v3tykk=.0aee7ef9-b6d7-4dea-9c6d-31c2d164859d@github.com>
Message-ID: <SbElzoMCP8XdAga_V2-7Fknfj8kfKpn502xN2hNtbK4=.d2f365a9-a050-41a3-9ba0-4ae80e056811@github.com>

On Tue, 12 Mar 2024 15:53:39 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> 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...
>
> Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:
> 
>  - Resolved master conflicts
>  - 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
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - ... and 37 more: https://git.openjdk.org/jdk/compare/782206bc...ff39ac12

src/hotspot/share/services/diagnosticCommand.cpp line 928:

> 926:                            DCmdWithParser(output, heap),
> 927:   _filename("filename", "Name of the directives file", "STRING", true),
> 928:   _refresh("-r", "Refresh affected methods.", "BOOLEAN", false, "false") {

Nit: The dot is not needed at the end, I think. The same applies to lines: 945, 970 and 987.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1522688369

From rrich at openjdk.org  Wed Mar 13 09:47:20 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 13 Mar 2024 09:47:20 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
Message-ID: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>

This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.

Testing:
make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync

More tests are pending.

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

Commit messages:
 - Switch to WXWrite before entering the vm

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

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

From dholmes at openjdk.org  Wed Mar 13 09:52:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 13 Mar 2024 09:52:15 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
Message-ID: <vxGx3wIPvBM7bs0tiKhCssTHZ-nNTrrnS4fCEE5clc0=.d59c75c1-756e-4c4c-97d7-defc03a2e84b@github.com>

On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
> 
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> 
> More tests are pending.

As I wrote in JBS, shouldn't this be handled by `ThreadInVMfromNative`?

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

PR Review: https://git.openjdk.org/jdk/pull/18238#pullrequestreview-1933634023

From dholmes at openjdk.org  Wed Mar 13 09:56:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 13 Mar 2024 09:56:13 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set
In-Reply-To: <kfyf0hVdRjVG3HyYoJ9GvBV2LOUwKuLAEPtFO6MWslQ=.a08b61e3-d59a-45ac-ab9e-f216fd043135@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <JIJGboCWnzDHqWiQ8dGL6V6Yi-PmosYyKDQv3vs4Sx4=.3449b3da-7bdf-4ac4-842c-a4fb22c47e6a@github.com>
 <kfyf0hVdRjVG3HyYoJ9GvBV2LOUwKuLAEPtFO6MWslQ=.a08b61e3-d59a-45ac-ab9e-f216fd043135@github.com>
Message-ID: <atHdCdAemzEXW52lXAxvDAMSQKpp8rFBTIK4gIbDg3Q=.561c6961-778d-42a5-9a16-6dc9ce82b4ec@github.com>

On Tue, 12 Mar 2024 08:23:04 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > GC folk should be reviewing this not runtime.
> 
> I don't fully agree with that. How these serviceability tools work, and their interfaces, are usually not something that we GC devs are directly responsible for. This change could be reviewed by any HotSpot developer that has a stake in the hprof tooling.

Sorry I assumed GC folk had an interest in `-XX:HeapDumpPath` and so how it might get used.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1993986904

From rrich at openjdk.org  Wed Mar 13 10:02:13 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 13 Mar 2024 10:02:13 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <vxGx3wIPvBM7bs0tiKhCssTHZ-nNTrrnS4fCEE5clc0=.d59c75c1-756e-4c4c-97d7-defc03a2e84b@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <vxGx3wIPvBM7bs0tiKhCssTHZ-nNTrrnS4fCEE5clc0=.d59c75c1-756e-4c4c-97d7-defc03a2e84b@github.com>
Message-ID: <zkJhZFbiWpLz1I95pZE4WSW1VyvyFsSeauSE7OnWBrU=.2f54fde5-2f37-4ceb-9585-51edc05a9c75@github.com>

On Wed, 13 Mar 2024 09:49:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As I wrote in JBS, shouldn't this be handled by `ThreadInVMfromNative`?

(I wanted to publish the PR before answering your comment)

This would be reasonable in my opinion.
I've hoisted setting `WXWrite` mode in `JfrJvmtiAgent::retransform_classes()` because multiple instances of `ThreadInVMfromNative` are reached. This is likely not even necessary. Still exceptions could be made if there are usages of `ThreadInVMfromNative` where it is needed.

While I agree I'd prefer to do it as a separate enhancement.

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-1994000304

From dholmes at openjdk.org  Wed Mar 13 12:22:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 13 Mar 2024 12:22:15 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
Message-ID: <LwiFM7Sj36liJgbF9_UEqj2LezKKAE9sb7CNvJPlAF8=.1ccb1252-ded5-41c4-9a24-26c93f855326@github.com>

On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
> 
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> 
> More tests are pending.

src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 160:

> 158:   ResourceMark rm(THREAD);
> 159:   // WXWrite is needed before entering the vm below and in callee methods.
> 160:   MACOS_AARCH64_ONLY(ThreadWXEnable __wx(WXWrite, THREAD));

I understand you placed this here to cover the transition inside `create_classes_array` and the immediate one at line 170, but doesn't this risk having the wrong WX state for code in between?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18238#discussion_r1523127288

From ihse at openjdk.org  Wed Mar 13 12:34:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Mar 2024 12:34:20 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution [v4]
In-Reply-To: <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
References: <lGtsPt-jwk2yeMj9usOUTYfflYDwX8DAhD7RLxWJQ9o=.ae41dd0a-9b28-43a4-9979-84c2f675e531@github.com>
 <V4syuDAMRYe1BSG2okxw2sdceihpIarwtYI1wIbfxhY=.16d008af-c3df-42fe-a97c-7ac41eaab757@github.com>
Message-ID: <YnEDV8WKjbtBEb-Fb-ugaSZdcxKW_Na1__l8H8PQBLE=.8da56e70-ef00-4aa4-b629-b13b253b3fd2@github.com>

On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
>> 
>> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
>> 
>> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
>> 
>> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into remove-toolchain-define
>  - Rename LANG to LINK_TYPE
>  - Reword "lib" comment to fit in better
>  - Merge branch 'master' into remove-toolchain-define
>  - 8326583: Remove over-generalized DefineNativeToolchain solution

I have opened https://bugs.openjdk.org/browse/JDK-8328079 to track the ccache regression.

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

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1994283777

From rrich at openjdk.org  Wed Mar 13 13:56:14 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 13 Mar 2024 13:56:14 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <LwiFM7Sj36liJgbF9_UEqj2LezKKAE9sb7CNvJPlAF8=.1ccb1252-ded5-41c4-9a24-26c93f855326@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <LwiFM7Sj36liJgbF9_UEqj2LezKKAE9sb7CNvJPlAF8=.1ccb1252-ded5-41c4-9a24-26c93f855326@github.com>
Message-ID: <I2vjqPLe4V4ppRKX4MizQ32-fKkQED4WIe0tDVZM7Cc=.bdc04eff-6b5e-4ace-9465-f7c8d70eaa56@github.com>

On Wed, 13 Mar 2024 12:19:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 160:
> 
>> 158:   ResourceMark rm(THREAD);
>> 159:   // WXWrite is needed before entering the vm below and in callee methods.
>> 160:   MACOS_AARCH64_ONLY(ThreadWXEnable __wx(WXWrite, THREAD));
> 
> I understand you placed this here to cover the transition inside `create_classes_array` and the immediate one at line 170, but doesn't this risk having the wrong WX state for code in between?

I've asked this myself (after making the change).
Being in `WXWrite` mode would be wrong if the thread would execute dynamically generated code. There's not too much happening outside the scope of the `ThreadInVMfromNative` instances. I see jni calls (`GetObjectArrayElement`, `ExceptionOccurred`) and a jvmti call (`RetransformClasses`) but these are safe because the callees enter the vm right away. We even avoid switching to `WXWrite` and back there.
So I thought it would be ok to coarsen the WXMode switching.
But maybe it's still better to avoid any risk especially since there's likely no performance effect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18238#discussion_r1523305040

From rrich at openjdk.org  Wed Mar 13 16:43:12 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 13 Mar 2024 16:43:12 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
Message-ID: <ZVNGLPrhVQ6ww6IuXGQFjw7FRq6EOweNFSfpsdp8NtI=.ff84a9d0-6cbe-41a5-b458-78af8a91a176@github.com>

On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
> 
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> 
> More tests are pending.

@MBaesken found 2 more locations in jvmti that need switching to `WXWrite`

JvmtiExport::get_jvmti_interface
GetCarrierThread

Both use `ThreadInVMfromNative`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-1994930681

From dchuyko at openjdk.org  Wed Mar 13 16:58:23 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Wed, 13 Mar 2024 16:58:23 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v29]
In-Reply-To: <Vy661u_BkXOeDibHaqTa2Tf9FyjGrw-nJvSow3dfBpU=.a0d39b50-51e8-45c2-818f-2a6f751303c0@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
 <IxvZvwtkIvtjZucyIz3Am0MCT15z37dMIfgR2v3tykk=.0aee7ef9-b6d7-4dea-9c6d-31c2d164859d@github.com>
 <Vy661u_BkXOeDibHaqTa2Tf9FyjGrw-nJvSow3dfBpU=.a0d39b50-51e8-45c2-818f-2a6f751303c0@github.com>
Message-ID: <L80sUalzYA6yaYsT-IRPLJbfWmIULu5lxL94fYumSyU=.c2d7721e-5bc3-4c6c-a282-96c674068303@github.com>

On Wed, 13 Mar 2024 07:43:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:
>> 
>>  - Resolved master conflicts
>>  - 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
>>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>>  - ... and 37 more: https://git.openjdk.org/jdk/compare/782206bc...ff39ac12
>
> src/hotspot/share/ci/ciEnv.cpp line 1144:
> 
>> 1142: 
>> 1143:       if (entry_bci == InvocationEntryBci) {
>> 1144:         if (TieredCompilation) {
> 
> Just a naive question. Why this check has been removed?

We want to let replacement of C2 method version by another C2 version of the same method in both tired and non-tired mode, which was not allowed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1523618332

From dchuyko at openjdk.org  Wed Mar 13 17:14:28 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Wed, 13 Mar 2024 17:14:28 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v30]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <rrn5lX_iqiS-VLh6zGZXZrHAC7WnvSqC9qPmBclK6sY=.df7958a1-7da3-4e21-bc21-79bdc49ab29d@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 48 commits:

 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Resolved master conflicts
 - 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 38 more: https://git.openjdk.org/jdk/compare/5cae7d20...22b42347

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

Changes: https://git.openjdk.org/jdk/pull/14111/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=29
  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 dchuyko at openjdk.org  Wed Mar 13 17:31:32 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Wed, 13 Mar 2024 17:31:32 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v31]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <qw8EmXNJ3GHm3ThejXNSwmZKrLFLVOoguHBL4L-UT4g=.373e7a9b-b3ba-426c-af1a-fc5d40b30cfa@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 incrementally with one additional commit since the last revision:

  No dots in -r descriptions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14111/files
  - new: https://git.openjdk.org/jdk/pull/14111/files/22b42347..36c30367

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=29-30

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 dchuyko at openjdk.org  Wed Mar 13 17:34:24 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Wed, 13 Mar 2024 17:34:24 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v29]
In-Reply-To: <SbElzoMCP8XdAga_V2-7Fknfj8kfKpn502xN2hNtbK4=.d2f365a9-a050-41a3-9ba0-4ae80e056811@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
 <IxvZvwtkIvtjZucyIz3Am0MCT15z37dMIfgR2v3tykk=.0aee7ef9-b6d7-4dea-9c6d-31c2d164859d@github.com>
 <SbElzoMCP8XdAga_V2-7Fknfj8kfKpn502xN2hNtbK4=.d2f365a9-a050-41a3-9ba0-4ae80e056811@github.com>
Message-ID: <1AM7yClR1fxPAHevEwcSaNI8hP-KM2oVTwYT41pyEo0=.06098a55-7e89-4214-bcbe-faef2965f4df@github.com>

On Wed, 13 Mar 2024 07:48:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:
>> 
>>  - Resolved master conflicts
>>  - 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
>>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>>  - ... and 37 more: https://git.openjdk.org/jdk/compare/782206bc...ff39ac12
>
> src/hotspot/share/services/diagnosticCommand.cpp line 928:
> 
>> 926:                            DCmdWithParser(output, heap),
>> 927:   _filename("filename", "Name of the directives file", "STRING", true),
>> 928:   _refresh("-r", "Refresh affected methods.", "BOOLEAN", false, "false") {
> 
> Nit: The dot is not needed at the end, I think. The same applies to lines: 945, 970 and 987.

Thanks, the dots were removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1523664980

From mchung at openjdk.org  Wed Mar 13 17:42:15 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 13 Mar 2024 17:42:15 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v10]
In-Reply-To: <5MCgY2p_D4NXKr71Tv_E0uqg9Y8WpQe0LMrFTGjaJUg=.c5f16c93-3c3b-4606-a351-425d4e8bb99f@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <5MCgY2p_D4NXKr71Tv_E0uqg9Y8WpQe0LMrFTGjaJUg=.c5f16c93-3c3b-4606-a351-425d4e8bb99f@github.com>
Message-ID: <vyEAK9gzbLmLWj70wD_YX70BLeSYzu7gCkOwE7ZeLAg=.5ce26638-30ab-4746-bd92-ac46895b07dc@github.com>

On Tue, 12 Mar 2024 19:58:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

The spec change looks good to me.    I leave to others to review the implementation and test changes.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 85:

> 83:  *
> 84:  * <p>JMX Subject Delegation has been removed. All methods that take a
> 85:  * delegationSubject parameter will throw UnsupportedOperationException if

Suggestion:

 * <p>JMX Subject Delegation has been removed. All methods that take a
 * delegation subject parameter will throw {@code UnsupportedOperationException} if

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18025#pullrequestreview-1934819628
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1523673795

From kevinw at openjdk.org  Wed Mar 13 19:15:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 13 Mar 2024 19:15:13 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v10]
In-Reply-To: <vyEAK9gzbLmLWj70wD_YX70BLeSYzu7gCkOwE7ZeLAg=.5ce26638-30ab-4746-bd92-ac46895b07dc@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <5MCgY2p_D4NXKr71Tv_E0uqg9Y8WpQe0LMrFTGjaJUg=.c5f16c93-3c3b-4606-a351-425d4e8bb99f@github.com>
 <vyEAK9gzbLmLWj70wD_YX70BLeSYzu7gCkOwE7ZeLAg=.5ce26638-30ab-4746-bd92-ac46895b07dc@github.com>
Message-ID: <EZMs2fRg21kV6CjhIjQV3TIKwgsMvo8sB6mkfV4E8_I=.3f99bd88-b6ca-4941-ad41-54eccb75fd66@github.com>

On Wed, 13 Mar 2024 17:39:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The spec change looks good to me. I leave to others to review the implementation and test changes.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1995445698

From amenkov at openjdk.org  Wed Mar 13 19:29:13 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 13 Mar 2024 19:29:13 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
Message-ID: <hcLiga2frALeRWVVRUAnkNvjLUkzbwm9EnLEDnMRQqk=.b8dbb825-e0e7-47da-be36-4f826b5f9df2@github.com>

On Wed, 13 Mar 2024 04:13:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed attributes_count from RecordComponent
>
> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 516:
> 
>> 514:                         + component->annotations() != nullptr ? 1 : 0
>> 515:                         + component->type_annotations() != nullptr ? 1 : 0;
>> 516:     write_u2(attributes_count);
> 
> Nit: I would suggest to define this function in the `RecordComponent` class:
> 
>   u2 attributes_count() const {
>      u2 attributes_count =  generic_signature_index() != 0 ? 1 : 0
>                     + annotations() != nullptr ? 1 : 0
>                     + type_annotations() != nullptr ? 1 : 0;
>      return attributes_count;
>   }

RecordComponent contains information about Record attribute, but it knows nothing about class bytes and attributute_count doesn't make sense for it.
So I think this is JvmtiClassFileReconstituter responsibility to calculate a value required to generate class bytes for RecordComponent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1523810447

From amenkov at openjdk.org  Wed Mar 13 19:37:15 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 13 Mar 2024 19:37:15 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
Message-ID: <ZYKVQRGpHpCY3YVMGRYI_qTU-fH7bL_SGHHb-_uM7bQ=.6634387a-2be8-4321-8ee1-0658bca0f011@github.com>

On Wed, 13 Mar 2024 04:29:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed attributes_count from RecordComponent
>
> test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 96:
> 
>> 94:         {
>> 95:             log("Test: retransform to null");
>> 96:             retransform(null);
> 
> Q: Could you add a comment why it is needed?

This is the test itself as described in the bug report - without the fix it fails with ClassFormatError

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1523819348

From kevinw at openjdk.org  Wed Mar 13 20:08:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 13 Mar 2024 20:08:36 GMT
Subject: RFR: 8327864: Support segmented heap dump for
 HotSpotDiagnosticMXBean
In-Reply-To: <qshguvc5YqLBPpMaLJtQ14WiLVvInkulNf5pHY6tgSc=.2af0d959-7d6b-4bbc-9bb5-64236559972a@github.com>
References: <qshguvc5YqLBPpMaLJtQ14WiLVvInkulNf5pHY6tgSc=.2af0d959-7d6b-4bbc-9bb5-64236559972a@github.com>
Message-ID: <okxNl-08QEME6en4eFQ0jGojAr0NOQaOHQ5G4a93A2Q=.d36c5a3c-03cc-456f-9486-249b96eb3d21@github.com>

On Tue, 12 Mar 2024 07:59:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> We've received feedback from users of cloud APM platform wanting the new version of the JDK to allow the HotSpotDiagnosticMXBean.dumpHeap underpinnings to reduce STW time using sgemented heapdump. Supporting segmented heapdump for mxbean is a reasonable requirement and adds little additional complexity, both in terms of maintainability and understanding.

Hi!

Segmented is an awkward term as we use that word inside hprof too.  For the previous change we used the phrase "two phase" as well as calling it segmented, which I think helps.

Also this change means jmm_DumpHeap will always use HeapDumper::default_num_of_dump_threads().

That's not a bad thing, but could the bug title be something like "Enable two-phase heap dump for HotSpotDiagnosticMXBean (JMX)" ?  I think then it's clearer what's happening just from the title.



+  if (current_thread->is_AttachListener_thread() || !_oome) {

I think "!_oome" here means "we are called from JMX" ?  We should clarify. 8-)  Trying to suggest a way of describing this.

    // Operating in attach listener or called by management library:
    // perform heapdump file merge operation in the current thread, preventing us
    // from occupying the VM Thread, which in turn affects the occurrence of
    // GC and other VM operations.
	
So the other case is only HeapDumpOnOutOfMemoryError processing, where we do the merge in a VM operation?  Just checking if that's all agreed. 8-)

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

PR Review: https://git.openjdk.org/jdk/pull/18221#pullrequestreview-1935100384

From mullan at openjdk.org  Wed Mar 13 20:09:09 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Mar 2024 20:09:09 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
Message-ID: <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>

On Tue, 5 Mar 2024 19:56:58 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to MBeanServerFileAccessController.java

test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 29:

> 27:  * @enablePreview
> 28:  * @summary Implement Subject.current and Subject.callAs using scoped values.
> 29:  *      Need @enablePreview to use StructuredTaskScope.

jtreg throws a `ParseException` because I think it tries to interpret it as an `@enablePreview` action. Suggest enclosing it in double quotes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1523838888

From sspitsyn at openjdk.org  Wed Mar 13 20:45:47 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 20:45:47 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v31]
In-Reply-To: <L80sUalzYA6yaYsT-IRPLJbfWmIULu5lxL94fYumSyU=.c2d7721e-5bc3-4c6c-a282-96c674068303@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
 <IxvZvwtkIvtjZucyIz3Am0MCT15z37dMIfgR2v3tykk=.0aee7ef9-b6d7-4dea-9c6d-31c2d164859d@github.com>
 <Vy661u_BkXOeDibHaqTa2Tf9FyjGrw-nJvSow3dfBpU=.a0d39b50-51e8-45c2-818f-2a6f751303c0@github.com>
 <L80sUalzYA6yaYsT-IRPLJbfWmIULu5lxL94fYumSyU=.c2d7721e-5bc3-4c6c-a282-96c674068303@github.com>
Message-ID: <n6vnmpx9IuGzw8BEzhSiUfBQ9zQ_7AGqQXmk1KXxiF0=.c2389e86-6064-425a-82d7-9db4f5eab220@github.com>

On Wed, 13 Mar 2024 16:55:28 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> src/hotspot/share/ci/ciEnv.cpp line 1144:
>> 
>>> 1142: 
>>> 1143:       if (entry_bci == InvocationEntryBci) {
>>> 1144:         if (TieredCompilation) {
>> 
>> Just a naive question. Why this check has been removed?
>
> We want to let replacement of C2 method version by another C2 version of the same method in both tired and non-tired mode, which was not allowed

Okay, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1523889164

From sspitsyn at openjdk.org  Wed Mar 13 20:56:45 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 20:56:45 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v31]
In-Reply-To: <qw8EmXNJ3GHm3ThejXNSwmZKrLFLVOoguHBL4L-UT4g=.373e7a9b-b3ba-426c-af1a-fc5d40b30cfa@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
 <qw8EmXNJ3GHm3ThejXNSwmZKrLFLVOoguHBL4L-UT4g=.373e7a9b-b3ba-426c-af1a-fc5d40b30cfa@github.com>
Message-ID: <QMa6GLW9Jwon1SsJhzRqYFu1yGKcc0I3eI52hC_eAnM=.3c7baa10-8503-47cb-b6d8-b51093a39a37@github.com>

On Wed, 13 Mar 2024 17:31:32 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> 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...
>
> Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No dots in -r descriptions

The fix looks good. But I do not have an expertise in the compiler-specific part.
So, a review from the Compiler team is still required.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14111#pullrequestreview-1935188358

From sspitsyn at openjdk.org  Wed Mar 13 21:02:39 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 21:02:39 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <ZYKVQRGpHpCY3YVMGRYI_qTU-fH7bL_SGHHb-_uM7bQ=.6634387a-2be8-4321-8ee1-0658bca0f011@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
 <ZYKVQRGpHpCY3YVMGRYI_qTU-fH7bL_SGHHb-_uM7bQ=.6634387a-2be8-4321-8ee1-0658bca0f011@github.com>
Message-ID: <ba5QWJjKdMJo5RdCAJ__Rx6hiUBdNZ8c6sJSWSssf_w=.842907dd-a30b-4e68-a87e-60ffab49d53a@github.com>

On Wed, 13 Mar 2024 19:34:17 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 96:
>> 
>>> 94:         {
>>> 95:             log("Test: retransform to null");
>>> 96:             retransform(null);
>> 
>> Q: Could you add a comment why it is needed?
>
> This is the test itself as described in the bug report - without the fix it fails with ClassFormatError

Could you add a short comment, please?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1523908781

From sspitsyn at openjdk.org  Wed Mar 13 21:08:40 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 21:08:40 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <hcLiga2frALeRWVVRUAnkNvjLUkzbwm9EnLEDnMRQqk=.b8dbb825-e0e7-47da-be36-4f826b5f9df2@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
 <hcLiga2frALeRWVVRUAnkNvjLUkzbwm9EnLEDnMRQqk=.b8dbb825-e0e7-47da-be36-4f826b5f9df2@github.com>
Message-ID: <ngULigXLGEgf5oJiBWJvylbQi1vihyc7sbp-JxBFtso=.63408a65-abf9-466e-a09c-312bb89a3c7d@github.com>

On Wed, 13 Mar 2024 19:26:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 516:
>> 
>>> 514:                         + component->annotations() != nullptr ? 1 : 0
>>> 515:                         + component->type_annotations() != nullptr ? 1 : 0;
>>> 516:     write_u2(attributes_count);
>> 
>> Nit: I would suggest to define this function in the `RecordComponent` class:
>> 
>>   u2 attributes_count() const {
>>      u2 attributes_count =  generic_signature_index() != 0 ? 1 : 0
>>                     + annotations() != nullptr ? 1 : 0
>>                     + type_annotations() != nullptr ? 1 : 0;
>>      return attributes_count;
>>   }
>
> RecordComponent contains information about Record attribute, but it knows nothing about class bytes and attributute_count doesn't make sense for it.
> So I think this is JvmtiClassFileReconstituter responsibility to calculate a value required to generate class bytes for RecordComponent.

The `attributute_count ` is a property of the `RecordComponent` even though it is not stored but calculated.
The `JvmtiClassFileReconstituter` should have a minimal knowledge about this property and how it is calculated, the same as any other consumer of the `RecordComponent`. Thre `RedefineClasses` in the future may need this number as well. Would it be also its responsibility to calculate it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1523914277

From sspitsyn at openjdk.org  Wed Mar 13 22:55:39 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 22:55:39 GMT
Subject: RFR: JDK-8326898: NSK tests should listen on loopback addresses
 only [v2]
In-Reply-To: <n3hQXBuq0zkKL4xe0npHwe0pCXFxD4Ol9U7o1wpeozg=.c21969de-1636-4ab7-a6fd-fad59e6f3c57@github.com>
References: <0S05fii4BnVxmQZnEC2qOSmrTzAtyZTvYlblSDeNiKg=.99d7c8b1-8144-47dc-9e03-5e447b283a58@github.com>
 <n3hQXBuq0zkKL4xe0npHwe0pCXFxD4Ol9U7o1wpeozg=.c21969de-1636-4ab7-a6fd-fad59e6f3c57@github.com>
Message-ID: <rJffXYs5L_Jk0z0JsQnFhwh_KRy1rYP1qT0Jb2fD8dk=.6d4caba9-7011-4ff1-b3fa-e0aa8f842f3d@github.com>

On Tue, 5 Mar 2024 02:24:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Many NSK tests create socket channel for test/target interprocess communication.
>> The change updates server side to listen only on loopback interface.
>> 
>> Testing - all tests that use then functionality:
>>  - test/hotspot/jtreg/vmTestbase/nsk/jdb, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/aod, test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SocketIOPipe.createClientIOPipe and getTestHost()/getDebugeeHost()

The update looks okay.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18053#pullrequestreview-1935351090

From amenkov at openjdk.org  Wed Mar 13 23:28:38 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 13 Mar 2024 23:28:38 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
Message-ID: <ILrrm1xQjM4TSOjtep-QDxCn3hxMAKFgbcxvF__lWh0=.4966b876-8e9f-4c0a-92c0-69afcbdbe8a0@github.com>

On Wed, 13 Mar 2024 04:36:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It is interesting that if an invisible attribute of a `RecordComponent` was not ignored because the `PreserveAllAnnotations` is enabled then it the `JvmtiClassFileReconstituter` treats it as a visible attribute. Not sure, if we should treat it as a bug.

Yes, if PreserveAllAnnotations is enabled, in the reconstituted class file the annotations become visible.
I suppose this is considered normal because effectively PreserveAllAnnotations makes annotations "visible" (i.e.VM sees them).

But we have an issue here.
if PreserveAllAnnotations is enabled and class has only RuntimeInvisibleAnnotations (no RuntimeVisibleAnnotations), the class constant pool does not contain "RuntimeVisibleAnnotations" and JvmtiClassFileReconstituter fails. I'll file a separate issue for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/18161#issuecomment-1996075217

From sspitsyn at openjdk.org  Wed Mar 13 23:31:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 23:31:38 GMT
Subject: RFR: JDK-8327468: Do not restart close if errno is EINTR
 [macOS/linux] [v2]
In-Reply-To: <ehBGokTt4vhU1VIwrMdhRie1r06Aylqr9XM0NO-q0mo=.6bb86b9d-e762-4ecc-b5d4-aaddcc605e39@github.com>
References: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
 <ehBGokTt4vhU1VIwrMdhRie1r06Aylqr9XM0NO-q0mo=.6bb86b9d-e762-4ecc-b5d4-aaddcc605e39@github.com>
Message-ID: <y9CD-FKlYPpsClyo6RplLeZe0dKkxQPFcfX3HJwj7zY=.cbee0cf4-8ee5-42c8-ae21-bdb32ef07c54@github.com>

On Mon, 11 Mar 2024 08:50:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a number of places remaining in the linux/macOS native JDK codebase where we use the RESTARTABLE macro with close, but this is unwanted on Linux/macOS.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not throw exception on close error

This looks okay to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18164#pullrequestreview-1935388674

From sspitsyn at openjdk.org  Wed Mar 13 23:43:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Mar 2024 23:43:38 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <ILrrm1xQjM4TSOjtep-QDxCn3hxMAKFgbcxvF__lWh0=.4966b876-8e9f-4c0a-92c0-69afcbdbe8a0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
 <ILrrm1xQjM4TSOjtep-QDxCn3hxMAKFgbcxvF__lWh0=.4966b876-8e9f-4c0a-92c0-69afcbdbe8a0@github.com>
Message-ID: <lTDTxupyViQGxyZ_-UcS1lxIfnGvnbkxe015vppPvGU=.ae3bfa1d-be79-4e0b-8f63-c6b171e286d9@github.com>

On Wed, 13 Mar 2024 23:25:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> But we have an issue here. if PreserveAllAnnotations is enabled and class has only RuntimeInvisibleAnnotations (no RuntimeVisibleAnnotations), the class constant pool does not contain "RuntimeVisibleAnnotations" and JvmtiClassFileReconstituter fails. I'll file a separate issue for this.

Nice catch. I felt there is something fishy there.

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

PR Comment: https://git.openjdk.org/jdk/pull/18161#issuecomment-1996100546

From amenkov at openjdk.org  Thu Mar 14 00:15:38 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 14 Mar 2024 00:15:38 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <ngULigXLGEgf5oJiBWJvylbQi1vihyc7sbp-JxBFtso=.63408a65-abf9-466e-a09c-312bb89a3c7d@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
 <hcLiga2frALeRWVVRUAnkNvjLUkzbwm9EnLEDnMRQqk=.b8dbb825-e0e7-47da-be36-4f826b5f9df2@github.com>
 <ngULigXLGEgf5oJiBWJvylbQi1vihyc7sbp-JxBFtso=.63408a65-abf9-466e-a09c-312bb89a3c7d@github.com>
Message-ID: <lKsxhQehvFpzK8FoRs4JQaLSsQeyQoKe9EQ1qs4eTBc=.0687675b-39ce-4f6a-ab18-e950c624e6f6@github.com>

On Wed, 13 Mar 2024 21:05:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> RecordComponent contains information about Record attribute, but it knows nothing about class bytes and attributute_count doesn't make sense for it.
>> So I think this is JvmtiClassFileReconstituter responsibility to calculate a value required to generate class bytes for RecordComponent.
>
> The `attributute_count ` is a property of the `RecordComponent` even though it is not stored but calculated.
> The `JvmtiClassFileReconstituter` should have a minimal knowledge about this property and how it is calculated, the same as any other consumer of the `RecordComponent`. Thre `RedefineClasses` in the future may need this number as well. Would it be also its responsibility to calculate it?

`attributute_count` is a property of `component_info` Record's attribute in the class file (it contains length of the following `attribute_info_attributes` array).
`RecordComponent` is VM representation of Record class attribute and contains data required by VM in a form that is useful for the VM.
`RecordComponent` knows nothing `attribute_info_attributes` array, so it does not need to know its length.

 ClassFileParser parses `attribute_info_attributes` array and convert it to corresponding fields of `RecordComponent`.
`JvmtiClassFileReconstituter` performs the reverse operation.
They may have different `attributute_count` (that's what this bug about).
If `RedefineClasses` needs the value, the code may be updated (it depends on what value it needs - from original class file or from reconstituted class file)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1524052651

From amenkov at openjdk.org  Thu Mar 14 00:22:43 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 14 Mar 2024 00:22:43 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v4]
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <VQqpRp_YEmRZkBFbfUyB8je_OhPKl_AUatZRiKUdrXo=.a381e705-47b3-412e-9e78-a597160195ee@github.com>

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> Also annotations can be changed (added/removed) by class redefinition.
> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Added comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18161/files
  - new: https://git.openjdk.org/jdk/pull/18161/files/f82e432a..671c71e1

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

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

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

From amenkov at openjdk.org  Thu Mar 14 00:22:44 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 14 Mar 2024 00:22:44 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <ba5QWJjKdMJo5RdCAJ__Rx6hiUBdNZ8c6sJSWSssf_w=.842907dd-a30b-4e68-a87e-60ffab49d53a@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
 <ZYKVQRGpHpCY3YVMGRYI_qTU-fH7bL_SGHHb-_uM7bQ=.6634387a-2be8-4321-8ee1-0658bca0f011@github.com>
 <ba5QWJjKdMJo5RdCAJ__Rx6hiUBdNZ8c6sJSWSssf_w=.842907dd-a30b-4e68-a87e-60ffab49d53a@github.com>
Message-ID: <wKGKSbvnHG7vTmk80gInCxENmkdSycaIIuhNxlQK-XA=.2dcd588e-c298-437e-8205-ee56b0a84a92@github.com>

On Wed, 13 Mar 2024 20:59:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is the test itself as described in the bug report - without the fix it fails with ClassFormatError
>
> Could you add a short comment, please?

Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1524055664

From cjplummer at openjdk.org  Thu Mar 14 00:23:41 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 14 Mar 2024 00:23:41 GMT
Subject: RFR: JDK-8326898: NSK tests should listen on loopback addresses
 only [v2]
In-Reply-To: <n3hQXBuq0zkKL4xe0npHwe0pCXFxD4Ol9U7o1wpeozg=.c21969de-1636-4ab7-a6fd-fad59e6f3c57@github.com>
References: <0S05fii4BnVxmQZnEC2qOSmrTzAtyZTvYlblSDeNiKg=.99d7c8b1-8144-47dc-9e03-5e447b283a58@github.com>
 <n3hQXBuq0zkKL4xe0npHwe0pCXFxD4Ol9U7o1wpeozg=.c21969de-1636-4ab7-a6fd-fad59e6f3c57@github.com>
Message-ID: <MMmUiO2q8K3_Fki-w39H-CHzAnJQlKnuKiEpZPEtGgM=.88de4632-4a2b-4a89-8fc6-29663da10165@github.com>

On Tue, 5 Mar 2024 02:24:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Many NSK tests create socket channel for test/target interprocess communication.
>> The change updates server side to listen only on loopback interface.
>> 
>> Testing - all tests that use then functionality:
>>  - test/hotspot/jtreg/vmTestbase/nsk/jdb, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/aod, test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SocketIOPipe.createClientIOPipe and getTestHost()/getDebugeeHost()

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18053#pullrequestreview-1935431224

From sspitsyn at openjdk.org  Thu Mar 14 02:16:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Mar 2024 02:16:38 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <lKsxhQehvFpzK8FoRs4JQaLSsQeyQoKe9EQ1qs4eTBc=.0687675b-39ce-4f6a-ab18-e950c624e6f6@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
 <hcLiga2frALeRWVVRUAnkNvjLUkzbwm9EnLEDnMRQqk=.b8dbb825-e0e7-47da-be36-4f826b5f9df2@github.com>
 <ngULigXLGEgf5oJiBWJvylbQi1vihyc7sbp-JxBFtso=.63408a65-abf9-466e-a09c-312bb89a3c7d@github.com>
 <lKsxhQehvFpzK8FoRs4JQaLSsQeyQoKe9EQ1qs4eTBc=.0687675b-39ce-4f6a-ab18-e950c624e6f6@github.com>
Message-ID: <EIFWxoiPJCZoEzuJmoiQJEmZJmNytP8yITdfrOo-Xr4=.d51bac99-af7c-47b5-9b3a-7e5b9c24177a@github.com>

On Thu, 14 Mar 2024 00:12:43 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The `attributute_count ` is a property of the `RecordComponent` even though it is not stored but calculated.
>> The `JvmtiClassFileReconstituter` should have a minimal knowledge about this property and how it is calculated, the same as any other consumer of the `RecordComponent`. Thre `RedefineClasses` in the future may need this number as well. Would it be also its responsibility to calculate it?
>
> `attributute_count` is a property of `component_info` Record's attribute in the class file (it contains length of the following `attribute_info_attributes` array).
> `RecordComponent` is VM representation of Record class attribute and contains data required by VM in a form that is useful for the VM.
> `RecordComponent` knows nothing `attribute_info_attributes` array, so it does not need to know its length.
> 
>  ClassFileParser parses `attribute_info_attributes` array and convert it to corresponding fields of `RecordComponent`.
> `JvmtiClassFileReconstituter` performs the reverse operation.
> They may have different `attributute_count` (that's what this bug about).
> If `RedefineClasses` needs the value, the code may be updated (it depends on what value it needs - from original class file or from reconstituted class file)

It does not matter what the `ClassFileParser` does.

> ` JvmtiClassFileReconstituter` performs the reverse operation.

True. It should know how to put the `attribute_count` value into the class file but it does not need to know how to calculate its value. What I do not like in your model is that there is no one single place which knows how to calculate this value and the existing and potential consumers should have this knowledge.

> They may have different `attributute_count `(that's what this bug about).

The bug is that the `attributute_count` field value from the class file stored in the `RecordComponent` does not match the calculated value because the invisible attribute was not saved (was ignored). My suggestion is not to store the `attributute_count` field value from the class file as it was before. The suggestion is to place the calculating function `attributute_count()` into the `RecordComponent` class.

>> Could you add a short comment, please?
>
> Added.

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1524116453
PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1524117292

From yyang at openjdk.org  Thu Mar 14 02:28:37 2024
From: yyang at openjdk.org (Yi Yang)
Date: Thu, 14 Mar 2024 02:28:37 GMT
Subject: RFR: 8327864: Support segmented heap dump for
 HotSpotDiagnosticMXBean
In-Reply-To: <okxNl-08QEME6en4eFQ0jGojAr0NOQaOHQ5G4a93A2Q=.d36c5a3c-03cc-456f-9486-249b96eb3d21@github.com>
References: <qshguvc5YqLBPpMaLJtQ14WiLVvInkulNf5pHY6tgSc=.2af0d959-7d6b-4bbc-9bb5-64236559972a@github.com>
 <okxNl-08QEME6en4eFQ0jGojAr0NOQaOHQ5G4a93A2Q=.d36c5a3c-03cc-456f-9486-249b96eb3d21@github.com>
Message-ID: <o2_nUU65oUN02Vpg5tLDN3IE4_aMDkBJwclGgrp8d_w=.5b39189e-a27f-42cd-aa4a-024f959901fc@github.com>

On Wed, 13 Mar 2024 20:01:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> We've received feedback from users of cloud APM platform wanting the new version of the JDK to allow the HotSpotDiagnosticMXBean.dumpHeap underpinnings to reduce STW time using sgemented heapdump. Supporting segmented heapdump for mxbean is a reasonable requirement and adds little additional complexity, both in terms of maintainability and understanding.
>
> Hi!
> 
> Segmented is an awkward term as we use that word inside hprof too.  For the previous change we used the phrase "two phase" as well as calling it segmented, which I think helps.
> 
> Also this change means jmm_DumpHeap will always use HeapDumper::default_num_of_dump_threads().
> 
> That's not a bad thing, but could the bug title be something like "Enable two-phase heap dump for HotSpotDiagnosticMXBean (JMX)" ?  I think then it's clearer what's happening just from the title.
> 
> 
> 
> +  if (current_thread->is_AttachListener_thread() || !_oome) {
> 
> I think "!_oome" here means "we are called from JMX" ?  We should clarify. 8-)  Trying to suggest a way of describing this.
> 
>     // Operating in attach listener or called by management library:
>     // perform heapdump file merge operation in the current thread, preventing us
>     // from occupying the VM Thread, which in turn affects the occurrence of
>     // GC and other VM operations.
> 	
> So the other case is only HeapDumpOnOutOfMemoryError processing, where we do the merge in a VM operation?  Just checking if that's all agreed. 8-)

Hi @kevinjwalls Thanks for your review! I was reminded by Alex that there is already a [similar issue](https://bugs.openjdk.org/browse/JDK-8322043) here ready to make two phase heap dump the default choice, so all we need is to simply change the default parallel parameter (and potential bug fix)

https://github.com/openjdk/jdk/blob/21279b1f652c54693e317d55e7da6478b959fdfb/src/hotspot/share/services/heapDumper.hpp#L64

I will first synergize with @alexmenkov to see if we can improve based on the current patch, or close the current PR and wait for his new one.

P.S. the phrase "two phase" makes sense to me:)

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

PR Comment: https://git.openjdk.org/jdk/pull/18221#issuecomment-1996279522

From yyang at openjdk.org  Thu Mar 14 02:41:39 2024
From: yyang at openjdk.org (Yi Yang)
Date: Thu, 14 Mar 2024 02:41:39 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v2]
In-Reply-To: <tm8wZB-vPfuSoyzWnxW6RI9A7FGkT6ucKB_iicwR4Ss=.d1ede645-f03a-4a34-b9f1-0b86fe7fec06@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <tm8wZB-vPfuSoyzWnxW6RI9A7FGkT6ucKB_iicwR4Ss=.d1ede645-f03a-4a34-b9f1-0b86fe7fec06@github.com>
Message-ID: <Py79NINZERjZj2GR_9Fp6pqpHh9zCqQsLXeuScl7Uwk=.76e7641e-10b3-4290-b167-6415a4c19fd7@github.com>

On Tue, 12 Mar 2024 12:22:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   alloc_and_create_heapdump_pathname adjust comment about freeing the returned  pointer

Looks reasonable, this is a harmless change, but the name `dump_to_heapdump_path` looks too details(and somewhat strange) to me

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

PR Review: https://git.openjdk.org/jdk/pull/18190#pullrequestreview-1935544801

From mbaesken at openjdk.org  Thu Mar 14 08:04:42 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 08:04:42 GMT
Subject: RFR: JDK-8327468: Do not restart close if errno is EINTR
 [macOS/linux] [v2]
In-Reply-To: <ehBGokTt4vhU1VIwrMdhRie1r06Aylqr9XM0NO-q0mo=.6bb86b9d-e762-4ecc-b5d4-aaddcc605e39@github.com>
References: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
 <ehBGokTt4vhU1VIwrMdhRie1r06Aylqr9XM0NO-q0mo=.6bb86b9d-e762-4ecc-b5d4-aaddcc605e39@github.com>
Message-ID: <zMssOx5YeZpD1eKe_nQZA42B8jkBWIVgC9_oPpYL3co=.56228eb8-e11e-43ee-9c47-b1d788279752@github.com>

On Mon, 11 Mar 2024 08:50:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a number of places remaining in the linux/macOS native JDK codebase where we use the RESTARTABLE macro with close, but this is unwanted on Linux/macOS.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not throw exception on close error

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/18164#issuecomment-1996775638

From mbaesken at openjdk.org  Thu Mar 14 08:04:43 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 08:04:43 GMT
Subject: Integrated: JDK-8327468: Do not restart close if errno is EINTR
 [macOS/linux]
In-Reply-To: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
References: <KAeKbxV0geb4I5Xqei6IwGaHncfwQTWfO0Ou0I-zG-o=.059384d1-26ac-419e-8c7d-e231321ec5dd@github.com>
Message-ID: <gpCCL7HvQQRbLweUw2-esd4aeTi3mRSey_ftUf3Z1T8=.1323e2fa-deb6-460c-90d2-29bd78c19655@github.com>

On Fri, 8 Mar 2024 10:12:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a number of places remaining in the linux/macOS native JDK codebase where we use the RESTARTABLE macro with close, but this is unwanted on Linux/macOS.

This pull request has now been integrated.

Changeset: 481c866d
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/481c866df87c693a90a1da20e131e5654b084ddd
Stats:     6 lines in 2 files changed: 0 ins; 3 del; 3 mod

8327468: Do not restart close if errno is EINTR [macOS/linux]

Reviewed-by: dholmes, sspitsyn

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

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

From tholenstein at openjdk.org  Thu Mar 14 08:41:50 2024
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Thu, 14 Mar 2024 08:41:50 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v31]
In-Reply-To: <qw8EmXNJ3GHm3ThejXNSwmZKrLFLVOoguHBL4L-UT4g=.373e7a9b-b3ba-426c-af1a-fc5d40b30cfa@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
 <qw8EmXNJ3GHm3ThejXNSwmZKrLFLVOoguHBL4L-UT4g=.373e7a9b-b3ba-426c-af1a-fc5d40b30cfa@github.com>
Message-ID: <ntjkEMdoyfLseWV2dOsS_iqSGni0vETDuj-f3GGBpY8=.9475ff29-2e45-4a66-972a-f309bafc70bb@github.com>

On Wed, 13 Mar 2024 17:31:32 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> 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...
>
> Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No dots in -r descriptions

Looks good to me too (Compiler Team)

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

Marked as reviewed by tholenstein (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14111#pullrequestreview-1936031298

From mbaesken at openjdk.org  Thu Mar 14 08:52:39 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 08:52:39 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v2]
In-Reply-To: <Py79NINZERjZj2GR_9Fp6pqpHh9zCqQsLXeuScl7Uwk=.76e7641e-10b3-4290-b167-6415a4c19fd7@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <tm8wZB-vPfuSoyzWnxW6RI9A7FGkT6ucKB_iicwR4Ss=.d1ede645-f03a-4a34-b9f1-0b86fe7fec06@github.com>
 <Py79NINZERjZj2GR_9Fp6pqpHh9zCqQsLXeuScl7Uwk=.76e7641e-10b3-4290-b167-6415a4c19fd7@github.com>
Message-ID: <fZdUtavMAP0NVVHj9mRC8HPENUbSiPOqUfqfVavA0y0=.4c5bae90-0d17-4394-ab35-09e7fc2a3248@github.com>

On Thu, 14 Mar 2024 02:39:28 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Looks reasonable, this is a harmless change, but the name `dump_to_heapdump_path` looks too details(and somewhat strange) to me

Do you  maybe have a good suggestion for a new name ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1996891933

From mbaesken at openjdk.org  Thu Mar 14 09:13:03 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 09:13:03 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v3]
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <DNwcOHm0GsUZdYYSd9D0Cb0CaArggYaVNI8ahKOPwuU=.65d38225-3dd5-442d-86b8-3dd89e2486bd@github.com>

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

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

  Adjust text related to HeapDumpPath in globals.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18190/files
  - new: https://git.openjdk.org/jdk/pull/18190/files/e335d9ee..7420fb47

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

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

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

From mbaesken at openjdk.org  Thu Mar 14 09:15:40 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 09:15:40 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v3]
In-Reply-To: <DNwcOHm0GsUZdYYSd9D0Cb0CaArggYaVNI8ahKOPwuU=.65d38225-3dd5-442d-86b8-3dd89e2486bd@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <DNwcOHm0GsUZdYYSd9D0Cb0CaArggYaVNI8ahKOPwuU=.65d38225-3dd5-442d-86b8-3dd89e2486bd@github.com>
Message-ID: <-74D6u4DQr6NYryXNj94H4t9J1ek-RurN2MEAzDAgHc=.6aab6091-386f-4838-bbc5-e271849a13c6@github.com>

On Thu, 14 Mar 2024 09:13:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust text related to HeapDumpPath in globals.hpp

Hi Kevin,

> globals.hpp documents HeapDumpPath as relating to HeapDumpOnOutOfMemoryError (so that will need changing if this change is happening).


I adjusted the related text in globals.hpp . Please check.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1996977356

From dchuyko at openjdk.org  Thu Mar 14 09:22:47 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 14 Mar 2024 09:22:47 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v31]
In-Reply-To: <qw8EmXNJ3GHm3ThejXNSwmZKrLFLVOoguHBL4L-UT4g=.373e7a9b-b3ba-426c-af1a-fc5d40b30cfa@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
 <qw8EmXNJ3GHm3ThejXNSwmZKrLFLVOoguHBL4L-UT4g=.373e7a9b-b3ba-426c-af1a-fc5d40b30cfa@github.com>
Message-ID: <MXwOuOQ5Ov_3aBPQxh3w-lwj1N_OTDlObUWAzjN31p8=.80df326d-e536-497d-b060-7db318b034eb@github.com>

On Wed, 13 Mar 2024 17:31:32 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> 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...
>
> Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No dots in -r descriptions

Thank you, Seguei and Tobias.

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

PR Comment: https://git.openjdk.org/jdk/pull/14111#issuecomment-1996995661

From mbaesken at openjdk.org  Thu Mar 14 09:23:44 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 09:23:44 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <ZVNGLPrhVQ6ww6IuXGQFjw7FRq6EOweNFSfpsdp8NtI=.ff84a9d0-6cbe-41a5-b458-78af8a91a176@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <ZVNGLPrhVQ6ww6IuXGQFjw7FRq6EOweNFSfpsdp8NtI=.ff84a9d0-6cbe-41a5-b458-78af8a91a176@github.com>
Message-ID: <VvZR50_gq2VHqqYWjz1SCWEcu-4aYVC1-hSNubnGZCE=.39a2f503-30b1-4e96-be18-cf09b07428d7@github.com>

On Wed, 13 Mar 2024 16:40:33 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> @MBaesken found 2 more locations in jvmti that need switching to `WXWrite`
> 
> JvmtiExport::get_jvmti_interface GetCarrierThread
> 
> Both use `ThreadInVMfromNative`.

Should we address those 2 more findings in this PR ? Or open a separate JBS issue ?

btw those were the jtreg tests triggering the 2 additional findings / asserts 

runtime/Thread/AsyncExceptionOnMonitorEnter.java
runtime/Thread/AsyncExceptionTest.java
serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.java
runtime/handshake/HandshakeDirectTest.java
runtime/handshake/SuspendBlocked.java
runtime/jni/terminatedThread/TestTerminatedThread.java
runtime/lockStack/TestStackWalk.java
serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default
serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#no-vmcontinuations
serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java
serviceability/jvmti/vthread/RawMonitorTest/RawMonitorTest.java
serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default
serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#xint
serviceability/jvmti/vthread/ThreadStateTest/ThreadStateTest.java
serviceability/jvmti/vthread/WaitNotifySuspendedVThreadTest/WaitNotifySuspendedVThreadTest.java

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-1996996689

From dchuyko at openjdk.org  Thu Mar 14 09:26:00 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 14 Mar 2024 09:26:00 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v32]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <lj7DCo-WVOX99W4nfoRGj8wmeKKeqA2WslHDK4Yg2Co=.d0026301-2a2a-4d02-b4f0-96449550b12f@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 50 commits:

 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - No dots in -r descriptions
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Resolved master conflicts
 - 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 40 more: https://git.openjdk.org/jdk/compare/49ce85fa...eb4ed2ea

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

Changes: https://git.openjdk.org/jdk/pull/14111/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=31
  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 dnsimon at openjdk.org  Thu Mar 14 10:51:54 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Mar 2024 10:51:54 GMT
Subject: RFR: 8328135:
 javax/management/remote/mandatory/loading/MissingClassTest.java fails on
 libgraal
Message-ID: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>

This PR increases a timeout in `MissingClassTest.java` to handle slight slower compilation on a fastdebug build when using `-Xcomp`.
Testing on mach5 shows that the increase from 60 s to 90 s resolves the timeouts.

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

Commit messages:
 - increase timeout in loop waiting for listeners to receive notifs

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

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

From ihse at openjdk.org  Thu Mar 14 10:59:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Mar 2024 10:59:48 GMT
Subject: RFR: 8328146: Set LIBCXX automatically
Message-ID: <G4PfVrm0hXu7yxO8Kl2TxJ1zoxzW7NQ7WEwUWxM6zMs=.b0f7e904-1c70-4349-b987-1ca60aa2fb15@github.com>

We are adding LIBCXX to LIBS in calls to SetupJdkLibrary whenever LINK_TYPE is C++. We should do this automatically in SetupJdkLibrary for C++ linking.

I also removed the superfluous `-lc` from some places where it had been added.

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

Commit messages:
 - 8328146: Set LIBCXX automatically

Changes: https://git.openjdk.org/jdk/pull/18298/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328146
  Stats: 27 lines in 10 files changed: 8 ins; 4 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/18298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18298/head:pull/18298

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

From kevinw at openjdk.org  Thu Mar 14 11:53:11 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 11:53:11 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v11]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <_QCspkFRemnLYapwCrVmuX7ePA7o1v2PB2COJfadYqw=.6b86cb4d-0614-4ce7-86f4-e1ad38a1a9bf@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - Clarify JMXConnector equivalence comment.
 - RMIConnectionImpl needs to explicity inherit the unchecked UOE.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/a3e09e90..418b635c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=09-10

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

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

From dfuchs at openjdk.org  Thu Mar 14 11:59:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 14 Mar 2024 11:59:40 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v11]
In-Reply-To: <_QCspkFRemnLYapwCrVmuX7ePA7o1v2PB2COJfadYqw=.6b86cb4d-0614-4ce7-86f4-e1ad38a1a9bf@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <_QCspkFRemnLYapwCrVmuX7ePA7o1v2PB2COJfadYqw=.6b86cb4d-0614-4ce7-86f4-e1ad38a1a9bf@github.com>
Message-ID: <jc2BiCU5QJiEcIb4NT21L4HSUsZosFu-LZuK0zJMWuU=.ecb50bc6-119b-4a8c-8077-5d13b7c3a6da@github.com>

On Thu, 14 Mar 2024 11:53:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Clarify JMXConnector equivalence comment.
>  - RMIConnectionImpl needs to explicity inherit the unchecked UOE.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18025#pullrequestreview-1936454653

From kevinw at openjdk.org  Thu Mar 14 12:23:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 12:23:09 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v12]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <XjIsXv08qda6XXHXwt6erFb5le4RzEw2MAyoDxRBZPs=.f5117016-d624-4d77-b7af-b850a36940c8@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  RMIConnectionImpl_Stub also should explicity inherit the unchecked UOE.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/418b635c..91ec015f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=10-11

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

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

From ihse at openjdk.org  Thu Mar 14 12:40:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Mar 2024 12:40:59 GMT
Subject: RFR: 8328157: Move C[XX]FLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk
Message-ID: <HWRIVhg1Alb0zwfbVmKdAcAlfLX2uEblr5a06TmAzDc=.0c11539b-e1a0-44f1-9ce1-1d9e49e1f2bf@github.com>

We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`, `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively, in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.

These flag variables contain a lot of duplication.

The first step towards bringing some sanity to this mess is to move the setting of these variables into `SetupJdkLibrary/SetupJdkExecutable`.

In a few places these standard flags are not set, partially or fullly. This is handled by the new arguments `DEFAULT_CFLAGS := false` (to disable the entire setting) and `C[XX]FLAGS_FILTER_OUT` (which excludes some specific flag) to `SetupJdkLibrary/SetupJdkExecutable`.

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

Commit messages:
 - 8328157: Move C[XX]FLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk

Changes: https://git.openjdk.org/jdk/pull/18301/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18301&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328157
  Stats: 170 lines in 31 files changed: 45 ins; 66 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/18301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18301/head:pull/18301

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

From ihse at openjdk.org  Thu Mar 14 12:40:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Mar 2024 12:40:59 GMT
Subject: RFR: 8328157: Move C[XX]FLAGS_JDK[LIB/EXE] to
 JdkNativeCompilation.gmk
In-Reply-To: <HWRIVhg1Alb0zwfbVmKdAcAlfLX2uEblr5a06TmAzDc=.0c11539b-e1a0-44f1-9ce1-1d9e49e1f2bf@github.com>
References: <HWRIVhg1Alb0zwfbVmKdAcAlfLX2uEblr5a06TmAzDc=.0c11539b-e1a0-44f1-9ce1-1d9e49e1f2bf@github.com>
Message-ID: <bB4J2iWMPAT_zrDk8K3yy0fMbt0CftBhh5j0iK2hEA0=.27809d16-3c01-40b0-a19e-63f84062c4f8@github.com>

On Thu, 14 Mar 2024 12:36:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`, `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively, in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.
> 
> These flag variables contain a lot of duplication.
> 
> The first step towards bringing some sanity to this mess is to move the setting of these variables into `SetupJdkLibrary/SetupJdkExecutable`.
> 
> In a few places these standard flags are not set, partially or fullly. This is handled by the new arguments `DEFAULT_CFLAGS := false` (to disable the entire setting) and `C[XX]FLAGS_FILTER_OUT` (which excludes some specific flag) to `SetupJdkLibrary/SetupJdkExecutable`.

I have verified with `COMPARE_BUILD` that there is no significant difference in the build result with or without this patch on Oracle default CI platforms (linux x64/aarch64, macos x64/aarch64, windows x64).

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

PR Comment: https://git.openjdk.org/jdk/pull/18301#issuecomment-1997359912

From dchuyko at openjdk.org  Thu Mar 14 12:41:53 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 14 Mar 2024 12:41:53 GMT
Subject: Integrated: 8309271: A way to align already compiled methods with
 compiler directives
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <ZtbPw2d_HvwZgl5xCvsQrweK4ruAUdeipbwxhgLaVSM=.4d1ad422-ffd8-4a18-b98f-e4b2cdac9bbe@github.com>

On Wed, 24 May 2023 00:38:27 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

> 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 ...

This pull request has now been integrated.

Changeset: c879627d
Author:    Dmitry Chuyko <dchuyko at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c879627dbd7e9295d44f19ef237edb5de10805d5
Stats:     381 lines in 15 files changed: 348 ins; 3 del; 30 mod

8309271: A way to align already compiled methods with compiler directives

Reviewed-by: apangin, sspitsyn, tholenstein

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

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

From kevinw at openjdk.org  Thu Mar 14 12:26:52 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 12:26:52 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v5]
In-Reply-To: <3wr96ORHqThVPL-jv9eLazPROui87Muw2kgfQ9nJh3k=.9482f911-64d2-48cf-87a2-48718e30b857@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <rera7_PPMV9H4etRwmdn131BwxUBv4K95jRcWGdzEdU=.09f33a41-a0cb-4958-a32f-ae95326339ae@github.com>
 <1QrD6mMnKNSnBPXUacl4pvrXahlrFvhryXqgbjQO52c=.9092d0f6-4d6e-421e-b04f-6d277812ebfd@github.com>
 <LdiC1iOnUOOy4ZMjrzxyQUudv67BRB9PhzvHUCf5FCo=.b4de5198-089b-4ed4-991e-590a033d5a17@github.com>
 <3wr96ORHqThVPL-jv9eLazPROui87Muw2kgfQ9nJh3k=.9482f911-64d2-48cf-87a2-48718e30b857@github.com>
Message-ID: <up4t-n3yiXgwCDp2eDz3f37NGMrvGjX9J_xHqHxm6tQ=.e70dc186-6a97-48c3-bf13-dc303da5cac0@github.com>

On Mon, 11 Mar 2024 15:19:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.
>> 
>> No, nothing uses SubjectDelegationPermission.  That can be deprecated.
>> 
>>> Are there remaining tests that test the JMX fine grained permissions feature w/o depending on subject delegation?
>> 
>> Yes there are some tests other than those changed here, which use MBeanPermission in policies and become irrelevant post-SM.
>
>> Is there any value in keeping `SubjectDelegationPermission` after this change? If so, I would mark that API deprecated for removal, so that it can be removed in the next release or two.
> 
> No issue with deprecation. I guess it can be removed once `java.security.Policy` is removed?

Thanks @dfuch for the comments and review. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/18025#issuecomment-1997329701

From mbaesken at openjdk.org  Thu Mar 14 13:43:09 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 13:43:09 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v4]
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

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

  add test HeapDumpJcmdPresetPathTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18190/files
  - new: https://git.openjdk.org/jdk/pull/18190/files/7420fb47..61165f55

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

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

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

From mbaesken at openjdk.org  Thu Mar 14 13:55:38 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 13:55:38 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v4]
In-Reply-To: <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>
Message-ID: <ESVo0bTWRIpxR6ebMPMQP6aUf9DAx-BrNA1CVpB-oWI=.b9bc872a-04dd-42d1-939d-add4c4df0321@github.com>

On Thu, 14 Mar 2024 13:43:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test HeapDumpJcmdPresetPathTest

Hi Kevin,

> (and btw regarding your comment on a test, yes I agree there should be a separate test or at least an adjustment/addition to the existing tests)

I added a test HeapDumpJcmdPresetPathTest.java .

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1997514632

From asteiner at openjdk.org  Thu Mar 14 14:43:39 2024
From: asteiner at openjdk.org (Andreas Steiner)
Date: Thu, 14 Mar 2024 14:43:39 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v4]
In-Reply-To: <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>
Message-ID: <-jwVMHk1MncNeUPlWQkFD16vluuJA_qnpHOcBXg-MZk=.22e18712-ad6b-42c4-9ce2-fc96b4ebd422@github.com>

On Thu, 14 Mar 2024 13:43:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test HeapDumpJcmdPresetPathTest

This is really helpful from a support point of view.

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

Marked as reviewed by asteiner (Author).

PR Review: https://git.openjdk.org/jdk/pull/18190#pullrequestreview-1936916215

From mbaesken at openjdk.org  Thu Mar 14 14:51:37 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 14 Mar 2024 14:51:37 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
Message-ID: <H5MBza8VmQIavhew-OEqINtUeIaphLI2NxSPBLpNS4s=.6689ec48-39ef-4882-a936-3799495b73b4@github.com>

On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
> 
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> 
> More tests are pending.

I noticed a few more asserts  (assert(_wx_state == expected) failed: wrong state)   in the jfr area  (jdk tier3 jfr tests).
E.g. 


V  [libjvm.dylib+0x8a5d94]  JavaThread::check_for_valid_safepoint_state()+0x0
V  [libjvm.dylib+0x3e95b4]  ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState, bool)+0x174
V  [libjvm.dylib+0x3e93d0]  ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*)+0x70
V  [libjvm.dylib+0x91a578]  JfrRecorderService::emit_leakprofiler_events(long long, bool, bool)+0xcc



and 


V  [libjvm.dylib+0x8a5d94]  JavaThread::check_for_valid_safepoint_state()+0x0
V  [libjvm.dylib+0x3e95b4]  ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState, bool)+0x174
V  [libjvm.dylib+0x3e93d0]  ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*)+0x70
V  [libjvm.dylib+0x8d7f74]  JfrJavaEventWriter::flush(_jobject*, int, int, JavaThread*)+0xf8
j  jdk.jfr.internal.JVM.flush(Ljdk/jfr/internal/event/EventWriter;II)V+0 jdk.jfr at 23-internal
j  jdk.jfr.internal.event.EventWriter.flush(II)V+3 jdk.jfr at 23-internal

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-1997635467

From kevinw at openjdk.org  Thu Mar 14 15:05:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 15:05:38 GMT
Subject: RFR: 8328135:
 javax/management/remote/mandatory/loading/MissingClassTest.java fails on
 libgraal
In-Reply-To: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
References: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
Message-ID: <_8EtVlFUCXxbPf7iLZLPpIbKPbnWVAPwzaSXVwp1j9w=.dff59ce4-146e-4ed0-88bb-068df59a1864@github.com>

On Thu, 14 Mar 2024 10:46:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR increases a timeout in `MissingClassTest.java` to handle slight slower compilation on a fastdebug build when using `-Xcomp`.
> Testing on mach5 shows that the increase from 60 s to 90 s resolves the timeouts.

Here we are again.

I see in a good run it would print "known=50; lost=100" if we made it.  So in the failing test runs it has only had time to lose e.g. 89 or 99 notifications.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18297#pullrequestreview-1936981847

From never at openjdk.org  Thu Mar 14 16:13:46 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 14 Mar 2024 16:13:46 GMT
Subject: RFR: 8328135:
 javax/management/remote/mandatory/loading/MissingClassTest.java fails on
 libgraal
In-Reply-To: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
References: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
Message-ID: <a9MtJXTX7mpm4Out6bdkZ9nFfwzyZQBlbNfMhKS_xvE=.cfc30599-1998-4359-bd61-6e4b2780d2dc@github.com>

On Thu, 14 Mar 2024 10:46:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR increases a timeout in `MissingClassTest.java` to handle slight slower compilation on a fastdebug build when using `-Xcomp`.
> Testing on mach5 shows that the increase from 60 s to 90 s resolves the timeouts.

Marked as reviewed by never (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18297#pullrequestreview-1937156027

From dnsimon at openjdk.org  Thu Mar 14 16:13:46 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Mar 2024 16:13:46 GMT
Subject: RFR: 8328135:
 javax/management/remote/mandatory/loading/MissingClassTest.java fails on
 libgraal
In-Reply-To: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
References: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
Message-ID: <6j0Sq5ayq2JIwnx1BfsHtkdUFgu8aihT7Ls_i9rUKEg=.fe203bd7-5017-44af-b06e-0ce72b2fb897@github.com>

On Thu, 14 Mar 2024 10:46:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR increases a timeout in `MissingClassTest.java` to handle slight slower compilation on a fastdebug build when using `-Xcomp`.
> Testing on mach5 shows that the increase from 60 s to 90 s resolves the timeouts.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/18297#issuecomment-1997817640

From dnsimon at openjdk.org  Thu Mar 14 16:13:47 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Mar 2024 16:13:47 GMT
Subject: Integrated: 8328135:
 javax/management/remote/mandatory/loading/MissingClassTest.java fails on
 libgraal
In-Reply-To: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
References: <w_BItL3VQFc3UuKwHSbH5kL57Ciy3hgs99cGBSIFuYo=.c9c2fd69-c00d-4287-ab62-1c2aa36c39f7@github.com>
Message-ID: <F9Chvx-3z_iY5znq-RSqF6lz6efSjL6GJ_FV9PxUuTs=.f981f107-1e77-4e49-b1f5-94712d0a56bf@github.com>

On Thu, 14 Mar 2024 10:46:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR increases a timeout in `MissingClassTest.java` to handle slight slower compilation on a fastdebug build when using `-Xcomp`.
> Testing on mach5 shows that the increase from 60 s to 90 s resolves the timeouts.

This pull request has now been integrated.

Changeset: e6a8fdd8
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6a8fdd82c2b97f7ae74dfe8fbd3402718c9161c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8328135: javax/management/remote/mandatory/loading/MissingClassTest.java fails on libgraal

Reviewed-by: kevinw, never

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

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

From mchung at openjdk.org  Thu Mar 14 17:03:46 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 14 Mar 2024 17:03:46 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v12]
In-Reply-To: <XjIsXv08qda6XXHXwt6erFb5le4RzEw2MAyoDxRBZPs=.f5117016-d624-4d77-b7af-b850a36940c8@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <XjIsXv08qda6XXHXwt6erFb5le4RzEw2MAyoDxRBZPs=.f5117016-d624-4d77-b7af-b850a36940c8@github.com>
Message-ID: <95VHtQC39WhLTqa1yWfTs4r3DglLJ7uKZPYpFag8dW4=.f2645183-9134-4d57-93bf-a39ab29ab748@github.com>

On Thu, 14 Mar 2024 12:23:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RMIConnectionImpl_Stub also should explicity inherit the unchecked UOE.

The spec updates are good with me.   Caught one formatting nit in the `RMIConnection` class spec.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 85:

> 83:  *
> 84:  * <p>JMX Subject Delegation has been removed. All methods that take a
> 85:  * delegationSubject parameter will throw UnsupportedOperationException if

Suggestion:

 * delegation subject parameter will throw {@code UnsupportedOperationException} if

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18025#pullrequestreview-1937202285
PR Review Comment: https://git.openjdk.org/jdk/pull/18025#discussion_r1525173122

From cjplummer at openjdk.org  Thu Mar 14 17:03:45 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 14 Mar 2024 17:03:45 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v4]
In-Reply-To: <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>
Message-ID: <wTHCH3-rlc1GSznPq1ADd9fwH_XZ453ktOJQ-u4rsps=.c4f8b9d0-bd77-44f5-934e-bad5e7a7c9cb@github.com>

On Thu, 14 Mar 2024 13:43:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test HeapDumpJcmdPresetPathTest

Changes requested by cjplummer (Reviewer).

src/hotspot/share/runtime/globals.hpp line 565:

> 563:           "triggered by jcmd GC.heap_dump without specifying a path, "      \
> 564:           "the path (filename or directory) of the dump file "              \
> 565:           "(defaults to java_pid<pid>.hprof in the working directory)")     \

This incorrectly leads one to conclude that if HeapDumpPath is not specified and GC.heap_dump is used without specifying a path, the default will be java_pid<pid>.hprof in the working directory. That's not the case. The jcmd will produce an error because it requires that either HeapDumpPath be specified or a filename be specified as a jcmd argument (I'm not sure why the jcmd does not default to java_pid<pid>.hprof) 

Also, if you are cleaning up this text, I would suggest changing "is on" to "is enabled".  Same for HeapDumpGzipLevel below.

src/hotspot/share/services/diagnosticCommand.cpp line 475:

> 473: HeapDumpDCmd::HeapDumpDCmd(outputStream* output, bool heap) :
> 474:                            DCmdWithParser(output, heap),
> 475:   _filename("filename","Name of the dump file", "STRING", false, "-XX:HeapDumpPath"),

I can't say I like using the "default" in this manner, but I understand why it was done. I wish there was a better way. I ran into a similar problem with Compiler.perfmap in #17359, but this case is a bit worse. For Compiler.perfmap the default had to be specified as `/tmp/perf-<pid>.map`, but at least it somewhat resembled the actual default.

Maybe it would help if you used something a bit more descriptive, like "The path specified by "-XX:HeapDumpPath".

You also should update jcmd.l to describe this argument much like I did for Compiler.perfmap. You especially need to call out that if -XX:HeapDumpPath is not used then the "filename" argument must be speified.

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

PR Review: https://git.openjdk.org/jdk/pull/18190#pullrequestreview-1937265589
PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1525211803
PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1525223292

From eirbjo at gmail.com  Thu Mar 14 17:06:09 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 14 Mar 2024 18:06:09 +0100
Subject: RFD: Can we remove per-thread compiler stats now?
Message-ID: <CA+pBWhtBhjXyyJ0GYc0JGdUvS9r7niNL056O2rSz=podcX4a-w@mail.gmail.com>

Hello,

Per-thread compiler performance counters were removed in JDK-8134607 [1]
(JDK 9). The corresponding sun.management API was marked @Deprecated since
it no longer returns any useful counter data.

Has time come to remove this API now?

My understanding is that since sun.management is an internal package this
should be low risk. But this being JMX-related, is there maybe some concern
to this being used in some remote/RMI scenario?

If not, I'd like to propose a PR to remove the following:

* Class sun.management.CompilerThreadStat
* Nested class sun.management.HotspotCompilation.CompilerThreadInfo
* Field sun.management.HotspotCompilation.threads and its initialization
* Method sun.management.HotspotCompilation.getCompilerThreadStats() and its
definition in HotspotCompilationMBean

Let me know what you think

Cheers,
Eirik :-)

[1] https://bugs.openjdk.org/browse/JDK-8134607
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240314/9b5182a0/attachment.htm>

From amenkov at openjdk.org  Thu Mar 14 18:05:44 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 14 Mar 2024 18:05:44 GMT
Subject: Integrated: JDK-8326898: NSK tests should listen on loopback addresses
 only
In-Reply-To: <0S05fii4BnVxmQZnEC2qOSmrTzAtyZTvYlblSDeNiKg=.99d7c8b1-8144-47dc-9e03-5e447b283a58@github.com>
References: <0S05fii4BnVxmQZnEC2qOSmrTzAtyZTvYlblSDeNiKg=.99d7c8b1-8144-47dc-9e03-5e447b283a58@github.com>
Message-ID: <SKmlJprNgmdF42JIvsadhccO4H0rxJWXqH7jxLFRu5U=.ec30d7e4-79b0-4fca-b611-d88306060cc1@github.com>

On Thu, 29 Feb 2024 01:50:02 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Many NSK tests create socket channel for test/target interprocess communication.
> The change updates server side to listen only on loopback interface.
> 
> Testing - all tests that use then functionality:
>  - test/hotspot/jtreg/vmTestbase/nsk/jdb, test/hotspot/jtreg/vmTestbase/nsk/jdi, test/hotspot/jtreg/vmTestbase/nsk/jdwp, test/hotspot/jtreg/vmTestbase/nsk/aod, test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand

This pull request has now been integrated.

Changeset: 2482a505
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2482a505e5c898cc6365aa4fb8ca3e8b758b3a97
Stats:     22 lines in 6 files changed: 2 ins; 0 del; 20 mod

8326898: NSK tests should listen on loopback addresses only

Reviewed-by: sspitsyn, cjplummer, dholmes, lmesnik

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

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

From weijun at openjdk.org  Thu Mar 14 18:10:42 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 14 Mar 2024 18:10:42 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v6]
In-Reply-To: <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <o_4HiAfg0-sWHphpeqHMDZmsEF_rvBIPwIKmK99Valg=.69ddd052-b12c-4073-aecd-48641c14f154@github.com>
 <8-yeiLAqTX09lCZI3pfoS8d2LRJ4gWniw1-YB58ba-w=.6ee6a4b0-8934-4fd1-80c7-10fcb23d540f@github.com>
Message-ID: <sgHC9jvz_mQFWtYkX2rREXbGel4XBTzme7hu_4hxOIY=.d04a7e2c-286f-4c14-b9b7-aa5072a1cf37@github.com>

On Wed, 13 Mar 2024 19:53:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes to MBeanServerFileAccessController.java
>
> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 29:
> 
>> 27:  * @enablePreview
>> 28:  * @summary Implement Subject.current and Subject.callAs using scoped values.
>> 29:  *      Need @enablePreview to use StructuredTaskScope.
> 
> jtreg throws a `ParseException` because I think it tries to interpret it as an `@enablePreview` action. Suggest enclosing it in double quotes.

Yes, I noticed that. Thanks.

> test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java line 55:
> 
>> 53:         Subject.callAs(subject, () -> check(0, Subject.current(), "Duke"));
>> 54: 
>> 55:         // Observable in the same thread in ACC mode, but not in the SV mode
> 
> Should this comment actually say "Observable in a new platform thread in ACC mode, but not in the SV mode".

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1525308150
PR Review Comment: https://git.openjdk.org/jdk/pull/17472#discussion_r1525308836

From sspitsyn at openjdk.org  Thu Mar 14 19:12:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 14 Mar 2024 19:12:57 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v10]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <q5jcR9gb1lt547WD--Pjvc1OWTvsYt79YzUn2S12qO8=.1ffa25e9-b4d8-4ea6-a0a7-290168ee9ca0@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

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 11 additional commits since the last revision:

 - Merge
 - Merge
 - review: dropped the catch of InterruptedException in Object.wait
 - optimize holding the interruptLock in JavaThread::is_interrupted
 - reordered JavaThread::is_interrupted code to use lock when needed only
 - removed trailing spaces in javaClasses.cpp and libInterruptRawMonitor.cpp
 - review: added ObjectLocker of interruptLock for sync
 - review: improved sync in new test InterruptRawMonitor
 - review: addressed a couple of comments on new test
 - fix trailing space in libInterruptRawMonitor.cpp
 - ... and 1 more: https://git.openjdk.org/jdk/compare/86a4542e...b13d9c51

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/df3b6383..b13d9c51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=08-09

  Stats: 16508 lines in 443 files changed: 9214 ins; 5600 del; 1694 mod
  Patch: https://git.openjdk.org/jdk/pull/18093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18093/head:pull/18093

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

From lmesnik at openjdk.org  Thu Mar 14 19:12:40 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Mar 2024 19:12:40 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <6qVLhkLWMMTfP-iN9W5DEt6M_D5DmlLJqLxmEhqxp9o=.f8c8db6a-10fa-48f0-98af-a59e8d9be04c@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

That's a more generic question. 
The driver and main (default mode) actions might be executed in 2 modes: agentvm or othervm. So each driver (or main)  action might reuse jvm or start a new one each time. This is controlled by -agetnvm flag in jtreg. While othervm mode in tests is used for tests that couldn't be executed in agentvm mode (use some specific VM options). We don't force /othrevm option in tests because something might be broken and affect other tests execution. (Really it means that every test that doesn't start new process should be othrevm).
Each time when we run jtreg in agentvm we allow tests to reuse the same JVM and taking risks of possible incosistency of the future tests execution. So if test manages to break some part of JVM/JDK (it might be thread state, compile, gc, debugger,classoader, java.util or javac) we have a risk that next tests have jdk in inconsistent state. 

I think that the debugger might be treated as any other component.  If we need more isolation then it is needed to use othervm mode for jtreg. 

And using of agentvm/othervm mode for VM testing might be separate topic.

I can do more testing in different modes to see if we have any new failures after update.

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-1998190351

From kevinw at openjdk.org  Thu Mar 14 21:39:54 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 21:39:54 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v13]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <tUNI_9kbpUdXRPsYeX60m6-SMf6i1I5saxgMjEW3Ti4=.6a6b6cf6-8a14-4e0e-bfec-4e37bfb3bdff@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  Missing code doc nit.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/91ec015f..64c9c64a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=11-12

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

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

From kevinw at openjdk.org  Thu Mar 14 21:44:52 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 14 Mar 2024 21:44:52 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v14]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <Yj8OKQh6B2Eb8W1MI_-WwLjV16qzVog87CR5DLOiNzk=.73e3b8e1-3560-4e6b-800a-13d52da4b086@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

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

  Missing code doc nit.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18025/files
  - new: https://git.openjdk.org/jdk/pull/18025/files/64c9c64a..43b10a12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=12-13

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

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

From amenkov at openjdk.org  Thu Mar 14 22:12:38 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 14 Mar 2024 22:12:38 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <EIFWxoiPJCZoEzuJmoiQJEmZJmNytP8yITdfrOo-Xr4=.d51bac99-af7c-47b5-9b3a-7e5b9c24177a@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
 <hcLiga2frALeRWVVRUAnkNvjLUkzbwm9EnLEDnMRQqk=.b8dbb825-e0e7-47da-be36-4f826b5f9df2@github.com>
 <ngULigXLGEgf5oJiBWJvylbQi1vihyc7sbp-JxBFtso=.63408a65-abf9-466e-a09c-312bb89a3c7d@github.com>
 <lKsxhQehvFpzK8FoRs4JQaLSsQeyQoKe9EQ1qs4eTBc=.0687675b-39ce-4f6a-ab18-e950c624e6f6@github.com>
 <EIFWxoiPJCZoEzuJmoiQJEmZJmNytP8yITdfrOo-Xr4=.d51bac99-af7c-47b5-9b3a-7e5b9c24177a@github.com>
Message-ID: <ldeboUvSNlpUcqrqUsOAOM_o6aBWLPZ7NilyspTAPIU=.e1acd7cf-fb83-4a78-8f1b-fc7b69f66463@github.com>

On Thu, 14 Mar 2024 02:12:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> True. It should know how to put the `attribute_count` value into the class file but it does not need to know how to calculate its value. What I do not like in your model is that there is no one single place which knows how to calculate this value and the existing and potential consumers should have this knowledge.

It **must** know how to calculate the value. Because this is number of `attribute_info_attributes` attributes that follow. And only `JvmtiClassFileReconstituter` knows how many attributes it's going to write.

> The bug is that the `attributute_count` field value from the class file stored in the `RecordComponent` does not match the calculated value because the invisible attribute was not saved (was ignored).

I'd consider this as design issue with the current implementation - `JvmtiClassFileReconstituter` gets the value from external source (`RecordComponent`) and uses it without validation.
This approach is inconsistent with other `JvmtiClassFileReconstituter` code.
For other similar cases it calculates record counts in place (from size of arrays, string length, from list enumerator, etc.).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1525542056

From clanger at openjdk.org  Fri Mar 15 07:02:39 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 15 Mar 2024 07:02:39 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v4]
In-Reply-To: <wTHCH3-rlc1GSznPq1ADd9fwH_XZ453ktOJQ-u4rsps=.c4f8b9d0-bd77-44f5-934e-bad5e7a7c9cb@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>
 <wTHCH3-rlc1GSznPq1ADd9fwH_XZ453ktOJQ-u4rsps=.c4f8b9d0-bd77-44f5-934e-bad5e7a7c9cb@github.com>
Message-ID: <qHMNpYzCWXGQPrxNfZV-gWRkLFg2FRDNkUA-YLq7XMg=.8a5111a6-b632-4217-80bf-a4dc58b0dadc@github.com>

On Thu, 14 Mar 2024 16:54:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test HeapDumpJcmdPresetPathTest
>
> src/hotspot/share/runtime/globals.hpp line 565:
> 
>> 563:           "triggered by jcmd GC.heap_dump without specifying a path, "      \
>> 564:           "the path (filename or directory) of the dump file "              \
>> 565:           "(defaults to java_pid<pid>.hprof in the working directory)")     \
> 
> This incorrectly leads one to conclude that if HeapDumpPath is not specified and GC.heap_dump is used without specifying a path, the default will be java_pid<pid>.hprof in the working directory. That's not the case. The jcmd will produce an error because it requires that either HeapDumpPath be specified or a filename be specified as a jcmd argument (I'm not sure why the jcmd does not default to java_pid<pid>.hprof) 
> 
> Also, if you are cleaning up this text, I would suggest changing "is on" to "is enabled".  Same for HeapDumpGzipLevel below.

Yes, why not make java_pid<pid>.hprof in the working directory the default if calling jcmd GC.heap_dump without specifying a path? Would there be any problem with that approach?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1525832839

From clanger at openjdk.org  Fri Mar 15 07:06:40 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 15 Mar 2024 07:06:40 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v4]
In-Reply-To: <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>
Message-ID: <u0FLWHJaaE-KxibARHbusuzNFXJu4-WWKrhyXkkpsgw=.dca1bbf3-b795-41b1-a42d-0b4dec6c50f4@github.com>

On Thu, 14 Mar 2024 13:43:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test HeapDumpJcmdPresetPathTest

test/hotspot/jtreg/serviceability/HeapDump/HeapDumpJcmdPresetPathTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

Should be SAP copyright.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1525835794

From yyang at openjdk.org  Fri Mar 15 08:03:38 2024
From: yyang at openjdk.org (Yi Yang)
Date: Fri, 15 Mar 2024 08:03:38 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v2]
In-Reply-To: <fZdUtavMAP0NVVHj9mRC8HPENUbSiPOqUfqfVavA0y0=.4c5bae90-0d17-4394-ab35-09e7fc2a3248@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <tm8wZB-vPfuSoyzWnxW6RI9A7FGkT6ucKB_iicwR4Ss=.d1ede645-f03a-4a34-b9f1-0b86fe7fec06@github.com>
 <Py79NINZERjZj2GR_9Fp6pqpHh9zCqQsLXeuScl7Uwk=.76e7641e-10b3-4290-b167-6415a4c19fd7@github.com>
 <fZdUtavMAP0NVVHj9mRC8HPENUbSiPOqUfqfVavA0y0=.4c5bae90-0d17-4394-ab35-09e7fc2a3248@github.com>
Message-ID: <2xHp6gPbB-Ss8xCqxoeAlRQN2tge86hAWADGwztSiD8=.67692b2d-fbdd-4716-8f92-0168306935f9@github.com>

On Thu, 14 Mar 2024 08:49:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Looks reasonable, this is a harmless change, but the name `dump_to_heapdump_path` looks too details(and somewhat strange) to me
> 
> Do you maybe have a good suggestion for a new name ?

Maybe `dump` and `dump_to`

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1999120772

From mbaesken at openjdk.org  Fri Mar 15 08:22:07 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Mar 2024 08:22:07 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v5]
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <eWRZv3cm78_M31nG9v1r0TpikUCmCMcm84t2XAEkqC4=.f42b25b4-7fa0-4a05-b98a-5c6c7ff3de7c@github.com>

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

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

  fix COPYRIGHT info in HeapDumpJcmdPresetPathTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18190/files
  - new: https://git.openjdk.org/jdk/pull/18190/files/61165f55..daab7df9

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

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

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

From mbaesken at openjdk.org  Fri Mar 15 08:35:56 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Mar 2024 08:35:56 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v6]
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <ZVOiX7Aa1dMIVhDPOzic--9dZ-XXAn8L8Om9RigBcbs=.ce9f6724-529e-4749-9b90-b7ad60898929@github.com>

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

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

  rename dump_to_heapdump_path

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18190/files
  - new: https://git.openjdk.org/jdk/pull/18190/files/daab7df9..b97921d5

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

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

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

From mbaesken at openjdk.org  Fri Mar 15 08:35:56 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Mar 2024 08:35:56 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v2]
In-Reply-To: <2xHp6gPbB-Ss8xCqxoeAlRQN2tge86hAWADGwztSiD8=.67692b2d-fbdd-4716-8f92-0168306935f9@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <tm8wZB-vPfuSoyzWnxW6RI9A7FGkT6ucKB_iicwR4Ss=.d1ede645-f03a-4a34-b9f1-0b86fe7fec06@github.com>
 <Py79NINZERjZj2GR_9Fp6pqpHh9zCqQsLXeuScl7Uwk=.76e7641e-10b3-4290-b167-6415a4c19fd7@github.com>
 <fZdUtavMAP0NVVHj9mRC8HPENUbSiPOqUfqfVavA0y0=.4c5bae90-0d17-4394-ab35-09e7fc2a3248@github.com>
 <2xHp6gPbB-Ss8xCqxoeAlRQN2tge86hAWADGwztSiD8=.67692b2d-fbdd-4716-8f92-0168306935f9@github.com>
Message-ID: <xn9in_L7demwBY6QtmdSdLoLOTK_lqJ-r_X-_lJfq4M=.817788b5-33a4-4920-aefe-72c27ba336e9@github.com>

On Fri, 15 Mar 2024 08:00:50 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Maybe `dump` and `dump_to`

Why not, I renamed the method to dump_to .

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1999165924

From rrich at openjdk.org  Fri Mar 15 08:37:38 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 15 Mar 2024 08:37:38 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <H5MBza8VmQIavhew-OEqINtUeIaphLI2NxSPBLpNS4s=.6689ec48-39ef-4882-a936-3799495b73b4@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <H5MBza8VmQIavhew-OEqINtUeIaphLI2NxSPBLpNS4s=.6689ec48-39ef-4882-a936-3799495b73b4@github.com>
Message-ID: <Sk0KcR-vanWHXasQigOm_kA_xWeL7Beox-68LGeFIvw=.e4edf344-2ca3-4ea5-944e-3c1895b7e055@github.com>

On Thu, 14 Mar 2024 14:49:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> I noticed a few more asserts  (assert(_wx_state == expected) failed: wrong state)   in the jfr area  (jdk tier3 jfr tests).
> E.g. 
> 
> 
> V  [libjvm.dylib+0x8a5d94]  JavaThread::check_for_valid_safepoint_state()+0x0
> V  [libjvm.dylib+0x3e95b4]  ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState, bool)+0x174
> V  [libjvm.dylib+0x3e93d0]  ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*)+0x70
> V  [libjvm.dylib+0x91a578]  JfrRecorderService::emit_leakprofiler_events(long long, bool, bool)+0xcc
> 
> 
> 
> and 
> 
> 
> V  [libjvm.dylib+0x8a5d94]  JavaThread::check_for_valid_safepoint_state()+0x0
> V  [libjvm.dylib+0x3e95b4]  ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState, bool)+0x174
> V  [libjvm.dylib+0x3e93d0]  ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*)+0x70
> V  [libjvm.dylib+0x8d7f74]  JfrJavaEventWriter::flush(_jobject*, int, int, JavaThread*)+0xf8
> j  jdk.jfr.internal.JVM.flush(Ljdk/jfr/internal/event/EventWriter;II)V+0 jdk.jfr at 23-internal
> j  jdk.jfr.internal.event.EventWriter.flush(II)V+3 jdk.jfr at 23-internal

> > @MBaesken found 2 more locations in jvmti that need switching to `WXWrite`
> > ```
> > JvmtiExport::get_jvmti_interface
> > GetCarrierThread
> > ```
> > Both use `ThreadInVMfromNative`.
> 
> Should we address those 2 more findings in this PR ? Or open a separate JBS issue ?
> 

I'm leaning towards fixing all locations in this PR even though this will prevent clean backports. Would that be ok?

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-1999168860

From mbaesken at openjdk.org  Fri Mar 15 08:43:38 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Mar 2024 08:43:38 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <H5MBza8VmQIavhew-OEqINtUeIaphLI2NxSPBLpNS4s=.6689ec48-39ef-4882-a936-3799495b73b4@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <H5MBza8VmQIavhew-OEqINtUeIaphLI2NxSPBLpNS4s=.6689ec48-39ef-4882-a936-3799495b73b4@github.com>
Message-ID: <CsD6rBvPwlREOOu7YeCWF6RZVrmBs9mepB1DF4L2jxo=.6173a1b4-cfad-4002-b0af-bd7f3542f782@github.com>

On Thu, 14 Mar 2024 14:49:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> I noticed a few more asserts  (assert(_wx_state == expected) failed: wrong state)   in the jfr area  (jdk tier3 jfr tests).
> E.g. 
> 
> 
> V  [libjvm.dylib+0x8a5d94]  JavaThread::check_for_valid_safepoint_state()+0x0
> V  [libjvm.dylib+0x3e95b4]  ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState, bool)+0x174
> V  [libjvm.dylib+0x3e93d0]  ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*)+0x70
> V  [libjvm.dylib+0x91a578]  JfrRecorderService::emit_leakprofiler_events(long long, bool, bool)+0xcc
> 
> 
> 
> and 
> 
> 
> V  [libjvm.dylib+0x8a5d94]  JavaThread::check_for_valid_safepoint_state()+0x0
> V  [libjvm.dylib+0x3e95b4]  ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState, bool)+0x174
> V  [libjvm.dylib+0x3e93d0]  ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*)+0x70
> V  [libjvm.dylib+0x8d7f74]  JfrJavaEventWriter::flush(_jobject*, int, int, JavaThread*)+0xf8
> j  jdk.jfr.internal.JVM.flush(Ljdk/jfr/internal/event/EventWriter;II)V+0 jdk.jfr at 23-internal
> j  jdk.jfr.internal.event.EventWriter.flush(II)V+3 jdk.jfr at 23-internal

> > > @MBaesken found 2 more locations in jvmti that need switching to `WXWrite`
> > > ```
> > > JvmtiExport::get_jvmti_interface
> > > GetCarrierThread
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > Both use `ThreadInVMfromNative`.
> > 
> > 
> > Should we address those 2 more findings in this PR ? Or open a separate JBS issue ?
> 
> I'm leaning towards fixing all locations in this PR even though this will prevent clean backports. Would that be ok?

I think this is ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-1999177986

From mbaesken at openjdk.org  Fri Mar 15 08:49:38 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Mar 2024 08:49:38 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
Message-ID: <8z-3qU5ADeGlrJd_DQ3H3kWItWG1DP8a-Xw-lbJOYaw=.b158ceec-94ea-4000-afe1-0083357deda3@github.com>

On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
> 
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> 
> More tests are pending.

`JfrRecorderService::emit_leakprofiler_events`  (src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp ) and `JfrJavaEventWriter::flush` (src/hotspot/share/jfr/writers/jfrJavaEventWriter.cpp) might need adjustment too (see the other findings I posted yesterday).

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-1999185059

From sspitsyn at openjdk.org  Fri Mar 15 09:02:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 15 Mar 2024 09:02:13 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v11]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <W8wSfid32mEykSi2w2Kg3JdcJrdLT5oR6lBQgqyPT0c=.d0e74f92-31d0-4872-ace7-6fd50814c3ea@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: restore the InterruptedException catch in Object.wait

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/b13d9c51..19a34934

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=09-10

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

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

From mbaesken at openjdk.org  Fri Mar 15 09:04:01 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Mar 2024 09:04:01 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v7]
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <Y4O-7Xzf2oNvwVqZ8EUlJzEzMyxAvERDM--6Sb3nahE=.a3534846-6047-46a7-84af-3b1c51e069d1@github.com>

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

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

  change is on to is enabled

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18190/files
  - new: https://git.openjdk.org/jdk/pull/18190/files/b97921d5..a71f04b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18190&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18190&range=05-06

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

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

From mbaesken at openjdk.org  Fri Mar 15 09:04:01 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Mar 2024 09:04:01 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v6]
In-Reply-To: <ZVOiX7Aa1dMIVhDPOzic--9dZ-XXAn8L8Om9RigBcbs=.ce9f6724-529e-4749-9b90-b7ad60898929@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <ZVOiX7Aa1dMIVhDPOzic--9dZ-XXAn8L8Om9RigBcbs=.ce9f6724-529e-4749-9b90-b7ad60898929@github.com>
Message-ID: <-FMEBl06UV1uRRc-7-MuuYA31aMz5zBvzt3XjHBOn1U=.b495cd3d-0eaa-4e16-a5b6-329b832d8a52@github.com>

On Fri, 15 Mar 2024 08:35:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename dump_to_heapdump_path

Hi Chris, thanks for the comments-

> Also, if you are cleaning up this text, I would suggest changing "is on" to "is enabled". Same for HeapDumpGzipLevel below.

I changed the two locations.
btw. seems we have more of those in globals.hpp .
See the comments related to PrintNMTStatistics and LogFile  (where the "is on" is used as well).

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1999211132

From sspitsyn at openjdk.org  Fri Mar 15 09:04:42 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 15 Mar 2024 09:04:42 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v11]
In-Reply-To: <W8wSfid32mEykSi2w2Kg3JdcJrdLT5oR6lBQgqyPT0c=.d0e74f92-31d0-4872-ace7-6fd50814c3ea@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <W8wSfid32mEykSi2w2Kg3JdcJrdLT5oR6lBQgqyPT0c=.d0e74f92-31d0-4872-ace7-6fd50814c3ea@github.com>
Message-ID: <7HocwHd3V3KJZlMjlZ-6pNCy-SdEKtEjJmzhwrfrdDs=.2e882f51-4b00-43fb-baeb-20d5e106a505@github.com>

On Fri, 15 Mar 2024 09:02:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: restore the InterruptedException catch in Object.wait

I've restored the `InterruptedException` catch in the `Object.wait`.
I believe, all the concerns have been resolved now.

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-1999212671

From sspitsyn at openjdk.org  Fri Mar 15 09:09:39 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 15 Mar 2024 09:09:39 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <SVchHmqu4zpZr56j26tpZAP2j4_97Jy3PksTix7p3bE=.11550706-58dc-480a-95f1-76a68f4a48d9@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
 <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>
 <_pbD7dEcZ0wjCfut2WEz5az3y11jhazNQp_8Ekje-Wg=.67400067-5142-49f0-bcfa-f40f77f6fe1c@github.com>
 <Kcx6SoNcp1C3-GTk8hHhLVWshuHKM9TRE5DN62_Zgeo=.4167311f-0f85-4424-9b77-d152ed43726f@github.com>
 <nc1GdDFdlBgC9TRyb4RrwRCrL306Kk_F5oj7y8nR18U=.3c183cb5-357c-4d79-b417-da414f74cfc9@github.com>
 <q0cikB2x4zIywyrGtJHWpiN3d_vLrmNUHmpGHwnw7-o=.415bfd3f-575d-40b5-9230-3300f7c7334a@github.com>
 <SVchHmqu4zpZr56j26tpZAP2j4_97Jy3PksTix7p3bE=.11550706-58dc-480a-95f1-76a68f4a48d9@github.com>
Message-ID: <_SkGGAyOqYb37n8VJpVdYRpvlnCXYObFR3eHePXi9Bw=.624a1045-b947-4eed-9795-4f224b51ebe5@github.com>

On Fri, 8 Mar 2024 06:21:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It may be that once Object.wait is implemented that we can remove the need to propagate the interrupt status (there are some TBDs here) so things will be a lot simpler.
>> 
>> I think the change here is okay for now but we still have the choice of limiting the change to just JVMTI RawMonitorWait.
>
> Personally I'd prefer to see changes limited to just JVMTI `RawMonitorWait`. That minimises the risk of any unintended consequences from making the change.

I've restored the `InterruptedException` catch in the `Object.wait`.
However, the fix in `JavaThread::is_interrupted()` also impacts the variations of `sleep_nanos()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1525958712

From asteiner at openjdk.org  Fri Mar 15 09:23:40 2024
From: asteiner at openjdk.org (Andreas Steiner)
Date: Fri, 15 Mar 2024 09:23:40 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v4]
In-Reply-To: <qHMNpYzCWXGQPrxNfZV-gWRkLFg2FRDNkUA-YLq7XMg=.8a5111a6-b632-4217-80bf-a4dc58b0dadc@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <QJTcRaAzkYHkGKO3_ZKGP_AtWrTq6eeo2d5W5ngnAwc=.c9b8aff9-3910-4d9b-94bc-b72e007699b6@github.com>
 <wTHCH3-rlc1GSznPq1ADd9fwH_XZ453ktOJQ-u4rsps=.c4f8b9d0-bd77-44f5-934e-bad5e7a7c9cb@github.com>
 <qHMNpYzCWXGQPrxNfZV-gWRkLFg2FRDNkUA-YLq7XMg=.8a5111a6-b632-4217-80bf-a4dc58b0dadc@github.com>
Message-ID: <OCxQVWwMx60xfFm96xOIjKGk1fN1IeenK6MmGmBnL-0=.c493a81a-feaf-4b75-88a7-92e28337b9bd@github.com>

On Fri, 15 Mar 2024 06:59:42 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 565:
>> 
>>> 563:           "triggered by jcmd GC.heap_dump without specifying a path, "      \
>>> 564:           "the path (filename or directory) of the dump file "              \
>>> 565:           "(defaults to java_pid<pid>.hprof in the working directory)")     \
>> 
>> This incorrectly leads one to conclude that if HeapDumpPath is not specified and GC.heap_dump is used without specifying a path, the default will be java_pid<pid>.hprof in the working directory. That's not the case. The jcmd will produce an error because it requires that either HeapDumpPath be specified or a filename be specified as a jcmd argument (I'm not sure why the jcmd does not default to java_pid<pid>.hprof) 
>> 
>> Also, if you are cleaning up this text, I would suggest changing "is on" to "is enabled".  Same for HeapDumpGzipLevel below.
>
> Yes, why not make java_pid<pid>.hprof in the working directory the default if calling jcmd GC.heap_dump without specifying a path? Would there be any problem with that approach?

Could fill up the working directory if the user is not aware of this default. If you will specify the HeapDumpPath or the filename explicitly you should be aware that you will need enough disk space there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1525976831

From dfuchs at openjdk.org  Fri Mar 15 09:46:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 15 Mar 2024 09:46:40 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v14]
In-Reply-To: <Yj8OKQh6B2Eb8W1MI_-WwLjV16qzVog87CR5DLOiNzk=.73e3b8e1-3560-4e6b-800a-13d52da4b086@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
 <Yj8OKQh6B2Eb8W1MI_-WwLjV16qzVog87CR5DLOiNzk=.73e3b8e1-3560-4e6b-800a-13d52da4b086@github.com>
Message-ID: <F7v4nCZI1wfg4kf99QgUUnHBqnkbgyCcWUqnIZpT4eo=.99a84303-e4e4-44d8-8e0b-115cb22ee7e1@github.com>

On Thu, 14 Mar 2024 21:44:52 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The deprecated Subject Delegation feature in JMX will be removed.
>> 
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing code doc nit.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18025#pullrequestreview-1938513465

From dholmes at openjdk.org  Fri Mar 15 10:07:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 15 Mar 2024 10:07:39 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <_SkGGAyOqYb37n8VJpVdYRpvlnCXYObFR3eHePXi9Bw=.624a1045-b947-4eed-9795-4f224b51ebe5@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
 <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>
 <_pbD7dEcZ0wjCfut2WEz5az3y11jhazNQp_8Ekje-Wg=.67400067-5142-49f0-bcfa-f40f77f6fe1c@github.com>
 <Kcx6SoNcp1C3-GTk8hHhLVWshuHKM9TRE5DN62_Zgeo=.4167311f-0f85-4424-9b77-d152ed43726f@github.com>
 <nc1GdDFdlBgC9TRyb4RrwRCrL306Kk_F5oj7y8nR18U=.3c183cb5-357c-4d79-b417-da414f74cfc9@github.com>
 <q0cikB2x4zIywyrGtJHWpiN3d_vLrmNUHmpGHwnw7-o=.415bfd3f-575d-40b5-9230-3300f7c7334a@github.com>
 <SVchHmqu4zpZr56j26tpZAP2j4_97Jy3PksTix7p3bE=.11550706-58dc-480a-95f1-76a68f4a48d9@github.com>
 <_SkGGAyOqYb37n8VJpVdYRpvlnCXYObFR3eHePXi9Bw=.624a1045-b947-4eed-9795-4f224b51ebe5@github.com>
Message-ID: <AzRCuRoSmvhkPSlVA1evznEsFCDIedwIz35DhwqP-2g=.ec50b36a-1b45-43a0-8528-9ff1df168a13@github.com>

On Fri, 15 Mar 2024 09:06:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Personally I'd prefer to see changes limited to just JVMTI `RawMonitorWait`. That minimises the risk of any unintended consequences from making the change.
>
> I've restored the `InterruptedException` catch in the `Object.wait`.
> However, the fix in `JavaThread::is_interrupted()` also impacts the variations of `sleep_nanos()`.

So the current changes do not limit this to just `RawMonitorWait`. I was expecting to only see additional code in `RawMonitorWait` that emulates what the Java code does to get the virtual and carrier thread interrupt states in sync, using the interruptLock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1526041006

From mbaesken at openjdk.org  Fri Mar 15 11:24:53 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Mar 2024 11:24:53 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

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

  Adjust jcmd manpage, help and globals comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18190/files
  - new: https://git.openjdk.org/jdk/pull/18190/files/a71f04b0..8b48c911

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18190&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18190&range=06-07

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

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

From tholenstein at openjdk.org  Fri Mar 15 14:15:27 2024
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Fri, 15 Mar 2024 14:15:27 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
In-Reply-To: <zkJhZFbiWpLz1I95pZE4WSW1VyvyFsSeauSE7OnWBrU=.2f54fde5-2f37-4ceb-9585-51edc05a9c75@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <vxGx3wIPvBM7bs0tiKhCssTHZ-nNTrrnS4fCEE5clc0=.d59c75c1-756e-4c4c-97d7-defc03a2e84b@github.com>
 <zkJhZFbiWpLz1I95pZE4WSW1VyvyFsSeauSE7OnWBrU=.2f54fde5-2f37-4ceb-9585-51edc05a9c75@github.com>
Message-ID: <K_NQuogFom7vsp2Bp93KQnAB2LjGfEiaC-ObtqgcMy0=.586d4da6-7d43-486d-9137-3f77e443fd98@github.com>

On Wed, 13 Mar 2024 10:00:02 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> As I wrote in JBS, shouldn't this be handled by `ThreadInVMfromNative`?

I agree. This is something I am investigating at the moment. Ideally, AssertWXAtThreadSync would also be true by default.

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-1999726588

From kevin.walls at oracle.com  Fri Mar 15 18:54:25 2024
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 15 Mar 2024 18:54:25 +0000
Subject: RFD: Can we remove per-thread compiler stats now?
In-Reply-To: <CA+pBWhtBhjXyyJ0GYc0JGdUvS9r7niNL056O2rSz=podcX4a-w@mail.gmail.com>
References: <CA+pBWhtBhjXyyJ0GYc0JGdUvS9r7niNL056O2rSz=podcX4a-w@mail.gmail.com>
Message-ID: <SN7PR10MB7032134B3133947F2754EEA397282@SN7PR10MB7032.namprd10.prod.outlook.com>

Hi,

Sounds like a good plan.

I don't think it causes any problems, we aren't creating them now.  These counters are in jdk8u.  The jcmd "jcmd PID PerfCounter.print" shows them when attaching to a JDK8 process.  But if nothing relies on them being there?

https://openjdk.org/jeps/277
"An API element should not be removed from the Java SE specification unless it has been delivered with an annotation of @Deprecated(forRemoval=true) in a previous version of Java SE."

So deprecations need to be "upgraded" to forRemoval, this will take a few updates to get them removed.

HotspotCompilationMBean:

@Deprecated
public java.util.List<CompilerThreadStat> getCompilerThreadStats();

.. need to consider whether a method is removed or  just "degraded" (not return any information, or throw).

That said, I see sun.management.CompilationImpl[java.lang:type=Compilation] ..rather than HotspotCompilation.

ManagementFactoryHelper.java: getCompilationMXBean() specifically creates a CompilationImpl, users don?t normally see the HotspotCompilation mbean.

Elsewhere in that file, registerInternalMBeans() does:
517         // CompilationMBean may not exist
518         if (getCompilationMXBean() != null) { <-- returns new CompilationImpl(jvm);
519             addMBean(mbs, getHotspotCompilationMBean(), <-- returns new HotspotCompilation(jvm)
520                 HOTSPOT_COMPILATION_MBEAN_NAME); <-- which is "sun.management:type=HotspotCompilation"
521         }

HotspotInternal (HotspotInternalMBean) calls ManagementFactoryHelper.registerInternalMBeans(server).
HotspotInternal is a non-public API, and might be the way of acquiring a HotspotCompilation.

The role of HotspotCompilationMBean needs more investigation, but basically yes to the idea. 8-)

Thanks
Kevin


From: serviceability-dev <serviceability-dev-retn at openjdk.org> On Behalf Of Eirik Bj?rsn?s
Sent: 14 March 2024 17:06
To: serviceability-dev at openjdk.org
Subject: RFD: Can we remove per-thread compiler stats now?


Hello,

Per-thread compiler performance counters were removed in JDK-8134607 [1] (JDK 9). The corresponding sun.management API was marked @Deprecated since it no longer returns any useful counter data.

Has time come to remove this API now?

My understanding is that since sun.management is an internal package this should be low risk. But this being JMX-related, is there maybe some concern to this being used in some remote/RMI scenario?

If not, I'd like to propose a PR to remove the following:

* Class sun.management.CompilerThreadStat
* Nested class sun.management.HotspotCompilation.CompilerThreadInfo
* Field sun.management.HotspotCompilation.threads and its initialization
* Method sun.management.HotspotCompilation.getCompilerThreadStats() and its definition in HotspotCompilationMBean

Let me know what you think

Cheers,
Eirik :-)

[1] https://bugs.openjdk.org/browse/JDK-8134607
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240315/85d30546/attachment-0001.htm>

From cjplummer at openjdk.org  Sat Mar 16 22:18:46 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 16 Mar 2024 22:18:46 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v6]
In-Reply-To: <-FMEBl06UV1uRRc-7-MuuYA31aMz5zBvzt3XjHBOn1U=.b495cd3d-0eaa-4e16-a5b6-329b832d8a52@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <ZVOiX7Aa1dMIVhDPOzic--9dZ-XXAn8L8Om9RigBcbs=.ce9f6724-529e-4749-9b90-b7ad60898929@github.com>
 <-FMEBl06UV1uRRc-7-MuuYA31aMz5zBvzt3XjHBOn1U=.b495cd3d-0eaa-4e16-a5b6-329b832d8a52@github.com>
Message-ID: <Yd1X9fhTKrnnutyIQGJ4V5F14pKbEDii-zoBIefnQdU=.6bb99455-6c6b-4492-9359-218694cb3819@github.com>

On Fri, 15 Mar 2024 09:01:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Chris, thanks for the comments-
> 
> > Also, if you are cleaning up this text, I would suggest changing "is on" to "is enabled". Same for HeapDumpGzipLevel below.
> 
> I changed the two locations. btw. seems we have more of those in globals.hpp . See the comments related to PrintNMTStatistics and LogFile (where the "is on" is used as well).

I didn't realize there were other occurrences. Up to you if you want to change some, all, or none.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2000291906

From cjplummer at openjdk.org  Sat Mar 16 22:18:58 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 16 Mar 2024 22:18:58 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
Message-ID: <cclVVJAdx2okigLogb54UwQFqftlB6mDoUKF2ywsayI=.8d852c1d-7f05-4282-a3da-b1fa61d79bd3@github.com>

On Fri, 15 Mar 2024 11:24:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust jcmd manpage, help and globals comment

src/hotspot/share/services/diagnosticCommand.cpp line 475:

> 473: HeapDumpDCmd::HeapDumpDCmd(outputStream* output, bool heap) :
> 474:                            DCmdWithParser(output, heap),
> 475:   _filename("filename","Name of the dump file", "STRING", false, "if no filename was specified, but -XX:HeapDumpPath=hdp is set, path hdp is taken"),

This seems clumsy, but I'm having a hard time coming up with something better.

"the filename specified by -XX:HeapDumpPath, if specified"
"If -XX:HeapDumpPath is specified, then it is used as the default"

Makes me wonder if this approach is wrong since it is hard to document clearly. Maybe we should go back to not having the jcmd use HeapDumpPath. I understand the argument for having the jcmd use the HeapDumpPath setting, but it might not be worth the documentation confusion it introduces. You can argue that HeapDumpPath really is just intended to help support HeapDumpOnOutOfMemoryError. Does the jcmd also use HeapDumpGzipLevel? I'm not sure, but we should be consistent with the application of HeapDumpPath and HeapDumpGzipLevel to the jcmd.

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

> 338: \f[I]filename\f[R]: The name of the dump file; in case no file is specified
> 339: but -XX:HeapDumpPath=path is set, the path provided by HeapDumpPath is used
> 340: (STRING, no default value)

Here we say "no default value" but the actual text of the help output says something different. But then what do we put in place of "no default value" here? Descriptive text (like in the help output) is not needed since we have the description here. I don't really have an answer for how to handle this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1526734113
PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1526736892

From mbaesken at openjdk.org  Sat Mar 16 22:19:01 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sat, 16 Mar 2024 22:19:01 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <cclVVJAdx2okigLogb54UwQFqftlB6mDoUKF2ywsayI=.8d852c1d-7f05-4282-a3da-b1fa61d79bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
 <cclVVJAdx2okigLogb54UwQFqftlB6mDoUKF2ywsayI=.8d852c1d-7f05-4282-a3da-b1fa61d79bd3@github.com>
Message-ID: <bM4Dhx26HysYBSIRfuOCIyfw5xF8U1QMrWVTcth0hag=.46c6c5ee-01ce-4026-8e17-25601ffc71b9@github.com>

On Fri, 15 Mar 2024 19:22:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust jcmd manpage, help and globals comment
>
> src/hotspot/share/services/diagnosticCommand.cpp line 475:
> 
>> 473: HeapDumpDCmd::HeapDumpDCmd(outputStream* output, bool heap) :
>> 474:                            DCmdWithParser(output, heap),
>> 475:   _filename("filename","Name of the dump file", "STRING", false, "if no filename was specified, but -XX:HeapDumpPath=hdp is set, path hdp is taken"),
> 
> This seems clumsy, but I'm having a hard time coming up with something better.
> 
> "the filename specified by -XX:HeapDumpPath, if specified"
> "If -XX:HeapDumpPath is specified, then it is used as the default"
> 
> Makes me wonder if this approach is wrong since it is hard to document clearly. Maybe we should go back to not having the jcmd use HeapDumpPath. I understand the argument for having the jcmd use the HeapDumpPath setting, but it might not be worth the documentation confusion it introduces. You can argue that HeapDumpPath really is just intended to help support HeapDumpOnOutOfMemoryError. Does the jcmd also use HeapDumpGzipLevel? I'm not sure, but we should be consistent with the application of HeapDumpPath and HeapDumpGzipLevel to the jcmd.

So far we only use the gzip level setting from jcmd, not HeapDumpGzipLevel .
See the `level` variable in  `HeapDumpDCmd::execute` . Yeah you are probably right we should make it consistent.

> src/jdk.jcmd/share/man/jcmd.1 line 340:
> 
>> 338: \f[I]filename\f[R]: The name of the dump file; in case no file is specified
>> 339: but -XX:HeapDumpPath=path is set, the path provided by HeapDumpPath is used
>> 340: (STRING, no default value)
> 
> Here we say "no default value" but the actual text of the help output says something different. But then what do we put in place of "no default value" here? Descriptive text (like in the help output) is not needed since we have the description here. I don't really have an answer for how to handle this.

Hi , 'no default' should be still correct. Both the old syntax and also the additional optional new one (evaluating -XX:HeapDumpPath) do not set some default string. The user has to specify something.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1527168801
PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1527167229

From sspitsyn at openjdk.org  Sat Mar 16 22:33:49 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 16 Mar 2024 22:33:49 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v12]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <laADXsrathl5JJKzu7LAa56G-KTdMaVOXwShzZGcbCw=.e10ab081-2d71-4489-8441-5c2633e9145c@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: made current changes limitedto just RawMonitorWait

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/19a34934..5e0db950

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=10-11

  Stats: 35 lines in 3 files changed: 20 ins; 9 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18093/head:pull/18093

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

From sspitsyn at openjdk.org  Sat Mar 16 22:33:59 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 16 Mar 2024 22:33:59 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <AzRCuRoSmvhkPSlVA1evznEsFCDIedwIz35DhwqP-2g=.ec50b36a-1b45-43a0-8528-9ff1df168a13@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
 <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>
 <_pbD7dEcZ0wjCfut2WEz5az3y11jhazNQp_8Ekje-Wg=.67400067-5142-49f0-bcfa-f40f77f6fe1c@github.com>
 <Kcx6SoNcp1C3-GTk8hHhLVWshuHKM9TRE5DN62_Zgeo=.4167311f-0f85-4424-9b77-d152ed43726f@github.com>
 <nc1GdDFdlBgC9TRyb4RrwRCrL306Kk_F5oj7y8nR18U=.3c183cb5-357c-4d79-b417-da414f74cfc9@github.com>
 <q0cikB2x4zIywyrGtJHWpiN3d_vLrmNUHmpGHwnw7-o=.415bfd3f-575d-40b5-9230-3300f7c7334a@github.com>
 <SVchHmqu4zpZr56j26tpZAP2j4_97Jy3PksTix7p3bE=.11550706-58dc-480a-95f1-76a68f4a48d9@github.com>
 <_SkGGAyOqYb37n8VJpVdYRpvlnCXYObFR3eHePXi9Bw=.624a1045-b947-4eed-9795-4f224b51ebe5@github.com>
 <AzRCuRoSmvhkPSlVA1evznEsFCDIedwIz35DhwqP-2g=.ec50b36a-1b45-43a0-8528-9ff1df168a13@github.com>
Message-ID: <w3e6DlxrB8WbL1ls6It_RxSdWy4qo9r2Z5C_Y01BHZc=.c5cc43c4-4e1c-4c13-bdc7-f9e1adab60fa@github.com>

On Fri, 15 Mar 2024 10:05:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I've restored the `InterruptedException` catch in the `Object.wait`.
>> However, the fix in `JavaThread::is_interrupted()` also impacts the variations of `sleep_nanos()`.
>
> So the current changes do not limit this to just `RawMonitorWait`. I was expecting to only see additional code in `RawMonitorWait` that emulates what the Java code does to get the virtual and carrier thread interrupt states in sync, using the interruptLock.

Okay, I can do this separation.
One minor concern is the `JavaThread::sleep_nanos(jlong nanos)` ?
It is used by the `JavaThread::sleep(jlong millis)` which in tern is not used much.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1526831878

From sspitsyn at openjdk.org  Sat Mar 16 22:34:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 16 Mar 2024 22:34:03 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v5]
In-Reply-To: <w3e6DlxrB8WbL1ls6It_RxSdWy4qo9r2Z5C_Y01BHZc=.c5cc43c4-4e1c-4c13-bdc7-f9e1adab60fa@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <orZrn7Pv_rVxDnTHt9kt35VD088NSalA0qc5cIneO48=.9cf5de5f-7aa7-4788-87f0-4b71e9099d08@github.com>
 <-k7GC-5E6Hv9fWk9UEnk8GR7tWhr1dKEFCSP9eSIYdU=.93997997-56b1-4ef7-bc47-31ba96760eda@github.com>
 <_pbD7dEcZ0wjCfut2WEz5az3y11jhazNQp_8Ekje-Wg=.67400067-5142-49f0-bcfa-f40f77f6fe1c@github.com>
 <Kcx6SoNcp1C3-GTk8hHhLVWshuHKM9TRE5DN62_Zgeo=.4167311f-0f85-4424-9b77-d152ed43726f@github.com>
 <nc1GdDFdlBgC9TRyb4RrwRCrL306Kk_F5oj7y8nR18U=.3c183cb5-357c-4d79-b417-da414f74cfc9@github.com>
 <q0cikB2x4zIywyrGtJHWpiN3d_vLrmNUHmpGHwnw7-o=.415bfd3f-575d-40b5-9230-3300f7c7334a@github.com>
 <SVchHmqu4zpZr56j26tpZAP2j4_97Jy3PksTix7p3bE=.11550706-58dc-480a-95f1-76a68f4a48d9@github.com>
 <_SkGGAyOqYb37n8VJpVdYRpvlnCXYObFR3eHePXi9Bw=.624a1045-b947-4eed-9795-4f224b51ebe5@github.com>
 <AzRCuRoSmvhkPSlVA1evznEsFCDIedwIz35DhwqP-2g=.ec50b36a-1b45-43a0-8528-9ff1df168a13@github.com>
 <w3e6DlxrB8WbL1ls6It_RxSdWy4qo9r2Z5C
 _Y01BHZc=.c5cc43c4-4e1c-4c13-bdc7-f9e1adab60fa@github.com>
Message-ID: <st3NZsE8CrkgLjlRgA6QsLeoLX9ZCUxP_jWdFOKe1WA=.153c9aa9-4a98-48c9-85bd-08d094a9466c@github.com>

On Fri, 15 Mar 2024 21:00:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> So the current changes do not limit this to just `RawMonitorWait`. I was expecting to only see additional code in `RawMonitorWait` that emulates what the Java code does to get the virtual and carrier thread interrupt states in sync, using the interruptLock.
>
> Okay, I can do this separation.
> One minor concern is the `JavaThread::sleep_nanos(jlong nanos)` ?
> It is used by the `JavaThread::sleep(jlong millis)` which in tern is not used much.

Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1527150170

From sspitsyn at openjdk.org  Sat Mar 16 22:34:19 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 16 Mar 2024 22:34:19 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use JvmtiHandshake
Message-ID: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>

The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.

Testing:
 - Ran mach5 tiers 1-6

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

Commit messages:
 - added a couple of more fields to the JvmtiUnifiedHaandshakeClosure
 - 8328285: GetOwnedMonitorInfo functions should use JvmtiHandshake

Changes: https://git.openjdk.org/jdk/pull/18332/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18332&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328285
  Stats: 130 lines in 3 files changed: 35 ins; 74 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/18332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18332/head:pull/18332

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

From eirbjo at gmail.com  Sun Mar 17 18:42:52 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sun, 17 Mar 2024 19:42:52 +0100
Subject: RFD: Can we remove per-thread compiler stats now?
In-Reply-To: <SN7PR10MB7032134B3133947F2754EEA397282@SN7PR10MB7032.namprd10.prod.outlook.com>
References: <CA+pBWhtBhjXyyJ0GYc0JGdUvS9r7niNL056O2rSz=podcX4a-w@mail.gmail.com>
 <SN7PR10MB7032134B3133947F2754EEA397282@SN7PR10MB7032.namprd10.prod.outlook.com>
Message-ID: <CA+pBWhu7MAARpGf-YEpuU8VXT6f9B2+P6az01rOwNXMsewmVtQ@mail.gmail.com>

On Fri, Mar 15, 2024 at 7:54?PM Kevin Walls <kevin.walls at oracle.com> wrote:


> https://openjdk.org/jeps/277
>
> "An API element should not be removed from the Java SE specification
> unless it has been delivered with an annotation of
> @Deprecated(forRemoval=true) in a previous version of Java SE."
>
>
>
> So deprecations need to be "upgraded" to forRemoval, this will take a few
> updates to get them removed.
>

Hmm.. But if sun.management.HotspotCompilationMBean is an internal class,
it's not defined in the Java SE Specification, right? My understanding when
working on similar core-libs cleanups is that internal APIs can be removed
directly without the need for a forRemoval step.

HotspotCompilationMBean:
>
>
>
> @Deprecated
>
> public java.util.List<CompilerThreadStat> getCompilerThreadStats();
>
>
>
> .. need to consider whether a method is removed or  just "degraded" (not
> return any information, or throw).
>

I think this is already "degraded" in the sense that it does not return
useful information (underlying counters are long removed). My intention
here is to remove crufty leftover code. I think the best outcome is if we
can remove the code so maintainers no longer need to see or reason about it.


> That said, I see
> sun.management.CompilationImpl[java.lang:type=Compilation] ..rather than
> HotspotCompilation.
>
>
>
> ManagementFactoryHelper.java: getCompilationMXBean() specifically creates
> a CompilationImpl, users don?t normally see the HotspotCompilation mbean.
>

This and the rest goes into code and concepts I'm not very familiar with
(yet!), so I'm not sure I understand the implications well. But do you
think perhaps the whole HotspotCompilationMBean with implementation could
be removed? I'm not sure I see any consumers within OpenJDK of this
interface?


> The role of HotspotCompilationMBean needs more investigation, but
> basically yes to the idea. 8-)
>

Good! It seems there is potential for some level of cleanup here, so I'll
go ahead and make a PR where we can continue the discussion.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240317/7044ccb3/attachment-0001.htm>

From alanb at openjdk.org  Mon Mar 18 00:15:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Mar 2024 00:15:30 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v12]
In-Reply-To: <laADXsrathl5JJKzu7LAa56G-KTdMaVOXwShzZGcbCw=.e10ab081-2d71-4489-8441-5c2633e9145c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <laADXsrathl5JJKzu7LAa56G-KTdMaVOXwShzZGcbCw=.e10ab081-2d71-4489-8441-5c2633e9145c@github.com>
Message-ID: <VdDfJJucFgNPuBB7ii-mZNMKJG2RFq_y5IO40W6EVVg=.053ad0d3-d5c0-4d90-a8ed-7e246441b9ae@github.com>

On Sat, 16 Mar 2024 22:33:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: made current changes limitedto just RawMonitorWait

src/hotspot/share/runtime/javaThread.cpp line 596:

> 594: // Checks and clears the interrupt status for platform or virtual thread.
> 595: // Used by the JVMTI RawMonitorWait only.
> 596: bool JavaThread::is_interrupted() {

Reading code that uses JavaThread::is_interrupted() won't be clear that it resets the interrupt status. Can this be something that get_and_clear_interrupted or something that makes it clearer?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1527652412

From dholmes at openjdk.org  Mon Mar 18 02:43:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Mar 2024 02:43:28 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v12]
In-Reply-To: <laADXsrathl5JJKzu7LAa56G-KTdMaVOXwShzZGcbCw=.e10ab081-2d71-4489-8441-5c2633e9145c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <laADXsrathl5JJKzu7LAa56G-KTdMaVOXwShzZGcbCw=.e10ab081-2d71-4489-8441-5c2633e9145c@github.com>
Message-ID: <BL-ZHnVCw8_IJ9S8dxIvagwyBF0yQXFHm4W1HVysfa4=.f2a43c03-f326-404b-9e68-7c040cd57fbb@github.com>

On Sat, 16 Mar 2024 22:33:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: made current changes limitedto just RawMonitorWait

Thanks for doing this update.

> One minor concern is the `JavaThread::sleep_nanos(jlong nanos)` ?
> It is used by the `JavaThread::sleep(jlong millis)` which in tern is not used much.

There should be no virtual threads involved in executing the internal `sleep(millis)` variant. But good catch!

src/hotspot/share/runtime/javaThread.cpp line 595:

> 593: 
> 594: // Checks and clears the interrupt status for platform or virtual thread.
> 595: // Used by the JVMTI RawMonitorWait only.

Or more strongly:

// This is only for use by JVMTI RawMonitorWait. It emulates the actions of the Java code in Object::wait
// which are not present in RawMonitorWait.

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

PR Review: https://git.openjdk.org/jdk/pull/18093#pullrequestreview-1941874826
PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1527695544

From dholmes at openjdk.org  Mon Mar 18 02:43:29 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Mar 2024 02:43:29 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v12]
In-Reply-To: <VdDfJJucFgNPuBB7ii-mZNMKJG2RFq_y5IO40W6EVVg=.053ad0d3-d5c0-4d90-a8ed-7e246441b9ae@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <laADXsrathl5JJKzu7LAa56G-KTdMaVOXwShzZGcbCw=.e10ab081-2d71-4489-8441-5c2633e9145c@github.com>
 <VdDfJJucFgNPuBB7ii-mZNMKJG2RFq_y5IO40W6EVVg=.053ad0d3-d5c0-4d90-a8ed-7e246441b9ae@github.com>
Message-ID: <VwnR0A6Go_MWnSySFZL-kqoDHb28hxBzDrzFrVCNmSs=.d5dfd4f4-74eb-4b4d-8019-6f1d53e44507@github.com>

On Mon, 18 Mar 2024 00:12:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: made current changes limitedto just RawMonitorWait
>
> src/hotspot/share/runtime/javaThread.cpp line 596:
> 
>> 594: // Checks and clears the interrupt status for platform or virtual thread.
>> 595: // Used by the JVMTI RawMonitorWait only.
>> 596: bool JavaThread::is_interrupted() {
> 
> Reading code that uses JavaThread::is_interrupted() won't be clear that it resets the interrupt status. Can this be something that get_and_clear_interrupted or something that makes it clearer?

Maybe `is_interrupted_with_reset`?  (though that would seem like an alias for `is_interrupted(true)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1527693604

From dholmes at openjdk.org  Mon Mar 18 02:57:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Mar 2024 02:57:26 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <L1rgR508Sy9I2GeSq8jqNt9T-k2cSQZx9ijrIJYzGwk=.a3baff46-a2b0-4d8f-bbe9-0d3dba103635@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

I agree there is a  more general issue of test interference in anything other than `othervm` mode but that is beside the point. It seems to me that going from othervm to driver mode for the debugger has some not insignificant risk when it comes to interference.

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-2002783668

From dholmes at openjdk.org  Mon Mar 18 04:47:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Mar 2024 04:47:26 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake
In-Reply-To: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
Message-ID: <7rHrpXK-x-H4iHT160S5aUCGNwYJ7fbCMkFnTKo1_Nw=.47a4e0df-099c-45e2-aa26-50361f18dc70@github.com>

On Fri, 15 Mar 2024 20:14:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

src/hotspot/share/prims/jvmtiEnvBase.cpp line 2004:

> 2002: 
> 2003:   hs_cl->set_target_jt(target_jt);   // can be needed in the virtual thread case
> 2004:   hs_cl->set_is_virtual(is_virtual); // needed when suspend is required for non-current target thread

Is this comment correct? Seems like it was just copied.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1527812762

From dholmes at openjdk.org  Mon Mar 18 05:48:27 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Mar 2024 05:48:27 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
Message-ID: <OTHNseb32_7xVb8rM5Y2ex_zVrQGdNA_8gTALCA53og=.f8551643-e2cd-4016-86e2-92071162b65f@github.com>

On Fri, 15 Mar 2024 11:24:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust jcmd manpage, help and globals comment

Once the changes to the jcmd manpage are finalized please ask someone from Oracle serviceability  to apply the changes to the closed sources and regenerate the troff file to ensure things match. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2002975829

From rrich at openjdk.org  Mon Mar 18 10:20:00 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 18 Mar 2024 10:20:00 GMT
Subject: RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite [v2]
In-Reply-To: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
Message-ID: <9VajIlhw5cE9UPXdnzU1D5NcvRDNwLTKHa_G4kw5aU8=.1247da61-e7fa-4ecd-824d-987543ecbd89@github.com>

> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
> 
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> 
> More tests are pending.

Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:

  Set WXWrite at more locations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18238/files
  - new: https://git.openjdk.org/jdk/pull/18238/files/b34ad5f3..9075f4be

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

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

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

From rrich at openjdk.org  Mon Mar 18 10:26:26 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 18 Mar 2024 10:26:26 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v2]
In-Reply-To: <K_NQuogFom7vsp2Bp93KQnAB2LjGfEiaC-ObtqgcMy0=.586d4da6-7d43-486d-9137-3f77e443fd98@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <vxGx3wIPvBM7bs0tiKhCssTHZ-nNTrrnS4fCEE5clc0=.d59c75c1-756e-4c4c-97d7-defc03a2e84b@github.com>
 <zkJhZFbiWpLz1I95pZE4WSW1VyvyFsSeauSE7OnWBrU=.2f54fde5-2f37-4ceb-9585-51edc05a9c75@github.com>
 <K_NQuogFom7vsp2Bp93KQnAB2LjGfEiaC-ObtqgcMy0=.586d4da6-7d43-486d-9137-3f77e443fd98@github.com>
Message-ID: <I3M2riv_6J8ENpk_FdPsZ_SyIdwXARHywjGE-j3jcqw=.f91d84dc-55e5-4c8e-a30a-9f3478326c15@github.com>

On Fri, 15 Mar 2024 13:58:15 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> > As I wrote in JBS, shouldn't this be handled by `ThreadInVMfromNative`?
> 
> I agree. This is something I am investigating at the moment. Ideally, AssertWXAtThreadSync would also be true by default.

I've added a bunch more locations we've seen when testing with AssertWXAtThreadSync.

@tobiasholenstein would you think that this PR is actually not needed because you are going to push a better way of handling the WXMode in the near future?
How should be handle the issues in released versions (jdk 21, 17, ...)? Will it be possible to backport your work?

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2003496165

From ihse at openjdk.org  Mon Mar 18 10:56:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Mar 2024 10:56:54 GMT
Subject: RFR: 8328177: Move LDFLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk
Message-ID: <SLLx5r0atjXi0tBfduohg2HrVPUvTQxorYZR4cmqsu4=.3b0a90c0-78b2-4dd7-9d74-cc5ff084faab@github.com>

Similar to [JDK-8328157](https://bugs.openjdk.org/browse/JDK-8328157), we want to move the setting of LDFLAGS to LDFLAGS_JDK[LIB/EXE into SetupJdkLibrary and SetupJdkExecutable.

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

Commit messages:
 - 8328177: Move LDFLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk

Changes: https://git.openjdk.org/jdk/pull/18343/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18343&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328177
  Stats: 155 lines in 32 files changed: 29 ins; 99 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/18343.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18343/head:pull/18343

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

From sspitsyn at openjdk.org  Mon Mar 18 11:10:26 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 18 Mar 2024 11:10:26 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake
In-Reply-To: <7rHrpXK-x-H4iHT160S5aUCGNwYJ7fbCMkFnTKo1_Nw=.47a4e0df-099c-45e2-aa26-50361f18dc70@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <7rHrpXK-x-H4iHT160S5aUCGNwYJ7fbCMkFnTKo1_Nw=.47a4e0df-099c-45e2-aa26-50361f18dc70@github.com>
Message-ID: <iFHl_IhvauCVe23ClPKAAYTEEBYQAeeW3iKMyR_6bzo=.de59e738-9aa9-49db-b17f-1f2f9f6ea0fa@github.com>

On Mon, 18 Mar 2024 04:43:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2004:
> 
>> 2002: 
>> 2003:   hs_cl->set_target_jt(target_jt);   // can be needed in the virtual thread case
>> 2004:   hs_cl->set_is_virtual(is_virtual); // needed when suspend is required for non-current target thread
> 
> Is this comment correct? Seems like it was just copied.

Good catch. It was a copy-paste of the wrong comment. Will fix it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1528332705

From sspitsyn at openjdk.org  Mon Mar 18 11:14:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 18 Mar 2024 11:14:27 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v12]
In-Reply-To: <BL-ZHnVCw8_IJ9S8dxIvagwyBF0yQXFHm4W1HVysfa4=.f2a43c03-f326-404b-9e68-7c040cd57fbb@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <laADXsrathl5JJKzu7LAa56G-KTdMaVOXwShzZGcbCw=.e10ab081-2d71-4489-8441-5c2633e9145c@github.com>
 <BL-ZHnVCw8_IJ9S8dxIvagwyBF0yQXFHm4W1HVysfa4=.f2a43c03-f326-404b-9e68-7c040cd57fbb@github.com>
Message-ID: <o7M4n3gtU3rBm_TIrRyPXYVh7v22guZbs58kRgI9tPA=.70fee03a-46b3-4d71-af2b-281c37fc71ea@github.com>

On Mon, 18 Mar 2024 02:23:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: made current changes limitedto just RawMonitorWait
>
> src/hotspot/share/runtime/javaThread.cpp line 595:
> 
>> 593: 
>> 594: // Checks and clears the interrupt status for platform or virtual thread.
>> 595: // Used by the JVMTI RawMonitorWait only.
> 
> Or more strongly:
> 
> // This is only for use by JVMTI RawMonitorWait. It emulates the actions of the Java code in Object::wait
> // which are not present in RawMonitorWait.

Good suggestion, thanks. Will make an update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1528337516

From sspitsyn at openjdk.org  Mon Mar 18 11:14:28 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 18 Mar 2024 11:14:28 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v12]
In-Reply-To: <VwnR0A6Go_MWnSySFZL-kqoDHb28hxBzDrzFrVCNmSs=.d5dfd4f4-74eb-4b4d-8019-6f1d53e44507@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <laADXsrathl5JJKzu7LAa56G-KTdMaVOXwShzZGcbCw=.e10ab081-2d71-4489-8441-5c2633e9145c@github.com>
 <VdDfJJucFgNPuBB7ii-mZNMKJG2RFq_y5IO40W6EVVg=.053ad0d3-d5c0-4d90-a8ed-7e246441b9ae@github.com>
 <VwnR0A6Go_MWnSySFZL-kqoDHb28hxBzDrzFrVCNmSs=.d5dfd4f4-74eb-4b4d-8019-6f1d53e44507@github.com>
Message-ID: <jEmMtdithUA_0MfAUO2zxDpeNHLvQOPwQ8UhDs6G5I4=.58d7f0e6-73f8-4812-8820-9fbc3f813208@github.com>

On Mon, 18 Mar 2024 02:21:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 596:
>> 
>>> 594: // Checks and clears the interrupt status for platform or virtual thread.
>>> 595: // Used by the JVMTI RawMonitorWait only.
>>> 596: bool JavaThread::is_interrupted() {
>> 
>> Reading code that uses JavaThread::is_interrupted() won't be clear that it resets the interrupt status. Can this be something that get_and_clear_interrupted or something that makes it clearer?
>
> Maybe `is_interrupted_with_reset`?  (though that would seem like an alias for `is_interrupted(true)`.

Thanks, Alan and David. Will consider your suggestions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1528336441

From rrich at openjdk.org  Mon Mar 18 13:14:41 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 18 Mar 2024 13:14:41 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
Message-ID: <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>

> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
> 
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> 
> More tests are pending.

Richard Reingruber 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 8327990_jfr_enters_vm_without_wxwrite
 - Set WXWrite at more locations
 - Switch to WXWrite before entering the vm

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18238/files
  - new: https://git.openjdk.org/jdk/pull/18238/files/9075f4be..1b4d7606

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

  Stats: 293771 lines in 434 files changed: 6197 ins; 6221 del; 281353 mod
  Patch: https://git.openjdk.org/jdk/pull/18238.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18238/head:pull/18238

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

From kevin.walls at oracle.com  Mon Mar 18 13:31:37 2024
From: kevin.walls at oracle.com (Kevin Walls)
Date: Mon, 18 Mar 2024 13:31:37 +0000
Subject: [External] : Re: RFD: Can we remove per-thread compiler stats now?
In-Reply-To: <CA+pBWhu7MAARpGf-YEpuU8VXT6f9B2+P6az01rOwNXMsewmVtQ@mail.gmail.com>
References: <CA+pBWhtBhjXyyJ0GYc0JGdUvS9r7niNL056O2rSz=podcX4a-w@mail.gmail.com>
 <SN7PR10MB7032134B3133947F2754EEA397282@SN7PR10MB7032.namprd10.prod.outlook.com>
 <CA+pBWhu7MAARpGf-YEpuU8VXT6f9B2+P6az01rOwNXMsewmVtQ@mail.gmail.com>
Message-ID: <SN7PR10MB7032C9364D4F84980CA60AC6972D2@SN7PR10MB7032.namprd10.prod.outlook.com>

Right, the existing Deprecated tag had me thinking this was a Java SE interface that had begun the deprecation process.
But it's not a published API.

Maybe we can go further: HotspotCompilationMBean and HotspotInternalMBean look unused.  They are not exposed in the standard PlatformMBeanServer.

While looking for who/what uses these, I also found a recent mailing list thread:
"Question on why sun.management MBeans are not exported?"
https://www.mail-archive.com/core-libs-dev at openjdk.org/msg19878.html

..where the idea of removal also came up.

Thanks
Kevin


From: Eirik Bj?rsn?s <eirbjo at gmail.com>
Sent: 17 March 2024 18:43
To: Kevin Walls <kevin.walls at oracle.com>
Cc: serviceability-dev at openjdk.org
Subject: [External] : Re: RFD: Can we remove per-thread compiler stats now?

On Fri, Mar 15, 2024 at 7:54?PM Kevin Walls <kevin.walls at oracle.com<mailto:kevin.walls at oracle.com>> wrote:

https://openjdk.org/jeps/277
"An API element should not be removed from the Java SE specification unless it has been delivered with an annotation of @Deprecated(forRemoval=true) in a previous version of Java SE."

So deprecations need to be "upgraded" to forRemoval, this will take a few updates to get them removed.

Hmm.. But if sun.management.HotspotCompilationMBean is an internal class, it's not defined in the Java SE Specification, right? My understanding when working on similar core-libs cleanups is that internal APIs can be removed directly without the need for a forRemoval step.

HotspotCompilationMBean:

@Deprecated
public java.util.List<CompilerThreadStat> getCompilerThreadStats();

.. need to consider whether a method is removed or  just "degraded" (not return any information, or throw).

I think this is already "degraded" in the sense that it does not return useful information (underlying counters are long removed). My intention here is to remove crufty leftover code. I think the best outcome is if we can remove the code so maintainers no longer need to see or reason about it.

That said, I see sun.management.CompilationImpl[java.lang:type=Compilation] ..rather than HotspotCompilation.

ManagementFactoryHelper.java: getCompilationMXBean() specifically creates a CompilationImpl, users don?t normally see the HotspotCompilation mbean.

This and the rest goes into code and concepts I'm not very familiar with (yet!), so I'm not sure I understand the implications well. But do you think perhaps the whole HotspotCompilationMBean with implementation could be removed? I'm not sure I see any consumers within OpenJDK of this interface?

The role of HotspotCompilationMBean needs more investigation, but basically yes to the idea. 8-)

Good! It seems there is potential for some level of cleanup here, so I'll go ahead and make a PR where we can continue the discussion.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240318/66f56683/attachment-0001.htm>

From eirbjo at gmail.com  Mon Mar 18 14:10:11 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 18 Mar 2024 15:10:11 +0100
Subject: [External] : Re: RFD: Can we remove per-thread compiler stats now?
In-Reply-To: <SN7PR10MB7032C9364D4F84980CA60AC6972D2@SN7PR10MB7032.namprd10.prod.outlook.com>
References: <CA+pBWhtBhjXyyJ0GYc0JGdUvS9r7niNL056O2rSz=podcX4a-w@mail.gmail.com>
 <SN7PR10MB7032134B3133947F2754EEA397282@SN7PR10MB7032.namprd10.prod.outlook.com>
 <CA+pBWhu7MAARpGf-YEpuU8VXT6f9B2+P6az01rOwNXMsewmVtQ@mail.gmail.com>
 <SN7PR10MB7032C9364D4F84980CA60AC6972D2@SN7PR10MB7032.namprd10.prod.outlook.com>
Message-ID: <CA+pBWhsMH9TK8eQEGVraorWB3-ixGaLLVqWw_KEWLKHyvY4Jng@mail.gmail.com>

On Mon, Mar 18, 2024 at 2:31?PM Kevin Walls <kevin.walls at oracle.com> wrote:

> Right, the existing Deprecated tag had me thinking this was a Java SE
> interface that had begun the deprecation process.
>
> But it's not a published API.
>

Great, it seems we have consensus that we can go ahead and remove these
deprecated methods which return no useful data.

Maybe we can go further: HotspotCompilationMBean and HotspotInternalMBean
> look unused.  They are not exposed in the standard PlatformMBeanServer.
>
>
It seems we can! But since (a) this is my first serviceability contribution
and (b) the motivations for removing other unused beans may differ and also
be more controversial, I'd prefer to warm up with a PR narrowly focused on
the deprecated per-thread stats. We can then follow up with a broader
discussion of removal of unused Hotspot internal beans.

Would that be okay with you?

While looking for who/what uses these, I also found a recent mailing list
> thread:
>
> "Question on why sun.management MBeans are not exported?"
>
> https://www.mail-archive.com/core-libs-dev at openjdk.org/msg19878.html
>

Thanks, that provides some very useful context.

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240318/0c80b992/attachment.htm>

From kevin.walls at oracle.com  Mon Mar 18 14:27:28 2024
From: kevin.walls at oracle.com (Kevin Walls)
Date: Mon, 18 Mar 2024 14:27:28 +0000
Subject: [External] : Re: RFD: Can we remove per-thread compiler stats now?
In-Reply-To: <CA+pBWhsMH9TK8eQEGVraorWB3-ixGaLLVqWw_KEWLKHyvY4Jng@mail.gmail.com>
References: <CA+pBWhtBhjXyyJ0GYc0JGdUvS9r7niNL056O2rSz=podcX4a-w@mail.gmail.com>
 <SN7PR10MB7032134B3133947F2754EEA397282@SN7PR10MB7032.namprd10.prod.outlook.com>
 <CA+pBWhu7MAARpGf-YEpuU8VXT6f9B2+P6az01rOwNXMsewmVtQ@mail.gmail.com>
 <SN7PR10MB7032C9364D4F84980CA60AC6972D2@SN7PR10MB7032.namprd10.prod.outlook.com>
 <CA+pBWhsMH9TK8eQEGVraorWB3-ixGaLLVqWw_KEWLKHyvY4Jng@mail.gmail.com>
Message-ID: <SN7PR10MB70322FBF5FC64BB9D55742BE972D2@SN7PR10MB7032.namprd10.prod.outlook.com>


Would that be okay with you?

Absolutely!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240318/c3baffef/attachment.htm>

From eirbjo at openjdk.org  Mon Mar 18 15:43:48 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Mar 2024 15:43:48 GMT
Subject: RFR: 8328341: Remove deprecated per-thread compiler stats in
 sun.management
Message-ID: <95hFFQNgW6zftM5_A0XDC1L0qatg6fUQ379vp53JTxw=.9b7ef1ad-6ea8-40a3-9fea-bd6d4b57cb82@github.com>

Please review this cleanup PR which removes per-thread compiler stats from `sun.management`

This removes:

* The deprecated interface method `HotspotCompilationMBean.getCompilerThreadStats()` along with the implementation method in `HotspotCompilation`
* The class returned by these methods, `CompilerThreadStat`
* The nested class `HotspotCompilation.CompilerThreadInfo` which now falls out of use
* The field `HotspotCompilation.threads`, along with its initialization in `initCompilerCounters`

Testing and verification: As this is purely a removal and cleanup PR of unused code, no updates are made on the testing side. I have verified that the string `getCompilerThreadStats` is not found in OpenJDK after this PR.

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

Commit messages:
 - Remove HotspotCompilationMBean.getCompilerThreadStats() with associated implementation code

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

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

From bhuang at openjdk.org  Mon Mar 18 16:52:47 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 18 Mar 2024 16:52:47 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests
Message-ID: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>

This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.

Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
- Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
- Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

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

Commit messages:
 - Clean up temporary files after tests complete.

Changes: https://git.openjdk.org/jdk/pull/18352/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327474
  Stats: 42 lines in 11 files changed: 20 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

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

From alanb at openjdk.org  Mon Mar 18 22:52:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Mar 2024 22:52:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <W4H6LMjZxokSSq71NxDkNNbQgPxQKAJ9unepFW6K2sU=.de53b1b9-60b7-4786-925c-9accf7681f7e@github.com>

On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

test/jdk/java/nio/channels/unixdomain/Bind.java line 191:

> 189:             server.bind(null);
> 190:             UnixDomainSocketAddress usa = (UnixDomainSocketAddress)server.getLocalAddress();
> 191:             usa.getPath().toFile().deleteOnExit();

The test already deletes the file, I think you just want a try-finally here, same comment on a few other tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1529408542

From sspitsyn at openjdk.org  Mon Mar 18 23:45:29 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 18 Mar 2024 23:45:29 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v13]
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <9ZLgQt6Pk3rPZYTA2npXe5gqPBEvB4igMvG0DTiLrlg=.28ac45b2-2940-4d55-b628-f06347bfcadd@github.com>

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: rename is_interrupted() to get_and_clear_interrupted(); update comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18093/files
  - new: https://git.openjdk.org/jdk/pull/18093/files/5e0db950..f45f355c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18093&range=11-12

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

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

From sspitsyn at openjdk.org  Tue Mar 19 00:00:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 19 Mar 2024 00:00:21 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v12]
In-Reply-To: <jEmMtdithUA_0MfAUO2zxDpeNHLvQOPwQ8UhDs6G5I4=.58d7f0e6-73f8-4812-8820-9fbc3f813208@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <laADXsrathl5JJKzu7LAa56G-KTdMaVOXwShzZGcbCw=.e10ab081-2d71-4489-8441-5c2633e9145c@github.com>
 <VdDfJJucFgNPuBB7ii-mZNMKJG2RFq_y5IO40W6EVVg=.053ad0d3-d5c0-4d90-a8ed-7e246441b9ae@github.com>
 <VwnR0A6Go_MWnSySFZL-kqoDHb28hxBzDrzFrVCNmSs=.d5dfd4f4-74eb-4b4d-8019-6f1d53e44507@github.com>
 <jEmMtdithUA_0MfAUO2zxDpeNHLvQOPwQ8UhDs6G5I4=.58d7f0e6-73f8-4812-8820-9fbc3f813208@github.com>
Message-ID: <Y6O0LGLgrguQ_Nak2lODyku4LD77Yec9yODF0ipwFss=.08719e38-7801-46e5-8e8d-a9962edfaf72@github.com>

On Mon, 18 Mar 2024 11:10:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Maybe `is_interrupted_with_reset`?  (though that would seem like an alias for `is_interrupted(true)`.
>
> Thanks, Alan and David. Will consider your suggestions.

Renamed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18093#discussion_r1529479113

From sspitsyn at openjdk.org  Tue Mar 19 00:10:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 19 Mar 2024 00:10:32 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v2]
In-Reply-To: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
Message-ID: <LTYU6ijwPPDQ5NWrhMf4vRjKI-KF7Fdzv6KUDlFWllg=.4316e737-6f2d-485d-816a-cd005eb0cb9d@github.com>

> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: correct one comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18332/files
  - new: https://git.openjdk.org/jdk/pull/18332/files/a31c4f71..78b7c894

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

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

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

From dholmes at openjdk.org  Tue Mar 19 04:26:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Mar 2024 04:26:21 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v13]
In-Reply-To: <9ZLgQt6Pk3rPZYTA2npXe5gqPBEvB4igMvG0DTiLrlg=.28ac45b2-2940-4d55-b628-f06347bfcadd@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <9ZLgQt6Pk3rPZYTA2npXe5gqPBEvB4igMvG0DTiLrlg=.28ac45b2-2940-4d55-b628-f06347bfcadd@github.com>
Message-ID: <d_NYq4QXy1aY3CRsd0gM1pkaCmnBZJ_w3oqGe5SNtPE=.94f17c9f-ce58-494f-8a10-0b7c30f61bd0@github.com>

On Mon, 18 Mar 2024 23:45:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: rename is_interrupted() to get_and_clear_interrupted(); update comment

Thanks for the updates. I think that is all from me.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18093#pullrequestreview-1945144021

From dholmes at openjdk.org  Tue Mar 19 04:40:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Mar 2024 04:40:22 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
Message-ID: <MyWe_C1tm3mmd2HXbXRgD9uSmcyDDPgAnHPYzXwvUjM=.d2ee7f68-565f-48b6-bd7b-502d1d5e15e3@github.com>

On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> Richard Reingruber 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 8327990_jfr_enters_vm_without_wxwrite
>  - Set WXWrite at more locations
>  - Switch to WXWrite before entering the vm

I still feel that this should be fixed inside the `ThreadInVMfromNative` transition - the number of callsites that need it just reinforces that for me. Granted we then need to look at where we would now have redundant calls.

That said we have had a lot of people looking at the overall WX state management logic in the past week or so due to https://bugs.openjdk.org/browse/JDK-8327860. The workaround there requires us to be in EXEC mode and there are a number of folk who are questioning why "we" chose WRITE mode as the default with a switch to EXEC, instead of EXEC as the default with a switch to WRITE. But whichever way that goes I think the VM state transitions are the places to enforce that choice.

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

PR Review: https://git.openjdk.org/jdk/pull/18238#pullrequestreview-1945158370

From kevinw at openjdk.org  Tue Mar 19 07:54:20 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 19 Mar 2024 07:54:20 GMT
Subject: RFR: 8328341: Remove deprecated per-thread compiler stats in
 sun.management
In-Reply-To: <95hFFQNgW6zftM5_A0XDC1L0qatg6fUQ379vp53JTxw=.9b7ef1ad-6ea8-40a3-9fea-bd6d4b57cb82@github.com>
References: <95hFFQNgW6zftM5_A0XDC1L0qatg6fUQ379vp53JTxw=.9b7ef1ad-6ea8-40a3-9fea-bd6d4b57cb82@github.com>
Message-ID: <FHTf_o6sjZ8J8QJJwjc9jDRA3TdeSGHV4CtcB_eEImE=.5a1f8d4f-0151-49d6-98c9-e8245ec75c2d@github.com>

On Mon, 18 Mar 2024 09:42:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes per-thread compiler stats from `sun.management`
> 
> This removes:
> 
> * The deprecated interface method `HotspotCompilationMBean.getCompilerThreadStats()` along with the implementation method in `HotspotCompilation`
> * The class returned by these methods, `CompilerThreadStat`
> * The nested class `HotspotCompilation.CompilerThreadInfo` which now falls out of use
> * The field `HotspotCompilation.threads`, along with its initialization in `initCompilerCounters`
> 
> This was initially discussed here: https://mail.openjdk.org/pipermail/serviceability-dev/2024-March/054589.html
> 
> Testing and verification: As this is purely a removal and cleanup PR of unused code, no updates are made on the testing side. I have verified that the string `getCompilerThreadStats` is not found in OpenJDK after this PR.

Yes, looks good.
No problems with testst in test/jdk/javax/management or test/jdk/sun/management.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18344#pullrequestreview-1945428269

From alanb at openjdk.org  Tue Mar 19 08:12:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Mar 2024 08:12:25 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v13]
In-Reply-To: <9ZLgQt6Pk3rPZYTA2npXe5gqPBEvB4igMvG0DTiLrlg=.28ac45b2-2940-4d55-b628-f06347bfcadd@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <9ZLgQt6Pk3rPZYTA2npXe5gqPBEvB4igMvG0DTiLrlg=.28ac45b2-2940-4d55-b628-f06347bfcadd@github.com>
Message-ID: <kZqyltG9cK7iA7rLsUc9dhOFEgCQW4VwNLD9fqP_R5s=.a41d2592-0cc9-4690-ba84-b251d87278e8@github.com>

On Mon, 18 Mar 2024 23:45:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: rename is_interrupted() to get_and_clear_interrupted(); update comment

I don't have any more comments either, the src changes looks okay. I have not reviewed the test.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18093#pullrequestreview-1945459563

From sspitsyn at openjdk.org  Tue Mar 19 08:30:29 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 19 Mar 2024 08:30:29 GMT
Subject: RFR: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is [v13]
In-Reply-To: <9ZLgQt6Pk3rPZYTA2npXe5gqPBEvB4igMvG0DTiLrlg=.28ac45b2-2940-4d55-b628-f06347bfcadd@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
 <9ZLgQt6Pk3rPZYTA2npXe5gqPBEvB4igMvG0DTiLrlg=.28ac45b2-2940-4d55-b628-f06347bfcadd@github.com>
Message-ID: <Z6J_E1TUCgmTedDSB4B6k_BJSBtmlTZXsMYo-Wq6Ym4=.65be8d73-5b9f-4fc0-bb2b-b92b32270b55@github.com>

On Mon, 18 Mar 2024 23:45:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
>> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
>> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
>> 
>> Testing:
>>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>>  - ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: rename is_interrupted() to get_and_clear_interrupted(); update comment

David and Alan, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18093#issuecomment-2006278437

From sspitsyn at openjdk.org  Tue Mar 19 08:30:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 19 Mar 2024 08:30:31 GMT
Subject: Integrated: 8325187: JVMTI GetThreadState says virtual thread is
 JVMTI_THREAD_STATE_INTERRUPTED when it no longer is
In-Reply-To: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
References: <ve5fmMarsJ2B1AXWzrdc8ImTGQf3D3SA2aPy6-Z9iQQ=.64bf31cb-ca2e-4ec9-bad8-66ea5cb1a11c@github.com>
Message-ID: <z1Vy3QkzsGfz_fNOYjjSZnTGBDYCAtqnSd0M3Jy1f7Y=.d55ef74c-92b8-420f-97f8-fbfc26a931ff@github.com>

On Fri, 1 Mar 2024 23:26:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Please, review this fix correcting the JVMTI  `RawMonitorWait()` implementation.
> The `RawMonitorWait()` is using the the  `jt->is_interrupted(true)` to update the interrupt status of the interrupted waiting thread.  The issue is that when it calls `jt->is_interrupted(true)` to fetch and clear the `interrupt status` of the virtual thread, this information is not propagated to the `java.lang.Thread` instance.
> In the `VirtualThread` class implementation the `interrupt status` for virtual thread is stored for both virtual and carrier threads. It is because the implementation of object monitors for virtual threads is based on pinning virtual threads, and so, always operates on carrier thread. The fix is to clear the interrupt status for both virtual and carrier  `java.lang.Thread` instances.
> 
> Testing:
>  - tested with new test `hotspot/jtreg/serviceability/jvmti/vthread/InterruptRawMonitor` which is passed with the fix and failed without it
>  - ran mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 6eea5d67
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6eea5d675566adca3fca88639008c6c0221450a4
Stats:     209 lines in 7 files changed: 205 ins; 1 del; 3 mod

8325187: JVMTI GetThreadState says virtual thread is JVMTI_THREAD_STATE_INTERRUPTED when it no longer is

Reviewed-by: dholmes, alanb

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

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

From aph at openjdk.org  Tue Mar 19 09:33:23 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 19 Mar 2024 09:33:23 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <MyWe_C1tm3mmd2HXbXRgD9uSmcyDDPgAnHPYzXwvUjM=.d2ee7f68-565f-48b6-bd7b-502d1d5e15e3@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
 <MyWe_C1tm3mmd2HXbXRgD9uSmcyDDPgAnHPYzXwvUjM=.d2ee7f68-565f-48b6-bd7b-502d1d5e15e3@github.com>
Message-ID: <CCeQsgzwpOyX8ZZdrDgEQneZ5lvoTeqdCRb8NMtocec=.5cc04bc3-f430-4ee6-802d-5e1e5d09edf6@github.com>

On Tue, 19 Mar 2024 04:37:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That said we have had a lot of people looking at the overall WX state management logic in the past week or so due to https://bugs.openjdk.org/browse/JDK-8327860. The workaround there requires us to be in EXEC mode

That's very odd. The example there doesn't even involve MAP_JIT memory, so what does it have to do with WX?

> and there are a number of folk who are questioning why "we" chose WRITE mode as the default with a switch to EXEC, instead of EXEC as the default with a switch to WRITE.
> But whichever way that goes I think the VM state transitions are the places to enforce that choice.

Hmm. Changing WX at VM state transitions is a form of temporal coupling, a classic design smell that has caused problems for decades. It's causing problems for us now. Instead, could we tag code that needs one or the other, keep track of the current WX state in thread-local memory, and flip WX only when we know we need to? That'd (by definition) reduce the number of transitions to the minimum if we were through.

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2006498201

From mbaesken at openjdk.org  Tue Mar 19 10:16:21 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 19 Mar 2024 10:16:21 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <bM4Dhx26HysYBSIRfuOCIyfw5xF8U1QMrWVTcth0hag=.46c6c5ee-01ce-4026-8e17-25601ffc71b9@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
 <cclVVJAdx2okigLogb54UwQFqftlB6mDoUKF2ywsayI=.8d852c1d-7f05-4282-a3da-b1fa61d79bd3@github.com>
 <bM4Dhx26HysYBSIRfuOCIyfw5xF8U1QMrWVTcth0hag=.46c6c5ee-01ce-4026-8e17-25601ffc71b9@github.com>
Message-ID: <FvCroqWSCUjLkithoBxwqUm4A3Rx0VXqnd3DJS3Qrz0=.bd438a8e-895b-4bd5-8713-4a91c4e33d30@github.com>

On Sat, 16 Mar 2024 12:50:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/hotspot/share/services/diagnosticCommand.cpp line 475:
>> 
>>> 473: HeapDumpDCmd::HeapDumpDCmd(outputStream* output, bool heap) :
>>> 474:                            DCmdWithParser(output, heap),
>>> 475:   _filename("filename","Name of the dump file", "STRING", false, "if no filename was specified, but -XX:HeapDumpPath=hdp is set, path hdp is taken"),
>> 
>> This seems clumsy, but I'm having a hard time coming up with something better.
>> 
>> "the filename specified by -XX:HeapDumpPath, if specified"
>> "If -XX:HeapDumpPath is specified, then it is used as the default"
>> 
>> Makes me wonder if this approach is wrong since it is hard to document clearly. Maybe we should go back to not having the jcmd use HeapDumpPath. I understand the argument for having the jcmd use the HeapDumpPath setting, but it might not be worth the documentation confusion it introduces. You can argue that HeapDumpPath really is just intended to help support HeapDumpOnOutOfMemoryError. Does the jcmd also use HeapDumpGzipLevel? I'm not sure, but we should be consistent with the application of HeapDumpPath and HeapDumpGzipLevel to the jcmd.
>
> So far we only use the gzip level setting from jcmd, not HeapDumpGzipLevel .
> See the `level` variable in  `HeapDumpDCmd::execute` . Yeah you are probably right we should make it consistent.

> If -XX:HeapDumpPath is specified, then it is used as the default

No, the filename set with jcmd GC:heamp_dump  filename   has priority. So we should better keep the current description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1530077879

From mbaesken at openjdk.org  Tue Mar 19 10:19:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 19 Mar 2024 10:19:22 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <FvCroqWSCUjLkithoBxwqUm4A3Rx0VXqnd3DJS3Qrz0=.bd438a8e-895b-4bd5-8713-4a91c4e33d30@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
 <cclVVJAdx2okigLogb54UwQFqftlB6mDoUKF2ywsayI=.8d852c1d-7f05-4282-a3da-b1fa61d79bd3@github.com>
 <bM4Dhx26HysYBSIRfuOCIyfw5xF8U1QMrWVTcth0hag=.46c6c5ee-01ce-4026-8e17-25601ffc71b9@github.com>
 <FvCroqWSCUjLkithoBxwqUm4A3Rx0VXqnd3DJS3Qrz0=.bd438a8e-895b-4bd5-8713-4a91c4e33d30@github.com>
Message-ID: <jAkqK-yX78T-P8APCvhYotdq8bac1MvhKb5oyHGCJL0=.61e1d46c-16ce-4de0-bc77-11b297f8fe0a@github.com>

On Tue, 19 Mar 2024 10:13:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> So far we only use the gzip level setting from jcmd, not HeapDumpGzipLevel .
>> See the `level` variable in  `HeapDumpDCmd::execute` . Yeah you are probably right we should make it consistent.
>
>> If -XX:HeapDumpPath is specified, then it is used as the default
> 
> No, the filename set with jcmd GC:heamp_dump  filename   has priority. So we should better keep the current description.

So should I also use  HeapDumpGzipLevel  the same way as HeapDumpPath ? Tehn we have to change the text in globals.hpp for HeapDumpGzipLevel as well because it mentions only the HeapDumpOnOutOfmemoryError case and not the jcmd case .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1530082635

From dholmes at openjdk.org  Tue Mar 19 12:20:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Mar 2024 12:20:21 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <CCeQsgzwpOyX8ZZdrDgEQneZ5lvoTeqdCRb8NMtocec=.5cc04bc3-f430-4ee6-802d-5e1e5d09edf6@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
 <MyWe_C1tm3mmd2HXbXRgD9uSmcyDDPgAnHPYzXwvUjM=.d2ee7f68-565f-48b6-bd7b-502d1d5e15e3@github.com>
 <CCeQsgzwpOyX8ZZdrDgEQneZ5lvoTeqdCRb8NMtocec=.5cc04bc3-f430-4ee6-802d-5e1e5d09edf6@github.com>
Message-ID: <StQc31_tIsFoNjJbswd3pLgr9UB4OYkyZ0DB1i3Mm8s=.03849f7f-9cb1-47c1-92b2-59b4aa0361b1@github.com>

On Tue, 19 Mar 2024 09:30:52 GMT, Andrew Haley <aph at openjdk.org> wrote:

> That's very odd. The example there doesn't even involve MAP_JIT memory, so what does it have to do with WX?

@theRealAph that is the mystery we hope will be resolved once we know the nature of the underlying OS bug. Somehow switching to exec mode fixes/works-around the issue. I can imagine a missing conditional to check if the region is MAP_JIT.

> Changing WX at VM state transitions is a form of temporal coupling, a classic design smell that has caused problems for decades.

The original introducers of WXEnable made the decision that the VM should be in WRITE mode unless it needs EXEC. That is the state we are presently trying to achieve with this change. If that original design choice is wrong then ...

> Instead, could we tag code that needs one or the other, keep track of the current WX state in thread-local memory, and flip WX only when we know we need to?

And I've asked about this every time a missing WXEnable has had to be added. We seem to be generically able to  describe what kind of code needs which mode, but we seem to struggle to pin it down. Though that is what https://bugs.openjdk.org/browse/JDK-8307817 is looking at doing.

> That'd (by definition) reduce the number of transitions to the minimum if we were through.

Not necessarily. It may well remove some transitions from paths that don't need it, but if you move the state change too low down the call chain you could end up transitioning much more often in code that does need it e.g. if a transitioning method is called in a loop. We need to optimise the actual call paths as well as identify specific methods.

But all this discussion suggests to me that this PR is not really worth pursuing at this time - IIUC no actual failures are observed other than those pertaining to `AssertWXAtThreadSync` and that flag will be gone if we do decide to be more fine-grained about WX management.

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2007029830

From mbaesken at openjdk.org  Tue Mar 19 13:22:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 19 Mar 2024 13:22:22 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <StQc31_tIsFoNjJbswd3pLgr9UB4OYkyZ0DB1i3Mm8s=.03849f7f-9cb1-47c1-92b2-59b4aa0361b1@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
 <MyWe_C1tm3mmd2HXbXRgD9uSmcyDDPgAnHPYzXwvUjM=.d2ee7f68-565f-48b6-bd7b-502d1d5e15e3@github.com>
 <CCeQsgzwpOyX8ZZdrDgEQneZ5lvoTeqdCRb8NMtocec=.5cc04bc3-f430-4ee6-802d-5e1e5d09edf6@github.com>
 <StQc31_tIsFoNjJbswd3pLgr9UB4OYkyZ0DB1i3Mm8s=.03849f7f-9cb1-47c1-92b2-59b4aa0361b1@github.com>
Message-ID: <N1GCE8duagx4kMheOWrZoTVg0SXNTO65Xa_0BrWSog8=.6dec3754-089c-496f-b199-92222d72c7e6@github.com>

On Tue, 19 Mar 2024 12:17:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>  IIUC no actual failures are observed other than those pertaining to AssertWXAtThreadSync

We saw sporadic crashes in our jtreg (maybe also jck?) runs; only **_later_** we enabled AssertWXAtThreadSync for more checking.

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2007159560

From stuefe at openjdk.org  Tue Mar 19 15:20:23 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 19 Mar 2024 15:20:23 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <StQc31_tIsFoNjJbswd3pLgr9UB4OYkyZ0DB1i3Mm8s=.03849f7f-9cb1-47c1-92b2-59b4aa0361b1@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
 <MyWe_C1tm3mmd2HXbXRgD9uSmcyDDPgAnHPYzXwvUjM=.d2ee7f68-565f-48b6-bd7b-502d1d5e15e3@github.com>
 <CCeQsgzwpOyX8ZZdrDgEQneZ5lvoTeqdCRb8NMtocec=.5cc04bc3-f430-4ee6-802d-5e1e5d09edf6@github.com>
 <StQc31_tIsFoNjJbswd3pLgr9UB4OYkyZ0DB1i3Mm8s=.03849f7f-9cb1-47c1-92b2-59b4aa0361b1@github.com>
Message-ID: <RksaTC6r-ek8MxJ2DIO784aFm8xXTXyH7lwcK7NDMpg=.bf9eb6ca-1cf7-4362-be6d-5e46e456c11f@github.com>

On Tue, 19 Mar 2024 12:17:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Instead, could we tag code that needs one or the other, keep track of the current WX state in thread-local memory, and flip WX only when we know we need to? 

The first part we already do.

I wonder wheter we could - at least as workaround for if we missed a spot - do wx switching as a reaction to a SIBBUS related to WX violation in code cache. Switch state around, return from signal handler and retry operation.

(Edit: tested it, does not seem to work. I guess when the SIGBUS is triggered in the kernel thread WX state had already been processed somehow).

> > That's very odd. The example there doesn't even involve MAP_JIT memory, so what does it have to do with WX?
> 
> @theRealAph that is the mystery we hope will be resolved once we know the nature of the underlying OS bug. Somehow switching to exec mode fixes/works-around the issue. I can imagine a missing conditional to check if the region is MAP_JIT.
> 
> > Changing WX at VM state transitions is a form of temporal coupling, a classic design smell that has caused problems for decades.
> 
> The original introducers of WXEnable made the decision that the VM should be in WRITE mode unless it needs EXEC. That is the state we are presently trying to achieve with this change. If that original design choice is wrong then ...
> 
> > Instead, could we tag code that needs one or the other, keep track of the current WX state in thread-local memory, and flip WX only when we know we need to?
> 
> And I've asked about this every time a missing WXEnable has had to be added. We seem to be generically able to describe what kind of code needs which mode, but we seem to struggle to pin it down. Though that is what https://bugs.openjdk.org/browse/JDK-8307817 is looking at doing.
> 
> > That'd (by definition) reduce the number of transitions to the minimum if we were through.
> 
> Not necessarily. It may well remove some transitions from paths that don't need it, but if you move the state change too low down the call chain you could end up transitioning much more often in code that does need it e.g. if a transitioning method is called in a loop. 

Not if you do the switching lazily. The first iteration would switch to the needed state; subsequent iterations would not do anything since the state already matches. Unless you interleave writes and execs, but then you would need the state changes anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2007469410

From eirbjo at openjdk.org  Tue Mar 19 16:34:29 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Mar 2024 16:34:29 GMT
Subject: RFR: 8328341: Remove deprecated per-thread compiler stats in
 sun.management
In-Reply-To: <95hFFQNgW6zftM5_A0XDC1L0qatg6fUQ379vp53JTxw=.9b7ef1ad-6ea8-40a3-9fea-bd6d4b57cb82@github.com>
References: <95hFFQNgW6zftM5_A0XDC1L0qatg6fUQ379vp53JTxw=.9b7ef1ad-6ea8-40a3-9fea-bd6d4b57cb82@github.com>
Message-ID: <VWGcy6lM6NjcDM3mtkJq1MT1cLzD9T4T1-_qZ3Seo_g=.525084d7-0378-433a-ad28-51a3ceec8db6@github.com>

On Mon, 18 Mar 2024 09:42:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes per-thread compiler stats from `sun.management`
> 
> This removes:
> 
> * The deprecated interface method `HotspotCompilationMBean.getCompilerThreadStats()` along with the implementation method in `HotspotCompilation`
> * The class returned by these methods, `CompilerThreadStat`
> * The nested class `HotspotCompilation.CompilerThreadInfo` which now falls out of use
> * The field `HotspotCompilation.threads`, along with its initialization in `initCompilerCounters`
> 
> This was initially discussed here: https://mail.openjdk.org/pipermail/serviceability-dev/2024-March/054589.html
> 
> Testing and verification: As this is purely a removal and cleanup PR of unused code, no updates are made on the testing side. I have verified that the string `getCompilerThreadStats` is not found in OpenJDK after this PR.

Thanks for reviewing, Kevin!

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

PR Comment: https://git.openjdk.org/jdk/pull/18344#issuecomment-2007634465

From eirbjo at openjdk.org  Tue Mar 19 16:34:30 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Mar 2024 16:34:30 GMT
Subject: Integrated: 8328341: Remove deprecated per-thread compiler stats in
 sun.management
In-Reply-To: <95hFFQNgW6zftM5_A0XDC1L0qatg6fUQ379vp53JTxw=.9b7ef1ad-6ea8-40a3-9fea-bd6d4b57cb82@github.com>
References: <95hFFQNgW6zftM5_A0XDC1L0qatg6fUQ379vp53JTxw=.9b7ef1ad-6ea8-40a3-9fea-bd6d4b57cb82@github.com>
Message-ID: <zldDOwPZpJ7RgzVGT5IztttmxeW4JaxJUV179gS02nE=.b469aaa4-13d0-4aa4-b5b6-3c9ec4b38e3e@github.com>

On Mon, 18 Mar 2024 09:42:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes per-thread compiler stats from `sun.management`
> 
> This removes:
> 
> * The deprecated interface method `HotspotCompilationMBean.getCompilerThreadStats()` along with the implementation method in `HotspotCompilation`
> * The class returned by these methods, `CompilerThreadStat`
> * The nested class `HotspotCompilation.CompilerThreadInfo` which now falls out of use
> * The field `HotspotCompilation.threads`, along with its initialization in `initCompilerCounters`
> 
> This was initially discussed here: https://mail.openjdk.org/pipermail/serviceability-dev/2024-March/054589.html
> 
> Testing and verification: As this is purely a removal and cleanup PR of unused code, no updates are made on the testing side. I have verified that the string `getCompilerThreadStats` is not found in OpenJDK after this PR.

This pull request has now been integrated.

Changeset: 9214a62f
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9214a62f26917162b3ff2144a1f3f9cde3b808fa
Stats:     149 lines in 3 files changed: 0 ins; 147 del; 2 mod

8328341: Remove deprecated per-thread compiler stats in sun.management

Reviewed-by: kevinw

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

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

From eirbjo at gmail.com  Tue Mar 19 16:41:13 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 19 Mar 2024 17:41:13 +0100
Subject: RFD: Remove Hotspot-internal MBeans from sun.management
Message-ID: <CA+pBWhv52Sw2E4z5d0xs+h7nWS4asSWgoe4Ke5CftNy2zAqznQ@mail.gmail.com>

Hi,

Last September, Volker shared the observation that we have Hotspot-internal
MBeans in sun.management which are strongly encapsulated and not used
internally by OpenJDK besides their unit tests:

https://www.mail-archive.com/core-libs-dev at openjdk.org/msg19878.html

A summary of the email thread:

Mandy pointed out:

We added these HotSpot internal MBeans in JDK 5 to expose the internal
> metrics.  Most of these internal metrics are exposed via jstat tool too.
> We didn't receive much feedback regarding these HotSpot internal MBeans.
>  Removing them is fine and good cleanup effort.


Alan made a similar point:

It's left over from experiments on exposing some internal metrics, I think
> during JDK 5. It's code that should probably have been removed a long time
> ago.


Kirk P raised a concern:

It would be a shame to lose these metrics because many of them have been
> very
> useful over time and some would be even more useful with some
> modifications.
>

To which Mandy responded:

What we're referring to is to remove sun.management.Hotspot*, the internal
> MBeans which are never exposed and registered in the platform MBeanServer.
>   The internal metrics in HotSpot VM should be retained as they are exposed
> through other ways like jstat, GC logs, etc.


The email thread seems to have ended here without further action taken.

My interpretation of the above is that we have a consensus that these
Hotspot-internal MBeans can be removed. Since I was not part of the initial
discussion and some time has passed, I'd like some confirmation that my
interpretation is correct.

Would a PR to remove these APIs be welcome?

(This would remove HotspotInternalMBean, HotspotMemoryMBean,
HotspotRuntimeMBean, HotspotThreadMBean, with associated implementation,
factory methods, tests and probably also some native code in libmanagement.
Details can be discussed in a PR)

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240319/30b2d877/attachment-0001.htm>

From mandy.chung at oracle.com  Tue Mar 19 16:48:12 2024
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 19 Mar 2024 09:48:12 -0700
Subject: RFD: Remove Hotspot-internal MBeans from sun.management
In-Reply-To: <CA+pBWhv52Sw2E4z5d0xs+h7nWS4asSWgoe4Ke5CftNy2zAqznQ@mail.gmail.com>
References: <CA+pBWhv52Sw2E4z5d0xs+h7nWS4asSWgoe4Ke5CftNy2zAqznQ@mail.gmail.com>
Message-ID: <2bc6ef91-eb5e-47e5-a028-d0596cf1fdd4@oracle.com>

> Would a PR to remove these APIs be welcome?
>

Good with me.

Mandy

On 3/19/24 9:41 AM, Eirik Bj?rsn?s wrote:
>
> Hi,
>
> Last September, Volker shared the observation that we have 
> Hotspot-internal MBeans in sun.management which are strongly 
> encapsulated and not used internally by OpenJDK besides their?unit tests:
>
> https://www.mail-archive.com/core-libs-dev at openjdk.org/msg19878.html 
> <https://urldefense.com/v3/__https://www.mail-archive.com/core-libs-dev at openjdk.org/msg19878.html__;!!ACWV5N9M2RV99hQ!KfW2PiXn5Gb38tJmxUNxLW_fhwy1H7NijeBmgeWH0ZWNw6QriJmDY_ZD5miuxMQq9q0Rl_k6ZOdb-b0$>
>
> A summary of the email thread:
>
> Mandy pointed out:
>
>     We added these HotSpot internal MBeans in JDK 5 to expose the
>     internal metrics.? Most of these internal metrics are exposed via
>     jstat tool too. ? We didn't receive much feedback regarding these
>     HotSpot internal MBeans. ? ?Removing them is fine and good cleanup
>     effort.
>
>
> Alan made a similar point:
>
>     It's left over from experiments on exposing some internal metrics,
>     I think during JDK 5. It's code that should probably have been
>     removed a long time ago.
>
>
> Kirk P raised a concern:
>
>     It would be a shame to lose these metrics because many of them
>     have been very
>     useful over time and some would be even more useful with some
>     modifications.
>
> To which Mandy responded:
>
>     What we're referring to is to remove sun.management.Hotspot*, the
>     internal MBeans which are never exposed and registered in the
>     platform MBeanServer. ? The internal metrics in HotSpot VM should
>     be retained as they are exposed through other ways like jstat, GC
>     logs, etc.
>
>
> The email thread seems to have ended here without further action taken.
>
> My interpretation of the above is that we have a consensus?that these 
> Hotspot-internal MBeans can be removed. Since I was not part of the 
> initial discussion and some time has passed, I'd like some 
> confirmation that my interpretation is correct.
>
> Would a PR to remove these APIs be welcome?
>
> (This would remove HotspotInternalMBean, HotspotMemoryMBean, 
> HotspotRuntimeMBean, HotspotThreadMBean, with associated 
> implementation, factory methods, tests and probably also some native 
> code in libmanagement. Details can be discussed in a PR)
>
> Cheers,
> Eirik.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240319/fcd319c9/attachment.htm>

From rrich at openjdk.org  Tue Mar 19 17:11:23 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 19 Mar 2024 17:11:23 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <StQc31_tIsFoNjJbswd3pLgr9UB4OYkyZ0DB1i3Mm8s=.03849f7f-9cb1-47c1-92b2-59b4aa0361b1@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
 <MyWe_C1tm3mmd2HXbXRgD9uSmcyDDPgAnHPYzXwvUjM=.d2ee7f68-565f-48b6-bd7b-502d1d5e15e3@github.com>
 <CCeQsgzwpOyX8ZZdrDgEQneZ5lvoTeqdCRb8NMtocec=.5cc04bc3-f430-4ee6-802d-5e1e5d09edf6@github.com>
 <StQc31_tIsFoNjJbswd3pLgr9UB4OYkyZ0DB1i3Mm8s=.03849f7f-9cb1-47c1-92b2-59b4aa0361b1@github.com>
Message-ID: <bQf66fbwEvOsCPHX1FBXDw5g1d0JQfpcFQGipjz2pX0=.075a18b3-6ed3-4c6e-8a5a-63931cd23c7e@github.com>

On Tue, 19 Mar 2024 12:17:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But all this discussion suggests to me that this PR is not really worth pursuing at this time - IIUC no actual failures are observed other than those pertaining to AssertWXAtThreadSync and that flag will be gone if we do decide to be more fine-grained about WX management.

I see it differently. This PR is just a simple attempt to get clean test runs with AssertWXAtThreadSync (after fixing an actual crash https://bugs.openjdk.org/browse/JDK-8327036). While the violating locations in this PR might be unlikely to produce actual crashes I think it is worthwhile to have clean testing with AssertWXAtThreadSync because this will help prevent regressions that are more likely.

Beyond the trivial fixes of this PR I'm very much in favor of further enhancements as the aforementioned https://bugs.openjdk.org/browse/JDK-8307817.
My recommendation would be to remove as much non-constant data from the code cache as possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2007709981

From tholenstein at openjdk.org  Tue Mar 19 17:26:22 2024
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Tue, 19 Mar 2024 17:26:22 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <bQf66fbwEvOsCPHX1FBXDw5g1d0JQfpcFQGipjz2pX0=.075a18b3-6ed3-4c6e-8a5a-63931cd23c7e@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
 <MyWe_C1tm3mmd2HXbXRgD9uSmcyDDPgAnHPYzXwvUjM=.d2ee7f68-565f-48b6-bd7b-502d1d5e15e3@github.com>
 <CCeQsgzwpOyX8ZZdrDgEQneZ5lvoTeqdCRb8NMtocec=.5cc04bc3-f430-4ee6-802d-5e1e5d09edf6@github.com>
 <StQc31_tIsFoNjJbswd3pLgr9UB4OYkyZ0DB1i3Mm8s=.03849f7f-9cb1-47c1-92b2-59b4aa0361b1@github.com>
 <bQf66fbwEvOsCPHX1FBXDw5g1d0JQfpcFQGipjz2pX0=.075a18b3-6ed3-4c6e-8a5a-63931cd23c7e@github.com>
Message-ID: <rE68qtF3pLA3v0ttenDCKPdyxQg5j-G8cjez6LzfcZQ=.20e41314-27a2-4bee-b34d-7a6fdf9054f7@github.com>

On Tue, 19 Mar 2024 17:08:52 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I see it differently. This PR is just a simple attempt to get clean test runs with AssertWXAtThreadSync (after fixing an actual crash https://bugs.openjdk.org/browse/JDK-8327036). While the violating locations in this PR might be unlikely to produce actual crashes I think it is worthwhile to have clean testing with AssertWXAtThreadSync because this will help prevent regressions that are more likely.

I agree. Fixing the current state with this PR makes sense to me. Changing the logic of W^X will take more time and discussion. So from my point of view this PR is ready and should be integrated. If no-one disagrees I will approve

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2007742855

From tholenstein at openjdk.org  Tue Mar 19 17:49:21 2024
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Tue, 19 Mar 2024 17:49:21 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <I2vjqPLe4V4ppRKX4MizQ32-fKkQED4WIe0tDVZM7Cc=.bdc04eff-6b5e-4ace-9465-f7c8d70eaa56@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <LwiFM7Sj36liJgbF9_UEqj2LezKKAE9sb7CNvJPlAF8=.1ccb1252-ded5-41c4-9a24-26c93f855326@github.com>
 <I2vjqPLe4V4ppRKX4MizQ32-fKkQED4WIe0tDVZM7Cc=.bdc04eff-6b5e-4ace-9465-f7c8d70eaa56@github.com>
Message-ID: <6SKAa4aj0VpZeAKntqNZ_Nr4pQsCp0o3zXsph-0Wa98=.b7be4d1f-465c-4edc-b9f1-1b6589271442@github.com>

On Wed, 13 Mar 2024 13:53:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 160:
>> 
>>> 158:   ResourceMark rm(THREAD);
>>> 159:   // WXWrite is needed before entering the vm below and in callee methods.
>>> 160:   MACOS_AARCH64_ONLY(ThreadWXEnable __wx(WXWrite, THREAD));
>> 
>> I understand you placed this here to cover the transition inside `create_classes_array` and the immediate one at line 170, but doesn't this risk having the wrong WX state for code in between?
>
> I've asked this myself (after making the change).
> Being in `WXWrite` mode would be wrong if the thread would execute dynamically generated code. There's not too much happening outside the scope of the `ThreadInVMfromNative` instances. I see jni calls (`GetObjectArrayElement`, `ExceptionOccurred`) and a jvmti call (`RetransformClasses`) but these are safe because the callees enter the vm right away. We even avoid switching to `WXWrite` and back there.
> So I thought it would be ok to coarsen the WXMode switching.
> But maybe it's still better to avoid any risk especially since there's likely no performance effect.

Or could the  `ThreadInVMfromNative tvmfn(THREAD);` in `check_exception_and_log` be move out to `JfrJvmtiAgent::retransform_classes`?  And then only use one `ThreadInVMfromNative` in `JfrJvmtiAgent::retransform_classes`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18238#discussion_r1530831165

From bhuang at openjdk.org  Tue Mar 19 17:58:46 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 19 Mar 2024 17:58:46 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/8472c31f..620f9259

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

  Stats: 136 lines in 5 files changed: 36 ins; 13 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

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

From stuefe at openjdk.org  Tue Mar 19 18:34:24 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 19 Mar 2024 18:34:24 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
Message-ID: <EisvwBifuGmux65Df_RJFRWUTg0__mPuM093a_0ewfw=.c7ed4cb7-344f-4dac-b3c6-23f53c40732b@github.com>

On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> Richard Reingruber 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 8327990_jfr_enters_vm_without_wxwrite
>  - Set WXWrite at more locations
>  - Switch to WXWrite before entering the vm

I think this patch makes sense, and does not compete with a long-term solution.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18238#pullrequestreview-1947069985

From mdoerr at openjdk.org  Tue Mar 19 19:19:22 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 19 Mar 2024 19:19:22 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
Message-ID: <axTwQanspIW5_SmtLtDgv_kXD9dChGT4qwlat3-q-UA=.a0a0cfff-0515-4208-91e3-7883221ec0f1@github.com>

On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> Richard Reingruber 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 8327990_jfr_enters_vm_without_wxwrite
>  - Set WXWrite at more locations
>  - Switch to WXWrite before entering the vm

+1

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18238#pullrequestreview-1947160377

From tholenstein at openjdk.org  Tue Mar 19 19:52:24 2024
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Tue, 19 Mar 2024 19:52:24 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
Message-ID: <ftcYWdJQj8qlvPNk15ACGRER838_cFozDhE_pOJQkY0=.4e3d229b-d91a-4e77-98f8-bb20f44485da@github.com>

On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> Richard Reingruber 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 8327990_jfr_enters_vm_without_wxwrite
>  - Set WXWrite at more locations
>  - Switch to WXWrite before entering the vm

Marked as reviewed by tholenstein (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18238#pullrequestreview-1947241693

From cjplummer at openjdk.org  Tue Mar 19 20:18:21 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 19 Mar 2024 20:18:21 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <jAkqK-yX78T-P8APCvhYotdq8bac1MvhKb5oyHGCJL0=.61e1d46c-16ce-4de0-bc77-11b297f8fe0a@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
 <cclVVJAdx2okigLogb54UwQFqftlB6mDoUKF2ywsayI=.8d852c1d-7f05-4282-a3da-b1fa61d79bd3@github.com>
 <bM4Dhx26HysYBSIRfuOCIyfw5xF8U1QMrWVTcth0hag=.46c6c5ee-01ce-4026-8e17-25601ffc71b9@github.com>
 <FvCroqWSCUjLkithoBxwqUm4A3Rx0VXqnd3DJS3Qrz0=.bd438a8e-895b-4bd5-8713-4a91c4e33d30@github.com>
 <jAkqK-yX78T-P8APCvhYotdq8bac1MvhKb5oyHGCJL0=.61e1d46c-16ce-4de0-bc77-11b297f8fe0a@github.com>
Message-ID: <RL6oDDvrgNU5CCeBeXu7HpAmcDZ5xWNr57iFmFwNDIw=.24abe921-cf1e-4852-98a8-8c661e94be5e@github.com>

On Tue, 19 Mar 2024 10:16:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> If -XX:HeapDumpPath is specified, then it is used as the default
>> 
>> No, the filename set with jcmd GC:heamp_dump  filename   has priority. So we should better keep the current description.
>
> So should I also use  HeapDumpGzipLevel  the same way as HeapDumpPath ? Tehn we have to change the text in globals.hpp for HeapDumpGzipLevel as well because it mentions only the HeapDumpOnOutOfmemoryError case and not the jcmd case .

I actually mentioned  HeapDumpGzipLevel as another reason not to make this change. I'm still not seeing it's value relative to the documentation headaches it causes.

@ansteiner commented that:

> This is really helpful from a support point of view.

I'd like to understand how. It seems to me that the person using the jcmd has a lot more interest in where the file ends up than the person launching the JVM, and can always specify the location with the jcmd. It seems odd to me that the jcmd user would want to rely on HeapDumpPath when they can just specify the path with the jcmd and know for sure where the file is going to end up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1531043688

From aph at openjdk.org  Tue Mar 19 20:30:27 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 19 Mar 2024 20:30:27 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <RksaTC6r-ek8MxJ2DIO784aFm8xXTXyH7lwcK7NDMpg=.bf9eb6ca-1cf7-4362-be6d-5e46e456c11f@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
 <MyWe_C1tm3mmd2HXbXRgD9uSmcyDDPgAnHPYzXwvUjM=.d2ee7f68-565f-48b6-bd7b-502d1d5e15e3@github.com>
 <CCeQsgzwpOyX8ZZdrDgEQneZ5lvoTeqdCRb8NMtocec=.5cc04bc3-f430-4ee6-802d-5e1e5d09edf6@github.com>
 <StQc31_tIsFoNjJbswd3pLgr9UB4OYkyZ0DB1i3Mm8s=.03849f7f-9cb1-47c1-92b2-59b4aa0361b1@github.com>
 <RksaTC6r-ek8MxJ2DIO784aFm8xXTXyH7lwcK7NDMpg=.bf9eb6ca-1cf7-4362-be6d-5e46e456c11f@github.com>
Message-ID: <NkAh08zgxrwn4KOSf4zk_XQW3SGZRzwA7lDQC8b2lRU=.1ac93ce4-fceb-47a9-811f-007aa966e77e@github.com>

On Tue, 19 Mar 2024 15:17:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > Not necessarily. It may well remove some transitions from paths that don't need it, but if you move the state change too low down the call chain you could end up transitioning much more often in code that does need it e.g. if a transitioning method is called in a loop.
> 
> Not if you do the switching lazily. The first iteration would switch to the needed state; subsequent iterations would not do anything since the state already matches. Unless you interleave writes and execs, but then you would need the state changes anyway.

Exactly. You do the transition when it's needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2008070652

From aph at openjdk.org  Tue Mar 19 20:30:26 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 19 Mar 2024 20:30:26 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
Message-ID: <m1CKAL5c6HtcDNLaRxXCQNV3pBjX-82SO7jiUDtKzGg=.52610068-318e-4c74-ab52-f00933a6e9a1@github.com>

On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> Richard Reingruber 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 8327990_jfr_enters_vm_without_wxwrite
>  - Set WXWrite at more locations
>  - Switch to WXWrite before entering the vm

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18238#pullrequestreview-1947320660

From cjplummer at openjdk.org  Tue Mar 19 20:48:21 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 19 Mar 2024 20:48:21 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <nlolcYKw5yGOf3Uiv_zn6XDt5ZArj4m0ngBt7HvnJR8=.055f5553-2b89-4e7a-911e-b9090825dc52@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

>  There were few tests which still execute using othervm mode. They require some specific classpath/settings.

Which ones? They are hard to find among the 2000+ files changed.

test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java line 757:

> 755:         }
> 756: 
> 757:         if (classPath != null && !vmArgs.contains("-cp") && !vmArgs.contains("-classpath")) {

How does this change relate to using driver instead of othervm?

test/hotspot/jtreg/vmTestbase/nsk/share/jdi/ClassExclusionFilterTest.java line 43:

> 41:         if (result != 0) {
> 42:             throw new RuntimeException("TEST FAILED with result " + result);
> 43:         }

Why do we have tests under jdi/share?

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-2008097455
PR Review Comment: https://git.openjdk.org/jdk/pull/18174#discussion_r1531083329
PR Review Comment: https://git.openjdk.org/jdk/pull/18174#discussion_r1531084477

From lmesnik at openjdk.org  Tue Mar 19 21:05:22 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Mar 2024 21:05:22 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <Her_PLBydnIc2NMvW55rlqgMt8NxIf63Dj4dL_4MvCE=.6a04bec2-f360-4348-be32-8de93cdd03f9@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

There are othervm/native tests. I am not sure if they could be just converted.
MonitorContendedEnteredRequest/addClassFilter_ClassName/TestDescription.java:64: * @run main/othervm/native
MonitorContendedEnteredRequest/MonitorContendedEnteredRequest001/TestDescription.java:54: * @run main/othervm/native
MonitorContendedEnteredRequest/MonitorContendedEnteredRequest002/TestDescription.java:54: * @run main/othervm/native
MonitorContendedEnteredRequest/addClassFilter_ReferenceType/TestDescription.java:62: * @run main/othervm/native
MonitorContendedEnteredRequest/addClassExclusionFilter/TestDescription.java:63: * @run main/othervm/native
MonitorContendedEnteredRequest/addInstanceFilter/TestDescription.java:63: * @run main/othervm/native
MonitorContendedEnteredRequest/addThreadFilter/TestDescription.java:63: * @run main/othervm/native
MonitorContendedEnterRequest/addClassFilter_ClassName/TestDescription.java:64: * @run main/othervm/native
MonitorContendedEnterRequest/addClassFilter_ReferenceType/TestDescription.java:62: * @run main/othervm/native
MonitorContendedEnterRequest/MonitorContendedEnterRequest001/TestDescription.java:54: * @run main/othervm/native
MonitorContendedEnterRequest/addClassExclusionFilter/TestDescription.java:63: * @run main/othervm/native
MonitorContendedEnterRequest/addInstanceFilter/TestDescription.java:63: * @run main/othervm/native
MonitorContendedEnterRequest/addThreadFilter/TestDescription.java:65: * @run main/othervm/native
MonitorContendedEnterRequest/MonitorContendedEnterRequest002/TestDescription.java:54: * @run main/othervm/native
MethodExitEvent/returnValue/returnValue004/returnValue004.java:50: * @run main/othervm/native
ThreadReference/forceEarlyReturn/forceEarlyReturn005/forceEarlyReturn005.java:54: * @run main/othervm/native
ThreadReference/forceEarlyReturn/forceEarlyReturn004/forceEarlyReturn004.java:42: * @run main/othervm/native
ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames004/ownedMonitorsAndFrames004.java:48: * @run main/othervm/native
ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames009/ownedMonitorsAndFrames009.java:47: * @run main/othervm/native
ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames002/ownedMonitorsAndFrames002.java:52: * @run main/othervm/native
ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames007/ownedMonitorsAndFrames007.java:54: * @run main/othervm/native
ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames008/TestDescription.java:57: * @run main/othervm/native
ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames006/ownedMonitorsAndFrames006.java:51: * @run main/othervm/native
ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames003/ownedMonitorsAndFrames003.java:51: * @run main/othervm/native
ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames005/ownedMonitorsAndFrames005.java:48: * @run main/othervm/native
ReferenceType/instances/instances001/instances001.java:62: * @run main/othervm/native
ReferenceType/instances/instances004/TestDescription.java:49: * @run main/othervm/native
ReferenceType/instances/instances002/instances002.java:44: * @run main/othervm/native
ReferenceType/instances/instances005/instances005.java:44: * @run main/othervm/native
ReferenceType/instances/instances003/instances003.java:48: * @run main/othervm/native
ObjectReference/referringObjects/referringObjects003/referringObjects003.java:60: * @run main/othervm/native
ObjectReference/referringObjects/referringObjects002/referringObjects002.java:61: * @run main/othervm/native
ObjectReference/referringObjects/referringObjects001/referringObjects001.java:60: * @run main/othervm/native
ObjectReference/referringObjects/referringObjects004/referringObjects004.java:44: * @run main/othervm/native
stress/MonitorEvents/MonitorEvents001/TestDescription.java:62: * @run main/othervm/native
stress/MonitorEvents/MonitorEvents002/TestDescription.java:62: * @run main/othervm/native
stress/serial/ownedMonitorsAndFrames002/TestDescription.java:61: * @run main/othervm/native
stress/serial/mixed001/TestDescription.java:68: * @run main/othervm/native
stress/serial/monitorEvents002/TestDescription.java:58: * @run main/othervm/native
stress/serial/ownedMonitorsAndFrames001/TestDescription.java:57: * @run main/othervm/native
stress/serial/mixed002/TestDescription.java:66: * @run main/othervm/native
stress/serial/monitorEvents001/TestDescription.java:56: * @run main/othervm/native
stress/serial/heapwalking002/TestDescription.java:60: * @run main/othervm/native
stress/serial/heapwalking001/TestDescription.java:58: * @run main/othervm/native
stress/serial/forceEarlyReturn002/TestDescription.java:66: * @run main/othervm/native
stress/serial/forceEarlyReturn001/TestDescription.java:64: * @run main/othervm/native
VirtualMachine/instanceCounts/instancecounts002/TestDescription.java:51: * @run main/othervm/native
VirtualMachine/instanceCounts/instancecounts001/instancecounts001.java:50: * @run main/othervm/native

and a bunch of tests for launching/connecting. 
They customized connection.
VirtualMachineManager/createVirtualMachine/createVM004/TestDescription.java:52: * @run main/othervm
VirtualMachineManager/createVirtualMachine/createVM003/TestDescription.java:51: * @run main/othervm
VirtualMachineManager/createVirtualMachine/createVM005/TestDescription.java:51: * @run main/othervm
ListeningConnector/accept/accept002/TestDescription.java:48: * @run main/othervm
ListeningConnector/accept/accept001/TestDescription.java:48: * @run main/othervm
ListeningConnector/startListening/startlis001/TestDescription.java:55: * @run main/othervm
ListeningConnector/startListening/startlis002/TestDescription.java:57: * @run main/othervm
ListeningConnector/listennosuspend/listennosuspend001/TestDescription.java:42: * @run main/othervm
AttachingConnector/attachnosuspend/attachnosuspend001/TestDescription.java:45: * @run main/othervm
AttachingConnector/attach/attach002/TestDescription.java:52: * @run main/othervm
AttachingConnector/attach/attach001/TestDescription.java:50: * @run main/othervm
PlugConnectors/AttachConnector/plugAttachConnect002/plugAttachConnect002.java:68: * @run main/othervm
PlugConnectors/AttachConnector/plugAttachConnect003/plugAttachConnect003.java:53: * @run main/othervm
PlugConnectors/AttachConnector/plugAttachConnect001/plugAttachConnect001.java:60: * @run main/othervm
PlugConnectors/ListenConnector/plugListenConnect002/plugListenConnect002.java:68: * @run main/othervm
PlugConnectors/ListenConnector/plugListenConnect001/plugListenConnect001.java:60: * @run main/othervm
PlugConnectors/ListenConnector/plugListenConnect003/plugListenConnect003.java:53: * @run main/othervm
PlugConnectors/LaunchConnector/plugLaunchConnect003/plugLaunchConnect003.java:53: * @run main/othervm
PlugConnectors/LaunchConnector/plugLaunchConnect002/plugLaunchConnect002.java:68: * @run main/othervm
PlugConnectors/LaunchConnector/plugLaunchConnect001/plugLaunchConnect001.java:60: * @run main/othervm
PlugConnectors/MultiConnectors/plugMultiConnect006/plugMultiConnect006.java:111: * @run main/othervm
PlugConnectors/MultiConnectors/plugMultiConnect003/plugMultiConnect003.java:89: * @run main/othervm
PlugConnectors/MultiConnectors/plugMultiConnect002/plugMultiConnect002.java:83: * @run main/othervm
PlugConnectors/MultiConnectors/plugMultiConnect004/plugMultiConnect004.java:98: * @run main/othervm
PlugConnectors/MultiConnectors/plugMultiConnect005/plugMultiConnect005.java:99: * @run main/othervm
PlugConnectors/MultiConnectors/plugMultiConnect001/plugMultiConnect001.java:71: * @run main/othervm
PlugConnectors/TransportService/transportService001/transportService001.java:77: * @run main/othervm
PlugConnectors/TransportService/transportService003/transportService003.java:54: * @run main/othervm
PlugConnectors/TransportService/transportService002/transportService002.java:77: * @run main/othervm
Argument/value/value003/TestDescription.java:56: * @run main/othervm
Argument/value/value004/TestDescription.java:55: * @run main/othervm
LaunchingConnector/launchnosuspend/launchnosuspend001/TestDescription.java:42: * @run main/othervm
LaunchingConnector/launch/launch002/TestDescription.java:50: * @run main/othervm
LaunchingConnector/launch/launch001/TestDescription.java:50: * @run main/othervm
LaunchingConnector/launch/launch004/TestDescription.java:50: * @run main/othervm
LaunchingConnector/launch/launch003/TestDescription.java:50: * @run main/othervm

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-2008130095

From lmesnik at openjdk.org  Tue Mar 19 21:16:20 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Mar 2024 21:16:20 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <nlolcYKw5yGOf3Uiv_zn6XDt5ZArj4m0ngBt7HvnJR8=.055f5553-2b89-4e7a-911e-b9090825dc52@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
 <nlolcYKw5yGOf3Uiv_zn6XDt5ZArj4m0ngBt7HvnJR8=.055f5553-2b89-4e7a-911e-b9090825dc52@github.com>
Message-ID: <361djHGx-MLejdMF4165cT7pXzXJvyYZ7s78i0PV3o4=.41f2a84e-6e66-4044-bdbb-c4d0c76b3272@github.com>

On Tue, 19 Mar 2024 20:42:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reverted failing tests.
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jdi/ClassExclusionFilterTest.java line 43:
> 
>> 41:         if (result != 0) {
>> 42:             throw new RuntimeException("TEST FAILED with result " + result);
>> 43:         }
> 
> Why do we have tests under jdi/share?

It is not a test, but helper class with not the best name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18174#discussion_r1531123676

From cjplummer at openjdk.org  Tue Mar 19 21:22:21 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 19 Mar 2024 21:22:21 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <MqoFP6Z5_vgAJjOe4tcflDwFZr5F4rCIyUp5QCIK8CM=.99808f59-4501-4362-8d2e-62c810dd2851@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

So no changes were made to any of these tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-2008154319

From amenkov at openjdk.org  Tue Mar 19 21:57:38 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 19 Mar 2024 21:57:38 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v5]
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <5z8uk5ctg807Oc5Xx3ybuHBzUErE4I0i6Bd-B0O2Slo=.2da3c652-86fa-405c-99cb-94e707f718ec@github.com>

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> Also annotations can be changed (added/removed) by class redefinition.
> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Updated the fix and the test for multiple annotations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18161/files
  - new: https://git.openjdk.org/jdk/pull/18161/files/671c71e1..9a53d4ca

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

  Stats: 82 lines in 2 files changed: 58 ins; 11 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18161.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18161/head:pull/18161

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

From lmesnik at openjdk.org  Tue Mar 19 22:06:20 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Mar 2024 22:06:20 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <R7k2RD61SBZYdgPTUTRN69HEJgjsfdciwq61YsKUB0E=.d2062d6a-fd8d-4c3e-a688-34c0526773dd@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

They also updated just to throw RuntimeException as other tests.

On Tue, Mar 19, 2024 at 2:20?PM Chris Plummer ***@***.***>
wrote:

> So no changes were made to any of these tests?
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/18174#issuecomment-2008154319>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABOQDW4KAIFB5Q5BLKAROS3YZCTYFAVCNFSM6AAAAABENMXMB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBYGE2TIMZRHE>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/18174#issuecomment-2008214565

From lmesnik at openjdk.org  Tue Mar 19 22:18:21 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Mar 2024 22:18:21 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <nlolcYKw5yGOf3Uiv_zn6XDt5ZArj4m0ngBt7HvnJR8=.055f5553-2b89-4e7a-911e-b9090825dc52@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
 <nlolcYKw5yGOf3Uiv_zn6XDt5ZArj4m0ngBt7HvnJR8=.055f5553-2b89-4e7a-911e-b9090825dc52@github.com>
Message-ID: <Hv1Gp_vo5rVeyzTMmSN5DzFBEKtgQfKVk034bODeHv4=.77eddd80-7c36-47bc-841c-22ce5e2edd70@github.com>

On Tue, 19 Mar 2024 20:41:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reverted failing tests.
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java line 757:
> 
>> 755:         }
>> 756: 
>> 757:         if (classPath != null && !vmArgs.contains("-cp") && !vmArgs.contains("-classpath")) {
> 
> How does this change relate to using driver instead of othervm?

The classpaths are different for tests executed in agentvm and othervm.
As I see from logs jtreg uses CLASSPATH in othervm mode so debugee also inherits it. While agentvm load classed from 'test.class.path'.
It is not harm to use classpath 'test.class.path' in othervm mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18174#discussion_r1531188332

From sspitsyn at openjdk.org  Tue Mar 19 22:48:19 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 19 Mar 2024 22:48:19 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <o-fEK8c9rs0u5ntcCzu3byWuM9grsAvHaIo2E0wxCUI=.47a9f3f8-cea9-410b-9580-f2bca872de0b@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

Looks okay. Is not this fix trivial? :)

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18174#pullrequestreview-1947544867

From dholmes at openjdk.org  Tue Mar 19 22:53:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Mar 2024 22:53:28 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <23RHDqAAB2cUnhC2j-H7g2X2KibSmk2IwKh4EisMfYo=.a6d727da-76c9-42d6-b2df-d2fd192bc229@github.com>
Message-ID: <ZXHqsE9M4BRIEy70lkoMUxfDIkDWpldmop099WV-SW4=.dffc8cd5-eea3-4235-a729-3931c82e67a8@github.com>

On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> Richard Reingruber 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 8327990_jfr_enters_vm_without_wxwrite
>  - Set WXWrite at more locations
>  - Switch to WXWrite before entering the vm

Not ideal but it fixes a real problem.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18238#pullrequestreview-1947550278

From weijun at openjdk.org  Wed Mar 20 01:57:51 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 01:57:51 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v7]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <2WzsZtBsmeZkMUZKZS_4IGdfxGH19xrE88_uzSgRVLg=.1229163e-adb6-418e-be61-7eab69e1ed32@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 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 11 additional commits since the last revision:

 - years and comments
 - Merge branch 'master' into 8296244
 - revert changes to MBeanServerFileAccessController.java
 - Merge branch 'master' into 8296244
 - revert some test changes, spec change for subject
 - fix MBeanServerFileAccessController, more test in SM
 - JMX needs SM
 - Resolve Alan's comments
 - remove exe bits
 - remove x bit
 - ... and 1 more: https://git.openjdk.org/jdk/compare/bb164794...dfa22af0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/80810b54..dfa22af0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=05-06

  Stats: 384142 lines in 1493 files changed: 18191 ins; 81433 del; 284518 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 pchilanomate at openjdk.org  Wed Mar 20 02:33:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 20 Mar 2024 02:33:22 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v2]
In-Reply-To: <LTYU6ijwPPDQ5NWrhMf4vRjKI-KF7Fdzv6KUDlFWllg=.4316e737-6f2d-485d-816a-cd005eb0cb9d@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <LTYU6ijwPPDQ5NWrhMf4vRjKI-KF7Fdzv6KUDlFWllg=.4316e737-6f2d-485d-816a-cd005eb0cb9d@github.com>
Message-ID: <6pArQVrMthR9Lwv2HkGzFhDz3pU28aIb0Vo-PDe6s5w=.89d12945-7151-4554-8897-94af619aec7d@github.com>

On Tue, 19 Mar 2024 00:10:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: correct one comment

Looks good to me.

src/hotspot/share/prims/jvmtiEnv.cpp line 1368:

> 1366:   if (java_thread != nullptr) {
> 1367:     Handle thread_handle(calling_thread, thread_oop);
> 1368:     EscapeBarrier eb(true, calling_thread, java_thread);

I see that now we will execute the EscapeBarrier code for the vthread case too. We actually had to disable that for virtual threads since it doesn't work (8285739 and 8305625). But we only addressed the case when targeting all threads and not the single thread one. We would need to add the same check in EscapeBarrier::deoptimize_objects(int d1, int d2) to skip a thread with mounted continuation.

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

PR Review: https://git.openjdk.org/jdk/pull/18332#pullrequestreview-1947846211
PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1531444319

From sspitsyn at openjdk.org  Wed Mar 20 03:28:20 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Mar 2024 03:28:20 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v5]
In-Reply-To: <5z8uk5ctg807Oc5Xx3ybuHBzUErE4I0i6Bd-B0O2Slo=.2da3c652-86fa-405c-99cb-94e707f718ec@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <5z8uk5ctg807Oc5Xx3ybuHBzUErE4I0i6Bd-B0O2Slo=.2da3c652-86fa-405c-99cb-94e707f718ec@github.com>
Message-ID: <VCKCptx6wI3mjxm7gKMssmvlhIP0UpDafVZyfLf-JDQ=.b2ea1553-6802-4ade-b846-4c0b99c3640a@github.com>

On Tue, 19 Mar 2024 21:57:38 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
>> Also annotations can be changed (added/removed) by class redefinition.
>> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
>> 
>> Testing: 
>> - tier1,tier2,hs-tier5-svc;
>>  - redefineClasses/retransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the fix and the test for multiple annotations

test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 107:

> 105:         newClassBytes = classBytes;
> 106:         fInst.retransformClasses(targetClass);
> 107:         assertTrue(targetClass.getName() + " was not seen by transform()", seenClassBytes != null);

Nit: I guess, the `targetClassName` was intended to be used in place of `targetClass.getName()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1531472856

From sspitsyn at openjdk.org  Wed Mar 20 04:43:20 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Mar 2024 04:43:20 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v5]
In-Reply-To: <VCKCptx6wI3mjxm7gKMssmvlhIP0UpDafVZyfLf-JDQ=.b2ea1553-6802-4ade-b846-4c0b99c3640a@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <5z8uk5ctg807Oc5Xx3ybuHBzUErE4I0i6Bd-B0O2Slo=.2da3c652-86fa-405c-99cb-94e707f718ec@github.com>
 <VCKCptx6wI3mjxm7gKMssmvlhIP0UpDafVZyfLf-JDQ=.b2ea1553-6802-4ade-b846-4c0b99c3640a@github.com>
Message-ID: <Mv8s-vph6Je1aafiGhLRo-lr5etSnQfu_7ERu19xjK8=.a2b11f57-82c6-4d3c-9ab5-5264d88ace26@github.com>

On Wed, 20 Mar 2024 03:25:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated the fix and the test for multiple annotations
>
> test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 107:
> 
>> 105:         newClassBytes = classBytes;
>> 106:         fInst.retransformClasses(targetClass);
>> 107:         assertTrue(targetClass.getName() + " was not seen by transform()", seenClassBytes != null);
> 
> Nit: I guess, the `targetClassName` was intended to be used in place of `targetClass.getName()`.

The `retransform()` method returns an array of bytes. There is also a comment about it at the line 101. But the result has never been checked (please, see lines: 116, 123, 129, 135). This creates some confusion and questions why the return value is needed.
The parameter `null` at lines 123, 129, 135 is also confusing and need some explanation.
As I read the code, the method  `retransform()` is saving the parameter `classBytes` in the `newClassBytes` field. The field `newClassBytes` value is then returned by the `transform()` method.
But the `ClassFileTransformer.html#transform` states this:
`Returns: a well-formed class file buffer (the result of the transform), or null if no transform is performed`.

So that, when the `null` is returned by the `transform()` then it means there was no real transform.
Could you comment on this? Do I miss anything here?

Please, see: [ClassFileTransformer.html#transform](https://docs.oracle.com/en/java/javase/21/docs/api/java.instrument/java/lang/instrument/ClassFileTransformer.html#transform(java.lang.Module,java.lang.ClassLoader,java.lang.String,java.lang.Class,java.security.ProtectionDomain,byte%5B%5D))

Also, the comment at line 122 is not needed at this form:

            // Ensure retransformation does not fail with ClassFormatError.

Sorry, I was not clear when I've asked to add a comment at this point. I wanted a clarification about what does passing the `null` mean in terms of transformation.
My understanding is that there is no real transformation when the `null` is returned but the `Instrumentation` mechanism is still working and can fail and we want to test/verify it.  So, passing a Null-transformer is enough for our testing. Is it correct?
Please, keep in mind that few people have some knowledge about the re-transformation details and would appreciate any clarification here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1531502998

From sspitsyn at openjdk.org  Wed Mar 20 08:14:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Mar 2024 08:14:22 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v2]
In-Reply-To: <6pArQVrMthR9Lwv2HkGzFhDz3pU28aIb0Vo-PDe6s5w=.89d12945-7151-4554-8897-94af619aec7d@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <LTYU6ijwPPDQ5NWrhMf4vRjKI-KF7Fdzv6KUDlFWllg=.4316e737-6f2d-485d-816a-cd005eb0cb9d@github.com>
 <6pArQVrMthR9Lwv2HkGzFhDz3pU28aIb0Vo-PDe6s5w=.89d12945-7151-4554-8897-94af619aec7d@github.com>
Message-ID: <FFKdtzFYDhKKr3pSdHN1pb1HvtwGyAm16QHZRD0c2Dg=.a609c071-e1e8-4031-ba85-ad57f835c7a5@github.com>

On Wed, 20 Mar 2024 02:10:28 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: correct one comment
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 1368:
> 
>> 1366:   if (java_thread != nullptr) {
>> 1367:     Handle thread_handle(calling_thread, thread_oop);
>> 1368:     EscapeBarrier eb(true, calling_thread, java_thread);
> 
> I see that now we will execute the EscapeBarrier code for the vthread case too. We actually had to disable that for virtual threads since it doesn't work (8285739 and 8305625). But we only addressed the case when targeting all threads and not the single thread one. We would need to add the same check in EscapeBarrier::deoptimize_objects(int d1, int d2) to skip a thread with mounted continuation.

Good suggestion, thanks!
Would the following fix work ? :


git diff
diff --git a/src/hotspot/share/runtime/escapeBarrier.cpp b/src/hotspot/share/runtime/escapeBarrier.cpp
index bc01d900285..1b6d57644dc 100644
--- a/src/hotspot/share/runtime/escapeBarrier.cpp
+++ b/src/hotspot/share/runtime/escapeBarrier.cpp
@@ -75,7 +75,7 @@ bool EscapeBarrier::deoptimize_objects(int d1, int d2) {
     // These frames are about to be removed. We must not interfere with that and signal failure.
     return false;
   }
-  if (deoptee_thread()->has_last_Java_frame()) {
+  if (deoptee_thread()->has_last_Java_frame() && deoptee_thread()->last_continuation() == nullptr) {
     assert(calling_thread() == Thread::current(), "should be");
     KeepStackGCProcessedMark ksgcpm(deoptee_thread());
     ResourceMark rm(calling_thread());


BTW, it seems the `PopFrame` and the `ForceEarlyReturn<RetType>` are broken the same way and, I hope, the fix above should solve the issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1531653123

From sspitsyn at openjdk.org  Wed Mar 20 08:53:49 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Mar 2024 08:53:49 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v3]
In-Reply-To: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
Message-ID: <ZcV5q2zBKKswKtIVWIPlNJrGGq2UoutTMS8tzyPMFdA=.c0d96d35-9ee4-4f18-b67e-f13859b15392@github.com>

> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

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

 - Merge
 - review: correct one comment
 - added a couple of more fields to the JvmtiUnifiedHaandshakeClosure
 - 8328285: GetOwnedMonitorInfo functions should use JvmtiHandshake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18332/files
  - new: https://git.openjdk.org/jdk/pull/18332/files/78b7c894..ebbf0a0f

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

  Stats: 294199 lines in 471 files changed: 6301 ins; 5813 del; 282085 mod
  Patch: https://git.openjdk.org/jdk/pull/18332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18332/head:pull/18332

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

From asteiner at openjdk.org  Wed Mar 20 09:08:21 2024
From: asteiner at openjdk.org (Andreas Steiner)
Date: Wed, 20 Mar 2024 09:08:21 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <RL6oDDvrgNU5CCeBeXu7HpAmcDZ5xWNr57iFmFwNDIw=.24abe921-cf1e-4852-98a8-8c661e94be5e@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
 <cclVVJAdx2okigLogb54UwQFqftlB6mDoUKF2ywsayI=.8d852c1d-7f05-4282-a3da-b1fa61d79bd3@github.com>
 <bM4Dhx26HysYBSIRfuOCIyfw5xF8U1QMrWVTcth0hag=.46c6c5ee-01ce-4026-8e17-25601ffc71b9@github.com>
 <FvCroqWSCUjLkithoBxwqUm4A3Rx0VXqnd3DJS3Qrz0=.bd438a8e-895b-4bd5-8713-4a91c4e33d30@github.com>
 <jAkqK-yX78T-P8APCvhYotdq8bac1MvhKb5oyHGCJL0=.61e1d46c-16ce-4de0-bc77-11b297f8fe0a@github.com>
 <RL6oDDvrgNU5CCeBeXu7HpAmcDZ5xWNr57iFmFwNDIw=.24abe921-cf1e-4852-98a8-8c661e94be5e@github.com>
Message-ID: <2_jSaAQuaJ5wj_f2Vq9Yn1ENJFWq_6F-ybcf_Sisbbc=.fb95129d-367a-42b3-854b-bbcf1aa22cd8@github.com>

On Tue, 19 Mar 2024 20:15:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> So should I also use  HeapDumpGzipLevel  the same way as HeapDumpPath ? Tehn we have to change the text in globals.hpp for HeapDumpGzipLevel as well because it mentions only the HeapDumpOnOutOfmemoryError case and not the jcmd case .
>
> I actually mentioned  HeapDumpGzipLevel as another reason not to make this change. I'm still not seeing it's value relative to the documentation headaches it causes.
> 
> @ansteiner commented that:
> 
>> This is really helpful from a support point of view.
> 
> I'd like to understand how. It seems to me that the person using the jcmd has a lot more interest in where the file ends up than the person launching the JVM, and can always specify the location with the jcmd. It seems odd to me that the jcmd user would want to rely on HeapDumpPath when they can just specify the path with the jcmd and know for sure where the file is going to end up.

In a cloud environment using containers, the HeapDumpPath is automatically set to a file system service to persist the heapdump. However, if a support engineer or DevOps detects high or increasing memory usage and wants to trigger a heapdump via jcmd, they would need to specify the filename. This requires retrieving the set HeapDumpPath from the app environment and copying it to the jcmd to use the persistent file system. This change can help avoid the need for an additional copy and paste step, which is prone to errors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1531715298

From shade at openjdk.org  Wed Mar 20 09:57:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 20 Mar 2024 09:57:39 GMT
Subject: RFR: 8328592: hprof tests fail with -XX:-CompactStrings
Message-ID: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>

See the bug for symptoms. The tests are failing because hprof test library is confused about non-compact strings.

Additional testing:
 - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now pass
 - [x]  `serviceability/HeapDump lib-test:all` with `-XX:+CompactStrings` still pass

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

Commit messages:
 - Fix

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

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

From egahlin at openjdk.org  Wed Mar 20 10:27:22 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 20 Mar 2024 10:27:22 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <E9ekmv_5nb6r5rq1GBtSGAtKe8odMuOy153p42a3kzQ=.20d60bba-892c-4566-8323-8a25e10891d8@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

Speaking for JFR, we should probably just create a normal file, possibly with a filename to indicate subtest and iteration. That said, test changes for JFR looks fine, and fixing the filename is outside the scope of this bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2009218768

From kevin.walls at oracle.com  Wed Mar 20 10:52:35 2024
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 20 Mar 2024 10:52:35 +0000
Subject: RFD: Remove Hotspot-internal MBeans from sun.management
In-Reply-To: <2bc6ef91-eb5e-47e5-a028-d0596cf1fdd4@oracle.com>
References: <CA+pBWhv52Sw2E4z5d0xs+h7nWS4asSWgoe4Ke5CftNy2zAqznQ@mail.gmail.com>
 <2bc6ef91-eb5e-47e5-a028-d0596cf1fdd4@oracle.com>
Message-ID: <SN7PR10MB703249BB36C4D7004554529B97332@SN7PR10MB7032.namprd10.prod.outlook.com>


Yes, I looked into it a little since you raised the previous issue, that looks like the right direction.
HotspotInternalMBean should be removed (an undocumented, unsupported and experimental interface)

HotspotInternalMBean creates: sun.management?.
HotspotClassLoading
HotspotMemory
HotspotRuntime
HotspotThread
HotspotCompilation

These have a peculiar way of accessing that we do not document as far as I can see.

It would be good to look at whether anything in there is not adequately available by other MBeans, or jstat, or any other mechanism.

Thanks
Kevin


From: Mandy Chung <mandy.chung at oracle.com>
Sent: 19 March 2024 16:48
To: Eirik Bj?rsn?s <eirbjo at gmail.com>; serviceability-dev at openjdk.org
Cc: Volker Simonis <volker.simonis at gmail.com>; Kevin Walls <kevin.walls at oracle.com>; Alan Bateman <alan.bateman at oracle.com>
Subject: Re: RFD: Remove Hotspot-internal MBeans from sun.management


Would a PR to remove these APIs be welcome?

Good with me.

Mandy
On 3/19/24 9:41 AM, Eirik Bj?rsn?s wrote:

Hi,

Last September, Volker shared the observation that we have Hotspot-internal MBeans in sun.management which are strongly encapsulated and not used internally by OpenJDK besides their unit tests:

https://www.mail-archive.com/core-libs-dev at openjdk.org/msg19878.html<https://urldefense.com/v3/__https:/www.mail-archive.com/core-libs-dev at openjdk.org/msg19878.html__;!!ACWV5N9M2RV99hQ!KfW2PiXn5Gb38tJmxUNxLW_fhwy1H7NijeBmgeWH0ZWNw6QriJmDY_ZD5miuxMQq9q0Rl_k6ZOdb-b0$>

A summary of the email thread:

Mandy pointed out:

We added these HotSpot internal MBeans in JDK 5 to expose the internal metrics.  Most of these internal metrics are exposed via jstat tool too.   We didn't receive much feedback regarding these HotSpot internal MBeans.    Removing them is fine and good cleanup effort.

Alan made a similar point:

It's left over from experiments on exposing some internal metrics, I think during JDK 5. It's code that should probably have been removed a long time ago.

Kirk P raised a concern:

It would be a shame to lose these metrics because many of them have been very
useful over time and some would be even more useful with some modifications.

To which Mandy responded:

What we're referring to is to remove sun.management.Hotspot*, the internal MBeans which are never exposed and registered in the platform MBeanServer.   The internal metrics in HotSpot VM should be retained as they are exposed through other ways like jstat, GC logs, etc.

The email thread seems to have ended here without further action taken.

My interpretation of the above is that we have a consensus that these Hotspot-internal MBeans can be removed. Since I was not part of the initial discussion and some time has passed, I'd like some confirmation that my interpretation is correct.

Would a PR to remove these APIs be welcome?

(This would remove HotspotInternalMBean, HotspotMemoryMBean, HotspotRuntimeMBean, HotspotThreadMBean, with associated implementation, factory methods, tests and probably also some native code in libmanagement. Details can be discussed in a PR)

Cheers,
Eirik.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240320/59235a21/attachment-0001.htm>

From rrich at openjdk.org  Wed Mar 20 13:55:22 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 20 Mar 2024 13:55:22 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v3]
In-Reply-To: <6SKAa4aj0VpZeAKntqNZ_Nr4pQsCp0o3zXsph-0Wa98=.b7be4d1f-465c-4edc-b9f1-1b6589271442@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <LwiFM7Sj36liJgbF9_UEqj2LezKKAE9sb7CNvJPlAF8=.1ccb1252-ded5-41c4-9a24-26c93f855326@github.com>
 <I2vjqPLe4V4ppRKX4MizQ32-fKkQED4WIe0tDVZM7Cc=.bdc04eff-6b5e-4ace-9465-f7c8d70eaa56@github.com>
 <6SKAa4aj0VpZeAKntqNZ_Nr4pQsCp0o3zXsph-0Wa98=.b7be4d1f-465c-4edc-b9f1-1b6589271442@github.com>
Message-ID: <36GRb42wLD9-BacUH8qpyJHrKsuz5aN6WUdg6KwynnI=.c30ca337-98fd-43f4-9cb5-75968a3b265f@github.com>

On Tue, 19 Mar 2024 17:46:31 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> I've asked this myself (after making the change).
>> Being in `WXWrite` mode would be wrong if the thread would execute dynamically generated code. There's not too much happening outside the scope of the `ThreadInVMfromNative` instances. I see jni calls (`GetObjectArrayElement`, `ExceptionOccurred`) and a jvmti call (`RetransformClasses`) but these are safe because the callees enter the vm right away. We even avoid switching to `WXWrite` and back there.
>> So I thought it would be ok to coarsen the WXMode switching.
>> But maybe it's still better to avoid any risk especially since there's likely no performance effect.
>
> Or could the  `ThreadInVMfromNative tvmfn(THREAD);` in `check_exception_and_log` be move out to `JfrJvmtiAgent::retransform_classes`?  And then only use one `ThreadInVMfromNative` in `JfrJvmtiAgent::retransform_classes`

I think this would require hoisting the `ThreadInVMfromNative` out of the loop with the `check_exception_and_log` call but then the thread would be in `_thread_in_vm` when doing the `GetObjectArrayElement` jni call which would be wrong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18238#discussion_r1532121487

From rrich at openjdk.org  Wed Mar 20 14:06:04 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 20 Mar 2024 14:06:04 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v4]
In-Reply-To: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
Message-ID: <iDmirOI7V-FkYwro4dBwJE_5G0-fvdRt-zOMl2LgEdU=.5748d2d5-dfb2-411e-8ebf-e30bda96214a@github.com>

> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
> 
> Testing:
> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
> 
> More tests are pending.

Richard Reingruber 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 branch 'master' into 8327990_jfr_enters_vm_without_wxwrite
 - 2 more locations
 - Merge branch 'master' into 8327990_jfr_enters_vm_without_wxwrite
 - Set WXWrite at more locations
 - Switch to WXWrite before entering the vm

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18238/files
  - new: https://git.openjdk.org/jdk/pull/18238/files/1b4d7606..8239638b

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

  Stats: 6136 lines in 243 files changed: 2379 ins; 2538 del; 1219 mod
  Patch: https://git.openjdk.org/jdk/pull/18238.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18238/head:pull/18238

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

From mdoerr at openjdk.org  Wed Mar 20 14:06:04 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 20 Mar 2024 14:06:04 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v4]
In-Reply-To: <iDmirOI7V-FkYwro4dBwJE_5G0-fvdRt-zOMl2LgEdU=.5748d2d5-dfb2-411e-8ebf-e30bda96214a@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <iDmirOI7V-FkYwro4dBwJE_5G0-fvdRt-zOMl2LgEdU=.5748d2d5-dfb2-411e-8ebf-e30bda96214a@github.com>
Message-ID: <RjcOeCZPFXhAKJfojCO0Zkd5KxdAPqR79WxxU-bPJps=.39b06a56-f8ef-4cd4-800a-e50b0eb22967@github.com>

On Wed, 20 Mar 2024 14:02:23 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This pr changes  `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>> 
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>> 
>> More tests are pending.
>
> Richard Reingruber 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 branch 'master' into 8327990_jfr_enters_vm_without_wxwrite
>  - 2 more locations
>  - Merge branch 'master' into 8327990_jfr_enters_vm_without_wxwrite
>  - Set WXWrite at more locations
>  - Switch to WXWrite before entering the vm

Good catch!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18238#pullrequestreview-1948978584

From weijun at openjdk.org  Wed Mar 20 14:45:50 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 14:45:50 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v8]
In-Reply-To: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
Message-ID: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@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:

  more allow and years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17472/files
  - new: https://git.openjdk.org/jdk/pull/17472/files/dfa22af0..1e6a7982

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17472&range=06-07

  Stats: 9 lines in 6 files changed: 0 ins; 0 del; 9 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 phh at openjdk.org  Wed Mar 20 14:48:20 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 20 Mar 2024 14:48:20 GMT
Subject: RFR: 8328592: hprof tests fail with -XX:-CompactStrings
In-Reply-To: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
References: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
Message-ID: <Z3iFMhkJc_1GrB6l2NB8nFV8s0Wcv10ceFCTEo1MvDI=.42b61616-9729-4701-9400-78fb01943518@github.com>

On Wed, 20 Mar 2024 09:53:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for symptoms. The tests are failing because hprof test library is confused about non-compact strings.
> 
> Additional testing:
>  - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now pass
>  - [x]  `serviceability/HeapDump lib-test:all` with `-XX:+CompactStrings` still pass

Are we guaranteed that non-compact string char component bytes are stored in little-endian order?

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

PR Review: https://git.openjdk.org/jdk/pull/18394#pullrequestreview-1949113961

From weijun at openjdk.org  Wed Mar 20 15:02:25 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 15:02:25 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v8]
In-Reply-To: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
Message-ID: <Lj2dIOon8EcxXTrhY7aevB-F-M6xQvnHHjezGoRkfBU=.c403d499-21ea-4256-a3bd-21f2d3f296f4@github.com>

On Wed, 20 Mar 2024 14:45:50 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more allow and years

There is no source code change to `java.management` anymore inside this PR. They will be resolved with new bugs at [JDK-8327618](https://bugs.openjdk.org/browse/JDK-8327618) and [JDK-8328263](https://bugs.openjdk.org/browse/JDK-8328263). There are test changes in these areas in this PR to force them running with SM allowed. Ideally, these changes can be reverted when the 2 new bugs are resolved.

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

PR Comment: https://git.openjdk.org/jdk/pull/17472#issuecomment-2009779837

From kevin.walls at oracle.com  Wed Mar 20 15:21:36 2024
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 20 Mar 2024 15:21:36 +0000
Subject: RFD: Remove Hotspot-internal MBeans from sun.management
In-Reply-To: <SN7PR10MB703249BB36C4D7004554529B97332@SN7PR10MB7032.namprd10.prod.outlook.com>
References: <CA+pBWhv52Sw2E4z5d0xs+h7nWS4asSWgoe4Ke5CftNy2zAqznQ@mail.gmail.com>
 <2bc6ef91-eb5e-47e5-a028-d0596cf1fdd4@oracle.com>
 <SN7PR10MB703249BB36C4D7004554529B97332@SN7PR10MB7032.namprd10.prod.outlook.com>
Message-ID: <SN7PR10MB7032422A0BAF9947E6252C6697332@SN7PR10MB7032.namprd10.prod.outlook.com>

Hi,

8328618: HotspotInternalMBean should be removed
https://bugs.openjdk.org/browse/JDK-8328618

I looked a bit further and logged this, with notes on what the HotSpotXX MBeans actually do.  It is almost all about providing a Java MBean interface to perf counters. HotspotThread additionally provides thread count and thread CPU usage by ?internal? threads, although the definition of that is maybe unclear.

Thanks
Kevin


From: Kevin Walls
Sent: 20 March 2024 10:53
To: Mandy Chung <mandy.chung at oracle.com>; Eirik Bj?rsn?s <eirbjo at gmail.com>; serviceability-dev at openjdk.org
Cc: Volker Simonis <volker.simonis at gmail.com>; Alan Bateman <alan.bateman at oracle.com>
Subject: RE: RFD: Remove Hotspot-internal MBeans from sun.management


Yes, I looked into it a little since you raised the previous issue, that looks like the right direction.

HotspotInternalMBean should be removed (an undocumented, unsupported and experimental interface)

HotspotInternalMBean creates: sun.management?.
HotspotClassLoading
HotspotMemory
HotspotRuntime
HotspotThread
HotspotCompilation

These have a peculiar way of accessing that we do not document as far as I can see.

It would be good to look at whether anything in there is not adequately available by other MBeans, or jstat, or any other mechanism.

Thanks
Kevin


From: Mandy Chung <mandy.chung at oracle.com<mailto:mandy.chung at oracle.com>>
Sent: 19 March 2024 16:48
To: Eirik Bj?rsn?s <eirbjo at gmail.com<mailto:eirbjo at gmail.com>>; serviceability-dev at openjdk.org<mailto:serviceability-dev at openjdk.org>
Cc: Volker Simonis <volker.simonis at gmail.com<mailto:volker.simonis at gmail.com>>; Kevin Walls <kevin.walls at oracle.com<mailto:kevin.walls at oracle.com>>; Alan Bateman <alan.bateman at oracle.com<mailto:alan.bateman at oracle.com>>
Subject: Re: RFD: Remove Hotspot-internal MBeans from sun.management


Would a PR to remove these APIs be welcome?

Good with me.

Mandy
On 3/19/24 9:41 AM, Eirik Bj?rsn?s wrote:

Hi,

Last September, Volker shared the observation that we have Hotspot-internal MBeans in sun.management which are strongly encapsulated and not used internally by OpenJDK besides their unit tests:

https://www.mail-archive.com/core-libs-dev at openjdk.org/msg19878.html<https://urldefense.com/v3/__https:/www.mail-archive.com/core-libs-dev at openjdk.org/msg19878.html__;!!ACWV5N9M2RV99hQ!KfW2PiXn5Gb38tJmxUNxLW_fhwy1H7NijeBmgeWH0ZWNw6QriJmDY_ZD5miuxMQq9q0Rl_k6ZOdb-b0$>

A summary of the email thread:

Mandy pointed out:

We added these HotSpot internal MBeans in JDK 5 to expose the internal metrics.  Most of these internal metrics are exposed via jstat tool too.   We didn't receive much feedback regarding these HotSpot internal MBeans.    Removing them is fine and good cleanup effort.

Alan made a similar point:

It's left over from experiments on exposing some internal metrics, I think during JDK 5. It's code that should probably have been removed a long time ago.

Kirk P raised a concern:

It would be a shame to lose these metrics because many of them have been very
useful over time and some would be even more useful with some modifications.

To which Mandy responded:

What we're referring to is to remove sun.management.Hotspot*, the internal MBeans which are never exposed and registered in the platform MBeanServer.   The internal metrics in HotSpot VM should be retained as they are exposed through other ways like jstat, GC logs, etc.

The email thread seems to have ended here without further action taken.

My interpretation of the above is that we have a consensus that these Hotspot-internal MBeans can be removed. Since I was not part of the initial discussion and some time has passed, I'd like some confirmation that my interpretation is correct.

Would a PR to remove these APIs be welcome?

(This would remove HotspotInternalMBean, HotspotMemoryMBean, HotspotRuntimeMBean, HotspotThreadMBean, with associated implementation, factory methods, tests and probably also some native code in libmanagement. Details can be discussed in a PR)

Cheers,
Eirik.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240320/b2405f7e/attachment-0001.htm>

From lmesnik at openjdk.org  Wed Mar 20 15:40:19 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Mar 2024 15:40:19 GMT
Subject: RFR: 8328592: hprof tests fail with -XX:-CompactStrings
In-Reply-To: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
References: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
Message-ID: <UgB1whtydBNzZZNt89t9LN_iPlUvvvW9jA_TaOo0H-c=.50d90388-f2ae-46af-b519-34801d1e5c01@github.com>

On Wed, 20 Mar 2024 09:53:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for symptoms. The tests are failing because hprof test library is confused about non-compact strings.
> 
> Additional testing:
>  - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now pass
>  - [x]  `serviceability/HeapDump lib-test:all` with `-XX:+CompactStrings` still pass

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18394#pullrequestreview-1949282694

From pchilanomate at openjdk.org  Wed Mar 20 16:02:20 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 20 Mar 2024 16:02:20 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v2]
In-Reply-To: <FFKdtzFYDhKKr3pSdHN1pb1HvtwGyAm16QHZRD0c2Dg=.a609c071-e1e8-4031-ba85-ad57f835c7a5@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <LTYU6ijwPPDQ5NWrhMf4vRjKI-KF7Fdzv6KUDlFWllg=.4316e737-6f2d-485d-816a-cd005eb0cb9d@github.com>
 <6pArQVrMthR9Lwv2HkGzFhDz3pU28aIb0Vo-PDe6s5w=.89d12945-7151-4554-8897-94af619aec7d@github.com>
 <FFKdtzFYDhKKr3pSdHN1pb1HvtwGyAm16QHZRD0c2Dg=.a609c071-e1e8-4031-ba85-ad57f835c7a5@github.com>
Message-ID: <ZkJYCrEfmHo4ZPt_MXNiiyjSys3CWc6RX_M-YBoeVqk=.4946e9ff-256a-4e10-bfca-18aa1a806804@github.com>

On Wed, 20 Mar 2024 08:12:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnv.cpp line 1368:
>> 
>>> 1366:   if (java_thread != nullptr) {
>>> 1367:     Handle thread_handle(calling_thread, thread_oop);
>>> 1368:     EscapeBarrier eb(true, calling_thread, java_thread);
>> 
>> I see that now we will execute the EscapeBarrier code for the vthread case too. We actually had to disable that for virtual threads since it doesn't work (8285739 and 8305625). But we only addressed the case when targeting all threads and not the single thread one. We would need to add the same check in EscapeBarrier::deoptimize_objects(int d1, int d2) to skip a thread with mounted continuation.
>
> Good suggestion, thanks!
> Would the following fix work ? :
> 
> 
> git diff
> diff --git a/src/hotspot/share/runtime/escapeBarrier.cpp b/src/hotspot/share/runtime/escapeBarrier.cpp
> index bc01d900285..1b6d57644dc 100644
> --- a/src/hotspot/share/runtime/escapeBarrier.cpp
> +++ b/src/hotspot/share/runtime/escapeBarrier.cpp
> @@ -75,7 +75,7 @@ bool EscapeBarrier::deoptimize_objects(int d1, int d2) {
>      // These frames are about to be removed. We must not interfere with that and signal failure.
>      return false;
>    }
> -  if (deoptee_thread()->has_last_Java_frame()) {
> +  if (deoptee_thread()->has_last_Java_frame() && deoptee_thread()->last_continuation() == nullptr) {
>      assert(calling_thread() == Thread::current(), "should be");
>      KeepStackGCProcessedMark ksgcpm(deoptee_thread());
>      ResourceMark rm(calling_thread());
> 
> 
> BTW, it seems the `PopFrame` and the `ForceEarlyReturn<RetType>` are broken the same way and, I hope, the fix above should solve the issue.

Fix looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1532363608

From shade at openjdk.org  Wed Mar 20 17:19:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 20 Mar 2024 17:19:34 GMT
Subject: RFR: 8328592: hprof tests fail with -XX:-CompactStrings [v2]
In-Reply-To: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
References: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
Message-ID: <fPIO0o8-umntxCr06JEDNdL7MZB0OK89lwDO3BD9hSo=.64a2f81e-82ff-4e89-84e5-3cbb600cc3cb@github.com>

> See the bug for symptoms. The tests are failing because hprof test library is confused about non-compact strings.
> 
> Additional testing:
>  - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now pass
>  - [x]  `serviceability/HeapDump lib-test:all` with `-XX:+CompactStrings` still pass

Aleksey Shipilev 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:

 - Handle platform endianness better
 - Merge branch 'master' into JDK-8328592-hprof-compact-strings
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18394/files
  - new: https://git.openjdk.org/jdk/pull/18394/files/5ba1f4b8..f783418d

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

  Stats: 292803 lines in 402 files changed: 5222 ins; 5761 del; 281820 mod
  Patch: https://git.openjdk.org/jdk/pull/18394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18394/head:pull/18394

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

From shade at openjdk.org  Wed Mar 20 17:19:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 20 Mar 2024 17:19:35 GMT
Subject: RFR: 8328592: hprof tests fail with -XX:-CompactStrings [v2]
In-Reply-To: <Z3iFMhkJc_1GrB6l2NB8nFV8s0Wcv10ceFCTEo1MvDI=.42b61616-9729-4701-9400-78fb01943518@github.com>
References: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
 <Z3iFMhkJc_1GrB6l2NB8nFV8s0Wcv10ceFCTEo1MvDI=.42b61616-9729-4701-9400-78fb01943518@github.com>
Message-ID: <MwXT5ZB2c3luRu61TiJlpWCh570vmT8TSawa-wo6DY0=.411125f5-69cd-439a-8f63-f563534fab3c@github.com>

On Wed, 20 Mar 2024 14:46:09 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> Are we guaranteed that non-compact string char component bytes are stored in little-endian order?

No, I don't think we are guaranteed any particular endianness, argh. The new patch follows what `StringUTF16` does: https://github.com/openjdk/jdk/blob/4e83f4cfc779e39cca0070b5729a508aeaa74654/src/java.base/share/classes/java/lang/StringUTF16.java#L1663-L1673

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

PR Comment: https://git.openjdk.org/jdk/pull/18394#issuecomment-2010124301

From mullan at openjdk.org  Wed Mar 20 20:45:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 20 Mar 2024 20:45:21 GMT
Subject: RFR: 8296244: Alternate implementation of user-based authorization
 Subject APIs that =?UTF-8?B?ZG9lc27igJl0?= depend on Security Manager APIs
 [v8]
In-Reply-To: <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
References: <YTs1brMfaCkbG9ucitwKmt41N1yMs7NasPSZXIgS4Tc=.ca8ae639-ee38-4bf6-a649-29128d510596@github.com>
 <vkcpZ7GuZyszsvBJWOy0vTglbPS8SU1Sq78jrs2BvW0=.72ab8a32-714c-43f4-a4ff-0af64f8df5c4@github.com>
Message-ID: <6q9lWdNP10bPYE7_UAGZmKwOGgA4UqHwcZmh4jTsjRI=.7ebc2d0d-a7c3-4f89-948e-bdacaec5f355@github.com>

On Wed, 20 Mar 2024 14:45:50 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.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more allow and years

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17472#pullrequestreview-1950109209

From weijun at openjdk.org  Wed Mar 20 21:28:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 20 Mar 2024 21:28:29 GMT
Subject: Integrated: 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: <sVQNg8PJbPuUovgGQYsvAzGqhH0l7cSKf6bJcrEuN60=.67048ca0-828e-49ce-9deb-d06b727ecc60@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.

This pull request has now been integrated.

Changeset: d32746ef
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d32746ef4a0ce6fec558274244321991be141698
Stats:     622 lines in 17 files changed: 477 ins; 27 del; 118 mod

8296244: Alternate implementation of user-based authorization Subject APIs that doesn?t depend on Security Manager APIs

Reviewed-by: mullan

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

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

From sspitsyn at openjdk.org  Wed Mar 20 21:59:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Mar 2024 21:59:22 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v2]
In-Reply-To: <ZkJYCrEfmHo4ZPt_MXNiiyjSys3CWc6RX_M-YBoeVqk=.4946e9ff-256a-4e10-bfca-18aa1a806804@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <LTYU6ijwPPDQ5NWrhMf4vRjKI-KF7Fdzv6KUDlFWllg=.4316e737-6f2d-485d-816a-cd005eb0cb9d@github.com>
 <6pArQVrMthR9Lwv2HkGzFhDz3pU28aIb0Vo-PDe6s5w=.89d12945-7151-4554-8897-94af619aec7d@github.com>
 <FFKdtzFYDhKKr3pSdHN1pb1HvtwGyAm16QHZRD0c2Dg=.a609c071-e1e8-4031-ba85-ad57f835c7a5@github.com>
 <ZkJYCrEfmHo4ZPt_MXNiiyjSys3CWc6RX_M-YBoeVqk=.4946e9ff-256a-4e10-bfca-18aa1a806804@github.com>
Message-ID: <HgSWKgMgnzwK3-N29HlJxVGHWZxkv774EiJFwc2Do4k=.f4d085c1-ae9e-4906-9a6d-5a72794b190a@github.com>

On Wed, 20 Mar 2024 15:59:34 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Good suggestion, thanks!
>> Would the following fix work ? :
>> 
>> 
>> git diff
>> diff --git a/src/hotspot/share/runtime/escapeBarrier.cpp b/src/hotspot/share/runtime/escapeBarrier.cpp
>> index bc01d900285..1b6d57644dc 100644
>> --- a/src/hotspot/share/runtime/escapeBarrier.cpp
>> +++ b/src/hotspot/share/runtime/escapeBarrier.cpp
>> @@ -75,7 +75,7 @@ bool EscapeBarrier::deoptimize_objects(int d1, int d2) {
>>      // These frames are about to be removed. We must not interfere with that and signal failure.
>>      return false;
>>    }
>> -  if (deoptee_thread()->has_last_Java_frame()) {
>> +  if (deoptee_thread()->has_last_Java_frame() && deoptee_thread()->last_continuation() == nullptr) {
>>      assert(calling_thread() == Thread::current(), "should be");
>>      KeepStackGCProcessedMark ksgcpm(deoptee_thread());
>>      ResourceMark rm(calling_thread());
>> 
>> 
>> BTW, it seems the `PopFrame` and the `ForceEarlyReturn<RetType>` are broken the same way and, I hope, the fix above should solve the issue.
>
> Fix looks good.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1532932393

From sspitsyn at openjdk.org  Wed Mar 20 22:03:30 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Mar 2024 22:03:30 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v4]
In-Reply-To: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
Message-ID: <2cbNK6BXIQuVDhocGrTYCLdHtsrHIs82LVW1oWGXBKg=.0de86729-cc55-425c-b3e1-44152ba29f02@github.com>

> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: work around problem for vthreads in EscapeBarrier::deoptimize_objects

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18332/files
  - new: https://git.openjdk.org/jdk/pull/18332/files/ebbf0a0f..b7380b19

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

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

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

From amenkov at openjdk.org  Wed Mar 20 22:28:47 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 20 Mar 2024 22:28:47 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v6]
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <CQliGNi0tFo4fXWf8bcN3633V9HQHDvrYdOME6D4f-A=.14691a39-aeb9-4abf-9a14-12bbe69f95b3@github.com>

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> Also annotations can be changed (added/removed) by class redefinition.
> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  updated the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18161/files
  - new: https://git.openjdk.org/jdk/pull/18161/files/9a53d4ca..93256d90

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

  Stats: 29 lines in 1 file changed: 16 ins; 7 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18161.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18161/head:pull/18161

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

From amenkov at openjdk.org  Wed Mar 20 22:28:48 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 20 Mar 2024 22:28:48 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v5]
In-Reply-To: <Mv8s-vph6Je1aafiGhLRo-lr5etSnQfu_7ERu19xjK8=.a2b11f57-82c6-4d3c-9ab5-5264d88ace26@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <5z8uk5ctg807Oc5Xx3ybuHBzUErE4I0i6Bd-B0O2Slo=.2da3c652-86fa-405c-99cb-94e707f718ec@github.com>
 <VCKCptx6wI3mjxm7gKMssmvlhIP0UpDafVZyfLf-JDQ=.b2ea1553-6802-4ade-b846-4c0b99c3640a@github.com>
 <Mv8s-vph6Je1aafiGhLRo-lr5etSnQfu_7ERu19xjK8=.a2b11f57-82c6-4d3c-9ab5-5264d88ace26@github.com>
Message-ID: <1VoLl2WmdojWejM2yDm8htYgb28P2L_GnILjG1n_PH4=.115b8696-c3ae-4d00-a637-ef4269aa8248@github.com>

On Wed, 20 Mar 2024 04:40:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 107:
>> 
>>> 105:         newClassBytes = classBytes;
>>> 106:         fInst.retransformClasses(targetClass);
>>> 107:         assertTrue(targetClass.getName() + " was not seen by transform()", seenClassBytes != null);
>> 
>> Nit: I guess, the `targetClassName` was intended to be used in place of `targetClass.getName()`.
>
> The `retransform()` method returns an array of bytes. There is also a comment about it at the line 101. But the result has never been checked (please, see lines: 116, 123, 129, 135). This creates some confusion and questions why the return value is needed.
> The parameter `null` at lines 123, 129, 135 is also confusing and need some explanation.
> As I read the code, the method  `retransform()` is saving the parameter `classBytes` in the `newClassBytes` field. The field `newClassBytes` value is then returned by the `transform()` method.
> But the `ClassFileTransformer.html#transform` states this:
> `Returns: a well-formed class file buffer (the result of the transform), or null if no transform is performed`.
> 
> So that, when the `null` is returned by the `transform()` then it means there was no real transform.
> Could you comment on this? Do I miss anything here?
> 
> Please, see: [ClassFileTransformer.html#transform](https://docs.oracle.com/en/java/javase/21/docs/api/java.instrument/java/lang/instrument/ClassFileTransformer.html#transform(java.lang.Module,java.lang.ClassLoader,java.lang.String,java.lang.Class,java.security.ProtectionDomain,byte%5B%5D))
> 
> Also, the comment at line 122 is not needed at this form:
> 
>             // Ensure retransformation does not fail with ClassFormatError.
> 
> Sorry, I was not clear when I've asked to add a comment at this point. I wanted a clarification about what does passing the `null` mean in terms of transformation. My understanding is that there is no real transformation when the `null` is returned but the `Instrumentation` mechanism is still working (for instance, the `JvmtiClassFileReconstituter` can be involved with an incorrect attributes counter) and can fail and we want to test/verify it.  So, passing a Null-transformer is enough for our testing. Is it correct?
> Please, keep in mind, few people have some knowledge about the re-transformation details and would appreciate any hints here.

Instrumentation.retransformClasses logic can be described by the following pseudo-code:

byte[] newClassBytes = JvmtiClassFileReconstituter.reconstitute(klass);
for (Transformer tr = firstTransformer(); tr != null; tr = tr->next()) {
  byte[] transformerClassBytes = tr.transform(newClassBytes);
  if (newClassBytes != null) {
    newClassBytes = transformerClassBytes;
  }
}

Then newClassBytes is parsed, verified and is used to redefine the class.

We need to verify that JvmtiClassFileReconstituter produces correct class bytes, so test transformer can return null or passed classfileBuffer.
Actually the issue can be reproduced without ClassFileTransformer at all (and this is mentioned in the CR) - in the case reconstituted class bytes is considered as a result of the instrumentation.

I've updated the test, hope it's clearer now.
`targetClassName`/`seenClassBytes`/`newClassBytes` was used by Transformer, I moved them to the class.
Please let me know if you think some additional comments would be useful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1532968774

From lmesnik at openjdk.org  Wed Mar 20 22:44:22 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Mar 2024 22:44:22 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v4]
In-Reply-To: <2cbNK6BXIQuVDhocGrTYCLdHtsrHIs82LVW1oWGXBKg=.0de86729-cc55-425c-b3e1-44152ba29f02@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <2cbNK6BXIQuVDhocGrTYCLdHtsrHIs82LVW1oWGXBKg=.0de86729-cc55-425c-b3e1-44152ba29f02@github.com>
Message-ID: <mWycdle-W8gGbOnXNeC8ourXXYrK1v9eCIjGcE27xb0=.d8959c82-8898-470c-a0a9-e054f36a17b2@github.com>

On Wed, 20 Mar 2024 22:03:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: work around problem for vthreads in EscapeBarrier::deoptimize_objects

src/hotspot/share/prims/jvmtiEnv.cpp line 1366:

> 1364:   }
> 1365: 
> 1366:   if (java_thread != nullptr) {

I am not sure why this check is needed at this level. It is duplication.The GetOwnedMonitorInfoClosure::do_vthread checks if thread is null (no-op for unmounted threads). 
Currently, the unmounted threads can't own monitor. But if it's changed we need to update this check as well as the implementation of handshakes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1532988358

From lmesnik at openjdk.org  Wed Mar 20 22:59:21 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Mar 2024 22:59:21 GMT
Subject: RFR: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
In-Reply-To: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
References: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
Message-ID: <dOH0NARVgPyIvPeQ-TQLjnji-M8k8kuXRCsUAh3YhcU=.a282dab7-922b-476f-842b-de9538a0795d@github.com>

On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.
> 
> If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.
> 
> Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.
> 
> Increasing the timeout and tidying up the handling so we can see the specific reason in future.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18381#pullrequestreview-1950389559

From amenkov at openjdk.org  Thu Mar 21 01:03:20 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 21 Mar 2024 01:03:20 GMT
Subject: RFR: 8328592: hprof tests fail with -XX:-CompactStrings [v2]
In-Reply-To: <fPIO0o8-umntxCr06JEDNdL7MZB0OK89lwDO3BD9hSo=.64a2f81e-82ff-4e89-84e5-3cbb600cc3cb@github.com>
References: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
 <fPIO0o8-umntxCr06JEDNdL7MZB0OK89lwDO3BD9hSo=.64a2f81e-82ff-4e89-84e5-3cbb600cc3cb@github.com>
Message-ID: <9uNcIw2nrNXs7M9i2T_fCms5cLcY64kLKoJt4JycZ3k=.dfd73fa8-9d02-47a2-8bd1-57ba8b43c118@github.com>

On Wed, 20 Mar 2024 17:19:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for symptoms. The tests are failing because hprof test library is confused about non-compact strings.
>> 
>> Additional testing:
>>  - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now pass
>>  - [x]  `serviceability/HeapDump lib-test:all` with `-XX:+CompactStrings` still pass
>
> Aleksey Shipilev 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:
> 
>  - Handle platform endianness better
>  - Merge branch 'master' into JDK-8328592-hprof-compact-strings
>  - Fix

Looks good. Please update copyright years before push

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

Marked as reviewed by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18394#pullrequestreview-1950543888

From sspitsyn at openjdk.org  Thu Mar 21 01:04:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Mar 2024 01:04:22 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v4]
In-Reply-To: <mWycdle-W8gGbOnXNeC8ourXXYrK1v9eCIjGcE27xb0=.d8959c82-8898-470c-a0a9-e054f36a17b2@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <2cbNK6BXIQuVDhocGrTYCLdHtsrHIs82LVW1oWGXBKg=.0de86729-cc55-425c-b3e1-44152ba29f02@github.com>
 <mWycdle-W8gGbOnXNeC8ourXXYrK1v9eCIjGcE27xb0=.d8959c82-8898-470c-a0a9-e054f36a17b2@github.com>
Message-ID: <hA2bWGmFJkqJnpomJtINj4w8MtEX1iOhZx6vISxmRI8=.f2ba5d62-862e-4ab5-8762-6aaa7a36c294@github.com>

On Wed, 20 Mar 2024 22:41:05 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: work around problem for vthreads in EscapeBarrier::deoptimize_objects
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 1366:
> 
>> 1364:   }
>> 1365: 
>> 1366:   if (java_thread != nullptr) {
> 
> I am not sure why this check is needed at this level. It is duplication.The GetOwnedMonitorInfoClosure::do_vthread checks if thread is null (no-op for unmounted threads). 
> Currently, the unmounted threads can't own monitor. But if it's changed we need to update this check as well as the implementation of handshakes.

This is needed to avoid using the `EscapeBarrier` for unmounted virtual threads.
But you are right there is a duplication here - thanks.
The following check can be removed:

+GetOwnedMonitorInfoClosure::do_vthread(Handle target_h) {
+  if (_target_jt == nullptr) {
+    _result = JVMTI_ERROR_NONE;
+    return;
+  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1533109911

From sspitsyn at openjdk.org  Thu Mar 21 01:09:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Mar 2024 01:09:52 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v5]
In-Reply-To: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
Message-ID: <ylz716pgizOPAQbFK7PIrle0uY7NDeX9t5aHuP0xy9A=.cd288052-37f9-4dd2-afad-bd43fd1fc0b7@github.com>

> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: replace redundand check with an assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18332/files
  - new: https://git.openjdk.org/jdk/pull/18332/files/b7380b19..429e696a

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

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

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

From lmesnik at openjdk.org  Thu Mar 21 01:13:21 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 21 Mar 2024 01:13:21 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v5]
In-Reply-To: <ylz716pgizOPAQbFK7PIrle0uY7NDeX9t5aHuP0xy9A=.cd288052-37f9-4dd2-afad-bd43fd1fc0b7@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <ylz716pgizOPAQbFK7PIrle0uY7NDeX9t5aHuP0xy9A=.cd288052-37f9-4dd2-afad-bd43fd1fc0b7@github.com>
Message-ID: <_NGc1wEEnXExWS5H29dLtyE1fbFsS7-D0ViSuFOyZfg=.b3ca08c5-c926-4a32-b6a3-74203324ed41@github.com>

On Thu, 21 Mar 2024 01:09:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: replace redundand check with an assert

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18332#pullrequestreview-1950561720

From lmesnik at openjdk.org  Thu Mar 21 01:13:23 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 21 Mar 2024 01:13:23 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v4]
In-Reply-To: <hA2bWGmFJkqJnpomJtINj4w8MtEX1iOhZx6vISxmRI8=.f2ba5d62-862e-4ab5-8762-6aaa7a36c294@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <2cbNK6BXIQuVDhocGrTYCLdHtsrHIs82LVW1oWGXBKg=.0de86729-cc55-425c-b3e1-44152ba29f02@github.com>
 <mWycdle-W8gGbOnXNeC8ourXXYrK1v9eCIjGcE27xb0=.d8959c82-8898-470c-a0a9-e054f36a17b2@github.com>
 <hA2bWGmFJkqJnpomJtINj4w8MtEX1iOhZx6vISxmRI8=.f2ba5d62-862e-4ab5-8762-6aaa7a36c294@github.com>
Message-ID: <pwNWqDmQFiaWG8ffWf2xk0qauwxM-ukKtJK7Fb9_miU=.e0beeefd-4ca4-4132-b904-34f1d839b509@github.com>

On Thu, 21 Mar 2024 01:01:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnv.cpp line 1366:
>> 
>>> 1364:   }
>>> 1365: 
>>> 1366:   if (java_thread != nullptr) {
>> 
>> I am not sure why this check is needed at this level. It is duplication.The GetOwnedMonitorInfoClosure::do_vthread checks if thread is null (no-op for unmounted threads). 
>> Currently, the unmounted threads can't own monitor. But if it's changed we need to update this check as well as the implementation of handshakes.
>
> This is needed to avoid using the `EscapeBarrier` for unmounted virtual threads.
> But you are right there is a duplication here - thanks.
> The following check can be removed:
> 
> +GetOwnedMonitorInfoClosure::do_vthread(Handle target_h) {
> +  if (_target_jt == nullptr) {
> +    _result = JVMTI_ERROR_NONE;
> +    return;
> +  }
> 
> I've replaced it with an assert:
> 
>   assert(_target_jt != nullptr, "sanity check");

Thanks, that should work!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1533118435

From phh at openjdk.org  Thu Mar 21 03:59:20 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 21 Mar 2024 03:59:20 GMT
Subject: RFR: 8328592: hprof tests fail with -XX:-CompactStrings [v2]
In-Reply-To: <fPIO0o8-umntxCr06JEDNdL7MZB0OK89lwDO3BD9hSo=.64a2f81e-82ff-4e89-84e5-3cbb600cc3cb@github.com>
References: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
 <fPIO0o8-umntxCr06JEDNdL7MZB0OK89lwDO3BD9hSo=.64a2f81e-82ff-4e89-84e5-3cbb600cc3cb@github.com>
Message-ID: <ffAAIzngMtVkizmSCSRwtOq5DTQTU_YtSz-KjoaUZGI=.e63b66f4-7048-4f42-a353-2497c9be14e8@github.com>

On Wed, 20 Mar 2024 17:19:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for symptoms. The tests are failing because hprof test library is confused about non-compact strings.
>> 
>> Additional testing:
>>  - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now pass
>>  - [x]  `serviceability/HeapDump lib-test:all` with `-XX:+CompactStrings` still pass
>
> Aleksey Shipilev 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:
> 
>  - Handle platform endianness better
>  - Merge branch 'master' into JDK-8328592-hprof-compact-strings
>  - Fix

Marked as reviewed by phh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18394#pullrequestreview-1950715132

From sspitsyn at openjdk.org  Thu Mar 21 05:05:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Mar 2024 05:05:22 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v5]
In-Reply-To: <1VoLl2WmdojWejM2yDm8htYgb28P2L_GnILjG1n_PH4=.115b8696-c3ae-4d00-a637-ef4269aa8248@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <5z8uk5ctg807Oc5Xx3ybuHBzUErE4I0i6Bd-B0O2Slo=.2da3c652-86fa-405c-99cb-94e707f718ec@github.com>
 <VCKCptx6wI3mjxm7gKMssmvlhIP0UpDafVZyfLf-JDQ=.b2ea1553-6802-4ade-b846-4c0b99c3640a@github.com>
 <Mv8s-vph6Je1aafiGhLRo-lr5etSnQfu_7ERu19xjK8=.a2b11f57-82c6-4d3c-9ab5-5264d88ace26@github.com>
 <1VoLl2WmdojWejM2yDm8htYgb28P2L_GnILjG1n_PH4=.115b8696-c3ae-4d00-a637-ef4269aa8248@github.com>
Message-ID: <xMYMbXKLFAc_RUy_MVnZyTVrQ0soB8GtN-2NFU_G350=.643127f2-979c-481f-979b-1e1e7219325f@github.com>

On Wed, 20 Mar 2024 22:24:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The `retransform()` method returns an array of bytes. There is also a comment about it at the line 101. But the result has never been checked (please, see lines: 116, 123, 129, 135). This creates some confusion and questions why the return value is needed.
>> The parameter `null` at lines 123, 129, 135 is also confusing and need some explanation.
>> As I read the code, the method  `retransform()` is saving the parameter `classBytes` in the `newClassBytes` field. The field `newClassBytes` value is then returned by the `transform()` method.
>> But the `ClassFileTransformer.html#transform` states this:
>> `Returns: a well-formed class file buffer (the result of the transform), or null if no transform is performed`.
>> 
>> So that, when the `null` is returned by the `transform()` then it means there was no real transform.
>> Could you comment on this? Do I miss anything here?
>> 
>> Please, see: [ClassFileTransformer.html#transform](https://docs.oracle.com/en/java/javase/21/docs/api/java.instrument/java/lang/instrument/ClassFileTransformer.html#transform(java.lang.Module,java.lang.ClassLoader,java.lang.String,java.lang.Class,java.security.ProtectionDomain,byte%5B%5D))
>> 
>> Also, the comment at line 122 is not needed at this form:
>> 
>>             // Ensure retransformation does not fail with ClassFormatError.
>> 
>> Sorry, I was not clear when I've asked to add a comment at this point. I wanted a clarification about what does passing the `null` mean in terms of transformation. My understanding is that there is no real transformation when the `null` is returned but the `Instrumentation` mechanism is still working (for instance, the `JvmtiClassFileReconstituter` can be involved with an incorrect attributes counter) and can fail and we want to test/verify it.  So, passing a Null-transformer is enough for our testing. Is it correct?
>> Please, keep in mind, few people have some knowledge about the re-transformation details and would appreciate any hints here.
>
> Instrumentation.retransformClasses logic can be described by the following pseudo-code:
> 
> byte[] newClassBytes = JvmtiClassFileReconstituter.reconstitute(klass);
> for (Transformer tr = firstTransformer(); tr != null; tr = tr->next()) {
>   byte[] transformerClassBytes = tr.transform(newClassBytes);
>   if (newClassBytes != null) {
>     newClassBytes = transformerClassBytes;
>   }
> }
> 
> Then newClassBytes is parsed, verified and is used to redefine the class.
> 
> We need to verify that JvmtiClassFileReconstituter produces correct class bytes, so test transformer can return null or passed classfileBuffer.
> Actually the issue can be reproduced without ClassFileTransformer at all (and this is mentioned in the CR) - in the case reconstituted class bytes is considered as a result of the instrumentation.
> 
> I've updated the test, hope it's clearer now.
> `targetClassName`/`seenClassBytes`/`newClassBytes` was used by Transformer, I moved them to the class.
> Please let me know if you think some additional comments would be useful.

Thank you for the update, it is a nice change.
I'd also suggest to add a comment before line 115, something like this:

  // Below the null is passed as the classBytes argument which means there won't be any transformation.
  // However, it is enough for testing purposes as the JvmtiClassFileReconstituter still involved
  // into preparation of the initial classfile bytecodes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1533251745

From sspitsyn at openjdk.org  Thu Mar 21 07:16:28 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Mar 2024 07:16:28 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a
 timeout
Message-ID: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>

This PR fixes a synchronization issue in the test:
  `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
  
The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.

The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.

Testing:
 - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5

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

Commit messages:
 - 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout

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

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

From shade at openjdk.org  Thu Mar 21 08:38:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 21 Mar 2024 08:38:34 GMT
Subject: RFR: 8328592: hprof tests fail with -XX:-CompactStrings [v3]
In-Reply-To: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
References: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
Message-ID: <qFHHwSIw--NdDagzImcz9yZnBVvOVGH51XKscXaGhoU=.0bf44aa3-07a7-433d-a90a-2dd90a17eace@github.com>

> See the bug for symptoms. The tests are failing because hprof test library is confused about non-compact strings.
> 
> Additional testing:
>  - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now pass
>  - [x]  `serviceability/HeapDump lib-test:all` with `-XX:+CompactStrings` still pass

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18394/files
  - new: https://git.openjdk.org/jdk/pull/18394/files/f783418d..6c677007

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

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

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

From kevinw at openjdk.org  Thu Mar 21 10:39:21 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 21 Mar 2024 10:39:21 GMT
Subject: RFR: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
In-Reply-To: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
References: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
Message-ID: <0TmxqjJxPO4Ez8v_0tMG_CEgU6mbncMWsQDH6uspGRc=.a5f62d91-1219-4433-bc9e-8c84957e3db4@github.com>

On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.
> 
> If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.
> 
> Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.
> 
> Increasing the timeout and tidying up the handling so we can see the specific reason in future.

Thanks Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/18381#issuecomment-2011885747

From shade at openjdk.org  Thu Mar 21 12:38:24 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 21 Mar 2024 12:38:24 GMT
Subject: RFR: 8328592: hprof tests fail with -XX:-CompactStrings [v3]
In-Reply-To: <qFHHwSIw--NdDagzImcz9yZnBVvOVGH51XKscXaGhoU=.0bf44aa3-07a7-433d-a90a-2dd90a17eace@github.com>
References: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
 <qFHHwSIw--NdDagzImcz9yZnBVvOVGH51XKscXaGhoU=.0bf44aa3-07a7-433d-a90a-2dd90a17eace@github.com>
Message-ID: <El1qUS7N1UEhIntFYIuprRpR-OMbe-yFp9F01u9ft0o=.4fe91181-9fdf-4b26-90dc-0f99bead85e3@github.com>

On Thu, 21 Mar 2024 08:38:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for symptoms. The tests are failing because hprof test library is confused about non-compact strings.
>> 
>> Additional testing:
>>  - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now pass
>>  - [x]  `serviceability/HeapDump lib-test:all` with `-XX:+CompactStrings` still pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

GHA failures look environmental. I am integrating this.

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

PR Comment: https://git.openjdk.org/jdk/pull/18394#issuecomment-2012171842

From shade at openjdk.org  Thu Mar 21 12:38:25 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 21 Mar 2024 12:38:25 GMT
Subject: Integrated: 8328592: hprof tests fail with -XX:-CompactStrings
In-Reply-To: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
References: <ab9-h8vOi3ovioWOqiu7YOV9qRh7zU2K-pyjv41ddbo=.e8c0446f-e4d4-496c-a72e-b9fd38b22134@github.com>
Message-ID: <DIQU5asHiHETaPmUu9Cmi8Q5hpTatsHwf8jukc811fQ=.0ce37695-5d2a-4b5e-892c-4340d8fa044f@github.com>

On Wed, 20 Mar 2024 09:53:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for symptoms. The tests are failing because hprof test library is confused about non-compact strings.
> 
> Additional testing:
>  - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now pass
>  - [x]  `serviceability/HeapDump lib-test:all` with `-XX:+CompactStrings` still pass

This pull request has now been integrated.

Changeset: bb3e84bd
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb3e84bd1fd8217fcb319de8a0716e44359e3423
Stats:     37 lines in 2 files changed: 29 ins; 1 del; 7 mod

8328592: hprof tests fail with -XX:-CompactStrings

Reviewed-by: phh, lmesnik, amenkov

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

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

From pchilanomate at openjdk.org  Thu Mar 21 13:56:20 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 21 Mar 2024 13:56:20 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v5]
In-Reply-To: <ylz716pgizOPAQbFK7PIrle0uY7NDeX9t5aHuP0xy9A=.cd288052-37f9-4dd2-afad-bd43fd1fc0b7@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <ylz716pgizOPAQbFK7PIrle0uY7NDeX9t5aHuP0xy9A=.cd288052-37f9-4dd2-afad-bd43fd1fc0b7@github.com>
Message-ID: <6ziCbagwDerlKMmIfd-_uNk2Jtu2cHbE4ZXmrkNQnh0=.1bea663e-4997-4fa3-a1af-17eefa52db3a@github.com>

On Thu, 21 Mar 2024 01:09:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: replace redundand check with an assert

Looks good to me, thanks Serguei.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18332#pullrequestreview-1952294929

From rrich at openjdk.org  Thu Mar 21 14:12:26 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 21 Mar 2024 14:12:26 GMT
Subject: RFR: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync [v4]
In-Reply-To: <iDmirOI7V-FkYwro4dBwJE_5G0-fvdRt-zOMl2LgEdU=.5748d2d5-dfb2-411e-8ebf-e30bda96214a@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
 <iDmirOI7V-FkYwro4dBwJE_5G0-fvdRt-zOMl2LgEdU=.5748d2d5-dfb2-411e-8ebf-e30bda96214a@github.com>
Message-ID: <JGxLgs-Sk2JBAFX9tyv_2NcjPT_Xh9JtromXbbOHXmo=.ec4b091f-9d0b-4b37-8ffb-931bbd8c4418@github.com>

On Wed, 20 Mar 2024 14:06:04 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Updated (2024-03-20):
>> 
>> This PR adds switching to `WXWrite` mode before entering the vm where it is missing.
>> 
>> With the changes the following jtreg tests succeed with AssertWXAtThreadSync enabled.
>> 
>> * hotspot tier 1-4
>> * jdk tier 1-4
>> * langtools
>> * jaxp
>
> Richard Reingruber 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 branch 'master' into 8327990_jfr_enters_vm_without_wxwrite
>  - 2 more locations
>  - Merge branch 'master' into 8327990_jfr_enters_vm_without_wxwrite
>  - Set WXWrite at more locations
>  - Switch to WXWrite before entering the vm

Tests with AssertWXAtThreadSync are clean now. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2012399791

From rrich at openjdk.org  Thu Mar 21 14:12:27 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 21 Mar 2024 14:12:27 GMT
Subject: Integrated: 8327990: [macosx-aarch64] Various tests fail with
 -XX:+AssertWXAtThreadSync
In-Reply-To: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
References: <r7mkXFMJfbtZpzeq4GJ8xAB4LnYeEL8ODEapy3QRK9g=.b0c68e55-bc54-407d-81bc-cee0f8d02dde@github.com>
Message-ID: <NZ8P0FLYlWsyge6qFgmbOniVOvDteHcQvqvbaQcjKG0=.7806d76e-f58f-4fa7-8e25-de14101b3303@github.com>

On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Updated (2024-03-20):
> 
> This PR adds switching to `WXWrite` mode before entering the vm where it is missing.
> 
> With the changes the following jtreg tests succeed with AssertWXAtThreadSync enabled.
> 
> * hotspot tier 1-4
> * jdk tier 1-4
> * langtools
> * jaxp

This pull request has now been integrated.

Changeset: e41bc42d
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e41bc42deb22615c9b93ee639d04e9ed2bd57f64
Stats:     13 lines in 8 files changed: 11 ins; 0 del; 2 mod

8327990: [macosx-aarch64] Various tests fail with -XX:+AssertWXAtThreadSync

Reviewed-by: dholmes, stuefe, mdoerr, tholenstein, aph

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

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

From jpai at openjdk.org  Thu Mar 21 14:44:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 14:44:20 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java line 57:

> 55: 
> 56:             File flagsFile = File.createTempFile("CheckOriginFlags", null);
> 57:             flagsFile.deleteOnExit();

Hello Bill, jtreg uses a scratch directory when running tests. When a test is launched, the current working directory points to the scratch directory for the test that's currently executing. jtreg manages the lifecycle of scratch directories and even cleans them up (as necessary).
Would it instead be better to just create the temporary file within the jtreg scratch directory (represented by the current working directory)? That way you could just do:


File flagsFile = Files.createTempFile(Path.of("."), "CheckOriginFlags", null).toFile();

and don't need any explicit deletions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534054951

From jpai at openjdk.org  Thu Mar 21 15:05:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 15:05:26 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <-LZotlcsvx3EbHNNn0DO-u7HsWB302dYqZ33vFTf0UA=.9728ca78-a90f-4705-8b81-de5c61d342ca@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/java/nio/channels/unixdomain/Bind.java line 201:

> 199:                 System.out.println("Null server address: " + server.getLocalAddress());
> 200:             } finally {
> 201:                 Files.deleteIfExists(usa.getPath());

`usa` can be `null` here, if it never got assigned due to some exception in the prior lines, which can lead to a `NullPointerException` here.

test/jdk/java/nio/channels/unixdomain/Bind.java line 341:

> 339:                 assertAddress(client.getRemoteAddress(), usa, "server");
> 340:             } finally {
> 341:                 Files.deleteIfExists(usa.getPath());

Same applies here about potential NullPointerException and some other places in other files as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534092806
PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534095046

From jpai at openjdk.org  Thu Mar 21 15:09:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Mar 2024 15:09:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
Message-ID: <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>

On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/java/util/zip/ZipFile/ZeroDate.java line 95:

> 93: 
> 94:         // ensure that the archive is still readable, and the date is 1979-11-30
> 95:         Path path = Utils.createTempFile("out", ".zip");

So it looks like the test library has this utility method which allows to create temporary files within the jtreg scratch directory. Perhaps we should use it then. Having said that, is there a reason why one test method in this test now uses `Files.createTempFile(...)` and this other test method uses `Utils.createTempFile(...)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534105420

From lmesnik at openjdk.org  Thu Mar 21 15:13:22 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 21 Mar 2024 15:13:22 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout
In-Reply-To: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
Message-ID: <_rt5TUvHRuEUb3CdauF_i7iA3ZXYitpmbDFp4jwciCM=.37e2f7dd-8040-4d6e-bad6-0015ff69ac3b@github.com>

On Thu, 21 Mar 2024 07:11:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This PR fixes a synchronization issue in the test:
>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>   
> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
> 
> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
> 
> Testing:
>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/PopFrameTest.java line 148:

> 146:             log("Main #B.2: got expected JVMTI_ERROR_NONE");
> 147:             resumeThread(testTaskThread);
> 148:             ensureAtBreakpoint();

Not sure if it should work. 
Thevariable  `bp_sync_reached` is reset in notifyAtBreakpoint(). 
I see the previous call to  ensureAtBreakpoint(); in line 131. So it means that 
bp_sync_reached is true in this line and never rest after it between 131 and 148.
So I expect that this check in 148 is just return always without waiting anything. So it is not clear for me what is expected here.

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

PR Review: https://git.openjdk.org/jdk/pull/18419#pullrequestreview-1952525795
PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1534110512

From sspitsyn at openjdk.org  Thu Mar 21 16:33:24 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Mar 2024 16:33:24 GMT
Subject: RFR: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake [v5]
In-Reply-To: <ylz716pgizOPAQbFK7PIrle0uY7NDeX9t5aHuP0xy9A=.cd288052-37f9-4dd2-afad-bd43fd1fc0b7@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
 <ylz716pgizOPAQbFK7PIrle0uY7NDeX9t5aHuP0xy9A=.cd288052-37f9-4dd2-afad-bd43fd1fc0b7@github.com>
Message-ID: <QIIldpO6gmlHogHTxJFW-V0na2eeCDD9VCcAO1n-WQ4=.03d85bcb-abbb-4145-b78d-2304d385ee62@github.com>

On Thu, 21 Mar 2024 01:09:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: replace redundand check with an assert

Patricio and Leonid, thank you for prompt review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18332#issuecomment-2012905000

From mbaesken at openjdk.org  Thu Mar 21 16:34:26 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 21 Mar 2024 16:34:26 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
Message-ID: <9E1DTAW3n4W-eZig7TaDnxtlCknuUdIpyo5EaUH_0tk=.20553650-f108-4a4e-b947-6457dd5bae85@github.com>

On Fri, 15 Mar 2024 11:24:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust jcmd manpage, help and globals comment

> In a cloud environment using containers, the HeapDumpPath is automatically set to a file system service to persist the heapdump. However, if a support engineer or DevOps detects high or increasing memory usage and wants to trigger a heapdump via jcmd, they would need to specify the filename. This requires retrieving the set HeapDumpPath from the app environment and copying it to the jcmd to use the persistent file system. This change can help avoid the need for an additional copy and paste step, which is prone to errors.

Hi Andreas , thanks for the details .
Chris, is this understable for you?  We indeed had quite a few user complains by cloud env users, that the HeapDumpPath  is currently not evaluated in the jcmd case/scenario .

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2012910338

From cjplummer at openjdk.org  Thu Mar 21 16:47:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 21 Mar 2024 16:47:23 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <9E1DTAW3n4W-eZig7TaDnxtlCknuUdIpyo5EaUH_0tk=.20553650-f108-4a4e-b947-6457dd5bae85@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
 <9E1DTAW3n4W-eZig7TaDnxtlCknuUdIpyo5EaUH_0tk=.20553650-f108-4a4e-b947-6457dd5bae85@github.com>
Message-ID: <1B_6170Hws8xS66HVrqAzg3fIemaGkU58bKorF0cwgE=.0e58a5a6-12c0-4f1c-b1f0-ccec2ce6ccf3@github.com>

On Thu, 21 Mar 2024 16:32:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Andreas , thanks for the details .
> Chris, is this understable for you? We indeed had quite a few user complains by cloud env users, that the HeapDumpPath is currently not evaluated in the jcmd case/scenario .

I'm still somewhat skeptical about this change and its value. The impact on help/docs and using -XX options in this manner don't sit well with me. I'd like to consult with a couple of people at Oracle who unfortunately are out of town until Monday. Can this PR wait until next week?

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2012958596

From bhuang at openjdk.org  Thu Mar 21 16:54:21 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 16:54:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
 <jzVj_8_7KBhwl_cXG32y34TEMOkUE49Whl0_8ljmek4=.56da910e-15c9-4f80-93f5-bd8bb33794b3@github.com>
Message-ID: <AW72Q2T6TyFJRUkyTjV-eZJdV0KUGZ-YFQa_ZatithQ=.bfd1c59b-1823-4c87-aa5f-5473959f4278@github.com>

On Thu, 21 Mar 2024 14:41:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java line 57:
> 
>> 55: 
>> 56:             File flagsFile = File.createTempFile("CheckOriginFlags", null);
>> 57:             flagsFile.deleteOnExit();
> 
> Hello Bill, jtreg uses a scratch directory when running tests. When a test is launched, the current working directory points to the scratch directory for the test that's currently executing. jtreg manages the lifecycle of scratch directories and even cleans them up (as necessary).
> Would it instead be better to just create the temporary file within the jtreg scratch directory (represented by the current working directory)? That way you could just do:
> 
> 
> File flagsFile = Files.createTempFile(Path.of("."), "CheckOriginFlags", null).toFile();
> 
> and don't need any explicit deletions?

Hi Jaikiran, I think both solutions work for this bug. I personally prefer to place the files in the scratch directory for the ease of debugging. 
In addition, for this specific test, I am considering using File.createTempFile("CheckOriginaFlags", null, Path.of(".").toFile) instead of Files.createTempFile for consistency purposes, as Files.createTempFile may have more restrictive access permissions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534283105

From bhuang at openjdk.org  Thu Mar 21 16:59:20 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 16:59:20 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v2]
In-Reply-To: <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <oWDY_Y3sP51qWbhbA0am0xf-iw9K1iiY0SINr1OF88w=.b52370e1-78b6-4502-a6a4-897435cc5437@github.com>
 <MWEMas3mh2FggdqQSg3vpRsMz266ToFM2VOuYdy11XY=.cc8ab71b-0119-4b97-bae9-73679a3bfc49@github.com>
Message-ID: <5fp1NwbiBibdMUnZA8mIj76MLVvTxdA2m_z9IM8dUEc=.28d46052-8e8d-4ede-96ac-5da5d7a568a9@github.com>

On Thu, 21 Mar 2024 15:06:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments
>
> test/jdk/java/util/zip/ZipFile/ZeroDate.java line 95:
> 
>> 93: 
>> 94:         // ensure that the archive is still readable, and the date is 1979-11-30
>> 95:         Path path = Utils.createTempFile("out", ".zip");
> 
> So it looks like the test library has this utility method which allows to create temporary files within the jtreg scratch directory. Perhaps we should use it then. Having said that, is there a reason why one test method in this test now uses `Files.createTempFile(...)` and this other test method uses `Utils.createTempFile(...)`?

Yes, you are right. We don't need explicit deletion for these files by using this util method, Utils.createTempFile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1534290137

From cjplummer at openjdk.org  Thu Mar 21 17:05:24 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 21 Mar 2024 17:05:24 GMT
Subject: RFR: 8327704: Update nsk/jdi tests to use driver instead of
 othervm [v3]
In-Reply-To: <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
 <qjuBx0-6GzEm8TZOLtBT55CI4IEsXlGku70ng4N3K9U=.48c44d2b-1746-437c-871c-93d077475a67@github.com>
Message-ID: <AKUrFLL2cZWzC2PnpnJZgX075LyOF_mCiXq0_chkJCw=.22b9cbed-4c1c-4798-b97a-11c876d7e66f@github.com>

On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
>> This fix updates tests to run debugger as driver to optimize execution time.
>> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
>> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
>> Tested by running all tests, with '-Xcomp' and virtual thread test factory.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted failing tests.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18174#pullrequestreview-1952843139

From bhuang at openjdk.org  Thu Mar 21 17:13:46 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 21 Mar 2024 17:13:46 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Fixed potential NPE issues.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/620f9259..2517f756

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

  Stats: 11 lines in 4 files changed: 5 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

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

From mullan at openjdk.org  Thu Mar 21 17:46:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Mar 2024 17:46:20 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <H3UoDTth09CIdHaBVX8occDp0THRZY-SI9UrWHnTN0c=.c3e8aaf5-0e94-4599-9862-5a8cdc09f3be@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed potential NPE issues.

The bug should have a `noreg-self` label.

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

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2013158192

From sspitsyn at openjdk.org  Thu Mar 21 17:53:34 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Mar 2024 17:53:34 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v2]
In-Reply-To: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
Message-ID: <o7dvdfkIQM34I4rG74ITc7Wu3pVMjcZyoQkoNx6Ojss=.daabae11-7ee8-40b2-9777-bc6148735eb1@github.com>

> This PR fixes a synchronization issue in the test:
>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>   
> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
> 
> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
> 
> Testing:
>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: updated test with one more call to notifyAtBreakpoint to reset the native state

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18419/files
  - new: https://git.openjdk.org/jdk/pull/18419/files/3ac5c496..7843111d

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

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

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

From sspitsyn at openjdk.org  Thu Mar 21 17:53:34 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Mar 2024 17:53:34 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v2]
In-Reply-To: <_rt5TUvHRuEUb3CdauF_i7iA3ZXYitpmbDFp4jwciCM=.37e2f7dd-8040-4d6e-bad6-0015ff69ac3b@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <_rt5TUvHRuEUb3CdauF_i7iA3ZXYitpmbDFp4jwciCM=.37e2f7dd-8040-4d6e-bad6-0015ff69ac3b@github.com>
Message-ID: <YPKdIfz70QIBiKSaoV0ZwiJ3_Uf8ytZs7h0TKZKj_X0=.7823ee9b-10b7-4c69-bd0e-c7a05aa8da2a@github.com>

On Thu, 21 Mar 2024 15:10:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: updated test with one more call to notifyAtBreakpoint to reset the native state
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/PopFrameTest.java line 148:
> 
>> 146:             log("Main #B.2: got expected JVMTI_ERROR_NONE");
>> 147:             resumeThread(testTaskThread);
>> 148:             ensureAtBreakpoint();
> 
> Not sure if it should work. 
> Thevariable  `bp_sync_reached` is reset in notifyAtBreakpoint(). 
> I see the previous call to  ensureAtBreakpoint(); in line 131. So it means that 
> bp_sync_reached is true in this line and never rest after it between 131 and 148.
> So I expect that this check in 148 is just return always without waiting anything. So it is not clear for me what is expected here.

Nice catch, thanks.
Added one more call to `notifyAtBreakpoint()` to reset the state variable `bp_sync_reached`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1534373208

From amenkov at openjdk.org  Thu Mar 21 18:10:49 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 21 Mar 2024 18:10:49 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v7]
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <nzsfEfEUW-DY4kF1BLvw4-0LE365dhZy89daVZwxxFk=.eae51c5a-766b-4026-9eb4-4ea477e7288a@github.com>

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> Also annotations can be changed (added/removed) by class redefinition.
> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  added comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18161/files
  - new: https://git.openjdk.org/jdk/pull/18161/files/93256d90..84ad8e37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18161&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18161&range=05-06

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

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

From sspitsyn at openjdk.org  Thu Mar 21 19:46:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Mar 2024 19:46:21 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v7]
In-Reply-To: <nzsfEfEUW-DY4kF1BLvw4-0LE365dhZy89daVZwxxFk=.eae51c5a-766b-4026-9eb4-4ea477e7288a@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <nzsfEfEUW-DY4kF1BLvw4-0LE365dhZy89daVZwxxFk=.eae51c5a-766b-4026-9eb4-4ea477e7288a@github.com>
Message-ID: <VOxju-DsXBuUBf7vjdFvTtt1nb1CtDxJeedtdUuAeQ4=.c034b9c2-2b44-4e43-91a5-77d3c722f2b4@github.com>

On Thu, 21 Mar 2024 18:10:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
>> Also annotations can be changed (added/removed) by class redefinition.
>> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
>> 
>> Testing: 
>> - tier1,tier2,hs-tier5-svc;
>>  - redefineClasses/retransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comment

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18161#pullrequestreview-1953245537

From sspitsyn at openjdk.org  Thu Mar 21 19:46:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Mar 2024 19:46:21 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v5]
In-Reply-To: <xMYMbXKLFAc_RUy_MVnZyTVrQ0soB8GtN-2NFU_G350=.643127f2-979c-481f-979b-1e1e7219325f@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <5z8uk5ctg807Oc5Xx3ybuHBzUErE4I0i6Bd-B0O2Slo=.2da3c652-86fa-405c-99cb-94e707f718ec@github.com>
 <VCKCptx6wI3mjxm7gKMssmvlhIP0UpDafVZyfLf-JDQ=.b2ea1553-6802-4ade-b846-4c0b99c3640a@github.com>
 <Mv8s-vph6Je1aafiGhLRo-lr5etSnQfu_7ERu19xjK8=.a2b11f57-82c6-4d3c-9ab5-5264d88ace26@github.com>
 <1VoLl2WmdojWejM2yDm8htYgb28P2L_GnILjG1n_PH4=.115b8696-c3ae-4d00-a637-ef4269aa8248@github.com>
 <xMYMbXKLFAc_RUy_MVnZyTVrQ0soB8GtN-2NFU_G350=.643127f2-979c-481f-979b-1e1e7219325f@github.com>
Message-ID: <u8VebqgfmB9E1G7ff2WL4weXLiTfCS6D1Uys1qL-eUY=.36476d0c-2114-40fa-82fe-39a5b7e63df1@github.com>

On Thu, 21 Mar 2024 05:02:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Instrumentation.retransformClasses logic can be described by the following pseudo-code:
>> 
>> byte[] newClassBytes = JvmtiClassFileReconstituter.reconstitute(klass);
>> for (Transformer tr = firstTransformer(); tr != null; tr = tr->next()) {
>>   byte[] transformerClassBytes = tr.transform(newClassBytes);
>>   if (newClassBytes != null) {
>>     newClassBytes = transformerClassBytes;
>>   }
>> }
>> 
>> Then newClassBytes is parsed, verified and is used to redefine the class.
>> 
>> We need to verify that JvmtiClassFileReconstituter produces correct class bytes, so test transformer can return null or passed classfileBuffer.
>> Actually the issue can be reproduced without ClassFileTransformer at all (and this is mentioned in the CR) - in the case reconstituted class bytes is considered as a result of the instrumentation.
>> 
>> I've updated the test, hope it's clearer now.
>> `targetClassName`/`seenClassBytes`/`newClassBytes` was used by Transformer, I moved them to the class.
>> Please let me know if you think some additional comments would be useful.
>
> Thank you for the update, it is a nice change.
> I'd also suggest to add a comment before line 115, something like this:
> 
>   // Below the null is passed as the classBytes argument which means there won't be any transformation.
>   // However, it is enough for testing purposes as the JvmtiClassFileReconstituter still involved
>   // into preparation of the initial classfile bytecodes.

Thank you for the update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1534563753

From amenkov at openjdk.org  Thu Mar 21 22:30:42 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 21 Mar 2024 22:30:42 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled
Message-ID: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>

The change fixes 3 nsk JDI tests.
Root cause in all 3 tests is the same - the tests requests JDI event with SUSPEND_ALL policy, but event handler thread stops handle incoming event and this causes debuggee to hang (suspended by JDI event).

All 3 tests are updated to exit event handler thread after getting VMDeathEvent or VMDisconnectEvent (and resume debuggee after any other events).
ClassPrepareEvent tests need to wait some time to allow handle all expected events before terminate the debuggee. The logic was implemented by using CountDownLatch.

All tests are passed with "--test-repeat 20"

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/18442/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18442&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328303
  Stats: 93 lines in 3 files changed: 32 ins; 22 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/18442.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18442/head:pull/18442

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

From lmesnik at openjdk.org  Thu Mar 21 22:38:28 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 21 Mar 2024 22:38:28 GMT
Subject: Integrated: 8327704: Update nsk/jdi tests to use driver instead of
 othervm
In-Reply-To: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
References: <GnxVmP8EQh8dTX6B20gyZ3u_hg-4BHxRMs9Rw4oCjB8=.1f097844-52f6-4d9d-ba0b-e2921d2adc09@github.com>
Message-ID: <mWJiMHcJtxfxE9CJGN4g9OxWThJWa2ZjoYd1eCSRHPE=.5b53b221-83f6-418f-aec5-fd8d2ee51095@github.com>

On Fri, 8 Mar 2024 20:33:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
> There is not need to start  debugger in the separate process for each test. Also, no need to run it with "-Xcomp" because the main goal is to test debugee behavior with different VM flags.
> This fix updates tests to run debugger as driver to optimize execution time.
> The fix also eliminates System.exit() which is not compatible with driver/agentvm mode and update shared classes to correctly add classpath when running debugee.
> There were few tests which still execute using othervm mode. They require some specific classpath/settings. 
> Tested by running all tests, with '-Xcomp' and virtual thread test factory.

This pull request has now been integrated.

Changeset: 771f6a2f
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/771f6a2f8e236e224b0e33b89f664c4bfc49e595
Stats:     7430 lines in 2080 files changed: 2794 ins; 228 del; 4408 mod

8327704: Update nsk/jdi tests to use driver instead of othervm

Reviewed-by: sspitsyn, cjplummer

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

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

From sspitsyn at openjdk.org  Fri Mar 22 00:32:33 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 22 Mar 2024 00:32:33 GMT
Subject: Integrated: 8328285: GetOwnedMonitorInfo functions should use
 JvmtiHandshake
In-Reply-To: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
References: <ZZnxzsUgG02EurQCR_SA88y0deuo5tyeHwZh8E8ta2k=.4c14a395-ac76-4c5d-978b-7d9aeff4ef1a@github.com>
Message-ID: <GaIY-lJso9LAswYZJpDjyIdtJyy3h5P6NH-s9YTFRdU=.08c3ca19-b7d1-4dac-ba20-4307155ba9ea@github.com>

On Fri, 15 Mar 2024 20:14:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` on the base of `JvmtiHandshake and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 4d36c4ad
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d36c4adcc47630ddc7149c48c06dc8a93c1be5c
Stats:     129 lines in 4 files changed: 33 ins; 74 del; 22 mod

8328285: GetOwnedMonitorInfo functions should use JvmtiHandshake

Reviewed-by: pchilanomate, lmesnik

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

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

From sspitsyn at openjdk.org  Fri Mar 22 02:50:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 22 Mar 2024 02:50:27 GMT
Subject: RFR: 8328758: GetCurrentContendedMonitor function should use
 JvmtiHandshake
Message-ID: <u7mq3ipLoVt2LUePkuF8zBMyJAA4_E9dFtj1si18O2E=.366e6d15-f024-43ee-b5ac-8e4fc91cc3fd@github.com>

The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI `GetCurrentContendedMonitor` function on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.

Testing:
 - Ran mach5 tiers 1-6

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

Commit messages:
 - 8328758: GetCurrentContendedMonitor function should use JvmtiHandshake

Changes: https://git.openjdk.org/jdk/pull/18444/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328758
  Stats: 57 lines in 3 files changed: 13 ins; 32 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18444/head:pull/18444

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

From cjplummer at openjdk.org  Fri Mar 22 04:29:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 22 Mar 2024 04:29:22 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled
In-Reply-To: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
Message-ID: <Sx6NBnECRULA2dkhiiRn04G2yVmFK5Cge4zmi8r7iKo=.a511c212-e24a-49d9-b971-6db1abe0fdf5@github.com>

On Thu, 21 Mar 2024 22:25:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes 3 nsk JDI tests.
> Root cause in all 3 tests is the same - the tests requests JDI event with SUSPEND_ALL policy, but event handler thread stops handle incoming event and this causes debuggee to hang (suspended by JDI event).
> 
> All 3 tests are updated to exit event handler thread after getting VMDeathEvent or VMDisconnectEvent (and resume debuggee after any other events).
> ClassPrepareEvent tests need to wait some time to allow handle all expected events before terminate the debuggee. The logic was implemented by using CountDownLatch.
> 
> All tests are passed with "--test-repeat 20"

Looks good. Just a minor suggestion.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 276:

> 274:             try {
> 275:                 if (!eventsReceivedLatch.await(eventTimeout, TimeUnit.MILLISECONDS)) {
> 276:                     log.complain("FAILURE 20: Timeout for waiting event was exceeded");

Should it be "Timeout waiting for all events was exceeded" or maybe "Timeout while waiting for all events"? Same thing for thread001.java.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18442#pullrequestreview-1953909318
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1535025663

From mbaesken at openjdk.org  Fri Mar 22 07:09:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 22 Mar 2024 07:09:23 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <1B_6170Hws8xS66HVrqAzg3fIemaGkU58bKorF0cwgE=.0e58a5a6-12c0-4f1c-b1f0-ccec2ce6ccf3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
 <9E1DTAW3n4W-eZig7TaDnxtlCknuUdIpyo5EaUH_0tk=.20553650-f108-4a4e-b947-6457dd5bae85@github.com>
 <1B_6170Hws8xS66HVrqAzg3fIemaGkU58bKorF0cwgE=.0e58a5a6-12c0-4f1c-b1f0-ccec2ce6ccf3@github.com>
Message-ID: <d6ABZTsZjSw6Shex-DD5zP1HE6BMfQAbXlEvuv2x7F8=.a19d550f-16ad-443b-9ec3-2c8a280a3b1c@github.com>

On Thu, 21 Mar 2024 16:44:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'd like to consult with a couple of people at Oracle who unfortunately are out of town until Monday. Can this PR wait until next week?

That's fine, no need to rush it into jdk-head this week.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2014480135

From kevinw at openjdk.org  Fri Mar 22 12:53:24 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 22 Mar 2024 12:53:24 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v7]
In-Reply-To: <cwk2OYW86sV22aA4SGRbGHiYv8_Xtcn8pqhMbJXumgk=.195513d1-0500-4710-865e-7d8cc76ad1da@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <cwk2OYW86sV22aA4SGRbGHiYv8_Xtcn8pqhMbJXumgk=.195513d1-0500-4710-865e-7d8cc76ad1da@github.com>
Message-ID: <Qtm2ypRio0GY6N-d-zZSVYZ05UetYGlaANRClPgxJn0=.307235dd-0acb-4194-91be-7b9fe461bc86@github.com>

On Tue, 5 Mar 2024 11:31:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>> 
>> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Having worked with this for a while, I'm quite liking simply adding jcmds, and not adding a group of commands as I initially proposed.

The VM.debug group had a story to it, as I mentioned, but maybe that's just history.  A  user just wants to use jcmd, and if VM.inspect is the command to inspect a JVM object, then OK.   The history in debug.cpp may not be that interesting.  

The command group does make it easy to restrict the commands with UnlockDiagnosticVMOptions, for example, so that was a benefit, but minor as it's just a flag check.  Another difference with the command group was you have to read the first argument and direct to the right utility, so you're doing some minor parsing rather than relying on the DiagnosticCommand parser, which is a minor downside.  Ease of adding commands is generally similar either way.

VM.inspect is the primary utility I want to add here.  I plan to rework this do to that. Others can be added in separate jcmds as needs arise.

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2015039530

From sgehwolf at openjdk.org  Fri Mar 22 12:56:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 22 Mar 2024 12:56:21 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <4igI0UicqIV8pAhAFkxreyNnV9rZiaZZ98JI5TZWpEo=.3a2747f4-bfc2-4e09-9172-2b2f6d9bc2d6@github.com>

On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

Anyone willing to review this?

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2015043712

From amenkov at openjdk.org  Fri Mar 22 19:26:33 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 22 Mar 2024 19:26:33 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v2]
In-Reply-To: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
Message-ID: <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>

> The change fixes 3 nsk JDI tests.
> Root cause in all 3 tests is the same - the tests requests JDI event with SUSPEND_ALL policy, but event handler thread stops handle incoming event and this causes debuggee to hang (suspended by JDI event).
> 
> All 3 tests are updated to exit event handler thread after getting VMDeathEvent or VMDisconnectEvent (and resume debuggee after any other events).
> ClassPrepareEvent tests need to wait some time to allow handle all expected events before terminate the debuggee. The logic was implemented by using CountDownLatch.
> 
> All tests are passed with "--test-repeat 20"

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18442/files
  - new: https://git.openjdk.org/jdk/pull/18442/files/cdcb4094..a30e3b70

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

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

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

From cjplummer at openjdk.org  Fri Mar 22 19:41:21 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 22 Mar 2024 19:41:21 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v2]
In-Reply-To: <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
 <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
Message-ID: <F_1TjyBnoAdqNPieRXFtfmNgVLhsXh683vSbhtwJJ44=.4efd0a6e-a883-4d7b-a236-27e1507d97ba@github.com>

On Fri, 22 Mar 2024 19:26:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes 3 nsk JDI tests.
>> Root cause in all 3 tests is the same - the tests requests JDI event with SUSPEND_ALL policy, but event handler thread stops handle incoming event and this causes debuggee to hang (suspended by JDI event).
>> 
>> All 3 tests are updated to exit event handler thread after getting VMDeathEvent or VMDisconnectEvent (and resume debuggee after any other events).
>> ClassPrepareEvent tests need to wait some time to allow handle all expected events before terminate the debuggee. The logic was implemented by using CountDownLatch.
>> 
>> All tests are passed with "--test-repeat 20"
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18442#pullrequestreview-1955661328

From sspitsyn at openjdk.org  Fri Mar 22 20:33:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 22 Mar 2024 20:33:23 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v2]
In-Reply-To: <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
 <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
Message-ID: <6UP-GrzWxPVLchPc92nfX74YTaWCJk4h_5q3ro7QSV8=.c0b107a7-ca7c-4c8a-a695-4c828ae7d31c@github.com>

On Fri, 22 Mar 2024 19:26:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes 3 nsk JDI tests.
>> Root cause in all 3 tests is the same - the tests requests JDI event with SUSPEND_ALL policy, but event handler thread stops handle incoming event and this causes debuggee to hang (suspended by JDI event).
>> 
>> All 3 tests are updated to exit event handler thread after getting VMDeathEvent or VMDisconnectEvent (and resume debuggee after any other events).
>> ClassPrepareEvent tests need to wait some time to allow handle all expected events before terminate the debuggee. The logic was implemented by using CountDownLatch.
>> 
>> All tests are passed with "--test-repeat 20"
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 116:

> 114: 
> 115:                     boolean isConnected = true;
> 116:                     boolean eventsReceived = false;

Nit: It'd better to rename this local to `allEventsReceived`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536178517

From sspitsyn at openjdk.org  Fri Mar 22 20:42:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 22 Mar 2024 20:42:27 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v2]
In-Reply-To: <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
 <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
Message-ID: <VsHy12G3AmoFIGDQbzHraHXXFHsvgdwPjAJ7MKcC9As=.ce77b6cb-773f-41a1-b7d5-f6be6dd0adb5@github.com>

On Fri, 22 Mar 2024 19:26:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes 3 nsk JDI tests.
>> Root cause in all 3 tests is the same - the tests requests JDI event with SUSPEND_ALL policy, but event handler thread stops handle incoming event and this causes debuggee to hang (suspended by JDI event).
>> 
>> All 3 tests are updated to exit event handler thread after getting VMDeathEvent or VMDisconnectEvent (and resume debuggee after any other events).
>> ClassPrepareEvent tests need to wait some time to allow handle all expected events before terminate the debuggee. The logic was implemented by using CountDownLatch.
>> 
>> All tests are passed with "--test-repeat 20"
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

This looks good. I've posted a couple of nits/questions though.

One more question. Why these tests are failed with the UT enabled? Or maybe this was wrong assumption?

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 134:

> 132:                         while (eventIterator.hasNext()) {
> 133:                             Event event = eventIterator.nextEvent();
> 134: //                            log.display("\nEvent received:\n  " + event);

Nit: Would it make sense to uncomment this log message? How many events are normally printed?

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 277:

> 275:                 if (!eventsReceivedLatch.await(eventTimeout, TimeUnit.MILLISECONDS)) {
> 276:                     log.complain("FAILURE 20: Timeout waiting for all events was exceeded");
> 277:                     testFailed = true;

As I understand the call to `eventHandler.interrupt()` is not needed now because now the `eventHandler` is expected to finish by itself when one of the events is received: `VMDeathEvent` or `VMDisconnectEvent`.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18442#pullrequestreview-1955749418
PR Comment: https://git.openjdk.org/jdk/pull/18442#issuecomment-2015874028
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536186503
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536184572

From dcubed at openjdk.org  Fri Mar 22 20:47:23 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 22 Mar 2024 20:47:23 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v2]
In-Reply-To: <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
 <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
Message-ID: <cJnK53U7yw2_WrmtlJ8aTArplRTLrzpioCJ-fsXAD0g=.87623355-cf2d-4a2a-bf76-7337f92736c0@github.com>

On Fri, 22 Mar 2024 19:26:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes 3 nsk JDI tests.
>> Root cause in all 3 tests is the same - the tests requests JDI event with SUSPEND_ALL policy, but event handler thread stops handle incoming event and this causes debuggee to hang (suspended by JDI event).
>> 
>> All 3 tests are updated to exit event handler thread after getting VMDeathEvent or VMDisconnectEvent (and resume debuggee after any other events).
>> ClassPrepareEvent tests need to wait some time to allow handle all expected events before terminate the debuggee. The logic was implemented by using CountDownLatch.
>> 
>> All tests are passed with "--test-repeat 20"
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Thumbs up. I only have nit comments.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 117:

> 115:                     boolean isConnected = true;
> 116:                     boolean eventsReceived = false;
> 117:                     // handle events until debugee is disconnected

Nit typo: s/debugee/debuggee/

But a lot of the NSK tests have this typo...

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 203:

> 201:                                               }
> 202: 
> 203:                                               // Check that all expected ClassPrepareEvent are received

nit typo: s/ClassPrepareEvent/ClassPrepareEvent(s)/

nit typo: Since this comment starts with a capital, it should have a period at the end.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 207:

> 205:                                                   eventsReceived = true;
> 206:                                                   for (int i = 0; i < checkedTypes.length; i++) {
> 207:                                                       if (checkedTypes[i][2] == "0") {

This if-statement could use a comment to explain the logic.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/thread/thread001.java line 138:

> 136:                     boolean isConnected = true;
> 137:                     boolean eventsReceived = false;
> 138:                     // handle events until debugee is disconnected

Nit typo: s/debugee/debuggee/

But a lot of the NSK tests have this typo...

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/thread/thread001.java line 233:

> 231:                                           }
> 232: 
> 233:                                           // Check that all expected ClassPrepareEvent are received

nit typo: s/ClassPrepareEvent/ClassPrepareEvent(s)/

nit typo: Since this comment starts with a capital, it should have a period at the end.

test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/thread/thread001.java line 237:

> 235:                                               eventsReceived = true;
> 236:                                               for (int i = 0; i < checkedThreads.length; i++) {
> 237:                                                   if (checkedThreads[i][2] == "0") {

This if-statement could use a comment to explain the logic.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18442#pullrequestreview-1955733734
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536172906
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536176808
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536178687
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536181360
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536183605
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536184067

From amenkov at openjdk.org  Fri Mar 22 21:29:03 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 22 Mar 2024 21:29:03 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v3]
In-Reply-To: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
Message-ID: <GK4TvKZGRIaDTrm4Zn0hsYFsTfWu7VsOEwZMsE41tMs=.86061071-2e1e-4e68-a8e7-0084abe3c1d1@github.com>

> The change fixes 3 nsk JDI tests.
> Root cause in all 3 tests is the same - the tests requests JDI event with SUSPEND_ALL policy, but event handler thread stops handle incoming event and this causes debuggee to hang (suspended by JDI event).
> 
> All 3 tests are updated to exit event handler thread after getting VMDeathEvent or VMDisconnectEvent (and resume debuggee after any other events).
> ClassPrepareEvent tests need to wait some time to allow handle all expected events before terminate the debuggee. The logic was implemented by using CountDownLatch.
> 
> All tests are passed with "--test-repeat 20"

Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:

 - updated comments
 - eventsReceived -> allEventsReceived

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18442/files
  - new: https://git.openjdk.org/jdk/pull/18442/files/a30e3b70..53e4c460

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

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

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

From amenkov at openjdk.org  Fri Mar 22 21:31:26 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 22 Mar 2024 21:31:26 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v2]
In-Reply-To: <6UP-GrzWxPVLchPc92nfX74YTaWCJk4h_5q3ro7QSV8=.c0b107a7-ca7c-4c8a-a695-4c828ae7d31c@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
 <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
 <6UP-GrzWxPVLchPc92nfX74YTaWCJk4h_5q3ro7QSV8=.c0b107a7-ca7c-4c8a-a695-4c828ae7d31c@github.com>
Message-ID: <3wO3ctcDtHZ-fXoXvcnm13WXxMYvhyTTLjc0Rtm_UEI=.dcc36e9b-62ee-4ff3-b346-1f8f6be0985c@github.com>

On Fri, 22 Mar 2024 20:31:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 116:
> 
>> 114: 
>> 115:                     boolean isConnected = true;
>> 116:                     boolean eventsReceived = false;
> 
> Nit: It'd better to rename this local to `allEventsReceived`.

I tried to make minimal changes in the tests, so kept variable names to avoid unnecessary changes

> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 134:
> 
>> 132:                         while (eventIterator.hasNext()) {
>> 133:                             Event event = eventIterator.nextEvent();
>> 134: //                            log.display("\nEvent received:\n  " + event);
> 
> Nit: Would it make sense to uncomment this log message? How many events are normally printed?

The only event received are ClassPrepareEvent (requested by test) and  VMDeathEvent (when debuggee exits)
Both types are logged below

> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 277:
> 
>> 275:                 if (!eventsReceivedLatch.await(eventTimeout, TimeUnit.MILLISECONDS)) {
>> 276:                     log.complain("FAILURE 20: Timeout waiting for all events was exceeded");
>> 277:                     testFailed = true;
> 
> As I understand the call to `eventHandler.interrupt()` is not needed now because now the `eventHandler` is expected to finish by itself when one of the events is received: `VMDeathEvent` or `VMDisconnectEvent`.

right. eventHandler exits when debuggee exits

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536200016
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536205663
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536207978

From amenkov at openjdk.org  Fri Mar 22 21:31:27 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 22 Mar 2024 21:31:27 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v2]
In-Reply-To: <3wO3ctcDtHZ-fXoXvcnm13WXxMYvhyTTLjc0Rtm_UEI=.dcc36e9b-62ee-4ff3-b346-1f8f6be0985c@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
 <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
 <6UP-GrzWxPVLchPc92nfX74YTaWCJk4h_5q3ro7QSV8=.c0b107a7-ca7c-4c8a-a695-4c828ae7d31c@github.com>
 <3wO3ctcDtHZ-fXoXvcnm13WXxMYvhyTTLjc0Rtm_UEI=.dcc36e9b-62ee-4ff3-b346-1f8f6be0985c@github.com>
Message-ID: <6-CMmnxE_4niIom77DnCPTW3DL9tSh7PiE01zgB373M=.aad5343f-372f-4999-8203-a82fbd7fdf1f@github.com>

On Fri, 22 Mar 2024 20:45:51 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 116:
>> 
>>> 114: 
>>> 115:                     boolean isConnected = true;
>>> 116:                     boolean eventsReceived = false;
>> 
>> Nit: It'd better to rename this local to `allEventsReceived`.
>
> I tried to make minimal changes in the tests, so kept variable names to avoid unnecessary changes

Looks like all lines with the variable are already touched, I'll change the name

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536212976

From amenkov at openjdk.org  Fri Mar 22 21:31:28 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 22 Mar 2024 21:31:28 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v2]
In-Reply-To: <cJnK53U7yw2_WrmtlJ8aTArplRTLrzpioCJ-fsXAD0g=.87623355-cf2d-4a2a-bf76-7337f92736c0@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
 <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
 <cJnK53U7yw2_WrmtlJ8aTArplRTLrzpioCJ-fsXAD0g=.87623355-cf2d-4a2a-bf76-7337f92736c0@github.com>
Message-ID: <hxciX6J4-q_Ap8lGRDuxa_L9gEMlQ-d-Z_JLmZh6jRE=.eaa017bd-f398-4c76-ad5a-7d4c1b6f7275@github.com>

On Fri, 22 Mar 2024 20:27:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 117:
> 
>> 115:                     boolean isConnected = true;
>> 116:                     boolean eventsReceived = false;
>> 117:                     // handle events until debugee is disconnected
> 
> Nit typo: s/debugee/debuggee/
> 
> But a lot of the NSK tests have this typo...

Fixed.

> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 207:
> 
>> 205:                                                   eventsReceived = true;
>> 206:                                                   for (int i = 0; i < checkedTypes.length; i++) {
>> 207:                                                       if (checkedTypes[i][2] == "0") {
> 
> This if-statement could use a comment to explain the logic.

Done.

> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/thread/thread001.java line 138:
> 
>> 136:                     boolean isConnected = true;
>> 137:                     boolean eventsReceived = false;
>> 138:                     // handle events until debugee is disconnected
> 
> Nit typo: s/debugee/debuggee/
> 
> But a lot of the NSK tests have this typo...

Fixed.

> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/thread/thread001.java line 233:
> 
>> 231:                                           }
>> 232: 
>> 233:                                           // Check that all expected ClassPrepareEvent are received
> 
> nit typo: s/ClassPrepareEvent/ClassPrepareEvent(s)/
> 
> nit typo: Since this comment starts with a capital, it should have a period at the end.

Fixed.

> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/thread/thread001.java line 237:
> 
>> 235:                                               eventsReceived = true;
>> 236:                                               for (int i = 0; i < checkedThreads.length; i++) {
>> 237:                                                   if (checkedThreads[i][2] == "0") {
> 
> This if-statement could use a comment to explain the logic.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536241165
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536241466
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536241591
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536241959
PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536242129

From amenkov at openjdk.org  Fri Mar 22 21:31:30 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 22 Mar 2024 21:31:30 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v3]
In-Reply-To: <Sx6NBnECRULA2dkhiiRn04G2yVmFK5Cge4zmi8r7iKo=.a511c212-e24a-49d9-b971-6db1abe0fdf5@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
 <Sx6NBnECRULA2dkhiiRn04G2yVmFK5Cge4zmi8r7iKo=.a511c212-e24a-49d9-b971-6db1abe0fdf5@github.com>
Message-ID: <2XMHhnuv34tsjIqBZ9UWpVI2Rab_PLsDCwPDuoRHJ24=.d277c3e7-2299-48a0-9592-9f74ab57130f@github.com>

On Fri, 22 Mar 2024 04:09:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - updated comments
>>  - eventsReceived -> allEventsReceived
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassPrepareEvent/referenceType/refType001.java line 276:
> 
>> 274:             try {
>> 275:                 if (!eventsReceivedLatch.await(eventTimeout, TimeUnit.MILLISECONDS)) {
>> 276:                     log.complain("FAILURE 20: Timeout for waiting event was exceeded");
> 
> Should it be "Timeout waiting for all events was exceeded" or maybe "Timeout while waiting for all events"? Same thing for thread001.java.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18442#discussion_r1536240012

From amenkov at openjdk.org  Fri Mar 22 21:42:32 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 22 Mar 2024 21:42:32 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v2]
In-Reply-To: <VsHy12G3AmoFIGDQbzHraHXXFHsvgdwPjAJ7MKcC9As=.ce77b6cb-773f-41a1-b7d5-f6be6dd0adb5@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
 <BDWj5p2mA4iSHm-rwdFCFZE0ScyKt0t7O6L0HzxQ0HA=.93ecc929-1d27-4dac-95af-55756384b52c@github.com>
 <VsHy12G3AmoFIGDQbzHraHXXFHsvgdwPjAJ7MKcC9As=.ce77b6cb-773f-41a1-b7d5-f6be6dd0adb5@github.com>
Message-ID: <wPDjhdAbjSGPmumLsdT84m6jw1v7b1SqORwJe_Qu7Y0=.2a1196ac-f7f5-409e-b1d2-650cecca4c90@github.com>

On Fri, 22 Mar 2024 20:39:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> One more question. Why these tests are failed with the UT enabled? Or maybe this was wrong assumption?

UT can add additional events (ClassPrepareEvent, ThreadDeathEvent). As the event are requested with SUSPEND_ALL policy, debuggee VM needs to be resumed.
But the tests didn't expect "extra" events from other thread, event handler thread can exit before all events are handled, and tests fail with timeout waiting while debuggee exits.

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

PR Comment: https://git.openjdk.org/jdk/pull/18442#issuecomment-2015967581

From amenkov at openjdk.org  Fri Mar 22 23:33:25 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 22 Mar 2024 23:33:25 GMT
Subject: RFR: JDK-8328303: 3 JDI tests timed out with UT enabled [v3]
In-Reply-To: <GK4TvKZGRIaDTrm4Zn0hsYFsTfWu7VsOEwZMsE41tMs=.86061071-2e1e-4e68-a8e7-0084abe3c1d1@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
 <GK4TvKZGRIaDTrm4Zn0hsYFsTfWu7VsOEwZMsE41tMs=.86061071-2e1e-4e68-a8e7-0084abe3c1d1@github.com>
Message-ID: <z0wvO3mqM8o5cZRzzm25Eb9eUKlLvLisSTrlpXafQtg=.af32e938-5f2f-48fd-8a69-567b35d6ad4f@github.com>

On Fri, 22 Mar 2024 21:29:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes 3 nsk JDI tests.
>> Root cause in all 3 tests is the same - the tests requests JDI event with SUSPEND_ALL policy, but event handler thread stops handle incoming event and this causes debuggee to hang (suspended by JDI event).
>> 
>> All 3 tests are updated to exit event handler thread after getting VMDeathEvent or VMDisconnectEvent (and resume debuggee after any other events).
>> ClassPrepareEvent tests need to wait some time to allow handle all expected events before terminate the debuggee. The logic was implemented by using CountDownLatch.
>> 
>> All tests are passed with "--test-repeat 20"
>
> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated comments
>  - eventsReceived -> allEventsReceived

Last update was cosmetic, so I'm going to integrate the fix to reduce noise in CI

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

PR Comment: https://git.openjdk.org/jdk/pull/18442#issuecomment-2016125851

From amenkov at openjdk.org  Fri Mar 22 23:33:26 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 22 Mar 2024 23:33:26 GMT
Subject: Integrated: JDK-8328303: 3 JDI tests timed out with UT enabled
In-Reply-To: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
References: <JKfpSFr2wyA6uCrjUUF5FCd6Ek-FSTiK5q4MWgj4nYs=.511ba72f-e5e5-45e0-a29c-3cb2d51e5300@github.com>
Message-ID: <qtSH4tvBqNmqWQxB__GNDDv7eQ44cK04xHtfIgoVE94=.c09388d8-631c-4781-aad9-ddecded410f5@github.com>

On Thu, 21 Mar 2024 22:25:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes 3 nsk JDI tests.
> Root cause in all 3 tests is the same - the tests requests JDI event with SUSPEND_ALL policy, but event handler thread stops handle incoming event and this causes debuggee to hang (suspended by JDI event).
> 
> All 3 tests are updated to exit event handler thread after getting VMDeathEvent or VMDisconnectEvent (and resume debuggee after any other events).
> ClassPrepareEvent tests need to wait some time to allow handle all expected events before terminate the debuggee. The logic was implemented by using CountDownLatch.
> 
> All tests are passed with "--test-repeat 20"

This pull request has now been integrated.

Changeset: bc739639
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc73963974a824d77d54b8b0edbf8f05262b721c
Stats:     97 lines in 3 files changed: 37 ins; 22 del; 38 mod

8328303: 3 JDI tests timed out with UT enabled

Reviewed-by: cjplummer, sspitsyn, dcubed

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

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

From sspitsyn at openjdk.org  Sat Mar 23 01:20:26 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 23 Mar 2024 01:20:26 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v7]
In-Reply-To: <cwk2OYW86sV22aA4SGRbGHiYv8_Xtcn8pqhMbJXumgk=.195513d1-0500-4710-865e-7d8cc76ad1da@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <cwk2OYW86sV22aA4SGRbGHiYv8_Xtcn8pqhMbJXumgk=.195513d1-0500-4710-865e-7d8cc76ad1da@github.com>
Message-ID: <XMmKxZ4z8Tv2VkeWAmzh9GZnMYDwVLzfHtDOF2Kyfas=.786a434e-f8c3-44ac-a1ee-2bbdbadf9881@github.com>

On Tue, 5 Mar 2024 11:31:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.debug" to implement access to a useful set of the established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>> 
>> Not recommended for live production use.  Calling these "debug" utilities, and not including them in the jcmd help output, is to remind us they are not general customer-facing tools.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Kevin, I hope you will update the CSR with new approach, so I'll review it then.

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2016262416

From lmesnik at openjdk.org  Sat Mar 23 15:35:20 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 23 Mar 2024 15:35:20 GMT
Subject: RFR: 8328758: GetCurrentContendedMonitor function should use
 JvmtiHandshake
In-Reply-To: <u7mq3ipLoVt2LUePkuF8zBMyJAA4_E9dFtj1si18O2E=.366e6d15-f024-43ee-b5ac-8e4fc91cc3fd@github.com>
References: <u7mq3ipLoVt2LUePkuF8zBMyJAA4_E9dFtj1si18O2E=.366e6d15-f024-43ee-b5ac-8e4fc91cc3fd@github.com>
Message-ID: <Z9YUYhjaPRvrJoVV73Fbxh7tnA14YIif4YhcsvCqUTk=.5e553ea6-2f52-4c94-ad13-f5189982a918@github.com>

On Fri, 22 Mar 2024 02:44:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI `GetCurrentContendedMonitor` function on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18444#pullrequestreview-1956396534

From kevinw at openjdk.org  Mon Mar 25 10:40:22 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 25 Mar 2024 10:40:22 GMT
Subject: RFR: 8327864: Support segmented heap dump for
 HotSpotDiagnosticMXBean
In-Reply-To: <qshguvc5YqLBPpMaLJtQ14WiLVvInkulNf5pHY6tgSc=.2af0d959-7d6b-4bbc-9bb5-64236559972a@github.com>
References: <qshguvc5YqLBPpMaLJtQ14WiLVvInkulNf5pHY6tgSc=.2af0d959-7d6b-4bbc-9bb5-64236559972a@github.com>
Message-ID: <SCGponAiuWk6FnBdziwB-mwPwlHjUT3kn3u8UAfOwXU=.45ceec2a-55de-44fc-9676-a47e724eba37@github.com>

On Tue, 12 Mar 2024 07:59:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> We've received feedback from users of cloud APM platform wanting the new version of the JDK to allow the HotSpotDiagnosticMXBean.dumpHeap underpinnings to reduce STW time using sgemented heapdump. Supporting segmented heapdump for mxbean is a reasonable requirement and adds little additional complexity, both in terms of maintainability and understanding.

We should close this now the issue is marked as a duplicate, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18221#issuecomment-2017694182

From ksakata at openjdk.org  Mon Mar 25 12:30:48 2024
From: ksakata at openjdk.org (Koichi Sakata)
Date: Mon, 25 Mar 2024 12:30:48 GMT
Subject: RFR: 8325186: JVMTI VirtualThreadGetThreadStateClosure class is no
 longer used and should be removed
Message-ID: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>

This pull request removes an unused class. 

I have investigated when this class was no longer in use. In the initial push of the virtual thread code (21972f45a64741ec3002499ef532e363cc3e9f93), there was only the definition of this class. I also checked subsequent commits, and it has never been used since the push.

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

Commit messages:
 - Remove JVMTI VirtualThreadGetThreadStateClosure class

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

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

From duke at openjdk.org  Mon Mar 25 12:37:28 2024
From: duke at openjdk.org (RacerZ)
Date: Mon, 25 Mar 2024 12:37:28 GMT
Subject: RFR: 8324241: Always record evol_method deps to avoid excessive
 method flushing [v5]
In-Reply-To: <Uic-G3-foi-h_eXkhPZZaESMU8Km2DB0pJ-9EqXcQ0g=.538ecbe1-4852-4a76-bc09-10fc0a5e19a4@github.com>
References: <npr_I1hJGJUJ3DGSHD-ULONxfDPWMsKk1ijk3i7KdXY=.83e0334f-0ebe-4956-9498-cf2690216928@github.com>
 <Uic-G3-foi-h_eXkhPZZaESMU8Km2DB0pJ-9EqXcQ0g=.538ecbe1-4852-4a76-bc09-10fc0a5e19a4@github.com>
Message-ID: <Y_f9PdfXvgnbK6nNriYR1dkHtrElPo66CAOAvwMj24I=.e5ab52af-f4e1-4856-a31c-198a2bfb1a97@github.com>

On Fri, 26 Jan 2024 13:14:57 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:
> 
>   Fixed whitepspace in flag documentation

I've noticed that the evol_method dependency is closely related to inline optimization. I'm curious if there is a way to extract evol_method information from the results of inline optimization (perhaps nmethod)?

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

PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-2017904506

From mbaesken at openjdk.org  Mon Mar 25 13:30:31 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 25 Mar 2024 13:30:31 GMT
Subject: RFR: JDK-8328930: [AIX] remove pase related coding
Message-ID: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>

We still have quite a lot of OS400 / pase related coding in the hotspot AIX codebase. But this does not work and was never supported in OpenJDK. So we can remove this.

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

Commit messages:
 - JDK-8328930

Changes: https://git.openjdk.org/jdk/pull/18471/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18471&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328930
  Stats: 419 lines in 8 files changed: 12 ins; 357 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/18471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18471/head:pull/18471

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

From kevinw at openjdk.org  Mon Mar 25 14:05:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 25 Mar 2024 14:05:30 GMT
Subject: RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use
Message-ID: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.ee3bac85-f683-48b1-9919-cd5035f0f5c4@github.com>

Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.

e.g. 

test output:
Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
	java.net.BindException: Address already in use
	
Test checks for:
        !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
		
Oops, we have an extra space in there.  A day-one typo from JDK-7195249.

While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java

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

Commit messages:
 - 8328619: sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed with BindException: Address already in use

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

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

From kevinw at openjdk.org  Mon Mar 25 19:07:47 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 25 Mar 2024 19:07:47 GMT
Subject: RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use
Message-ID: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>

Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.

e.g. 

test output:
Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
	java.net.BindException: Address already in use
	
Test checks for:
        !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
		
Oops, we have an extra space in there.  A day-one typo from JDK-7195249.

While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java

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

Commit messages:
 - 8328619: sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed with BindException: Address already in use

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

PR: https://git.openjdk.org/jdk/pull/18470

From cjplummer at openjdk.org  Mon Mar 25 19:07:47 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 25 Mar 2024 19:07:47 GMT
Subject: RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use
In-Reply-To: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
Message-ID: <_M8m6GWVZeI9naGSojuKbhXFOvk0gzxOHGF5tVYI_6I=.a145f19f-f332-4553-b6b5-59bb2e721704@github.com>

On Mon, 25 Mar 2024 13:15:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
> 
> e.g. 
> 
> test output:
> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
> 	java.net.BindException: Address already in use
> 	
> Test checks for:
>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
> 		
> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
> 
> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java

test/jdk/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java line 144:

> 142: 
> 143:         if (doTest() != 0) {
> 144:             System.out.println("FAILURE");

Would be better to print out which test failed and include the error #.

test/jdk/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java line 159:

> 157: 
> 158:         if (doTest() == 0) {
> 159:             System.out.println("FAILURE");

Would be better to print out which test failed and include the error #.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18470#discussion_r1538097934
PR Review Comment: https://git.openjdk.org/jdk/pull/18470#discussion_r1538098137

From cjplummer at openjdk.org  Mon Mar 25 19:12:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 25 Mar 2024 19:12:22 GMT
Subject: RFR: 8325186: JVMTI VirtualThreadGetThreadStateClosure class is no
 longer used and should be removed
In-Reply-To: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
References: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
Message-ID: <bQqWoMu1puzE8NGs4iOwzkxiHy8CewUG-rws8sFQaJ8=.20a7a9f9-fb29-46eb-bba7-ca24b68c552e@github.com>

On Mon, 18 Mar 2024 08:19:47 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> This pull request removes an unused class. 
> 
> I have investigated when this class was no longer in use. In the initial push of the virtual thread code (21972f45a64741ec3002499ef532e363cc3e9f93), there was only the definition of this class. I also checked subsequent commits, and it has never been used since the push.

Please update copyright dates.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18341#pullrequestreview-1958574710

From pchilanomate at openjdk.org  Mon Mar 25 19:57:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 25 Mar 2024 19:57:21 GMT
Subject: RFR: 8328758: GetCurrentContendedMonitor function should use
 JvmtiHandshake
In-Reply-To: <u7mq3ipLoVt2LUePkuF8zBMyJAA4_E9dFtj1si18O2E=.366e6d15-f024-43ee-b5ac-8e4fc91cc3fd@github.com>
References: <u7mq3ipLoVt2LUePkuF8zBMyJAA4_E9dFtj1si18O2E=.366e6d15-f024-43ee-b5ac-8e4fc91cc3fd@github.com>
Message-ID: <A7hb0cNVKxrk-VKMp3e8mzIfaZn_coCCOY5zwRs4idk=.26f22728-17e9-46d0-a0eb-fe8d467c4e50@github.com>

On Fri, 22 Mar 2024 02:44:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI `GetCurrentContendedMonitor` function on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

Looks good to me.

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18444#pullrequestreview-1958659004

From lmesnik at openjdk.org  Mon Mar 25 21:00:22 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 25 Mar 2024 21:00:22 GMT
Subject: RFR: 8325186: JVMTI VirtualThreadGetThreadStateClosure class is no
 longer used and should be removed
In-Reply-To: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
References: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
Message-ID: <uj6HykRMY17sAXP9bZY0TxQF0iaFgz7F0C898Pdmpbw=.97062265-f889-4fb0-bafd-29d04d54ff25@github.com>

On Mon, 18 Mar 2024 08:19:47 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> This pull request removes an unused class. 
> 
> I have investigated when this class was no longer in use. In the initial push of the virtual thread code (21972f45a64741ec3002499ef532e363cc3e9f93), there was only the definition of this class. I also checked subsequent commits, and it has never been used since the push.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18341#pullrequestreview-1958772118

From kevinw at openjdk.org  Mon Mar 25 22:42:21 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 25 Mar 2024 22:42:21 GMT
Subject: RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use
In-Reply-To: <_M8m6GWVZeI9naGSojuKbhXFOvk0gzxOHGF5tVYI_6I=.a145f19f-f332-4553-b6b5-59bb2e721704@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
 <_M8m6GWVZeI9naGSojuKbhXFOvk0gzxOHGF5tVYI_6I=.a145f19f-f332-4553-b6b5-59bb2e721704@github.com>
Message-ID: <0t2tpMCWE_kKUGwxTi4OAyi7x9AvtUBP44fFNest0TU=.20f8993a-a784-4653-9802-c92b7000bdfa@github.com>

On Mon, 25 Mar 2024 19:00:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
>> 
>> e.g. 
>> 
>> test output:
>> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
>> 	java.net.BindException: Address already in use
>> 	
>> Test checks for:
>>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
>> 		
>> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
>> 
>> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java
>
> test/jdk/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java line 144:
> 
>> 142: 
>> 143:         if (doTest() != 0) {
>> 144:             System.out.println("FAILURE");
> 
> Would be better to print out which test failed and include the error #.

Maybe very marginally useful. I'll add it.  8-)

It's the exit code of the JVM process, being zero or not zero, and the output already printed before the "FAILURE" note that will be the guide as to what went wrong.

If it's the port failure, you'll see the retries then the eventual FAILURE, so that will be clear.

If the JVM failed to startup, it's more the output than the exit code that we want.

I really wanted the FAILURE printed because it tests two things, and when you see this test for the first time, it may not be obvious which of the tests is the actual failure - particularly as test2 is expected to cause an error and a non-zero exit code.  So it says "1 failure", and you can stare at two things that look like failures. 8-)

Maybe very marginally useful. I'll add it.  8-)

It's the exit code of the JVM process, being zero or not zero, and the output already printed before the "FAILURE" note will be the guide as to what went wrong.  (If it's the port failure, you'll see the retries then the eventual FAILURE, so that will be clear.)

If the JVM failed to startup, it's more the text output than the exit code that we want.

I really wanted the FAILURE printed because it tests two things, and when you see this test for the first time, it may not be obvious which of the tests is the actual failure - particularly as test2 is expected to cause an error and a non-zero exit code.  So it says "1 failure", and you can stare at two things that look like failures. 8-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18470#discussion_r1538323593

From kevinw at openjdk.org  Mon Mar 25 22:46:47 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 25 Mar 2024 22:46:47 GMT
Subject: RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use [v2]
In-Reply-To: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
Message-ID: <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>

> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
> 
> e.g. 
> 
> test output:
> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
> 	java.net.BindException: Address already in use
> 	
> Test checks for:
>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
> 		
> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
> 
> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  show exit code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18470/files
  - new: https://git.openjdk.org/jdk/pull/18470/files/78456dac..5047f7d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18470&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18470&range=00-01

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18470/head:pull/18470

PR: https://git.openjdk.org/jdk/pull/18470

From sspitsyn at openjdk.org  Mon Mar 25 23:02:24 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 25 Mar 2024 23:02:24 GMT
Subject: RFR: 8325186: JVMTI VirtualThreadGetThreadStateClosure class is no
 longer used and should be removed
In-Reply-To: <bQqWoMu1puzE8NGs4iOwzkxiHy8CewUG-rws8sFQaJ8=.20a7a9f9-fb29-46eb-bba7-ca24b68c552e@github.com>
References: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
 <bQqWoMu1puzE8NGs4iOwzkxiHy8CewUG-rws8sFQaJ8=.20a7a9f9-fb29-46eb-bba7-ca24b68c552e@github.com>
Message-ID: <LrW1Qt8WZ0D7Gk3tyFgvGFDlyTEUnVNU-eZs5EBcDm8=.ca97df86-5a96-4c13-b6da-0d8ff459a0b3@github.com>

On Mon, 25 Mar 2024 19:09:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Please update copyright dates.

Need to merge with the main line which has the updated copyright headers. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18341#issuecomment-2019064922

From sspitsyn at openjdk.org  Mon Mar 25 23:07:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 25 Mar 2024 23:07:23 GMT
Subject: RFR: 8325186: JVMTI VirtualThreadGetThreadStateClosure class is no
 longer used and should be removed
In-Reply-To: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
References: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
Message-ID: <01c5ldfjKFITgpc_ZDDSe1CftyR7znwVlteYgZK9knQ=.0f251395-d2f9-4bf2-a182-dffa5056be64@github.com>

On Mon, 18 Mar 2024 08:19:47 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> This pull request removes an unused class. 
> 
> I have investigated when this class was no longer in use. In the initial push of the virtual thread code (21972f45a64741ec3002499ef532e363cc3e9f93), there was only the definition of this class. I also checked subsequent commits, and it has never been used since the push.

Looks good. Thank you for taking care about it!

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18341#pullrequestreview-1958946924

From lmesnik at openjdk.org  Mon Mar 25 23:08:23 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 25 Mar 2024 23:08:23 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v2]
In-Reply-To: <o7dvdfkIQM34I4rG74ITc7Wu3pVMjcZyoQkoNx6Ojss=.daabae11-7ee8-40b2-9777-bc6148735eb1@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <o7dvdfkIQM34I4rG74ITc7Wu3pVMjcZyoQkoNx6Ojss=.daabae11-7ee8-40b2-9777-bc6148735eb1@github.com>
Message-ID: <lWD89i2KefUfYObhwkoIryfKcbBbejZNnr_Gf-Yum1s=.10054e6d-e78e-42d6-8218-13911c58c177@github.com>

On Thu, 21 Mar 2024 17:53:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This PR fixes a synchronization issue in the test:
>>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>>   
>> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
>> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
>> 
>> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
>> 
>> Testing:
>>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: updated test with one more call to notifyAtBreakpoint to reset the native state

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18419#pullrequestreview-1958949308

From sspitsyn at openjdk.org  Mon Mar 25 23:35:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 25 Mar 2024 23:35:23 GMT
Subject: RFR: 8328758: GetCurrentContendedMonitor function should use
 JvmtiHandshake
In-Reply-To: <u7mq3ipLoVt2LUePkuF8zBMyJAA4_E9dFtj1si18O2E=.366e6d15-f024-43ee-b5ac-8e4fc91cc3fd@github.com>
References: <u7mq3ipLoVt2LUePkuF8zBMyJAA4_E9dFtj1si18O2E=.366e6d15-f024-43ee-b5ac-8e4fc91cc3fd@github.com>
Message-ID: <w9hUziZQZfi7ARstihqcVi1Fr8DdB_JcnAiSxnnAnRQ=.9c294fba-a801-497f-870c-640dd950764b@github.com>

On Fri, 22 Mar 2024 02:44:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI `GetCurrentContendedMonitor` function on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

Leonid and Patricio, thank you for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18444#issuecomment-2019103923

From lmesnik at openjdk.org  Mon Mar 25 23:45:22 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 25 Mar 2024 23:45:22 GMT
Subject: RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use [v2]
In-Reply-To: <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
 <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
Message-ID: <mgP4JS60uKW7UYQZTBywVLLQMLyo9w8ce52V4sFTXUE=.3dd8ab5e-1c17-4c77-bb6c-a005e85a19ee@github.com>

On Mon, 25 Mar 2024 22:46:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
>> 
>> e.g. 
>> 
>> test output:
>> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
>> 	java.net.BindException: Address already in use
>> 	
>> Test checks for:
>>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
>> 		
>> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
>> 
>> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   show exit code

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18470#pullrequestreview-1958989271

From yyang at openjdk.org  Tue Mar 26 01:50:26 2024
From: yyang at openjdk.org (Yi Yang)
Date: Tue, 26 Mar 2024 01:50:26 GMT
Subject: Withdrawn: 8327864: Support segmented heap dump for
 HotSpotDiagnosticMXBean
In-Reply-To: <qshguvc5YqLBPpMaLJtQ14WiLVvInkulNf5pHY6tgSc=.2af0d959-7d6b-4bbc-9bb5-64236559972a@github.com>
References: <qshguvc5YqLBPpMaLJtQ14WiLVvInkulNf5pHY6tgSc=.2af0d959-7d6b-4bbc-9bb5-64236559972a@github.com>
Message-ID: <lZMKJ8IuHQJxxwDB2qAs66BTPqWvGCinhy6tzjt0jAg=.e26d400b-ac68-4913-aa96-dd842ffd9d20@github.com>

On Tue, 12 Mar 2024 07:59:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> We've received feedback from users of cloud APM platform wanting the new version of the JDK to allow the HotSpotDiagnosticMXBean.dumpHeap underpinnings to reduce STW time using sgemented heapdump. Supporting segmented heapdump for mxbean is a reasonable requirement and adds little additional complexity, both in terms of maintainability and understanding.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18221

From sspitsyn at openjdk.org  Tue Mar 26 02:24:25 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 26 Mar 2024 02:24:25 GMT
Subject: Integrated: 8328758: GetCurrentContendedMonitor function should use
 JvmtiHandshake
In-Reply-To: <u7mq3ipLoVt2LUePkuF8zBMyJAA4_E9dFtj1si18O2E=.366e6d15-f024-43ee-b5ac-8e4fc91cc3fd@github.com>
References: <u7mq3ipLoVt2LUePkuF8zBMyJAA4_E9dFtj1si18O2E=.366e6d15-f024-43ee-b5ac-8e4fc91cc3fd@github.com>
Message-ID: <FnD7qrCuBxUK4ley2WWYCzE0vqcRUfVcWNtf3EDmHCI=.6585ea51-eaac-4b6c-84e8-78426fc9fe1b@github.com>

On Fri, 22 Mar 2024 02:44:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI `GetCurrentContendedMonitor` function on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 5f7432f7
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f7432f7b1ca52941b717fd35a929c91fbdd276d
Stats:     57 lines in 3 files changed: 13 ins; 32 del; 12 mod

8328758: GetCurrentContendedMonitor function should use JvmtiHandshake

Reviewed-by: lmesnik, pchilanomate

-------------

PR: https://git.openjdk.org/jdk/pull/18444

From cjplummer at openjdk.org  Tue Mar 26 03:27:28 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 26 Mar 2024 03:27:28 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
Message-ID: <BfpIYwsxPSrvLxeXNtHEpZ9ESzQD6ubi5mtzI9GBTlA=.978b361a-6ad8-4dc6-9623-4c5b0d6fec41@github.com>

On Fri, 15 Mar 2024 11:24:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust jcmd manpage, help and globals comment

src/hotspot/share/services/diagnosticCommand.cpp line 498:

> 496:   // in case no specific filename was passed to heap_dump command,
> 497:   // attempt to use the HeapDumpPath if it was set
> 498:   const char* filename = HeapDumpPath;

Why is this here? It is confusing because it makes it look like the HeapDumpPath will be used in place of specifying a filename with the jcmd, but in fact HeapDumpPath can be null, and logic below relies on that fact. Why not just check if HeapDumpPath is null below. You don't really need `filename`.  See suggested changes below.

src/hotspot/share/services/diagnosticCommand.cpp line 531:

> 529:     use_heapdump_path = true;
> 530:   }
> 531: 

Suggestion:

  if (!_filename.is_set()) {
    if (HeapDumpPath != nullptr) {
      // use HeapDumpPath (file or directory is possible)
      use_heapdump_path = true;
    } else {
      output()->print_cr("Filename or -XX:HeapDumpPath must be set!");
      return;
    }
  }

src/hotspot/share/services/diagnosticCommand.cpp line 540:

> 538:     dumper.dump_to(output(), (int)level, _overwrite.value(), (uint)parallel);
> 539:   } else {
> 540:     dumper.dump(filename, output(), (int)level, _overwrite.value(), (uint)parallel);

Suggestion:

    dumper.dump(_filename.value(), output(), (int)level, _overwrite.value(), (uint)parallel);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1538535068
PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1538535317
PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1538535458

From ksakata at openjdk.org  Tue Mar 26 04:15:40 2024
From: ksakata at openjdk.org (Koichi Sakata)
Date: Tue, 26 Mar 2024 04:15:40 GMT
Subject: RFR: 8325186: JVMTI VirtualThreadGetThreadStateClosure class is no
 longer used and should be removed [v2]
In-Reply-To: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
References: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
Message-ID: <T2gPAqUU1Jt3U_fsJt9-pNzKivVMACwijL39BjuJ71M=.d7e4b174-d068-4468-8d0c-a7b0dd6a49ca@github.com>

> This pull request removes an unused class. 
> 
> I have investigated when this class was no longer in use. In the initial push of the virtual thread code (21972f45a64741ec3002499ef532e363cc3e9f93), there was only the definition of this class. I also checked subsequent commits, and it has never been used since the push.

Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18341/files
  - new: https://git.openjdk.org/jdk/pull/18341/files/09af50a0..b37187ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18341&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18341&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18341.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18341/head:pull/18341

PR: https://git.openjdk.org/jdk/pull/18341

From ksakata at openjdk.org  Tue Mar 26 04:20:33 2024
From: ksakata at openjdk.org (Koichi Sakata)
Date: Tue, 26 Mar 2024 04:20:33 GMT
Subject: RFR: 8325186: JVMTI VirtualThreadGetThreadStateClosure class is no
 longer used and should be removed [v2]
In-Reply-To: <T2gPAqUU1Jt3U_fsJt9-pNzKivVMACwijL39BjuJ71M=.d7e4b174-d068-4468-8d0c-a7b0dd6a49ca@github.com>
References: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
 <T2gPAqUU1Jt3U_fsJt9-pNzKivVMACwijL39BjuJ71M=.d7e4b174-d068-4468-8d0c-a7b0dd6a49ca@github.com>
Message-ID: <txbfT1V1aE1c-_IxjtrX40lxI7Nf_DC_-nSR1RrJUcA=.ad9a708a-75f1-4c18-b1c7-3bfa2e45b27c@github.com>

On Tue, 26 Mar 2024 04:15:40 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

>> This pull request removes an unused class. 
>> 
>> I have investigated when this class was no longer in use. In the initial push of the virtual thread code (21972f45a64741ec3002499ef532e363cc3e9f93), there was only the definition of this class. I also checked subsequent commits, and it has never been used since the push.
>
> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Thank you for reviewing this pull request. I've updated the copyright year.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18341#issuecomment-2019353342

From ksakata at openjdk.org  Tue Mar 26 04:20:34 2024
From: ksakata at openjdk.org (Koichi Sakata)
Date: Tue, 26 Mar 2024 04:20:34 GMT
Subject: Integrated: 8325186: JVMTI VirtualThreadGetThreadStateClosure class is
 no longer used and should be removed
In-Reply-To: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
References: <vxjXJDVCzx-yD_6XMVIEXq-mNf6ri-thz59jfBxzPeI=.ddd30cfc-9d0d-4f58-930e-6189b0c90da6@github.com>
Message-ID: <1vYDqDFfUrDSZEoyaAlFO4WFJlJ7Beb5fGZRIgiaLdg=.239c14b3-9b55-494b-8f08-c7fddab0c475@github.com>

On Mon, 18 Mar 2024 08:19:47 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> This pull request removes an unused class. 
> 
> I have investigated when this class was no longer in use. In the initial push of the virtual thread code (21972f45a64741ec3002499ef532e363cc3e9f93), there was only the definition of this class. I also checked subsequent commits, and it has never been used since the push.

This pull request has now been integrated.

Changeset: 5d19d155
Author:    Koichi Sakata <ksakata at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d19d15517f08e13dc4b2025bf289091e47fa55b
Stats:     42 lines in 2 files changed: 0 ins; 42 del; 0 mod

8325186: JVMTI VirtualThreadGetThreadStateClosure class is no longer used and should be removed

Reviewed-by: lmesnik, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/18341

From aturbanov at openjdk.org  Tue Mar 26 07:30:23 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 26 Mar 2024 07:30:23 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <dnzll7uMjmAmGD_8ZaudJH1Kw90Dqq-j3TEiABaWSu4=.560e44c6-d426-4799-9fe6-fc04b338ef38@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed potential NPE issues.

test/jdk/java/nio/channels/unixdomain/Bind.java line 162:

> 160:         // address with space should work
> 161:         checkNormal(() -> {
> 162:             UnixDomainSocketAddress usa =  UnixDomainSocketAddress.of("with space");

Suggestion:

            UnixDomainSocketAddress usa = UnixDomainSocketAddress.of("with space");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1538701870

From clanger at openjdk.org  Tue Mar 26 09:31:22 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 26 Mar 2024 09:31:22 GMT
Subject: RFR: JDK-8328930: [AIX] remove pase related coding
In-Reply-To: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
References: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
Message-ID: <d7S3Rjs6HerQHit4QcilbV9f30-iWBsKrxizbQR3vSk=.ecca15ff-727a-403f-b0e5-0878eb0cb0bc@github.com>

On Mon, 25 Mar 2024 13:26:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still have quite a lot of OS400 / pase related coding in the hotspot AIX codebase. But this does not work and was never supported in OpenJDK. So we can remove this.

Welcome cleanup. I made two minor comments.

src/hotspot/os/aix/os_aix.cpp line 607:

> 605:   memset(pmi, 0, sizeof(meminfo_t));
> 606: 
> 607:   // On AIX, I use the (dynamically loaded) perfstat library to retrieve memory statistics

maybe remove the "I" pronoun in the comment here? Also the links could be placed on one line.

src/hotspot/os/aix/os_aix.cpp line 626:

> 624: 
> 625:   // excerpt from
> 626:   // http://publib.boulder.ibm.com/infocenter/systems/index.jsp

Same here. URL on one line. Does it still work?

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18471#pullrequestreview-1959796540
PR Review Comment: https://git.openjdk.org/jdk/pull/18471#discussion_r1538868553
PR Review Comment: https://git.openjdk.org/jdk/pull/18471#discussion_r1538869884

From mbaesken at openjdk.org  Tue Mar 26 13:57:55 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Mar 2024 13:57:55 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v9]
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <msScnhT6AfK5kOl0zOQr4U88V0JeF4qrr8xPCT3LXIw=.aae43b38-dc57-43aa-b462-72713ff5857e@github.com>

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  suggestions from Chris for diagnosticCommand.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18190/files
  - new: https://git.openjdk.org/jdk/pull/18190/files/8b48c911..b414b1be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18190&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18190&range=07-08

  Stats: 12 lines in 1 file changed: 0 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18190.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18190/head:pull/18190

PR: https://git.openjdk.org/jdk/pull/18190

From mbaesken at openjdk.org  Tue Mar 26 13:57:55 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Mar 2024 13:57:55 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v8]
In-Reply-To: <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <fPamBAgjggJE4TQEPQ1fxhN279hxD-yxeAAy5kOvbS0=.47f7b744-b5d9-4255-86d5-0ca9446ee568@github.com>
Message-ID: <dW4Ld0lbPD-wtXzkuyBb6jU3HmNYnkt78nMA-xJWwTw=.920729f4-d518-4be4-8b24-34a476f622db@github.com>

On Fri, 15 Mar 2024 11:24:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust jcmd manpage, help and globals comment

Hi Chris, thanks for the suggestions , I added them to the latest commit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2020494383

From mbaesken at openjdk.org  Tue Mar 26 13:58:24 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Mar 2024 13:58:24 GMT
Subject: RFR: JDK-8328930: [AIX] remove pase related coding
In-Reply-To: <d7S3Rjs6HerQHit4QcilbV9f30-iWBsKrxizbQR3vSk=.ecca15ff-727a-403f-b0e5-0878eb0cb0bc@github.com>
References: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
 <d7S3Rjs6HerQHit4QcilbV9f30-iWBsKrxizbQR3vSk=.ecca15ff-727a-403f-b0e5-0878eb0cb0bc@github.com>
Message-ID: <ytQPx3jcSKg4DEU2CUo9-BCPvReohNk2JihDLZjkYZ0=.7c1f746b-0643-4bf7-b81c-70135be76bdf@github.com>

On Tue, 26 Mar 2024 09:27:01 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> We still have quite a lot of OS400 / pase related coding in the hotspot AIX codebase. But this does not work and was never supported in OpenJDK. So we can remove this.
>
> src/hotspot/os/aix/os_aix.cpp line 626:
> 
>> 624: 
>> 625:   // excerpt from
>> 626:   // http://publib.boulder.ibm.com/infocenter/systems/index.jsp
> 
> Same here. URL on one line. Does it still work?

The link is dead, it does not work any more. I think we can remove it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18471#discussion_r1539288321

From mbaesken at openjdk.org  Tue Mar 26 14:18:34 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Mar 2024 14:18:34 GMT
Subject: RFR: JDK-8328930: [AIX] remove pase related coding [v2]
In-Reply-To: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
References: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
Message-ID: <XgPsKti4wCpHdBDWNPzrxxxDKPe0OLjB3oUOfL6ZmEQ=.8116abd2-5c96-450c-9c12-80097e8c8ec9@github.com>

> We still have quite a lot of OS400 / pase related coding in the hotspot AIX codebase. But this does not work and was never supported in OpenJDK. So we can remove this.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust/remove some comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18471/files
  - new: https://git.openjdk.org/jdk/pull/18471/files/d1c4c7de..ba02f086

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18471&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18471&range=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18471/head:pull/18471

PR: https://git.openjdk.org/jdk/pull/18471

From mbaesken at openjdk.org  Tue Mar 26 14:18:34 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Mar 2024 14:18:34 GMT
Subject: RFR: JDK-8328930: [AIX] remove pase related coding
In-Reply-To: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
References: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
Message-ID: <vmgVej8iRhcxrGxIpNYwnKfjJMWg49fM-JdL_26G0ZY=.127b87c6-3ef0-4eff-875a-1316313bd00d@github.com>

On Mon, 25 Mar 2024 13:26:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still have quite a lot of OS400 / pase related coding in the hotspot AIX codebase. But this does not work and was never supported in OpenJDK. So we can remove this.

Hi Christoph, I adjusted/removed the comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18471#issuecomment-2020550254

From clanger at openjdk.org  Tue Mar 26 15:36:24 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 26 Mar 2024 15:36:24 GMT
Subject: RFR: JDK-8328930: [AIX] remove pase related coding [v2]
In-Reply-To: <XgPsKti4wCpHdBDWNPzrxxxDKPe0OLjB3oUOfL6ZmEQ=.8116abd2-5c96-450c-9c12-80097e8c8ec9@github.com>
References: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
 <XgPsKti4wCpHdBDWNPzrxxxDKPe0OLjB3oUOfL6ZmEQ=.8116abd2-5c96-450c-9c12-80097e8c8ec9@github.com>
Message-ID: <J15kUVEHl_6057MPdFC3laF8YhNqapN18Bf4onfHnx0=.5bece867-2513-4a4d-9220-d01e6e7885fc@github.com>

On Tue, 26 Mar 2024 14:18:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still have quite a lot of OS400 / pase related coding in the hotspot AIX codebase. But this does not work and was never supported in OpenJDK. So we can remove this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust/remove some comments

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18471#pullrequestreview-1960822263

From michaelm at openjdk.org  Tue Mar 26 15:56:23 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 26 Mar 2024 15:56:23 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v3]
In-Reply-To: <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <EufPG-P3eVsHZJ7BMr9nTShQc06SdeQB8kC_l6k0OxI=.20bf3378-77b7-4cb2-a38e-377b05191f2d@github.com>
Message-ID: <dDrW4l3mQ8774vjN_VH6nQ94gMJSKK5xcEzMpxy_EPU=.8d557a74-6ad1-44ae-ba35-cab23db68f39@github.com>

On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed potential NPE issues.

unixdomain NIO test changes look fine to me

-------------

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18352#pullrequestreview-1960889711

From lucy at openjdk.org  Tue Mar 26 16:22:25 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 26 Mar 2024 16:22:25 GMT
Subject: RFR: JDK-8328930: [AIX] remove pase related coding [v2]
In-Reply-To: <XgPsKti4wCpHdBDWNPzrxxxDKPe0OLjB3oUOfL6ZmEQ=.8116abd2-5c96-450c-9c12-80097e8c8ec9@github.com>
References: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
 <XgPsKti4wCpHdBDWNPzrxxxDKPe0OLjB3oUOfL6ZmEQ=.8116abd2-5c96-450c-9c12-80097e8c8ec9@github.com>
Message-ID: <MTGHuk6ccHYkmI8KbOt8O0IrOKm0njLWnT3emmJ_VR4=.9d7edb4f-0e9d-420f-a927-a45b9509b9e5@github.com>

On Tue, 26 Mar 2024 14:18:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still have quite a lot of OS400 / pase related coding in the hotspot AIX codebase. But this does not work and was never supported in OpenJDK. So we can remove this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust/remove some comments

Looks good.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18471#pullrequestreview-1960988506

From mbaesken at openjdk.org  Tue Mar 26 16:26:26 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Mar 2024 16:26:26 GMT
Subject: RFR: JDK-8328930: [AIX] remove pase related coding [v2]
In-Reply-To: <XgPsKti4wCpHdBDWNPzrxxxDKPe0OLjB3oUOfL6ZmEQ=.8116abd2-5c96-450c-9c12-80097e8c8ec9@github.com>
References: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
 <XgPsKti4wCpHdBDWNPzrxxxDKPe0OLjB3oUOfL6ZmEQ=.8116abd2-5c96-450c-9c12-80097e8c8ec9@github.com>
Message-ID: <AOPvqdVaPlT0Bfxeh5HeF3Urs6mmgLkeIftofYjyQDg=.093bc13f-e2e1-4cac-81e3-c0ceb0884fbc@github.com>

On Tue, 26 Mar 2024 14:18:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still have quite a lot of OS400 / pase related coding in the hotspot AIX codebase. But this does not work and was never supported in OpenJDK. So we can remove this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust/remove some comments

Hi Lutz and Christoph, thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18471#issuecomment-2020898141

From mbaesken at openjdk.org  Tue Mar 26 16:26:27 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Mar 2024 16:26:27 GMT
Subject: Integrated: JDK-8328930: [AIX] remove pase related coding
In-Reply-To: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
References: <J3tbGnRJ1LKv2RaH6GYt4zFb2xhkIJaCH6G12FsWfu4=.d19b3107-f4ee-4b9c-8376-abcd45016f6a@github.com>
Message-ID: <TEUsNrkbOUb05UPYqwq28IrRp6qsf0R_qLKtHoctmwI=.2d1a6df8-9d0b-484a-b738-139e2fb428ff@github.com>

On Mon, 25 Mar 2024 13:26:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still have quite a lot of OS400 / pase related coding in the hotspot AIX codebase. But this does not work and was never supported in OpenJDK. So we can remove this.

This pull request has now been integrated.

Changeset: 153410f4
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/153410f480c372604e5825bfcd3a63f137e6a013
Stats:     416 lines in 8 files changed: 9 ins; 363 del; 44 mod

8328930: [AIX] remove pase related coding

Reviewed-by: clanger, lucy

-------------

PR: https://git.openjdk.org/jdk/pull/18471

From kevinw at openjdk.org  Tue Mar 26 17:01:49 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 26 Mar 2024 17:01:49 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v8]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <vqliNFqAU6kSlLzu0xZVqzz5G3Ao_ueOWKxu8SFKkTc=.1eed40bf-5726-438b-9ed0-c73e47e88c59@github.com>

> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
> 
> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.

Kevin Walls 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 20 additional commits since the last revision:

 - Change to jcmd VM.inspect
 - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
 - Test update
 - Show description if unknown subcommand.
 - Remove unnecessary 'events' subcommand.
 - Usage correction
 - Help to clarify this is VM inspection.  Comment to relate source to debug.cpp.
 - jcheck trailing whitespace
 - Test update omitted from previous commit.
 - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
 - ... and 10 more: https://git.openjdk.org/jdk/compare/872dc5a5...739bcbfa

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/3f566649..739bcbfa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=06-07

  Stats: 458556 lines in 4892 files changed: 36637 ins; 91690 del; 330229 mod
  Patch: https://git.openjdk.org/jdk/pull/17655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655

PR: https://git.openjdk.org/jdk/pull/17655

From amenkov at openjdk.org  Tue Mar 26 18:08:24 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 26 Mar 2024 18:08:24 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v7]
In-Reply-To: <nzsfEfEUW-DY4kF1BLvw4-0LE365dhZy89daVZwxxFk=.eae51c5a-766b-4026-9eb4-4ea477e7288a@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <nzsfEfEUW-DY4kF1BLvw4-0LE365dhZy89daVZwxxFk=.eae51c5a-766b-4026-9eb4-4ea477e7288a@github.com>
Message-ID: <hW2L9stGL6oUxxVERr3UHJUd34XQdCSA2Ml7Qc8rRXU=.0614fe40-a01e-4418-9065-aa449e0c93de@github.com>

On Thu, 21 Mar 2024 18:10:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
>> Also annotations can be changed (added/removed) by class redefinition.
>> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
>> 
>> Testing: 
>> - tier1,tier2,hs-tier5-svc;
>>  - redefineClasses/retransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comment

Can I get 2nd review plase

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18161#issuecomment-2021144086

From bhuang at openjdk.org  Tue Mar 26 18:18:39 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 26 Mar 2024 18:18:39 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v4]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/nio/channels/unixdomain/Bind.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/2517f756..0f4130a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

PR: https://git.openjdk.org/jdk/pull/18352

From coleenp at openjdk.org  Tue Mar 26 19:13:24 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 26 Mar 2024 19:13:24 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v3]
In-Reply-To: <ldeboUvSNlpUcqrqUsOAOM_o6aBWLPZ7NilyspTAPIU=.e1acd7cf-fb83-4a78-8f1b-fc7b69f66463@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <Kd1kldN0NtG8E60KQC-QlOAvYxp4IgwpDlkpb9_8ZDs=.fffba6cc-15aa-47c1-8d3f-2422753c4234@github.com>
 <aMwJLN_La9nBjwfNGS-6wwzGBrAHwaVhf7G2IvLGvPo=.477600ab-6475-4860-a81d-5f3573a257e9@github.com>
 <hcLiga2frALeRWVVRUAnkNvjLUkzbwm9EnLEDnMRQqk=.b8dbb825-e0e7-47da-be36-4f826b5f9df2@github.com>
 <ngULigXLGEgf5oJiBWJvylbQi1vihyc7sbp-JxBFtso=.63408a65-abf9-466e-a09c-312bb89a3c7d@github.com>
 <lKsxhQehvFpzK8FoRs4JQaLSsQeyQoKe9EQ1qs4eTBc=.0687675b-39ce-4f6a-ab18-e950c624e6f6@github.com>
 <EIFWxoiPJCZoEzuJmoiQJEmZJmNytP8yITdfrOo-Xr4=.d51bac99-af7c-47b5-9b3a-7e5b9c24177a@github.com>
 <ldeboUvSNlpUcqrqUsOAOM_o6aBWLPZ7NilyspTAPIU=.e1acd7cf-fb83-4a78-8f1b-fc7b69f66463@github.com>
Message-ID: <d7HqJgeH_Yyn6BBNzjdqN4QYCQ3PlYOJDhDzRpTpXx8=.346b2d92-fdb1-44c1-9a35-237c3b75a206@github.com>

On Thu, 14 Mar 2024 22:09:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> It does not matter what the `ClassFileParser` does.
>> 
>>> ` JvmtiClassFileReconstituter` performs the reverse operation.
>> 
>> True. It should know how to put the `attribute_count` value into the class file but it does not need to know how to calculate its value. What I do not like in your model is that there is no one single place which knows how to calculate this value and the existing and potential consumers should have this knowledge.
>> 
>>> They may have different `attributute_count `(that's what this bug about).
>> 
>> The bug is that the `attributute_count` field value from the class file stored in the `RecordComponent` does not match the calculated value because the invisible attribute was not saved (was ignored). My suggestion is not to store the `attributute_count` field value from the class file as it was before. The suggestion is to place the calculating function `attributute_count()` into the `RecordComponent` class.
>
>> True. It should know how to put the `attribute_count` value into the class file but it does not need to know how to calculate its value. What I do not like in your model is that there is no one single place which knows how to calculate this value and the existing and potential consumers should have this knowledge.
> 
> It **must** know how to calculate the value. Because this is number of `attribute_info_attributes` attributes that follow. And only `JvmtiClassFileReconstituter` knows how many attributes it's going to write.
> 
>> The bug is that the `attributute_count` field value from the class file stored in the `RecordComponent` does not match the calculated value because the invisible attribute was not saved (was ignored).
> 
> I'd consider this as design issue with the current implementation - `JvmtiClassFileReconstituter` gets the value from external source (`RecordComponent`) and uses it without validation.
> This approach is inconsistent with other `JvmtiClassFileReconstituter` code.
> For other similar cases it calculates record counts in place (from size of arrays, string length, from list enumerator, etc.).

So this makes sense. You only want the number of attributes that are applicable to the RecordComponent, and that is the three attributes that you then write out in the class file reconstituter: generic_signature_index, annotations and type_annotations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1539950465

From coleenp at openjdk.org  Tue Mar 26 19:13:24 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 26 Mar 2024 19:13:24 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v7]
In-Reply-To: <nzsfEfEUW-DY4kF1BLvw4-0LE365dhZy89daVZwxxFk=.eae51c5a-766b-4026-9eb4-4ea477e7288a@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <nzsfEfEUW-DY4kF1BLvw4-0LE365dhZy89daVZwxxFk=.eae51c5a-766b-4026-9eb4-4ea477e7288a@github.com>
Message-ID: <pS1DJk3SR7Fz45JkjQPKbvXn0aZUMtEu-S7lJVleVig=.09da372c-4f7d-483c-9ef7-ce2e19b50e3e@github.com>

On Thu, 21 Mar 2024 18:10:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
>> Also annotations can be changed (added/removed) by class redefinition.
>> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
>> 
>> Testing: 
>> - tier1,tier2,hs-tier5-svc;
>>  - redefineClasses/retransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comment

This looks good.

test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 30:

> 28:  *
> 29:  * @library /test/lib
> 30:  * @run shell MakeJAR.sh retransformAgent

Does the presence of attributes mean you can't use the simpler RedefineClassHelper that the tests in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses use?

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18161#pullrequestreview-1961478084
PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1539953736

From kevinw at openjdk.org  Tue Mar 26 20:00:53 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 26 Mar 2024 20:00:53 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v15]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <mtRDhj44eF5_DQmeYTy_jrTWSoT9zZe8MtVVet8Uixk=.8eb70b9a-9a3c-42b6-a72e-f04cda25e743@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge
 - Missing code doc nit.
 - Missing code doc nit.
 - RMIConnectionImpl_Stub also should explicity inherit the unchecked UOE.
 - Clarify JMXConnector equivalence comment.
 - RMIConnectionImpl needs to explicity inherit the unchecked UOE.
 - typo
 - Javadoc update
 - Remove unnecessary constructor in private class
 - Merge remote-tracking branch 'upstream/master' into 8326666_SubjectDelegation_remove
 - ... and 14 more: https://git.openjdk.org/jdk/compare/cc1800fa...903ce55b

-------------

Changes: https://git.openjdk.org/jdk/pull/18025/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=14
  Stats: 2026 lines in 35 files changed: 214 ins; 1632 del; 180 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

PR: https://git.openjdk.org/jdk/pull/18025

From amenkov at openjdk.org  Tue Mar 26 20:24:23 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 26 Mar 2024 20:24:23 GMT
Subject: RFR: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE [v7]
In-Reply-To: <pS1DJk3SR7Fz45JkjQPKbvXn0aZUMtEu-S7lJVleVig=.09da372c-4f7d-483c-9ef7-ce2e19b50e3e@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
 <nzsfEfEUW-DY4kF1BLvw4-0LE365dhZy89daVZwxxFk=.eae51c5a-766b-4026-9eb4-4ea477e7288a@github.com>
 <pS1DJk3SR7Fz45JkjQPKbvXn0aZUMtEu-S7lJVleVig=.09da372c-4f7d-483c-9ef7-ce2e19b50e3e@github.com>
Message-ID: <Jq9W7vCdoFkTwL4UpRh9sDhEfvD5WtV_vwxXMUEXIcU=.6a53da6a-0e47-4527-8a39-36e990beccd9@github.com>

On Tue, 26 Mar 2024 19:10:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added comment
>
> test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 30:
> 
>> 28:  *
>> 29:  * @library /test/lib
>> 30:  * @run shell MakeJAR.sh retransformAgent
> 
> Does the presence of attributes mean you can't use the simpler RedefineClassHelper that the tests in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses use?

RedefineClassHelper supports only class redefinition, the test needs class retransformation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18161#discussion_r1540044735

From sspitsyn at openjdk.org  Tue Mar 26 20:57:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 26 Mar 2024 20:57:31 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v8]
In-Reply-To: <vqliNFqAU6kSlLzu0xZVqzz5G3Ao_ueOWKxu8SFKkTc=.1eed40bf-5726-438b-9ed0-c73e47e88c59@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <vqliNFqAU6kSlLzu0xZVqzz5G3Ao_ueOWKxu8SFKkTc=.1eed40bf-5726-438b-9ed0-c73e47e88c59@github.com>
Message-ID: <m_9BPcu4h0YPRpi1PEWENagXmwoFVkTgmoNNKBFExis=.0761589b-96b1-44a8-8c30-8e03eac41125@github.com>

On Tue, 26 Mar 2024 17:01:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls 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 20 additional commits since the last revision:
> 
>  - Change to jcmd VM.inspect
>  - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
>  - Test update
>  - Show description if unknown subcommand.
>  - Remove unnecessary 'events' subcommand.
>  - Usage correction
>  - Help to clarify this is VM inspection.  Comment to relate source to debug.cpp.
>  - jcheck trailing whitespace
>  - Test update omitted from previous commit.
>  - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/0a4d6c74...739bcbfa

It looks good in general. Still need to review the test.

src/hotspot/share/services/diagnosticCommand.cpp line 59:

> 57: #include "runtime/jniHandles.hpp"
> 58: #include "runtime/os.hpp"
> 59: #include "runtime/threads.hpp"

Is the `#include` lines a leftover from the initial version? Do we still need them?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17655#pullrequestreview-1961713172
PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1540097938

From sspitsyn at openjdk.org  Tue Mar 26 21:12:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 26 Mar 2024 21:12:27 GMT
Subject: RFR: 8318026: jcmd should provide access to low-level JVM debug
 information [v8]
In-Reply-To: <vqliNFqAU6kSlLzu0xZVqzz5G3Ao_ueOWKxu8SFKkTc=.1eed40bf-5726-438b-9ed0-c73e47e88c59@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <vqliNFqAU6kSlLzu0xZVqzz5G3Ao_ueOWKxu8SFKkTc=.1eed40bf-5726-438b-9ed0-c73e47e88c59@github.com>
Message-ID: <EQYA0h5u0_0weYReleehd8kRG30qjN5hgN4W7Qm1FuM=.ea8366d4-c99b-4a02-bd5d-1fa390c925dc@github.com>

On Tue, 26 Mar 2024 17:01:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls 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 20 additional commits since the last revision:
> 
>  - Change to jcmd VM.inspect
>  - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
>  - Test update
>  - Show description if unknown subcommand.
>  - Remove unnecessary 'events' subcommand.
>  - Usage correction
>  - Help to clarify this is VM inspection.  Comment to relate source to debug.cpp.
>  - jcheck trailing whitespace
>  - Test update omitted from previous commit.
>  - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/730651a5...739bcbfa

Kevin, the PR title needs an update to match the CR title:
`jcmd should provide access to detailed JVM object information`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2021479991

From cjplummer at openjdk.org  Tue Mar 26 21:45:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 26 Mar 2024 21:45:23 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v9]
In-Reply-To: <msScnhT6AfK5kOl0zOQr4U88V0JeF4qrr8xPCT3LXIw=.aae43b38-dc57-43aa-b462-72713ff5857e@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <msScnhT6AfK5kOl0zOQr4U88V0JeF4qrr8xPCT3LXIw=.aae43b38-dc57-43aa-b462-72713ff5857e@github.com>
Message-ID: <Di371ecjc13u_EARd0yDPUTYj7R3F5TAbDRtBQp_QT8=.86208d9b-3324-4e0f-ae9f-7cb5fc8f541d@github.com>

On Tue, 26 Mar 2024 13:57:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestions from Chris for diagnosticCommand.cpp

We have a couple of additional documents that need to be updated:

https://docs.oracle.com/en/java/javase/21/troubleshoot/command-line-options1.html#GUID-A84ECBFB-B6CF-44C3-B627-58BB509C8D05

This is an Oracle produced document. A `docs` CR will need to be filed to get it updated (and I see it is already appears out-of-date w.r.t. `HeapDumpGzipLevel`)

    src/java.base/share/man/java.1

Much like jcmd.1, this one is also derived from a closed markdown file, so eventually someone internal at Oracle will need to update the markdown file, but we need to see the proposed changes in the java.1 file first. This document is also missing the `HeapDumpGzipLevel` update.

If your counting, there are 7 places where documentation will need updating

1. Oracle trouble shooting guide
2. open java.1
3. closed markdown file that java.1 is generated from
4. open jcmd.1
5. closed markdown file that jcmd.1 is generated from
6. globals.hpp
7. jcmd help output

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2021523855

From kevinw at openjdk.org  Tue Mar 26 21:55:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 26 Mar 2024 21:55:38 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>

> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
> 
> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Undo include

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/739bcbfa..bf5e4b26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655

PR: https://git.openjdk.org/jdk/pull/17655

From kevinw at openjdk.org  Tue Mar 26 21:55:41 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 26 Mar 2024 21:55:41 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v8]
In-Reply-To: <m_9BPcu4h0YPRpi1PEWENagXmwoFVkTgmoNNKBFExis=.0761589b-96b1-44a8-8c30-8e03eac41125@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <vqliNFqAU6kSlLzu0xZVqzz5G3Ao_ueOWKxu8SFKkTc=.1eed40bf-5726-438b-9ed0-c73e47e88c59@github.com>
 <m_9BPcu4h0YPRpi1PEWENagXmwoFVkTgmoNNKBFExis=.0761589b-96b1-44a8-8c30-8e03eac41125@github.com>
Message-ID: <PlsVJv9IJ9kEyfJdsSN89MQWSeTF78uP6ddUzJV0zGI=.e6173ba6-9f25-40f6-859a-c0e1bc5072bb@github.com>

On Tue, 26 Mar 2024 20:52:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls 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 20 additional commits since the last revision:
>> 
>>  - Change to jcmd VM.inspect
>>  - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
>>  - Test update
>>  - Show description if unknown subcommand.
>>  - Remove unnecessary 'events' subcommand.
>>  - Usage correction
>>  - Help to clarify this is VM inspection.  Comment to relate source to debug.cpp.
>>  - jcheck trailing whitespace
>>  - Test update omitted from previous commit.
>>  - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/91a3bbb4...739bcbfa
>
> src/hotspot/share/services/diagnosticCommand.cpp line 59:
> 
>> 57: #include "runtime/jniHandles.hpp"
>> 58: #include "runtime/os.hpp"
>> 59: #include "runtime/threads.hpp"
> 
> Is the `#include` lines a leftover from the initial version? Do we still need them?

Yes, undoing that, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1540153524

From sspitsyn at openjdk.org  Tue Mar 26 22:50:24 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 26 Mar 2024 22:50:24 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
Message-ID: <4xUIgYy6-xY9KSD2B8kz2PJJeBNHQGbWTtzXUJEyyk0=.1ba27143-387b-4e28-a576-559fe71d2869@github.com>

On Tue, 26 Mar 2024 21:55:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Undo include

test/hotspot/jtreg/serviceability/dcmd/vm/VMInspectTest.java line 217:

> 215:         t.start();
> 216:       }
> 217:     }

Nit: The indents in the `work()` method has to be 4, not 2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1540202705

From sspitsyn at openjdk.org  Tue Mar 26 22:55:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 26 Mar 2024 22:55:23 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
Message-ID: <OpIEF6MeqH6h1rhkyIJWIbPTWSA_IhE8kqfejyNiFPc=.77937618-c7e1-4ae1-878d-03328e716362@github.com>

On Tue, 26 Mar 2024 21:55:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Undo include

test/hotspot/jtreg/serviceability/dcmd/vm/VMInspectTest.java line 123:

> 121:         ptr = findPointer(threadPrintOutput, waiting_on_mylock, 1);
> 122:         output = executor.execute("VM.inspect " + pointerText(ptr));
> 123:         System.out.println(output);

Nit: May I ask you to add empty lines after the lines 101 and 123 to make the code more readable?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1540205562

From amenkov at openjdk.org  Tue Mar 26 23:58:27 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 26 Mar 2024 23:58:27 GMT
Subject: Integrated: JDK-8315575: Retransform of record class with record
 component annotation fails with CFE
In-Reply-To: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
References: <Pa3hPg3KfAckiYEghD-avaxH7C_yR4cQC896IZCvfjY=.6b79f8d7-71a1-4aeb-a5af-74b0e9f01be0@github.com>
Message-ID: <xKjbM2ZzxEkT5UxSh744U4TOwQMkg95ydTCTmPwN9AM=.ba006709-654f-4d2f-b219-9e94e891ce0c@github.com>

On Fri, 8 Mar 2024 02:54:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may skip RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations.
> Also annotations can be changed (added/removed) by class redefinition.
> The fix removes attributes_count from RecordComponent; JvmtiClassFileReconstituter calculates correct attributes_count generating class bytes.
> 
> Testing: 
> - tier1,tier2,hs-tier5-svc;
>  - redefineClasses/retransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

This pull request has now been integrated.

Changeset: 8fc9097b
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8fc9097b3720314ef7efaf1f3ac31898c8d6ca19
Stats:     208 lines in 5 files changed: 190 ins; 10 del; 8 mod

8315575: Retransform of record class with record component annotation fails with CFE

Reviewed-by: sspitsyn, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/18161

From sspitsyn at openjdk.org  Wed Mar 27 02:57:40 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 27 Mar 2024 02:57:40 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v3]
In-Reply-To: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
Message-ID: <f_iHo9iIuPy5KGO7EOUjyc3aMTuaa2u6aJGP2cjYleo=.8533e4f6-b2dc-4758-afdb-262002e0c821@github.com>

> This PR fixes a synchronization issue in the test:
>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>   
> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
> 
> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
> 
> Testing:
>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5

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: updated test with one more call to notifyAtBreakpoint to reset the native state
 - 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18419/files
  - new: https://git.openjdk.org/jdk/pull/18419/files/7843111d..1502492f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18419&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18419&range=01-02

  Stats: 61204 lines in 2409 files changed: 11744 ins; 7474 del; 41986 mod
  Patch: https://git.openjdk.org/jdk/pull/18419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18419/head:pull/18419

PR: https://git.openjdk.org/jdk/pull/18419

From cjplummer at openjdk.org  Wed Mar 27 05:15:25 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 27 Mar 2024 05:15:25 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v3]
In-Reply-To: <f_iHo9iIuPy5KGO7EOUjyc3aMTuaa2u6aJGP2cjYleo=.8533e4f6-b2dc-4758-afdb-262002e0c821@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <f_iHo9iIuPy5KGO7EOUjyc3aMTuaa2u6aJGP2cjYleo=.8533e4f6-b2dc-4758-afdb-262002e0c821@github.com>
Message-ID: <I-vZXCZEj4BR3AjOFOGssDviKdxKd8J3EozH_Gr5le0=.9df74602-b598-4d27-880e-d3368349cb99@github.com>

On Wed, 27 Mar 2024 02:57:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This PR fixes a synchronization issue in the test:
>>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>>   
>> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
>> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
>> 
>> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
>> 
>> Testing:
>>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5
>
> 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: updated test with one more call to notifyAtBreakpoint to reset the native state
>  - 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout

test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/PopFrameTest.java line 147:

> 145:             }
> 146:             log("Main #B.2: got expected JVMTI_ERROR_NONE");
> 147:             notifyAtBreakpoint(); // needed to reset the native state

This doesn't make much sense to me.  The purpose of `notifyAtBreakpoint()` is to unblock the Breakpoint event handler, which is waiting for this notify. However, the event handler can only ever be entered once, yet we have a previous `noitfyBreakpoint()` above and a 3rd `notifyAtBreakpoint()` below. It seems that this call and the one below are no-ops. I don't see how bp_sync_reached ever gets set true again after the first `notifyAtBreakpoint()` call is made.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1540476191

From cjplummer at openjdk.org  Wed Mar 27 05:47:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 27 Mar 2024 05:47:23 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
Message-ID: <IML33eLfWNHULkwhOJ65UQ06kjnJb_ZgfaU4-grtejA=.429c10ea-0f17-4723-a405-35584ac94dd1@github.com>

On Tue, 26 Mar 2024 21:55:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Undo include

It looks like the test only inspects a thread and a java object. Perhaps you could add tests for additional VM objects. Maybe grab a frame PC from a thread stack trace.

src/hotspot/share/services/diagnosticCommand.hpp line 590:

> 588:   }
> 589:   static const char* description() {
> 590:     return "Inspect VM object at address.";

Maybe distinguishing between java heap objects and VM objects would be useful to the reader/user.

src/hotspot/share/utilities/debug.cpp line 679:

> 677: }
> 678: 
> 679: // Additional "good oop" checks, separate method to not disturb existing asserts.

Suggestion:

// Additional "good oop" checks. Separate method to not disturb existing asserts.

src/hotspot/share/utilities/debug.cpp line 680:

> 678: 
> 679: // Additional "good oop" checks, separate method to not disturb existing asserts.
> 680: extern "C" bool dbg_is_good_oop_detailed(oopDesc* o) {

What was the motivation for adding this? Is this copied from other HS code? How do we know it's doing a good enough job of verification? What happens if verification is not thorough enough?

test/hotspot/jtreg/serviceability/dcmd/vm/VMInspectTest.java line 83:

> 81:         }
> 82: 
> 83:         // Tests where enabled:

Suggestion:

        // Tests run with VM.inspect support enabled:

-------------

PR Review: https://git.openjdk.org/jdk/pull/17655#pullrequestreview-1962319603
PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1540483489
PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1540485389
PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1540486518
PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1540492385

From sspitsyn at openjdk.org  Wed Mar 27 06:44:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 27 Mar 2024 06:44:37 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
Message-ID: <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>

> This PR fixes a synchronization issue in the test:
>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>   
> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
> 
> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
> 
> Testing:
>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: improve diagnostics and reliability

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18419/files
  - new: https://git.openjdk.org/jdk/pull/18419/files/1502492f..f4f92e92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18419&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18419&range=02-03

  Stats: 19 lines in 2 files changed: 9 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18419/head:pull/18419

PR: https://git.openjdk.org/jdk/pull/18419

From sspitsyn at openjdk.org  Wed Mar 27 07:01:34 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 27 Mar 2024 07:01:34 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v3]
In-Reply-To: <I-vZXCZEj4BR3AjOFOGssDviKdxKd8J3EozH_Gr5le0=.9df74602-b598-4d27-880e-d3368349cb99@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <f_iHo9iIuPy5KGO7EOUjyc3aMTuaa2u6aJGP2cjYleo=.8533e4f6-b2dc-4758-afdb-262002e0c821@github.com>
 <I-vZXCZEj4BR3AjOFOGssDviKdxKd8J3EozH_Gr5le0=.9df74602-b598-4d27-880e-d3368349cb99@github.com>
Message-ID: <nuF8nyphByAJ82uiap_YKpdq34BiqgMSkuFg3jlaQpU=.44f45b9a-e835-4df5-8ee3-f61e6f5cd16c@github.com>

On Wed, 27 Mar 2024 05:12:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> 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: updated test with one more call to notifyAtBreakpoint to reset the native state
>>  - 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/PopFrameTest.java line 147:
> 
>> 145:             }
>> 146:             log("Main #B.2: got expected JVMTI_ERROR_NONE");
>> 147:             notifyAtBreakpoint(); // needed to reset the native state
> 
> This doesn't make much sense to me.  The purpose of `notifyAtBreakpoint()` is to unblock the Breakpoint event handler, which is waiting for this notify. However, the event handler can only ever be entered once, yet we have a previous `noitfyBreakpoint()` above and a 3rd `notifyAtBreakpoint()` below. It seems that this call and the one below are no-ops. I don't see how bp_sync_reached ever gets set true again after the first `notifyAtBreakpoint()` call is made.

Thank you for the comment, Chris. You are right.
I've already figured my mistake/confusion (shared it on our team meeting) but tested my update which has been just pushed. My analysis in the bug report is incorrect, I'll update it soon. In fact, I don't really know what was the root cause of this deadlock because I can't reproduce the issue. Also, it is not easy to figure out by the code observation. The only idea I have is that it was a spurious wakeup on the `wait()` at line 52 in the Breakpoint handler of the native agent. I've added a couple of checks for robustness and added more tracing to get more details if this happen again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1540566744

From stuefe at openjdk.org  Wed Mar 27 09:36:29 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 27 Mar 2024 09:36:29 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
Message-ID: <FkpkXtC4BSEXGM0uCYWiroHZ4Y4MTdqhjfgb_AbCVOI=.ef819314-1dc5-4460-a807-400887fbeada@github.com>

On Tue, 26 Mar 2024 21:55:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Undo include

I am still feeling uneasy about this new command. I can see its potential usefulness, but as stated before would prefer it being limited to debug-only JVMs.

- jcmd can be exposed remotely, e.g., via jmx. I am not sure whether other solutions exist, but exposing jcmd beyond the immediate box the JVM runs on is something many folks want, and that is technically easy to do. So, customer-local solutions may exist for that, and the reach of jcmd may be larger than we think.
- the underlying functionality for print_location was written with debugging and error analysis in mind. We keep adding functionality there. I don't think developers adding to that function have in mind that this functionality may be exposed, possibly remotely.

In my opinion, UnlockDiagnosticVMOptions is not a good enough safeguard since it guards a whole swathe of switches that we may instruct the customer to enable. Once enabled, my experience is that UnlockDiagnosticVMOptions often lingers around. It is not unusual for customer scenarios to have set +UnlockDiagnosticVMOptions because of some years ago support cases.

If others feel this command is safe enough, I'll shut up and be quiet, since I cannot think up a concrete attack scenario.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2022310874

From kevinw at openjdk.org  Wed Mar 27 12:23:50 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 27 Mar 2024 12:23:50 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v10]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <IPu3hQItKhE-XbC1uFD5ApSeSlIiI84hoNa1spfO_Io=.3fab1d84-a2cb-433f-905f-748ba4157d92@github.com>

> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
> 
> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - Argument to be named address.
 - test nit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/bf5e4b26..837154c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=08-09

  Stats: 28 lines in 3 files changed: 6 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/17655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655

PR: https://git.openjdk.org/jdk/pull/17655

From mbaesken at openjdk.org  Wed Mar 27 12:39:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 27 Mar 2024 12:39:23 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v9]
In-Reply-To: <Di371ecjc13u_EARd0yDPUTYj7R3F5TAbDRtBQp_QT8=.86208d9b-3324-4e0f-ae9f-7cb5fc8f541d@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <msScnhT6AfK5kOl0zOQr4U88V0JeF4qrr8xPCT3LXIw=.aae43b38-dc57-43aa-b462-72713ff5857e@github.com>
 <Di371ecjc13u_EARd0yDPUTYj7R3F5TAbDRtBQp_QT8=.86208d9b-3324-4e0f-ae9f-7cb5fc8f541d@github.com>
Message-ID: <DXqhUZufg0tyNDOq8ysGagV0wDpKBuOKPQd8mIW-3EU=.a8453cf5-0aa7-4bed-9159-da248d0f4e1d@github.com>

On Tue, 26 Mar 2024 21:42:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> A docs CR will need to be filed to get it updated (and I see it is already appears out-of-date w.r.t. HeapDumpGzipLevel)

Sorry maybe it is maybe obvious for you but where should I open a "docs CR", would that be a separate JBS issue with Component name docs ?
Should I include the HeapDumpGzipLevel in the same "docs CR" (but this might be bad for potential backporting) ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2022660444

From mbaesken at openjdk.org  Wed Mar 27 13:44:42 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 27 Mar 2024 13:44:42 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
Message-ID: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>

> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
> Syntax : GC.heap_dump [options] <filename>
> 
> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
> 
> new syntax :
> GC.heap_dump [options] <filename> .. has precedence over second option
> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
> 
> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust java.1 man page

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18190/files
  - new: https://git.openjdk.org/jdk/pull/18190/files/b414b1be..8039b9a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18190&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18190&range=08-09

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18190.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18190/head:pull/18190

PR: https://git.openjdk.org/jdk/pull/18190

From kevinw at openjdk.org  Wed Mar 27 16:54:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 27 Mar 2024 16:54:26 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v10]
In-Reply-To: <IPu3hQItKhE-XbC1uFD5ApSeSlIiI84hoNa1spfO_Io=.3fab1d84-a2cb-433f-905f-748ba4157d92@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <IPu3hQItKhE-XbC1uFD5ApSeSlIiI84hoNa1spfO_Io=.3fab1d84-a2cb-433f-905f-748ba4157d92@github.com>
Message-ID: <Ewr1Yj89Sndx3F-HcIR7zchPTIwSL7T6ICGKYR9k_B0=.91746df7-e0ed-4f3a-a237-21213f51d280@github.com>

On Wed, 27 Mar 2024 12:23:50 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Argument to be named address.
>  - test nit

Thanks for the comments, addressed nits and will update further on the remaining points.

Thomas thanks for your comments.  Yes, you do see stale CompilerCommand directives etc... hanging around at times, we can only encourage good housekeeping!  Remote access over JMX is not required for this command (hidden).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2023297192

From simonis at openjdk.org  Wed Mar 27 17:32:32 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 27 Mar 2024 17:32:32 GMT
Subject: RFR: 8329204: Diagnostic command for zeroing unused parts of the heap
Message-ID: <b4mPQ-O25iKRZTAsKCoUJ2IrB78D_aEYs1kZRNRS4O4=.e64e5fee-52f4-4543-8c5e-3d6dd60cd8d7@github.com>

Diagnostic command for zeroing unused parts of the heap

I propose to add a new diagnostic command `System.zero_unused_memory` which zeros out all unused parts of the heap. The name of the command is intentionally GC/heap agnostic because in the future it might be extended to also zero unused parts of the Metaspace and/or CodeCache.

Currently `System.zero_unused_memory` triggers a full GC and afterwards zeros unused parts of the heap. Zeroing can help snapshotting technologies like [CRIU][1] or [Firecracker][2] to shrink the snapshot size of VMs/containers with running JVM processes because pages which only contain zero bytes can be easily removed from the image by making the image *sparse* (e.g. with [`fallocate -p`][3]).

Notice that uncommitting unused heap parts in the JVM doesn't help in the context of virtualization (e.g. KVM/Firecracker) because from the host perspective they are still dirty and can't be easily removed from the snapshot image because they usually contain some non-zero data. More details can be found in my FOSDEM talk ["Zeroing and the semantic gap between host and guest"][4].

Furthermore, removing pages which only contain zero bytes (i.e. "empty pages") from a snapshot image not only decreases the image size but also speeds up the restore process because empty pages don't have to be read from the image file but will be populated by the kernel zero page first until they are used for the first time. This also decreases the initial memory footprint of a restored process. 

An additional argument for memory zeroing is security. By zeroing unused heap parts, we can make sure that secrets contained in unreferenced Java objects are deleted. Something that's currently impossibly to achieve from Java because even if a Java program zeroes out arrays with sensitive data after usage, it can never guarantee that the corresponding object hasn't already been moved by the GC and an old, unreferenced copy of that data still exists somewhere in the heap.

A prototype implementation for this proposal for Serial, Parallel, G1 and Shenandoah GC is available in the linked pull request.

[1]: https://criu.org
[2]: https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md
[3]: https://man7.org/linux/man-pages/man1/fallocate.1.html
[4]: https://fosdem.org/2024/schedule/event/fosdem-2024-3454-zeroing-and-the-semantic-gap-between-host-and-guest/

-------------

Commit messages:
 - Make VM_ZeroUnusedMemory a VM_GC_Sync_Operation
 - Implement unused memory zeroing for ShenadoahGC and move the zeroing part into a VM operation
 - Implement unused memory zeroing for G1GC
 - Implement unused memory zeroing for ParallelGC
 - 8329204: Diagnostic command for zeroing unused parts of the heap

Changes: https://git.openjdk.org/jdk/pull/18521/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18521&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329204
  Stats: 187 lines in 29 files changed: 187 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18521.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18521/head:pull/18521

PR: https://git.openjdk.org/jdk/pull/18521

From simonis at openjdk.org  Wed Mar 27 18:10:34 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 27 Mar 2024 18:10:34 GMT
Subject: RFR: 8329204: Diagnostic command for zeroing unused parts of the
 heap [v2]
In-Reply-To: <b4mPQ-O25iKRZTAsKCoUJ2IrB78D_aEYs1kZRNRS4O4=.e64e5fee-52f4-4543-8c5e-3d6dd60cd8d7@github.com>
References: <b4mPQ-O25iKRZTAsKCoUJ2IrB78D_aEYs1kZRNRS4O4=.e64e5fee-52f4-4543-8c5e-3d6dd60cd8d7@github.com>
Message-ID: <p4sSye_a4X9sPx6nscEVzKvZBc50BEYDpIBtKu1ObB8=.42fd8b03-97af-4b4c-bd00-9da18e86e3e4@github.com>

> Diagnostic command for zeroing unused parts of the heap
> 
> I propose to add a new diagnostic command `System.zero_unused_memory` which zeros out all unused parts of the heap. The name of the command is intentionally GC/heap agnostic because in the future it might be extended to also zero unused parts of the Metaspace and/or CodeCache.
> 
> Currently `System.zero_unused_memory` triggers a full GC and afterwards zeros unused parts of the heap. Zeroing can help snapshotting technologies like [CRIU][1] or [Firecracker][2] to shrink the snapshot size of VMs/containers with running JVM processes because pages which only contain zero bytes can be easily removed from the image by making the image *sparse* (e.g. with [`fallocate -p`][3]).
> 
> Notice that uncommitting unused heap parts in the JVM doesn't help in the context of virtualization (e.g. KVM/Firecracker) because from the host perspective they are still dirty and can't be easily removed from the snapshot image because they usually contain some non-zero data. More details can be found in my FOSDEM talk ["Zeroing and the semantic gap between host and guest"][4].
> 
> Furthermore, removing pages which only contain zero bytes (i.e. "empty pages") from a snapshot image not only decreases the image size but also speeds up the restore process because empty pages don't have to be read from the image file but will be populated by the kernel zero page first until they are used for the first time. This also decreases the initial memory footprint of a restored process. 
> 
> An additional argument for memory zeroing is security. By zeroing unused heap parts, we can make sure that secrets contained in unreferenced Java objects are deleted. Something that's currently impossibly to achieve from Java because even if a Java program zeroes out arrays with sensitive data after usage, it can never guarantee that the corresponding object hasn't already been moved by the GC and an old, unreferenced copy of that data still exists somewhere in the heap.
> 
> A prototype implementation for this proposal for Serial, Parallel, G1 and Shenandoah GC is available in the linked pull request.
> 
> [1]: https://criu.org
> [2]: https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md
> [3]: https://man7.org/linux/man-pages/man1/fallocate.1.html
> [4]: https://fosdem.org/2024/schedule/event/fosdem-2024-3454-zeroing-and-the-semantic-gap-between-host-and-guest/

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Fix build error on MacOs (with clang, if we use 'override' for a virtual method we have to use it for all methods to avoid '-Winconsistent-missing-override')

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18521/files
  - new: https://git.openjdk.org/jdk/pull/18521/files/b06aa327..4264e53d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18521&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18521&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18521.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18521/head:pull/18521

PR: https://git.openjdk.org/jdk/pull/18521

From kevinw at openjdk.org  Wed Mar 27 18:31:50 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 27 Mar 2024 18:31:50 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <IML33eLfWNHULkwhOJ65UQ06kjnJb_ZgfaU4-grtejA=.429c10ea-0f17-4723-a405-35584ac94dd1@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
 <IML33eLfWNHULkwhOJ65UQ06kjnJb_ZgfaU4-grtejA=.429c10ea-0f17-4723-a405-35584ac94dd1@github.com>
Message-ID: <Yyi54ykxVpU2Zar5450F4A-sk1vTnR7CYmoBVHH5pBc=.4ac2dc66-053e-4f2e-a7fe-d1ec681855e1@github.com>

On Wed, 27 Mar 2024 05:44:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> It looks like the test only inspects a thread and a java object. Perhaps you could add tests for additional VM objects. Maybe grab a frame PC from a thread stack trace.

Yes - added a couple of metadata tests, and a compiled method test, which gets an address from Events info.  We know that should resolve to a compiled method (if we have such an event, so this copes if there are none).


Also the VM.info and Thread.print runs with the CommandExecutor are now silent.  They are long, and max out the test log file and make it truncate.  That output could mainly be useful if  the regexes can't match items, but the output format should be reproducible in a new run.  Also if we fail to find something we need, like a thread id, it will print the full output it searched.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2023578758

From kevinw at openjdk.org  Wed Mar 27 18:31:50 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 27 Mar 2024 18:31:50 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v11]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <dOvDzyHCw8sJixlFGHxhcBhG7ttmqB33pNo5WhIqnKk=.5f505681-d7de-48c4-909a-437852d2cc4d@github.com>

> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
> 
> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Test more pointer types: compiled method and metadata.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/837154c1..9ed958f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=09-10

  Stats: 58 lines in 1 file changed: 46 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655

PR: https://git.openjdk.org/jdk/pull/17655

From cjplummer at openjdk.org  Wed Mar 27 18:42:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 27 Mar 2024 18:42:23 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <FkpkXtC4BSEXGM0uCYWiroHZ4Y4MTdqhjfgb_AbCVOI=.ef819314-1dc5-4460-a807-400887fbeada@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
 <FkpkXtC4BSEXGM0uCYWiroHZ4Y4MTdqhjfgb_AbCVOI=.ef819314-1dc5-4460-a807-400887fbeada@github.com>
Message-ID: <Eh8mqo-MHczioKlpe_o_cvgpWZ9kminPmqNRkKPk0lA=.35465d6a-5668-4dbd-99c9-a43387b4915a@github.com>

On Wed, 27 Mar 2024 09:33:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In my opinion, UnlockDiagnosticVMOptions is not a good enough safeguard since it guards a whole swathe of switches that we may instruct the customer to enable. Once enabled, my experience is that UnlockDiagnosticVMOptions often lingers around. It is not unusual for customer scenarios to have set +UnlockDiagnosticVMOptions because of some years ago support cases.

I think we also need to consider the flip side of this argument. Is this something that some customers might want to always enable, but don't want to always have UnlockDiagnosticVMOptions enabled. A new command line flag would be needed in that case.

Also, isn't UnlockDiagnosticVMOptions meant for enabling the use of diagnostic command line flags? Do we have examples of it enabling a hotspot feature that does not also require setting a diagnostic command line flag?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2023675637

From cjplummer at openjdk.org  Wed Mar 27 20:10:50 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 27 Mar 2024 20:10:50 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
Message-ID: <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>

On Wed, 27 Mar 2024 06:44:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This PR fixes a synchronization issue in the test:
>>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>>   
>> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
>> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
>> 
>> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
>> 
>> Testing:
>>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: improve diagnostics and reliability

test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/PopFrameTest.java line 148:

> 146:             log("Main #B.2: got expected JVMTI_ERROR_NONE");
> 147:             resumeThread(testTaskThread);
> 148: 

You probably don't need this minor edit or the copyright update any more.

However, it's still unclear to me how the ensureAtBreakpoint() below is suppose to work if we already called notifyAtBreakpoint() between the 1st and 2nd ensureAtBreakpoint(). From what I can tell, notifyAtBreakpoint() clears the flag that ensureAtBreakpoint() checks for, and there is no 2nd breakpoint to set it again. I would expect the ensureAtBreakpoint() below to always wait indefinitely, but that doesn't appear to be the case. So how is this working? I must be missing something.

test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 58:

> 56:   LOG("Breakpoint: In method TestTask.B(): after sync section\n");
> 57: 
> 58:   if (do_pop_frame != JNI_FALSE) {

Suggestion:

  if (do_pop_frame) {

test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 161:

> 159:   int attempts = 0;
> 160:   while (!bp_sync_reached) {
> 161:     LOG("Main: ensureAtBreakpoint: waitig 5 millis\n");

Suggestion:

    LOG("Main: ensureAtBreakpoint: waiting 10 millis\n");


I think this should be moved directly above the wait(10) call.

test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 163:

> 161:     LOG("Main: ensureAtBreakpoint: waitig 5 millis\n");
> 162:     if (++attempts > 100) {
> 163:       fatal(jni, "Main: ensureAtBreakpoint: waited 1 sec");

1 second isn't very long when you are talking about something that is relying on debugger/debuggee communication. Maybe wait 100ms at a time for a total of 10 seconds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1541957419
PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1541958086
PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1541947950
PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1541960905

From dcubed at openjdk.org  Wed Mar 27 20:30:36 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 27 Mar 2024 20:30:36 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
Message-ID: <_7Oa2vFPXsQ_axKlTcLeDrBsSW_q6iuEsRqruErpj8k=.45a5bc91-c9cc-46f5-8fe7-4abbfd34c9b4@github.com>

On Wed, 27 Mar 2024 20:08:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: improve diagnostics and reliability
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 163:
> 
>> 161:     LOG("Main: ensureAtBreakpoint: waitig 5 millis\n");
>> 162:     if (++attempts > 100) {
>> 163:       fatal(jni, "Main: ensureAtBreakpoint: waited 1 sec");
> 
> 1 second isn't very long when you are talking about something that is relying on debugger/debuggee communication. Maybe wait 100ms at a time for a total of 10 seconds.

Caught this comment in passing. Delays like this should be scaled with
defaultTimeoutFactor so that test tasks that invoke tests with options
that can slow the test down, e.g., `-Xcomp`, can be accommodated.

I believe the defaultTimeoutFact for `-Xcomp` test tasks gets bumped
from 4 to 10.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1541986223

From jjg at openjdk.org  Wed Mar 27 22:08:57 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 27 Mar 2024 22:08:57 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc
 comments
Message-ID: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>

Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.

The work can be thought of as in 3 parts:

1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.

2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.

     *  Dangling documentation comments are handled as follows.
     *  1. {@code Scanner} adds all doc comments to a queue of
     *     recent doc comments. The queue is flushed whenever
     *     it is known that the recent doc comments should be
     *     ignored and should not cause any warnings.
     *  2. The primary documentation comment is the one obtained
     *     from the first token of any declaration.
     *     (using {@code token.getDocComment()}.
     *  3. At the end of the "signature" of the declaration
     *     (that is, before any initialization or body for the
     *     declaration) any other "recent" comments are saved
     *     in a map using the primary comment as a key,
     *     using this method, {@code saveDanglingComments}.
     *  4. When the tree node for the declaration is finally
     *     available, and the primary comment, if any,
     *     is "attached", (in {@link #attach}) any related
     *     dangling comments are also attached to the tree node
     *     by registering them using the {@link #deferredLintHandler}.
     *  5. (Later) Warnings may be genereated for the dangling
     *     comments, subject to the {@code -Xlint} and
     *     {@code @SuppressWarnings}.


3.  Updates to the make files to disable the warnings in modules for which the 
warning is generated.  This is often because of the confusing use of `/**` to
create box or other standout comments.

-------------

Commit messages:
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303689
  Stats: 477 lines in 60 files changed: 368 ins; 5 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

PR: https://git.openjdk.org/jdk/pull/18527

From prappo at openjdk.org  Wed Mar 27 22:44:31 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 27 Mar 2024 22:44:31 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Would this be the first lint -- not doclint -- warning related to comments, let alone doc comments?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024106466

From prappo at openjdk.org  Wed Mar 27 22:55:32 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 27 Mar 2024 22:55:32 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <WsC10GQD9Q9xTXY9eY2_v5C91f8J5WKuRlRwmP4jElw=.b13568b0-44c3-470e-a8e4-aa27833ecd28@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Javadoc changes look trivially good. I only note that the javadoc man page diff contains some unrelated changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024116236

From prappo at openjdk.org  Wed Mar 27 22:59:34 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 27 Mar 2024 22:59:34 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <CR1gXDa9g51mJiCtmPnP6-P-eT_71xIppMf2ND8axQ0=.bc1e2507-9973-498a-b6c4-159732c2e406@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

src/jdk.javadoc/share/man/javadoc.1 line 111:

> 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more
> 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R].
> 111: Within a source file, you may use suppress any warnings generated by

Typo?
Suggestion:

Within a source file, you may suppress any warnings generated by

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542131487

From dholmes at openjdk.org  Wed Mar 27 23:07:32 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 27 Mar 2024 23:07:32 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
Message-ID: <DBNLEWzUviYUgGABpvom-abyhEDIn6D_RXx23IDPzAc=.232608f0-3803-4705-b95f-f9f02cf24fb1@github.com>

On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust java.1 man page

Notwithstanding that there may be cases where this change would be convenient, I really don't like this coupling between the jcmd behaviour and a -XX flag that is intended for something else. It doesn't completely mesh with the jcmd usage and other options, and the documentation story is quite complicated.

> This change can help avoid the need for an additional copy and paste step, which is prone to errors.

To me that is not a sufficient benefit for the complexity this change would add. Further, it is not at all clear to me that a dynamic heap-dump _should_ be using the same destination as that set for the  `HeapDumpOnOutOfMemory` case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2024127213

From cjplummer at openjdk.org  Wed Mar 27 23:28:33 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 27 Mar 2024 23:28:33 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v9]
In-Reply-To: <DXqhUZufg0tyNDOq8ysGagV0wDpKBuOKPQd8mIW-3EU=.a8453cf5-0aa7-4bed-9159-da248d0f4e1d@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <msScnhT6AfK5kOl0zOQr4U88V0JeF4qrr8xPCT3LXIw=.aae43b38-dc57-43aa-b462-72713ff5857e@github.com>
 <Di371ecjc13u_EARd0yDPUTYj7R3F5TAbDRtBQp_QT8=.86208d9b-3324-4e0f-ae9f-7cb5fc8f541d@github.com>
 <DXqhUZufg0tyNDOq8ysGagV0wDpKBuOKPQd8mIW-3EU=.a8453cf5-0aa7-4bed-9159-da248d0f4e1d@github.com>
Message-ID: <3QNNsjYH-BrclWxnJjUei1Ufz_DpJrZrq3tlNtWYA2g=.72e94346-6dd4-4f43-bb97-898181216060@github.com>

On Wed, 27 Mar 2024 12:36:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Sorry maybe it is maybe obvious for you but where should I open a "docs CR", would that be a separate JBS issue with Component name docs ?

You would file a JBS issue with component "docs" and subcategory "hotspot". But let's hold off on that for now until if it is decided if the PR is going to be pushed. My main reason for mentioning it was to point out additional fallout of this change.

> Should I include the HeapDumpGzipLevel in the same "docs CR" (but this might be bad for potential backporting) ?

Backporting also came to mind since the trouble shooting guide would need to be updated for each Oracle version this PR is backported to. And yes, HeapDumpGzipLevel docs need to match the actual implementation. I'm not sure if HeapDumpGzipLevel has been backported to 8, 11, and 17 (in the open for for the Oracle release).  I'm inclined to say a separate jbs issue should track updating docs for HeapDumpGzipLevel, but then we also have the question of whether or not HeapDumpGzipLevel should impact the jcmd if this PR is to be pushed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2024147551

From cjplummer at openjdk.org  Wed Mar 27 23:35:32 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 27 Mar 2024 23:35:32 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <DBNLEWzUviYUgGABpvom-abyhEDIn6D_RXx23IDPzAc=.232608f0-3803-4705-b95f-f9f02cf24fb1@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <DBNLEWzUviYUgGABpvom-abyhEDIn6D_RXx23IDPzAc=.232608f0-3803-4705-b95f-f9f02cf24fb1@github.com>
Message-ID: <MsOIAEIh4yUh6Ywzm2d_ymAyKkOlQyjegqzLnJSlU_A=.74c63329-164e-4699-874c-f076cc672969@github.com>

On Wed, 27 Mar 2024 23:05:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Notwithstanding that there may be cases where this change would be convenient...

I did get feedback from a couple of our support engineers. One felt it was of no real benefit as it was just as easy to provide the filename as an argument to the jcmd. The other thought it might be of some benefit, but also had a misunderstanding of how the jcmd currently works (thought that with no filename given, it would automatically dump into the current directory). There were no strong arguments for this PR, especially that overcome all the issues it creates.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2024153420

From jjg at openjdk.org  Wed Mar 27 23:47:32 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 27 Mar 2024 23:47:32 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com>
Message-ID: <VBk0641TIJuEE_Ez3MN1g9kd8v7zpjiBY4wdBvzaQP8=.9e11bd0d-14e8-4c9f-ac2c-72d0b77daeae@github.com>

On Wed, 27 Mar 2024 22:41:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Would this be the first lint -- not doclint -- warning related to comments, let alone doc comments?

No. `-Xlint:dep-ann` correlates `@Deprecated` annotations with `@deprecated` tags in doc comments.

> src/jdk.javadoc/share/man/javadoc.1 line 111:
> 
>> 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more
>> 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R].
>> 111: Within a source file, you may use suppress any warnings generated by
> 
> Typo?
> Suggestion:
> 
> Within a source file, you may suppress any warnings generated by

Thanks; I'll check the underlying original.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024162355
PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542157047

From stuefe at openjdk.org  Thu Mar 28 07:04:36 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 28 Mar 2024 07:04:36 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
Message-ID: <NM_-NsTTOGAxlIwZlSaVf2TgV3UbcbLxIRA_9gZNY0c=.3aba23e1-a875-46bc-9fa9-6e892e534be8@github.com>

On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust java.1 man page

To weight in on the side of this patch, in most customer scenarios I have seen, there is just one location for heap dumps. Using the same location for OOM and for manual heap dumps seems logical to me.

@dholmes-ora 
> Notwithstanding that there may be cases where this change would be convenient, I really don't like this coupling between the jcmd behaviour and a -XX flag that is intended for something else. It doesn't completely mesh with the jcmd usage and other options, and the documentation story is quite complicated.

Wouldn't this just be a case of changing a flag description? As luck has it, the flag already has a generic name that is not tied to OOMs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2024535044

From stuefe at openjdk.org  Thu Mar 28 07:07:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 28 Mar 2024 07:07:41 GMT
Subject: RFR: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
In-Reply-To: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
References: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
Message-ID: <A_hTLKgozHXgDrwUFKBOX5wHZylK7w6KTRiQuTcWXTM=.f5e50a43-0728-48aa-937e-572b7b7ce5d0@github.com>

On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.
> 
> If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.
> 
> Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.
> 
> Increasing the timeout and tidying up the handling so we can see the specific reason in future.

Looks good!

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18381#pullrequestreview-1965321788

From mbaesken at openjdk.org  Thu Mar 28 08:56:38 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 28 Mar 2024 08:56:38 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v9]
In-Reply-To: <3QNNsjYH-BrclWxnJjUei1Ufz_DpJrZrq3tlNtWYA2g=.72e94346-6dd4-4f43-bb97-898181216060@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <msScnhT6AfK5kOl0zOQr4U88V0JeF4qrr8xPCT3LXIw=.aae43b38-dc57-43aa-b462-72713ff5857e@github.com>
 <Di371ecjc13u_EARd0yDPUTYj7R3F5TAbDRtBQp_QT8=.86208d9b-3324-4e0f-ae9f-7cb5fc8f541d@github.com>
 <DXqhUZufg0tyNDOq8ysGagV0wDpKBuOKPQd8mIW-3EU=.a8453cf5-0aa7-4bed-9159-da248d0f4e1d@github.com>
 <3QNNsjYH-BrclWxnJjUei1Ufz_DpJrZrq3tlNtWYA2g=.72e94346-6dd4-4f43-bb97-898181216060@github.com>
Message-ID: <YqEaLgh3PmumaGNNIq1UOWZXwIf9OUSq35KDZ5nXgUk=.1c3bc764-f80d-4799-96e5-e1d143b71232@github.com>

On Wed, 27 Mar 2024 23:26:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> 
> Backporting also came to mind since the trouble shooting guide would need to be updated for each Oracle version this PR is backported to. And yes, HeapDumpGzipLevel docs need to match the actual implementation. I'm not sure if HeapDumpGzipLevel has been backported to 8, 11, and 17 (in the open for for the Oracle release). I'm inclined to say a separate jbs issue should track updating docs for HeapDumpGzipLevel, but then we also have the question of whether or not HeapDumpGzipLevel should impact the jcmd if this PR is to be pushed.

HeapDumpGzipLevel is in openjdk17 and openjdk21 .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2024698315

From mbaesken at openjdk.org  Thu Mar 28 09:01:33 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 28 Mar 2024 09:01:33 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <MsOIAEIh4yUh6Ywzm2d_ymAyKkOlQyjegqzLnJSlU_A=.74c63329-164e-4699-874c-f076cc672969@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <DBNLEWzUviYUgGABpvom-abyhEDIn6D_RXx23IDPzAc=.232608f0-3803-4705-b95f-f9f02cf24fb1@github.com>
 <MsOIAEIh4yUh6Ywzm2d_ymAyKkOlQyjegqzLnJSlU_A=.74c63329-164e-4699-874c-f076cc672969@github.com>
Message-ID: <9_qWKPSy28L20cRZVV7sWVjzPfNcXxWIhJhrL_hFR48=.0f0f40df-b69c-4e6c-b649-9f8f95da6a26@github.com>

On Wed, 27 Mar 2024 23:33:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I did get feedback from a couple of our support engineers. One felt it was of no real benefit as it was just as easy to provide the > filename as an argument to the jcmd.

That might be true for this support engineer, but not for others with other setups where it is an issue to find out where to write in cloud/container scenarios .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2024704505

From kevinw at openjdk.org  Thu Mar 28 09:09:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 28 Mar 2024 09:09:35 GMT
Subject: RFR: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
In-Reply-To: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
References: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
Message-ID: <XIVPyz6_ewFOY2YCn1lkmSGPvcrS4PAC7fHN5bWWFhs=.4d22ade7-0856-423f-8d22-11ffc11e8b5f@github.com>

On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.
> 
> If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.
> 
> Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.
> 
> Increasing the timeout and tidying up the handling so we can see the specific reason in future.

Thanks Thomas!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18381#issuecomment-2024715786

From kevinw at openjdk.org  Thu Mar 28 09:09:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 28 Mar 2024 09:09:35 GMT
Subject: Integrated: 8327505: Test
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
 fails
In-Reply-To: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
References: <y5plDuqbjBjdIQOZLKtusl8rzSsHMKCq2n9JB14I5ew=.afd4b832-505f-4f23-bd90-8734115282e0@github.com>
Message-ID: <tlkDBaY_F1z-M28di8fbTQvTDMyX2VEyl7FHtXU7nTU=.40a46e3e-5ca3-45b4-aca1-33856e013f38@github.com>

On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for 10 notifications.
> 
> If it fails, you can't tell if CountDownLatch.await threw, or returned false and the app threw InterruptedException, due to the way Client.java handles these.
> 
> Seems most likely the 30 second wait expired, as we are dealing with -Xcomp failures in a debug build.  Passing runs can take a few seconds, but can be 25 seconds.
> 
> Increasing the timeout and tidying up the handling so we can see the specific reason in future.

This pull request has now been integrated.

Changeset: 2b79c22c
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b79c22c43a2de0815e77c9aa71f010906be8670
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8327505: Test com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java fails

Reviewed-by: lmesnik, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/18381

From dfuchs at openjdk.org  Thu Mar 28 11:29:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 28 Mar 2024 11:29:33 GMT
Subject: RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use [v2]
In-Reply-To: <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
 <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
Message-ID: <eRRB-cxnNuV3vaR5fxnDjSsGtWW0WyKY8YFIr7GkU8g=.276e2e50-94af-44a9-827e-dba20228c279@github.com>

On Mon, 25 Mar 2024 22:46:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
>> 
>> e.g. 
>> 
>> test output:
>> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
>> 	java.net.BindException: Address already in use
>> 	
>> Test checks for:
>>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
>> 		
>> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
>> 
>> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   show exit code

Looks reasonable. I wish we had a way to get rid of this getFreePort() logic.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18470#pullrequestreview-1965847115
PR Review: https://git.openjdk.org/jdk/pull/18470#pullrequestreview-1965848443

From kevinw at openjdk.org  Thu Mar 28 11:37:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 28 Mar 2024 11:37:37 GMT
Subject: RFR: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use [v2]
In-Reply-To: <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
 <PKVzMXaLZdEfaRfBgQBB0LPqH1_JAEgir8A1BdOTAJU=.26162723-f62d-4f50-80d1-5a25844e3960@github.com>
Message-ID: <h1T2uTgV9qBpThObE-9RtuZePqER0C_xGnjaa_beSIA=.4cb90de1-c55f-40cc-a31b-1ed737bb7d0f@github.com>

On Mon, 25 Mar 2024 22:46:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
>> 
>> e.g. 
>> 
>> test output:
>> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
>> 	java.net.BindException: Address already in use
>> 	
>> Test checks for:
>>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
>> 		
>> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
>> 
>> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   show exit code

Thanks Daniel.
Yes, the variations of the starting-with-a-free-port problem will be nice to standardize at some point... 8-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18470#issuecomment-2024969513

From kevinw at openjdk.org  Thu Mar 28 11:37:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 28 Mar 2024 11:37:38 GMT
Subject: Integrated: 8328619:
 sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed
 with BindException: Address already in use
In-Reply-To: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
References: <wJwH0hDMamuyMBVzTdpZbP4cO4fjx3xHX704JRqlB4c=.83cac8a3-af8a-4403-b157-1e1c8876486e@github.com>
Message-ID: <60H69ES1wIMaliGZh1PMOWBhk02yWCNNB5LnaPWF1d8=.7e1c026b-41fe-420e-a4be-2ddfc9eeea67@github.com>

On Mon, 25 Mar 2024 13:15:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test uses  jdk.test.lib.Utils.getFreePort() when launching a new Java command.
> Looks like it already recognises "java.rmi.server.ExportException: Port already in use: " and retries, but there is a long-standing typo in the check.
> 
> e.g. 
> 
> test output:
> Error: Exception thrown by the agent: java.rmi.server.ExportException: Port already in use: 37049; nested exception is: 
> 	java.net.BindException: Address already in use
> 	
> Test checks for:
>         !output.getOutput().contains("Exception thrown by the agent : java.rmi.server.ExportException: Port already in use")
> 		
> Oops, we have an extra space in there.  A day-one typo from JDK-7195249.
> 
> While here, try to clarify the while loop which recognises this port failure.  Also add something to clarify which test(s) failed, and correct a comment in test2 of AbstractFilePermissionTest.java

This pull request has now been integrated.

Changeset: 2af0312c
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2af0312c958e693b1377f4c014ae8f84cabf6b83
Stats:     19 lines in 1 file changed: 7 ins; 2 del; 10 mod

8328619: sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java failed with BindException: Address already in use

Reviewed-by: lmesnik, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/18470

From dholmes at openjdk.org  Thu Mar 28 13:11:32 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Mar 2024 13:11:32 GMT
Subject: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode
 profiling
In-Reply-To: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
References: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
Message-ID: <_0QPWO8jZJmvtVe7LshTODnjNK5rINcFS36TXT0QvG4=.24eeed9d-9c16-46a3-ab4a-c911b0ac6a03@github.com>

On Wed, 27 Mar 2024 01:02:41 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
> Reentrancy is required in the cases when two or more profiling engines are running at the same time, e.g., when CPU and Wall clock profilers work together and therefore one profiler may interrupt another in the middle of getting a stack trace.
> 
> Tested with async-profiler:
> 
> java -agentpath:/path/to/libasyncProfiler.so=start,event=cpu,interval=1ms,wall=1ms,file=profile.jfr

I have my doubts as to whether AGCT is actually re-entrant in a general sense, but I can see that the `ThreadInAsgct` RAII object introduced a reentrancy constraint that did not exist prior, and so removing it should not make AGCT any less safe and should allow previous reentrancy cases to continue to work as before.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18504#pullrequestreview-1966173558

From adinn at openjdk.org  Thu Mar 28 14:14:36 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 28 Mar 2024 14:14:36 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <Yyi54ykxVpU2Zar5450F4A-sk1vTnR7CYmoBVHH5pBc=.4ac2dc66-053e-4f2e-a7fe-d1ec681855e1@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
 <IML33eLfWNHULkwhOJ65UQ06kjnJb_ZgfaU4-grtejA=.429c10ea-0f17-4723-a405-35584ac94dd1@github.com>
 <Yyi54ykxVpU2Zar5450F4A-sk1vTnR7CYmoBVHH5pBc=.4ac2dc66-053e-4f2e-a7fe-d1ec681855e1@github.com>
Message-ID: <JDS-WM8MXt0AA6Xag_To7-nPnSa1-5wg1i4x6rOplHw=.45bcdd7c-9577-4641-8304-c81a4ae8b9a9@github.com>

On Wed, 27 Mar 2024 18:28:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> It looks like the test only inspects a thread and a java object. Perhaps you could add tests for additional VM objects. Maybe grab a frame PC from a thread stack trace.
>
>> It looks like the test only inspects a thread and a java object. Perhaps you could add tests for additional VM objects. Maybe grab a frame PC from a thread stack trace.
> 
> Yes - added a couple of metadata tests, and a compiled method test, which gets an address from Events info.  We know that should resolve to a compiled method (if we have such an event, so this copes if there are none).
> 
> 
> Also the VM.info and Thread.print runs with the CommandExecutor are now silent.  They are long, and max out the test log file and make it truncate.  That output could mainly be useful if  the regexes can't match items, but the output format should be reproducible in a new run.  Also if we fail to find something we need, like a thread id, it will print the full output it searched.

@kevinjwalls Hi Kevin. Sorry to offer a drive-by comment but I have been watching this thread and I can understand why @tstuefe is expressing his concern about the potential for security issues when it comes to using jcmd to expose JVM internals.

Exposure of details like a thread/stack/metadata value address or a datum embedded at such a location does look to me like something bad agents might be able to profit from. The danger is not just being able to retrieve specific details of the layout or content of JVM structures themselves, but the opportunity to use that knowledge to upgrade a weak security hole like, say, a memory exposure, into a stronger targeted attack that knows where or to what it might want to apply the crowbar.

So, first off, please understand that I am not suggesting there *is* a problem here. I am happy to accept your conclusion that your proposed jcmd changes do not expose new data to users who ought not to be able to view either via local or via remote accesses. However, not being an expert when it comes to the jcmd/DCmd implementation, I'm not sure I really understand why that is so from your current explanation. In particular I don't understand what you said about visibility of different commands for local and remote access.

That confession of my own ignorance is not really of any immediate importance as I have no intention of trying to review this change. However, I still feel it might be useful if you could summarize on this JIRA precisely what security safeguards are currently in place when it comes to running specific jcmds/DCmds and why that means exposure of JVM internal details via jcmd, whether locally or remotely via JMX, will only be to a safe audience of users. That would help any maintainer/developer who refers to this JIRA to follow how those safeguards apply to the proposed commands (in particular it might be of great help to those performing and assessing the correctness of backports). However, it would probably also as a prophylactic to ensure that any future development work does not inadvertently lead to unexpected exposure, which I think is the thing Thomas is more worried about. Indeed, as Thomas suggested, a clear statement of what policies and mechanisms are (or should be) in place 
 to ensure jcmd content is securely viewable  might be a good starting point for you and/or Thomas to raise follow-up JIRAs if needed to:
1. add comments to the code base to ensure devs to not inadvertently add or modify new DCmds in a way that prejudices security
2. enable a review of the existing DCmd organization to see if a better grouping of commands or assignent of access restrictions might be warranted

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2025282602

From mbaesken at openjdk.org  Thu Mar 28 15:11:39 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 28 Mar 2024 15:11:39 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <NM_-NsTTOGAxlIwZlSaVf2TgV3UbcbLxIRA_9gZNY0c=.3aba23e1-a875-46bc-9fa9-6e892e534be8@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <NM_-NsTTOGAxlIwZlSaVf2TgV3UbcbLxIRA_9gZNY0c=.3aba23e1-a875-46bc-9fa9-6e892e534be8@github.com>
Message-ID: <LMtCcLS4Vmt2SN3AnXDdKTl1jAlo6Ehp4lZDGGbZxQg=.b10bd71e-fea3-48e7-9c31-4caecee18fe0@github.com>

On Thu, 28 Mar 2024 07:02:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Wouldn't this just be a case of changing a flag description? As luck has it, the flag already has a generic name that is not tied to OOMs.

Yes it is some work on documentation (but seems some doc work needs to be done anyway because it was forgotten when `HeapDumpGzipLevel` was introduced). 
And the current name is generic and does not mention the OOM case in the name itself, the current implementation would better match the name if it was `HeapDumpPathOnOom` or something like this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2025456286

From kevinw at openjdk.org  Thu Mar 28 16:47:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 28 Mar 2024 16:47:33 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <JDS-WM8MXt0AA6Xag_To7-nPnSa1-5wg1i4x6rOplHw=.45bcdd7c-9577-4641-8304-c81a4ae8b9a9@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
 <IML33eLfWNHULkwhOJ65UQ06kjnJb_ZgfaU4-grtejA=.429c10ea-0f17-4723-a405-35584ac94dd1@github.com>
 <Yyi54ykxVpU2Zar5450F4A-sk1vTnR7CYmoBVHH5pBc=.4ac2dc66-053e-4f2e-a7fe-d1ec681855e1@github.com>
 <JDS-WM8MXt0AA6Xag_To7-nPnSa1-5wg1i4x6rOplHw=.45bcdd7c-9577-4641-8304-c81a4ae8b9a9@github.com>
Message-ID: <712TKIhgXCWS1pzRjFB80eqkqvZdF9-v7KKXtJnNUro=.8831c3c9-08df-4bdf-a412-d4d7a4c1e309@github.com>

On Thu, 28 Mar 2024 14:12:08 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>>> It looks like the test only inspects a thread and a java object. Perhaps you could add tests for additional VM objects. Maybe grab a frame PC from a thread stack trace.
>> 
>> Yes - added a couple of metadata tests, and a compiled method test, which gets an address from Events info.  We know that should resolve to a compiled method (if we have such an event, so this copes if there are none).
>> 
>> 
>> Also the VM.info and Thread.print runs with the CommandExecutor are now silent.  They are long, and max out the test log file and make it truncate.  That output could mainly be useful if  the regexes can't match items, but the output format should be reproducible in a new run.  Also if we fail to find something we need, like a thread id, it will print the full output it searched.
>
> @kevinjwalls Hi Kevin. Sorry to offer a drive-by comment but I have been watching this thread and I can understand why @tstuefe is expressing his concern about the potential for security issues when it comes to using jcmd to expose JVM internals.
> 
> Exposure of details like a thread/stack/metadata value address or a datum embedded at such a location does look to me like something bad agents might be able to profit from. The danger is not just being able to retrieve specific details of the layout or content of JVM structures themselves, but the opportunity to use that knowledge to upgrade a weak security hole like, say, a memory exposure, into a stronger targeted attack that knows where or to what it might want to apply the crowbar.
> 
> So, first off, please understand that I am not suggesting there *is* a problem here. I am happy to accept your conclusion that your proposed jcmd changes do not expose new data to users who ought not to be able to view either via local or via remote accesses. However, not being an expert when it comes to the jcmd/DCmd implementation, I'm not sure I really understand why that is so from your current explanation. In particular I don't understand what you said about visibility of different commands for local and remote access.
> 
> That confession of my own ignorance is not really of any immediate importance as I have no intention of trying to review this change. However, I still feel it might be useful if you could summarize on this JIRA precisely what security safeguards are currently in place when it comes to running specific jcmds/DCmds and why that means exposure of JVM internal details via jcmd, whether locally or remotely via JMX, will only be to a safe audience of users. That would help any maintainer/developer who refers to this JIRA to follow how those safeguards apply to the proposed commands (in particular it might be of great help to those performing and assessing the correctness of backports). However, it would probably also as a prophylactic to ensure that any future development work does not inadvertently lead to unexpected exposure, which I think is the thing Thomas is more worried about. Indeed, as Thomas suggested, a clear statement of what policies and mechanisms are (or should be) in plac
 e to ensure jcmd content is securely viewable  might be a good starting point for you and/or Thomas to raise follow-up JIRAs if needed to:
> 1. add comments to the code base to ensure devs to not inadvertently add or modify new DCmds ...

Hi @adinn 
Drive-bys are welcome. 8-)

Providing new crowbars to attackers is not something we want to do.

jcmd is protected by the attach api and is not open to other users.  We are trusting in that.  If you can satisfy the attach API connection, you have all the jcmds/DiagnosticCommands available.  No limits.  Likewise you can use other tools to examine abritrary memory in the target process, take a gcore, kill it, etc... 


Why will VM.inspect not be available remotely?

Because this marks the jcmd as "hidden": src/hotspot/share/services/diagnosticCommand.cpp: 
 DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<VMInspectDCmd>(full_export, true, true /* hidden */ ));
 (The new test for VM.inspect checks it does not appear in the jcmd help output, to ensure it stays hidden.)

In JMX, DiagnosticCommandMBean(Impl) does not expose hidden commands: 

The route for that is DiagnosticCommandImpl.java calling its native getDiagnosticCommands(), that gets into management.cpp's  jmm_GetDiagnosticCommands() calling DCmdFactory::DCmd_list().  In diagnosticFramework.cpp, this iterates DCmdFactories, choosing those which are not hidden.  

Querying over JMX I cannot see or access vmInspect, like I can see vmInfo, gcClassHistogram etc... through the exposed DiagnosticCommandMBean.

That "hidden" flag could be more obvious or better documented perhaps.  Also I don't think we actually say in the DiagnosticCommandMBean API docs that it provides access to the DiagnosticCommand implementations which are also exposed by the jcmd tool.  These concerns could be addressed in a separate PR if desired.

(As well as the hidden flag, we have flags to implement different categories of diagnostic command.  these are not widely used and I think the hidden flag is a better fit, as it keeps it out of the jcmd general help.  This command should be documented in other guides in due course.).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2025665216

From kevinw at openjdk.org  Thu Mar 28 17:18:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 28 Mar 2024 17:18:33 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <Eh8mqo-MHczioKlpe_o_cvgpWZ9kminPmqNRkKPk0lA=.35465d6a-5668-4dbd-99c9-a43387b4915a@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
 <FkpkXtC4BSEXGM0uCYWiroHZ4Y4MTdqhjfgb_AbCVOI=.ef819314-1dc5-4460-a807-400887fbeada@github.com>
 <Eh8mqo-MHczioKlpe_o_cvgpWZ9kminPmqNRkKPk0lA=.35465d6a-5668-4dbd-99c9-a43387b4915a@github.com>
Message-ID: <Od6ytN_fIx6iqNjp1bB5cFUVCm4cXh0MBnmJddZflLk=.00d26c3b-6792-458d-9832-4971b90c3513@github.com>

On Wed, 27 Mar 2024 18:39:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I think we also need to consider the flip side of this argument. Is this something that some customers might want to always enable, but don't want to always have UnlockDiagnosticVMOptions enabled. A new command line flag would be needed in that case.
> 
> Also, isn't UnlockDiagnosticVMOptions meant for enabling the use of diagnostic command line flags? Do we have examples of it enabling a hotspot feature that does not also require setting a diagnostic command line flag?

Thanks Chris - that is correct now I check the wording, UnlockDiagnosticVMOptions: "Enable normal processing of flags relating to field diagnostics"

Yes it makes flags which are DIAGNOSTIC available at the command-line.  We have UnlockExperimentalVMOptions also.

My original reason for the guard, is that the risk of fooling  the "good oop" check is that we could possibly crash (so that's answering your other question).  Inspecting an arbitrary pointer that looks enough like a Java heap object to fool the test, means it might try and resolve bad addresses for Klass pointer or field data.

I also have a stress test which examines every address in a Java heap to test for crashes.  That's obviously long-running as it does a jcmd for every iteration.  But I can't currently get a crash, trying G1, ZGC, ZGCGenerational.

Having a global guard to prevent usage of VM.inspect may be needed less than I thought, but will wait on the other thread before saying that is really the case.  We could have a new -XX flag to guard it (whether specific to this command or a more general UnlockDiagnosticFeatures.  I would definitely stick to this being in all builds, as we frequently "debug" non-debug builds.

Also, for your comment above about the new version of dbg_is_good_oop: this was added because although there are not many callers of it, I did not want to upset them.  During my earlier testing the detailed version of this method did upset something, although I cannot reproduce that today.  

I will rerun some tests on these items...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2025726278

From amenkov at openjdk.org  Thu Mar 28 22:18:38 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 28 Mar 2024 22:18:38 GMT
Subject: RFR: JDK-8328137: PreserveAllAnnotations can cause failure of class
 retransformation
Message-ID: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>

PreserveAllAnnotations option causes class file parser to preserve RuntimeInvisibleAnnotations so VM considers them as RuntimeVisibleAnnotations.
For class retransformation JvmtiClassFileReconstituter restores all annotations as RuntimeVisibleAnnotations attributes.
This can cause problem is the class contains only RuntimeInvisibleAnnotations, so corresponding RuntimeVisibleAnnotations attribute name is not present in the class constant pool.

Correct solution would be to store additional information about RuntimeInvisibleAnnotations and restore them exactly as they were in the original class (this should be done for all annotations: RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations for class, fields and records, RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations/RuntimeInvisibleParameterAnnotations for methods; need to ensure the information is correctly updated during class redefinition & retransformation).

I think it doesn't make sense to add all the complexity for almost no value (I doubt anyone uses PreserveAllAnnotations, the flag looks like experimental, we don't have any tests for it).

The suggested fix adds workaround for this corner case - if "visible" attribute name is not in the CP, the annotations are restored with "invisible" attribute name.

Testing:
  - tier1,tier2,hs-tier5-svc
  - all java/lang/instrument tests;
  - all RedefineClasses/RetransformClasses tests

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/18540/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18540&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328137
  Stats: 33 lines in 3 files changed: 22 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/18540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18540/head:pull/18540

PR: https://git.openjdk.org/jdk/pull/18540

From apangin at openjdk.org  Thu Mar 28 22:43:30 2024
From: apangin at openjdk.org (Andrei Pangin)
Date: Thu, 28 Mar 2024 22:43:30 GMT
Subject: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode
 profiling
In-Reply-To: <_0QPWO8jZJmvtVe7LshTODnjNK5rINcFS36TXT0QvG4=.24eeed9d-9c16-46a3-ab4a-c911b0ac6a03@github.com>
References: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
 <_0QPWO8jZJmvtVe7LshTODnjNK5rINcFS36TXT0QvG4=.24eeed9d-9c16-46a3-ab4a-c911b0ac6a03@github.com>
Message-ID: <vpX5zmQHAhLbVWyxcqbV5Qexr7oiIH5w3NYIjx_yypo=.6fcfff59-12d2-44c1-9bed-2259c04a0474@github.com>

On Thu, 28 Mar 2024 13:09:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
>> Reentrancy is required in the cases when two or more profiling engines are running at the same time, e.g., when CPU and Wall clock profilers work together and therefore one profiler may interrupt another in the middle of getting a stack trace.
>> 
>> Tested with async-profiler:
>> 
>> java -agentpath:/path/to/libasyncProfiler.so=start,event=cpu,interval=1ms,wall=1ms,file=profile.jfr
>
> I have my doubts as to whether AGCT is actually re-entrant in a general sense, but I can see that the `ThreadInAsgct` RAII object introduced a reentrancy constraint that did not exist prior, and so removing it should not make AGCT any less safe and should allow previous reentrancy cases to continue to work as before.

@dholmes-ora Thank you for the review. When looking at the AGCT code, nothing suspicious that could affect reentrancy caught my eye. Also, benchmarks (specJVM, Renaissance) now run fine with two profilers enabled.
So yes, while I don't have 100% proof that AGCT is async-signal-safe, the fix definitely improves the situation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18504#issuecomment-2026255860

From sspitsyn at openjdk.org  Thu Mar 28 23:11:34 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 28 Mar 2024 23:11:34 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
Message-ID: <9j-q30DMKhtFJxQasXanGOHnSjvOikwrCknVbDzTFuY=.efaa32bc-4fd3-4986-821d-feaa21bc3efb@github.com>

On Wed, 27 Mar 2024 20:06:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: improve diagnostics and reliability
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/PopFrameTest.java line 148:
> 
>> 146:             log("Main #B.2: got expected JVMTI_ERROR_NONE");
>> 147:             resumeThread(testTaskThread);
>> 148: 
> 
> You probably don't need this minor edit or the copyright update any more.
> 
> However, it's still unclear to me how the ensureAtBreakpoint() below is suppose to work if we already called notifyAtBreakpoint() between the 1st and 2nd ensureAtBreakpoint(). From what I can tell, notifyAtBreakpoint() clears the flag that ensureAtBreakpoint() checks for, and there is no 2nd breakpoint to set it again. I would expect the ensureAtBreakpoint() below to always wait indefinitely, but that doesn't appear to be the case. So how is this working? I must be missing something.

Thanks, Chris. I noticed that some an additional cleanup is needed in the Java part.
The `TestTask.run()` has two calls to the method `B()`:

        public void run() {
            log("TestTask.run: started");

            A();
            sleep(1); // to cause yield

            prepareAgent(TestTask.class, false); // No doPopFrame
            B();
            sleep(1); // to cause yield

            prepareAgent(TestTask.class, true); // doPopFrame
            B();
            sleep(1); // to cause yield

            C();
            finished = true;
        }

The second `B()` call does the JVMTI `PopFrame` call on its own thread in the `Breakpoint()` event hadler.
Please, note, `true` in the `prepareAgent` parameters:
   `prepareAgent(TestTask.class, true); // doPopFrame`
So, the second `ensureAtBreakpoint()` is a sync point with it.

> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 58:
> 
>> 56:   LOG("Breakpoint: In method TestTask.B(): after sync section\n");
>> 57: 
>> 58:   if (do_pop_frame != JNI_FALSE) {
> 
> Suggestion:
> 
>   if (do_pop_frame) {

Okay, thanks. I can do this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1543825742
PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1543826541

From sspitsyn at openjdk.org  Thu Mar 28 23:32:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 28 Mar 2024 23:32:32 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <_7Oa2vFPXsQ_axKlTcLeDrBsSW_q6iuEsRqruErpj8k=.45a5bc91-c9cc-46f5-8fe7-4abbfd34c9b4@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
 <_7Oa2vFPXsQ_axKlTcLeDrBsSW_q6iuEsRqruErpj8k=.45a5bc91-c9cc-46f5-8fe7-4abbfd34c9b4@github.com>
Message-ID: <IuK2HZd9luuh7D6DwrhW21zRy1gn38fMVWcA2vJuQhE=.caa13016-af40-4d38-8b68-6f35a793b37f@github.com>

On Wed, 27 Mar 2024 20:27:42 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 163:
>> 
>>> 161:     LOG("Main: ensureAtBreakpoint: waitig 5 millis\n");
>>> 162:     if (++attempts > 100) {
>>> 163:       fatal(jni, "Main: ensureAtBreakpoint: waited 1 sec");
>> 
>> 1 second isn't very long when you are talking about something that is relying on debugger/debuggee communication. Maybe wait 100ms at a time for a total of 10 seconds.
>
> Caught this comment in passing. Delays like this should be scaled with
> defaultTimeoutFactor so that test tasks that invoke tests with options
> that can slow the test down, e.g., `-Xcomp`, can be accommodated.
> 
> I believe the defaultTimeoutFact for `-Xcomp` test tasks gets bumped
> from 4 to 10.

Thanks for the comments, Chris and Dan. Updated as Chris suggested. I've added this with `-Xcomp` consideration as the worst case scenario in mind. Now, I think it is more save to make it 10 seconds instead of one. Is it going to be good enough? In fact, I've added this for manual testing to save time in waiting for test completion when it is deadlocked.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1543839536

From sspitsyn at openjdk.org  Thu Mar 28 23:38:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 28 Mar 2024 23:38:54 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v5]
In-Reply-To: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
Message-ID: <GPndY9P0uEiuEcmY9gJ_jvJlt8c8z5wPoI_MqCFaaWE=.796bafd4-1504-4151-bbc5-a9ff616dc422@github.com>

> This PR fixes a synchronization issue in the test:
>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>   
> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
> 
> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
> 
> Testing:
>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: pilished native waiting timouts in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18419/files
  - new: https://git.openjdk.org/jdk/pull/18419/files/f4f92e92..14e0e60f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18419&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18419&range=03-04

  Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18419/head:pull/18419

PR: https://git.openjdk.org/jdk/pull/18419

From vromero at openjdk.org  Fri Mar 29 03:07:32 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Mar 2024 03:07:32 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <GAZpxf-ZJzNHTZxqSFBUfMxBextCyxBNuNrINXTddyw=.8d42905b-1d96-49d8-992b-8edd48ae8a9b@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-1967750057

From cjplummer at openjdk.org  Fri Mar 29 03:52:32 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 29 Mar 2024 03:52:32 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
Message-ID: <3-Soz1SrpIusTU6vwYUCXEK_Zx6jvQealAj-AP9JSZs=.435e2c6e-429c-45da-9355-6f1972a1074a@github.com>

On Wed, 27 Mar 2024 19:59:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: improve diagnostics and reliability
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 161:
> 
>> 159:   int attempts = 0;
>> 160:   while (!bp_sync_reached) {
>> 161:     LOG("Main: ensureAtBreakpoint: waitig 5 millis\n");
> 
> Suggestion:
> 
>     LOG("Main: ensureAtBreakpoint: waiting 10 millis\n");
> 
> 
> I think this should be moved directly above the wait(10) call.

I think you missed this suggestion. There is a typo in the log message, and this LOG should be move to just before the wait() statement below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1544028878

From cjplummer at openjdk.org  Fri Mar 29 04:07:37 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 29 Mar 2024 04:07:37 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <LMtCcLS4Vmt2SN3AnXDdKTl1jAlo6Ehp4lZDGGbZxQg=.b10bd71e-fea3-48e7-9c31-4caecee18fe0@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <NM_-NsTTOGAxlIwZlSaVf2TgV3UbcbLxIRA_9gZNY0c=.3aba23e1-a875-46bc-9fa9-6e892e534be8@github.com>
 <LMtCcLS4Vmt2SN3AnXDdKTl1jAlo6Ehp4lZDGGbZxQg=.b10bd71e-fea3-48e7-9c31-4caecee18fe0@github.com>
Message-ID: <ZcoE2ZRNm7mrOU7XUXy1enpXNER4aWlUjUkbtJAzf1s=.8bc168d0-545e-447d-b035-641e7bd06e1b@github.com>

On Thu, 28 Mar 2024 15:08:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Wouldn't this just be a case of changing a flag description? As luck has it, the flag already has a generic name that is not tied to OOMs.

One of the issues with this PR is that there are 7 places where some sort of doc/help update is needed.  The help output for the `filename` option does not work well, because currently it is required option and has no default. This PR sort of gives it a default, but not always, so the default needs to be given in descriptive way , but jcmd help is not really setup to handle descriptive defaults, so we end up with this:

_filename("filename","Name of the dump file", "STRING", false, "if no filename was specified, but -XX:HeapDumpPath=hdp is set, path hdp is taken"),

And even this is not complete. HeapDumpPath can be a directory, in which case a filename is generated using the PID and a dump sequence number. Probably all this belongs in the argument description, which currently just says "Name of dump file", but you still need to put something in for the default. If the description is complete, maybe just using "See description" would be better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2026614466

From sspitsyn at openjdk.org  Fri Mar 29 04:08:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Mar 2024 04:08:37 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v11]
In-Reply-To: <dOvDzyHCw8sJixlFGHxhcBhG7ttmqB33pNo5WhIqnKk=.5f505681-d7de-48c4-909a-437852d2cc4d@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <dOvDzyHCw8sJixlFGHxhcBhG7ttmqB33pNo5WhIqnKk=.5f505681-d7de-48c4-909a-437852d2cc4d@github.com>
Message-ID: <3ZAHb7N67_sF8KheEMD2Wb44QX0zgRjkALBx9sk0WhA=.85029ac8-8cda-4f4f-a204-332b4a67d0bf@github.com>

On Wed, 27 Mar 2024 18:31:50 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test more pointer types: compiled method and metadata.

test/hotspot/jtreg/serviceability/dcmd/vm/VMInspectTest.java line 117:

> 115:         output = executor.execute("VM.inspect -1");
> 116:         output.shouldContain("address not safe");
> 117: 

Nit: Just a suggestion to make the test more readable. Now when more test cases have been added you may want to refactor it to call a separate method for each sub-test.
E.g.: `testBaddAddresses()`, `testMisalignedAddress()`, `testCompiledMethodAddress()`, `testMetadataAddress()`, `testClassAddress()`, `testThreadAddress()`, etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1544038490

From sspitsyn at openjdk.org  Fri Mar 29 04:15:43 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Mar 2024 04:15:43 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v6]
In-Reply-To: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
Message-ID: <GFoWgbzM0eR7CvL8EVES1XQNHw4FGAOCRL3CqSR1cd0=.a80b41e2-c1c0-4646-b40e-f95a43582113@github.com>

> This PR fixes a synchronization issue in the test:
>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>   
> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
> 
> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
> 
> Testing:
>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: move log message to the right place

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18419/files
  - new: https://git.openjdk.org/jdk/pull/18419/files/14e0e60f..f8344149

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18419&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18419&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18419/head:pull/18419

PR: https://git.openjdk.org/jdk/pull/18419

From sspitsyn at openjdk.org  Fri Mar 29 04:15:43 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Mar 2024 04:15:43 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <3-Soz1SrpIusTU6vwYUCXEK_Zx6jvQealAj-AP9JSZs=.435e2c6e-429c-45da-9355-6f1972a1074a@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
 <3-Soz1SrpIusTU6vwYUCXEK_Zx6jvQealAj-AP9JSZs=.435e2c6e-429c-45da-9355-6f1972a1074a@github.com>
Message-ID: <_qq6sUo_jv1NN4PfPiNWj8h0eN-KkoPQut530Rrqa1o=.3a63fb09-749f-4d00-a53a-2c5b64156bf7@github.com>

On Fri, 29 Mar 2024 03:50:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 161:
>> 
>>> 159:   int attempts = 0;
>>> 160:   while (!bp_sync_reached) {
>>> 161:     LOG("Main: ensureAtBreakpoint: waitig 5 millis\n");
>> 
>> Suggestion:
>> 
>>     LOG("Main: ensureAtBreakpoint: waiting 10 millis\n");
>> 
>> 
>> I think this should be moved directly above the wait(10) call.
>
> I think you missed this suggestion. There is a typo in the log message, and this LOG should be move to just before the wait() statement below.

Sorry, missed to do this. Fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1544041108

From cjplummer at openjdk.org  Fri Mar 29 04:17:41 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 29 Mar 2024 04:17:41 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <LMtCcLS4Vmt2SN3AnXDdKTl1jAlo6Ehp4lZDGGbZxQg=.b10bd71e-fea3-48e7-9c31-4caecee18fe0@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <NM_-NsTTOGAxlIwZlSaVf2TgV3UbcbLxIRA_9gZNY0c=.3aba23e1-a875-46bc-9fa9-6e892e534be8@github.com>
 <LMtCcLS4Vmt2SN3AnXDdKTl1jAlo6Ehp4lZDGGbZxQg=.b10bd71e-fea3-48e7-9c31-4caecee18fe0@github.com>
Message-ID: <jXp9C900RJWni3Vx_e8h3d1tvim1E3Vs5i53FWO8g1E=.0c0f9f2a-4c6e-42a1-ac19-227a4344f805@github.com>

On Thu, 28 Mar 2024 15:08:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Yes it is some work on documentation (but seems some doc work needs to be done anyway because it was forgotten when `HeapDumpGzipLevel` was introduced).

That currently only impacts 3 documents. Having HeapDumpGzipLevel apply to the jcmd impacts 4 more, and if it doesn't apply to the jcmd then you have an inconsistency with how HeapDumpXXX options are applied.

There's also a question of whether currently missing doc updates for HeapDumpGzipLevel should be made part of this PR because it complicates back porting. We need to make sure we don't backport HeapDumpGzipLevel changes to a JDK version that has HeapDumpPath but not HeapDumpGzipLevel. I think as of right now HeapDumpPath is in 11 but HeapDumpGzipLevel is only backported to 17.

> And the current name is generic and does not mention the OOM case in the name itself, the current implementation would better match the name if it was `HeapDumpPathOnOom` or something like this.

There's still the question of whether or not it is even appropriate to have -XX options taking the place of jcmd options.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2026620689

From sspitsyn at openjdk.org  Fri Mar 29 05:58:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Mar 2024 05:58:31 GMT
Subject: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode
 profiling
In-Reply-To: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
References: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
Message-ID: <x9o2bu_W-d6WlsuYeFndBE900fvbZnVBqjUPZ7cEbWc=.6cb31439-92e0-4ff4-abfd-9801725e5045@github.com>

On Wed, 27 Mar 2024 01:02:41 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
> Reentrancy is required in the cases when two or more profiling engines are running at the same time, e.g., when CPU and Wall clock profilers work together and therefore one profiler may interrupt another in the middle of getting a stack trace.
> 
> Tested with async-profiler:
> 
> java -agentpath:/path/to/libasyncProfiler.so=start,event=cpu,interval=1ms,wall=1ms,file=profile.jfr

Marked as reviewed by sspitsyn (Reviewer).

src/hotspot/share/runtime/thread.hpp line 664:

> 662:   ThreadInAsgct(Thread* thread) : _thread(thread) {
> 663:     assert(thread != nullptr, "invariant");
> 664:     // AsyncGetCallTrace is reentrant - save the previous state.

Nit: It is possible to rephrase this comment as follows:

  // Allow AsyncGetCallTrace to be reentrant - save the previous state.
``

-------------

PR Review: https://git.openjdk.org/jdk/pull/18504#pullrequestreview-1967889766
PR Review Comment: https://git.openjdk.org/jdk/pull/18504#discussion_r1544102770

From sspitsyn at openjdk.org  Fri Mar 29 07:11:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Mar 2024 07:11:31 GMT
Subject: RFR: JDK-8328137: PreserveAllAnnotations can cause failure of
 class retransformation
In-Reply-To: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
References: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
Message-ID: <96J31hsh_reOYgnV_R5vmM1ID17_YgQBuBLIYkmXWTA=.5e357beb-2d49-4719-aa03-4dfa577e0054@github.com>

On Thu, 28 Mar 2024 22:12:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Correct solution would be to store additional information about RuntimeInvisibleAnnotations and restore them exactly as they were in the original class (this should be done for all annotations: RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations for class, fields and records, RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations/RuntimeInvisibleParameterAnnotations for methods; need to ensure the information is correctly updated during class redefinition & retransformation).
> 
> I think it doesn't make sense to add all the complexity for almost no value (I doubt anyone uses PreserveAllAnnotations, the flag looks like experimental, we don't have any tests for it).

This solution looks okay in general but still is a little bit confusing. It feels like saving just one bit would not add much complexity but would even simplify the implementation as it will become straight-forward. At least, there would be no need in this additional function with the `fallback_attr_name` parameter.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18540#issuecomment-2026785793

From apangin at openjdk.org  Fri Mar 29 11:35:57 2024
From: apangin at openjdk.org (Andrei Pangin)
Date: Fri, 29 Mar 2024 11:35:57 GMT
Subject: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode
 profiling [v2]
In-Reply-To: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
References: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
Message-ID: <ezV9V76k6OLv895D1qR3sYkvgAwT1t_Tx5fJATLkhO0=.5e6d94c2-d067-4706-b7c7-1c752180692f@github.com>

> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
> Reentrancy is required in the cases when two or more profiling engines are running at the same time, e.g., when CPU and Wall clock profilers work together and therefore one profiler may interrupt another in the middle of getting a stack trace.
> 
> Tested with async-profiler:
> 
> java -agentpath:/path/to/libasyncProfiler.so=start,event=cpu,interval=1ms,wall=1ms,file=profile.jfr

Andrei Pangin has updated the pull request incrementally with one additional commit since the last revision:

  Rephrased comment about AsyncGetCallTrace reentrancy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18504/files
  - new: https://git.openjdk.org/jdk/pull/18504/files/af9a57fd..fc5a4831

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18504&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18504&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18504/head:pull/18504

PR: https://git.openjdk.org/jdk/pull/18504

From apangin at openjdk.org  Fri Mar 29 11:39:33 2024
From: apangin at openjdk.org (Andrei Pangin)
Date: Fri, 29 Mar 2024 11:39:33 GMT
Subject: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode
 profiling [v2]
In-Reply-To: <x9o2bu_W-d6WlsuYeFndBE900fvbZnVBqjUPZ7cEbWc=.6cb31439-92e0-4ff4-abfd-9801725e5045@github.com>
References: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
 <x9o2bu_W-d6WlsuYeFndBE900fvbZnVBqjUPZ7cEbWc=.6cb31439-92e0-4ff4-abfd-9801725e5045@github.com>
Message-ID: <l3merCs1xiv03AodmOQpRgtBvbLBp5A3FKmudtul9UM=.e5c56d16-c0e2-4900-ab91-41c44cc8415a@github.com>

On Fri, 29 Mar 2024 05:55:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Andrei Pangin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rephrased comment about AsyncGetCallTrace reentrancy
>
> src/hotspot/share/runtime/thread.hpp line 664:
> 
>> 662:   ThreadInAsgct(Thread* thread) : _thread(thread) {
>> 663:     assert(thread != nullptr, "invariant");
>> 664:     // AsyncGetCallTrace is reentrant - save the previous state.
> 
> Nit: It is possible to rephrase this comment as follows:
> 
>   // Allow AsyncGetCallTrace to be reentrant - save the previous state.
> ``

Thank you for the review - I updated the comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18504#discussion_r1544400438

From sspitsyn at openjdk.org  Fri Mar 29 13:10:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Mar 2024 13:10:32 GMT
Subject: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode
 profiling [v2]
In-Reply-To: <ezV9V76k6OLv895D1qR3sYkvgAwT1t_Tx5fJATLkhO0=.5e6d94c2-d067-4706-b7c7-1c752180692f@github.com>
References: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
 <ezV9V76k6OLv895D1qR3sYkvgAwT1t_Tx5fJATLkhO0=.5e6d94c2-d067-4706-b7c7-1c752180692f@github.com>
Message-ID: <a9lWMAc5fqRcsoz1zjvNIpjCw_sRWWDH_p4npbQfSVA=.55894855-aece-4923-a966-180f58f3522b@github.com>

On Fri, 29 Mar 2024 11:35:57 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
>> Reentrancy is required in the cases when two or more profiling engines are running at the same time, e.g., when CPU and Wall clock profilers work together and therefore one profiler may interrupt another in the middle of getting a stack trace.
>> 
>> Tested with async-profiler:
>> 
>> java -agentpath:/path/to/libasyncProfiler.so=start,event=cpu,interval=1ms,wall=1ms,file=profile.jfr
>
> Andrei Pangin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rephrased comment about AsyncGetCallTrace reentrancy

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18504#pullrequestreview-1968490876

From dcubed at openjdk.org  Fri Mar 29 13:31:32 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 29 Mar 2024 13:31:32 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <IuK2HZd9luuh7D6DwrhW21zRy1gn38fMVWcA2vJuQhE=.caa13016-af40-4d38-8b68-6f35a793b37f@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
 <_7Oa2vFPXsQ_axKlTcLeDrBsSW_q6iuEsRqruErpj8k=.45a5bc91-c9cc-46f5-8fe7-4abbfd34c9b4@github.com>
 <IuK2HZd9luuh7D6DwrhW21zRy1gn38fMVWcA2vJuQhE=.caa13016-af40-4d38-8b68-6f35a793b37f@github.com>
Message-ID: <UtHFXIRXIM0bfJjSQab0Aek3WM_CHjAyEDU6GWQNaTM=.1f9f3ac1-42fa-4cfd-aaa6-fad99f9050c1@github.com>

On Thu, 28 Mar 2024 23:29:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Caught this comment in passing. Delays like this should be scaled with
>> defaultTimeoutFactor so that test tasks that invoke tests with options
>> that can slow the test down, e.g., `-Xcomp`, can be accommodated.
>> 
>> I believe the defaultTimeoutFact for `-Xcomp` test tasks gets bumped
>> from 4 to 10.
>
> Thanks for the comments, Chris and Dan. Updated as Chris suggested. I've added this with `-Xcomp` consideration as the worst case scenario in mind. Now, I think it is more save to make it 10 seconds instead of one. Is it going to be good enough? In fact, I've added this for manual testing to save time in waiting for test completion when it is deadlocked. Also, this is better for diagnosability.

runtime/8176717/TestInheritFD.java has an example of what I'm talking about:

    public static float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));
    public static long subProcessTimeout = (long)(15L * timeoutFactor);

so you fetch the test.timeout.factor value and then you scale your delay value.

Also:

nit typo: s/waitig/waiting/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1544497738

From cjplummer at openjdk.org  Fri Mar 29 18:47:33 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 29 Mar 2024 18:47:33 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v6]
In-Reply-To: <GFoWgbzM0eR7CvL8EVES1XQNHw4FGAOCRL3CqSR1cd0=.a80b41e2-c1c0-4646-b40e-f95a43582113@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <GFoWgbzM0eR7CvL8EVES1XQNHw4FGAOCRL3CqSR1cd0=.a80b41e2-c1c0-4646-b40e-f95a43582113@github.com>
Message-ID: <8jVAqZX1RFR2qcvbBKILpwrcbXcJ_JCW4_6xm6xlOMc=.5b5c0fb3-5962-4910-a42d-f2ad6e604c00@github.com>

On Fri, 29 Mar 2024 04:15:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This PR fixes a synchronization issue in the test:
>>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>>   
>> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
>> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
>> 
>> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
>> 
>> Testing:
>>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: move log message to the right place

test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 164:

> 162:       fatal(jni, "Main: ensureAtBreakpoint: waited 10 sec");
> 163:     }
> 164:     LOG("Main: ensureAtBreakpoint: waitig 100 millis\n");

Suggestion:

    LOG("Main: ensureAtBreakpoint: waiting 100 millis\n");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1544769747

From amenkov at openjdk.org  Fri Mar 29 19:20:31 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 29 Mar 2024 19:20:31 GMT
Subject: RFR: JDK-8328137: PreserveAllAnnotations can cause failure of
 class retransformation
In-Reply-To: <96J31hsh_reOYgnV_R5vmM1ID17_YgQBuBLIYkmXWTA=.5e357beb-2d49-4719-aa03-4dfa577e0054@github.com>
References: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
 <96J31hsh_reOYgnV_R5vmM1ID17_YgQBuBLIYkmXWTA=.5e357beb-2d49-4719-aa03-4dfa577e0054@github.com>
Message-ID: <RJb_dLNNGrhQF1NqqWmKfnBBDHy1odYdKzJKEscEiko=.ba9d9c24-11c2-460f-91e2-8b7066d743fe@github.com>

On Fri, 29 Mar 2024 07:08:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > Correct solution would be to store additional information about RuntimeInvisibleAnnotations and restore them exactly as they were in the original class (this should be done for all annotations: RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations for class, fields and records, RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations/RuntimeInvisibleParameterAnnotations for methods; need to ensure the information is correctly updated during class redefinition & retransformation).
> > I think it doesn't make sense to add all the complexity for almost no value (I doubt anyone uses PreserveAllAnnotations, the flag looks like experimental, we don't have any tests for it).
> 
> This solution looks okay in general but still is a little bit confusing. It feels like saving just one bit would not add much complexity but would even simplify the implementation as it will become straight-forward. At least, there would be no need in this additional function with the `fallback_attr_name` parameter.

It's a bit more complicated than storing 1 bit.
Lets consider ClassFileParser::parse_classfile_record_attribute as an example.
There are 2 type of annotations for records: RuntimeVisibleAnnotations and RuntimeVisibleTypeAnnotations.
For each type if PreserveAllAnnotations is set ClassFileParser additionally handles invisible annotations (RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations).
Then it "assembles" annotations (concatenates visible and invisible annotations into single array).
To restore original annotations we need to keep number of visible annotations in the annotation array (so jvmtiClassReconstituter writes part of the annotation array as visible, and the rest as invisible).
And we need to store this number for each annotation type (Annotations and TypeAnnotations for records, Annotations and TypeAnnotations for class, Annotations and TypeAnnotations for fields, Annotations/TypeAnnotations/ParameterAnnotations for methods).

I considered another way to implement the workaround - add method
`bool is_symbol_in_cp(const char* symbol)`
But then each writing would become very verbose and more confusing (needs some explanation in each place):

if (is_symbol_in_cp("RuntimeVisibleTypeAnnotations")) {
  write_annotations_attribute("RuntimeVisibleTypeAnnotations", component->type_annotations());
} else {
  write_annotations_attribute("RuntimeInvisibleTypeAnnotations", component->type_annotations());
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18540#issuecomment-2027647051

From sspitsyn at openjdk.org  Fri Mar 29 20:47:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Mar 2024 20:47:31 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <UtHFXIRXIM0bfJjSQab0Aek3WM_CHjAyEDU6GWQNaTM=.1f9f3ac1-42fa-4cfd-aaa6-fad99f9050c1@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
 <_7Oa2vFPXsQ_axKlTcLeDrBsSW_q6iuEsRqruErpj8k=.45a5bc91-c9cc-46f5-8fe7-4abbfd34c9b4@github.com>
 <IuK2HZd9luuh7D6DwrhW21zRy1gn38fMVWcA2vJuQhE=.caa13016-af40-4d38-8b68-6f35a793b37f@github.com>
 <UtHFXIRXIM0bfJjSQab0Aek3WM_CHjAyEDU6GWQNaTM=.1f9f3ac1-42fa-4cfd-aaa6-fad99f9050c1@github.com>
Message-ID: <bwq7M7lUiCRWA1oKy90K0CHBs3--BTKcdwxzQXUQCA4=.95855656-b272-493e-bd0d-7565c95e3f20@github.com>

On Fri, 29 Mar 2024 13:29:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Thanks for the comments, Chris and Dan. Updated as Chris suggested. I've added this with `-Xcomp` consideration as the worst case scenario in mind. Now, I think it is more save to make it 10 seconds instead of one. Is it going to be good enough? In fact, I've added this for manual testing to save time in waiting for test completion when it is deadlocked. Also, this is better for diagnosability.
>
> runtime/8176717/TestInheritFD.java has an example of what I'm talking about:
> 
>     public static float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));
>     public static long subProcessTimeout = (long)(15L * timeoutFactor);
> 
> so you fetch the test.timeout.factor value and then you scale your delay value.
> 
> Also:
> 
> nit typo: s/waitig/waiting/

Thank you for the example and for catching the typo. The timeout factor also needs to be passed to the native side. I think, this fragment is not worth this kind of extra complexity. One approach would be to just make it big enough, eg. make it 100 seconds instead of 10.  Another - to get rid of this trap at all. What would you prefer?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1544855730

From sspitsyn at openjdk.org  Fri Mar 29 20:47:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Mar 2024 20:47:32 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v6]
In-Reply-To: <8jVAqZX1RFR2qcvbBKILpwrcbXcJ_JCW4_6xm6xlOMc=.5b5c0fb3-5962-4910-a42d-f2ad6e604c00@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <GFoWgbzM0eR7CvL8EVES1XQNHw4FGAOCRL3CqSR1cd0=.a80b41e2-c1c0-4646-b40e-f95a43582113@github.com>
 <8jVAqZX1RFR2qcvbBKILpwrcbXcJ_JCW4_6xm6xlOMc=.5b5c0fb3-5962-4910-a42d-f2ad6e604c00@github.com>
Message-ID: <ES7WqD-Q96jSAkvnxdKeEPR6nY8rTmxqpfFaECje7nk=.76f6c761-83a0-490c-907d-a5c1fee141c9@github.com>

On Fri, 29 Mar 2024 18:44:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: move log message to the right place
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 164:
> 
>> 162:       fatal(jni, "Main: ensureAtBreakpoint: waited 10 sec");
>> 163:     }
>> 164:     LOG("Main: ensureAtBreakpoint: waitig 100 millis\n");
> 
> Suggestion:
> 
>     LOG("Main: ensureAtBreakpoint: waiting 100 millis\n");

Thanks, Chris. Will fix it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1544856030

From dcubed at openjdk.org  Fri Mar 29 22:20:48 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 29 Mar 2024 22:20:48 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <bwq7M7lUiCRWA1oKy90K0CHBs3--BTKcdwxzQXUQCA4=.95855656-b272-493e-bd0d-7565c95e3f20@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
 <_7Oa2vFPXsQ_axKlTcLeDrBsSW_q6iuEsRqruErpj8k=.45a5bc91-c9cc-46f5-8fe7-4abbfd34c9b4@github.com>
 <IuK2HZd9luuh7D6DwrhW21zRy1gn38fMVWcA2vJuQhE=.caa13016-af40-4d38-8b68-6f35a793b37f@github.com>
 <UtHFXIRXIM0bfJjSQab0Aek3WM_CHjAyEDU6GWQNaTM=.1f9f3ac1-42fa-4cfd-aaa6-fad99f9050c1@github.com>
 <bwq7M7lUiCRWA1oKy90K0CHBs3--BTKcdwxzQXUQCA4=.95855656-b272-493e-bd0d-7565c95e3f20@github.com>
Message-ID: <NxMMqvpK4L_QeBcfMBDPg4hmPOWWBU0Jx_mPrlZrHfc=.90c2daae-85be-4329-ab92-8eb74a4b0645@github.com>

On Fri, 29 Mar 2024 20:44:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> runtime/8176717/TestInheritFD.java has an example of what I'm talking about:
>> 
>>     public static float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));
>>     public static long subProcessTimeout = (long)(15L * timeoutFactor);
>> 
>> so you fetch the test.timeout.factor value and then you scale your delay value.
>> 
>> Also:
>> 
>> nit typo: s/waitig/waiting/
>
> Thank you for the example and for catching the typo. The timeout factor also needs to be passed to the native side. I think, this fragment is not worth this kind of extra complexity. One approach would be to just make it big enough, eg. make it 100 seconds instead of 10.  Another - to get rid of this trap at all. What would you prefer?

So that would mean that the native side would always wait for 100 seconds?
Or will it wait for some increment of time upto a maximum of 100 seconds?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1544915772

From sspitsyn at openjdk.org  Fri Mar 29 23:04:36 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Mar 2024 23:04:36 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <NxMMqvpK4L_QeBcfMBDPg4hmPOWWBU0Jx_mPrlZrHfc=.90c2daae-85be-4329-ab92-8eb74a4b0645@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
 <_7Oa2vFPXsQ_axKlTcLeDrBsSW_q6iuEsRqruErpj8k=.45a5bc91-c9cc-46f5-8fe7-4abbfd34c9b4@github.com>
 <IuK2HZd9luuh7D6DwrhW21zRy1gn38fMVWcA2vJuQhE=.caa13016-af40-4d38-8b68-6f35a793b37f@github.com>
 <UtHFXIRXIM0bfJjSQab0Aek3WM_CHjAyEDU6GWQNaTM=.1f9f3ac1-42fa-4cfd-aaa6-fad99f9050c1@github.com>
 <bwq7M7lUiCRWA1oKy90K0CHBs3--BTKcdwxzQXUQCA4=.95855656-b272-493e-bd0d-7565c95e3f20@github.com>
 <NxMMqvpK4L_QeBcfMBDPg4hmPOWWBU0Jx_mPrlZrHfc=.90c2daae-85be-4329-ab92-8eb74a4b0645@github.com>
Message-ID: <ticDOo4d_kGcyuU4T7Qd-oOlbupwnncY-31vX5bYMQs=.5b70d652-b5b0-4a14-a92a-5c84bdb5a2f6@github.com>

On Fri, 29 Mar 2024 22:18:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Thank you for the example and for catching the typo. The timeout factor also needs to be passed to the native side. I think, this fragment is not worth this kind of extra complexity. One approach would be to just make it big enough, eg. make it 100 seconds instead of 10.  Another - to get rid of this trap at all. What would you prefer?
>
> So that would mean that the native side would always wait for 100 seconds?
> Or will it wait for some increment of time upto a maximum of 100 seconds?

It wait for some increment of time upto a maximum of 100 seconds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1544937616

From sspitsyn at openjdk.org  Fri Mar 29 23:11:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Mar 2024 23:11:31 GMT
Subject: RFR: JDK-8328137: PreserveAllAnnotations can cause failure of
 class retransformation
In-Reply-To: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
References: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
Message-ID: <Ev5r2FqaL7ylxOGTlBRG1Rowi3CbTsNkMu5VlWvAQ3Q=.54f577ea-27c8-4b46-9989-a2213f7b49c5@github.com>

On Thu, 28 Mar 2024 22:12:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> PreserveAllAnnotations option causes class file parser to preserve RuntimeInvisibleAnnotations so VM considers them as RuntimeVisibleAnnotations.
> For class retransformation JvmtiClassFileReconstituter restores all annotations as RuntimeVisibleAnnotations attributes.
> This can cause problem is the class contains only RuntimeInvisibleAnnotations, so corresponding RuntimeVisibleAnnotations attribute name is not present in the class constant pool.
> 
> Correct solution would be to store additional information about RuntimeInvisibleAnnotations and restore them exactly as they were in the original class (this should be done for all annotations: RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations for class, fields and records, RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations/RuntimeInvisibleParameterAnnotations for methods; need to ensure the information is correctly updated during class redefinition & retransformation).
> 
> I think it doesn't make sense to add all the complexity for almost no value (I doubt anyone uses PreserveAllAnnotations, the flag looks like experimental, we don't have any tests for it).
> 
> The suggested fix adds workaround for this corner case - if "visible" attribute name is not in the CP, the annotations are restored with "invisible" attribute name.
> 
> Testing:
>   - tier1,tier2,hs-tier5-svc
>   - all java/lang/instrument tests;
>   - all RedefineClasses/RetransformClasses tests

Thank you for explaining, Alex. I see the complexity of the "simple" solution. :)
My guess is that all workarounds are going to be ugly, so I'd suggest to use the simplest one (your initial version).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18540#issuecomment-2027811158

From dcubed at openjdk.org  Sat Mar 30 01:35:39 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 30 Mar 2024 01:35:39 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <ticDOo4d_kGcyuU4T7Qd-oOlbupwnncY-31vX5bYMQs=.5b70d652-b5b0-4a14-a92a-5c84bdb5a2f6@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
 <_7Oa2vFPXsQ_axKlTcLeDrBsSW_q6iuEsRqruErpj8k=.45a5bc91-c9cc-46f5-8fe7-4abbfd34c9b4@github.com>
 <IuK2HZd9luuh7D6DwrhW21zRy1gn38fMVWcA2vJuQhE=.caa13016-af40-4d38-8b68-6f35a793b37f@github.com>
 <UtHFXIRXIM0bfJjSQab0Aek3WM_CHjAyEDU6GWQNaTM=.1f9f3ac1-42fa-4cfd-aaa6-fad99f9050c1@github.com>
 <bwq7M7lUiCRWA1oKy90K0CHBs3--BTKcdwxzQXUQCA4=.95855656-b272-493e-bd0d-7565c95e3f20@github.com>
 <NxMMqvpK4L_QeBcfMBDPg4hmPOWWBU0Jx_mPrlZrHfc=.90c2daae-85be-4329-ab92-8eb74a4b0645@github.com>
 <ticDOo4d_kGcyuU4T7Qd-oOlbupwnncY-31vX5bYMQs=.5b70d652-b5b0-4a14-a92a-5c84bdb5a2f6@github.com>
Message-ID: <TxC-gIhQAhnYgjKHHWNUQNBJGzvoPdSMbOuTOFpT_fk=.bad3d75d-a53b-4941-b293-94fa6693cb6d@github.com>

On Fri, 29 Mar 2024 23:02:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> So that would mean that the native side would always wait for 100 seconds?
>> Or will it wait for some increment of time upto a maximum of 100 seconds?
>
> It wait for some increment of time upto a maximum of 100 seconds.

I'm good with that. Thanks for clarifying.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1544999877

From kvn at openjdk.org  Sat Mar 30 01:48:47 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 30 Mar 2024 01:48:47 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
Message-ID: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>

Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.

I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.

I do not see (and not expected) performance difference with these changes.

Tested tier1-5, xcomp, stress. Running performance testing.

I need help with testing on platforms which Oracle does not support.

-------------

Commit messages:
 - remove trailing whitespace
 - 8329332: Remove CompiledMethod and CodeBlobLayout classes

Changes: https://git.openjdk.org/jdk/pull/18554/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18554&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329332
  Stats: 3885 lines in 118 files changed: 1281 ins; 1723 del; 881 mod
  Patch: https://git.openjdk.org/jdk/pull/18554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18554/head:pull/18554

PR: https://git.openjdk.org/jdk/pull/18554