From sspitsyn at openjdk.org Sat Jun 1 00:06:01 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 1 Jun 2024 00:06:01 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v2] In-Reply-To: References: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com> Message-ID: On Fri, 31 May 2024 21:04:41 GMT, Daniel D. Daugherty wrote: > Ping @sspitsyn - who handles JLI/JPLIS reviews for the Serviceability team? Sorry for the latency. Will start reviewing it today. Also, I see Alex is reviewing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19495#issuecomment-2143136005 From amenkov at openjdk.org Sat Jun 1 01:07:11 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 1 Jun 2024 01:07:11 GMT Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes [v3] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 23:55:20 GMT, Serguei Spitsyn wrote: >> Please, review the following `interp-only` issue related to carrier threads. >> There are 3 problems fixed here: >> - The `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter. >> - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. >> - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted. >> >> The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio. >> >> Testing: >> - Ran new test case locally >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: refactored def and use of process_pending_interp_only() test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 40: > 38: > 39: static const char* CTHREAD_NAME_START = "ForkJoinPool"; > 40: static const size_t CTHREAD_NAME_START_LEN = (int)strlen("ForkJoinPool"); `(int)` cast is not needed test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 58: > 56: cthreads[ct_cnt++] = jni->NewGlobalRef(thread); > 57: } > 58: deallocate(jvmti, jni, (void*)tname); cast to `void*` is not needed test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 96: > 94: } > 95: jvmtiError err = jvmti->Deallocate((unsigned char*)carrier_threads); > 96: check_jvmti_status(jni, err, "deallocate: error in JVMTI Deallocate call"); replace with `deallocate(jvmti, jni, carrier_threads);` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1623060427 PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1623061692 PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1623061890 From amenkov at openjdk.org Sat Jun 1 01:07:11 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 1 Jun 2024 01:07:11 GMT Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes [v3] In-Reply-To: <7D1Cchdl8jpFGHWJq0YLCELHQGXz6OLpkxHdLahhgmA=.4b815259-ba39-4ecb-9819-585c0123fca5@github.com> References: <7D1Cchdl8jpFGHWJq0YLCELHQGXz6OLpkxHdLahhgmA=.4b815259-ba39-4ecb-9819-585c0123fca5@github.com> Message-ID: On Thu, 30 May 2024 02:41:39 GMT, Serguei Spitsyn wrote: >> test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 201: >> >>> 199: >>> 200: // need to reset this value after the breakpoint_hit1 >>> 201: received_method_exit_event = JNI_FALSE; >> >> There was a loom-dev email thread regarding this last year. Seems related. I had concluded that the way the test was written that no MethodExit event should have been received. I'm not sure if I missed something in my analysis or if this failure is a result of your changes: >> >> https://mail.openjdk.org/pipermail/loom-dev/2023-August/006059.html >> https://mail.openjdk.org/pipermail/loom-dev/2023-September/006170.html > > Thank you for the comment and links to the discussion. In fact, I've observed the MethodExit events really posted between the breakpoint hits: `hit1` and `hit2`. The first one is at the return from the `unmount()` method. I was not able to prove why they should not be expected. I'm not sure I follow the test logic. Its summary says "Verifies that MethodExit events are delivered on both carrier and virtual threads", but now it just ignores MethodExit requested for carrier thread in breakpoint_hit1. Then there is no sense to request the event on carrier thread. Per the test summary I'd expect the test should test MethodExit for carrier thread, but then java part needs to force unmount ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1623073345 From jpai at openjdk.org Sat Jun 1 01:21:08 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 1 Jun 2024 01:21:08 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v2] In-Reply-To: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com> References: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com> Message-ID: On Fri, 31 May 2024 12:01:14 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? >> >> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. >> >> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). >> >> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. >> >> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. >> >> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. >> >> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > fix Boot-Class-Path value for Windows Hello Alex, what you suggest seems interesting and like you note much more simpler. I'll try it out and if that will work fine with the use of `--release` for the `asmlib/Instrumentor.java`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19495#issuecomment-2143194801 From amenkov at openjdk.org Sat Jun 1 02:05:05 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 1 Jun 2024 02:05:05 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v2] In-Reply-To: References: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com> Message-ID: On Sat, 1 Jun 2024 01:18:35 GMT, Jaikiran Pai wrote: > Hello Alex, what you suggest seems interesting and like you note much more simpler. I'll try it out and if that will work fine with the use of `--release` for the `asmlib/Instrumentor.java`. Actually I think you don't need to specify `--release` if you use jtreg "@enablePreview" tag, so "@build" should work fine ------------- PR Comment: https://git.openjdk.org/jdk/pull/19495#issuecomment-2143215730 From syan at openjdk.org Sat Jun 1 04:09:05 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 1 Jun 2024 04:09:05 GMT Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected waiter_count [v3] In-Reply-To: References: Message-ID: On Thu, 30 May 2024 06:36:09 GMT, SendaoYan wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> change from java_lang_VirtualThread::is_instance(thread_oop) to hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in Threads::get_pending_threads() > > The GHA test runner report a intermittent failure `ToolTabSnippetTest.testCleaningCompletionTODO(): failure`, which has been recorded in [JDK-8287078](https://bugs.openjdk.org/browse/JDK-8287078), I think it's unrelated to this PR. > @sendaoYan The serviceability fixes require two reviews. Please, wait for a second reviewer before integration. Okey. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19405#issuecomment-2143276984 From alanb at openjdk.org Sat Jun 1 04:35:07 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 1 Jun 2024 04:35:07 GMT Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected waiter_count [v3] In-Reply-To: References: Message-ID: On Thu, 30 May 2024 01:13:20 GMT, SendaoYan wrote: >> Hi all, >> ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32. >> There are two changes in this PR: >> 1. In `JvmtiEnvBase::get_object_monitor_usage` function, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. >> 2. In `Threads::get_pending_threads(ThreadsList *, int, address)` function of threads.cpp file, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. This modified function only used by `JvmtiEnvBase::get_object_monitor_usage(JavaThread*, jobject, jvmtiMonitorUsage*)`, so the risk of the modified on threads.cpp file is low. >> >> >> >> Additional testing: >> - [x] linux x86_32 run all testcases in serviceability/jvmti, all testcases run successed expect `serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default` run failed. This test also run failed before this PR, which has been recorded in [JDK-8333140](https://bugs.openjdk.org/browse/JDK-8333140) >> - [x] linux x86_64 run all testcases in serviceability/jvmti, all testcases run successed. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > change from java_lang_VirtualThread::is_instance(thread_oop) to hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in Threads::get_pending_threads() Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19405#pullrequestreview-2092010428 From jpai at openjdk.org Sat Jun 1 07:41:29 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 1 Jun 2024 07:41:29 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v3] In-Reply-To: References: Message-ID: > Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? > > There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. > > In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). > > This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. > > So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. > > The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. > > The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Alex's input - simplify the test by using ClassFileInstaller ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19495/files - new: https://git.openjdk.org/jdk/pull/19495/files/88997f4f..3c7512b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=01-02 Stats: 187 lines in 2 files changed: 13 ins; 144 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/19495.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19495/head:pull/19495 PR: https://git.openjdk.org/jdk/pull/19495 From jpai at openjdk.org Sat Jun 1 07:41:29 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 1 Jun 2024 07:41:29 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v2] In-Reply-To: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com> References: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com> Message-ID: On Fri, 31 May 2024 12:01:14 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? >> >> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. >> >> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). >> >> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. >> >> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. >> >> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. >> >> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > fix Boot-Class-Path value for Windows Alex's input to use `ClassFileInstaller` test utility helped. I've now updated the PR to simplify the jar creation. The updated tests continue to pass with these changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19495#issuecomment-2143343918 From jpai at openjdk.org Sat Jun 1 07:44:02 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 1 Jun 2024 07:44:02 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v2] In-Reply-To: <7zH-GQuftpl5CMZr34giEYACj7PE3GOV4-7Vz-QGudU=.33fa90e4-b99c-467e-b4e2-33b931a09c42@github.com> References: <-zmXJc__sIZ1QQlRgZle1klnLhOIRen1H5__WQZsNE4=.92d774b3-ed95-4653-b801-771cb0fdaaec@github.com> <7zH-GQuftpl5CMZr34giEYACj7PE3GOV4-7Vz-QGudU=.33fa90e4-b99c-467e-b4e2-33b931a09c42@github.com> Message-ID: On Fri, 31 May 2024 17:33:47 GMT, Leonid Mesnik wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> fix Boot-Class-Path value for Windows > > test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 168: > >> 166: >> 167: private static void launchApp(final Path agentJar) throws Exception { >> 168: final OutputAnalyzer oa = ProcessTools.executeLimitedTestJava( > > Is there any reason the test uses 'executeLimitedTestJava' and not 'executeTestJava'? > It might make sense to run it with different VM flags. Hello Leonid, I had intentionally used `executeLimitedTestJava()` to avoid passing along any additional options when launching that test application jar because it wasn't clear to me if passing those along will be of any use. Especially, options like `-Xcomp` which might be used when launching jtreg. That was the sole reason. Having said that, I have now updated the tests to use `executeTestJava()` to allow them to pass along these options to the jar being launched, since prior to this change, the test would have anyway ended up using those additional jtreg launch specific options. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1623170660 From amitkumar at openjdk.org Sat Jun 1 10:01:03 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Sat, 1 Jun 2024 10:01:03 GMT Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected waiter_count [v3] In-Reply-To: References: Message-ID: <_lQq2jS8E5XcQFs8HqPsIkdXcR982O67w8FreOCAWBc=.c2de08eb-6609-4c24-b388-f9a0a66f3aae@github.com> On Thu, 30 May 2024 01:13:20 GMT, SendaoYan wrote: >> Hi all, >> ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32. >> There are two changes in this PR: >> 1. In `JvmtiEnvBase::get_object_monitor_usage` function, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. >> 2. In `Threads::get_pending_threads(ThreadsList *, int, address)` function of threads.cpp file, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. This modified function only used by `JvmtiEnvBase::get_object_monitor_usage(JavaThread*, jobject, jvmtiMonitorUsage*)`, so the risk of the modified on threads.cpp file is low. >> >> >> >> Additional testing: >> - [x] linux x86_32 run all testcases in serviceability/jvmti, all testcases run successed expect `serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default` run failed. This test also run failed before this PR, which has been recorded in [JDK-8333140](https://bugs.openjdk.org/browse/JDK-8333140) >> - [x] linux x86_64 run all testcases in serviceability/jvmti, all testcases run successed. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > change from java_lang_VirtualThread::is_instance(thread_oop) to hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in Threads::get_pending_threads() I have tested it on s390x as well. I don't see any new test failure appearing. Thanks for fixing it. ------------- Marked as reviewed by amitkumar (Committer). PR Review: https://git.openjdk.org/jdk/pull/19405#pullrequestreview-2092069640 From syan at openjdk.org Sat Jun 1 11:34:08 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 1 Jun 2024 11:34:08 GMT Subject: Integrated: 8332923: ObjectMonitorUsage.java failed with unexpected waiter_count In-Reply-To: References: Message-ID: <98JMw-XThU6_wRMWY5cJLodhWhlziZi6epVTcdeYyZw=.fc956c2e-c26a-4260-a686-cb616533e141@github.com> On Sun, 26 May 2024 09:27:00 GMT, SendaoYan wrote: > Hi all, > ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32. > There are two changes in this PR: > 1. In `JvmtiEnvBase::get_object_monitor_usage` function, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. > 2. In `Threads::get_pending_threads(ThreadsList *, int, address)` function of threads.cpp file, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. This modified function only used by `JvmtiEnvBase::get_object_monitor_usage(JavaThread*, jobject, jvmtiMonitorUsage*)`, so the risk of the modified on threads.cpp file is low. > > > > Additional testing: > - [x] linux x86_32 run all testcases in serviceability/jvmti, all testcases run successed expect `serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default` run failed. This test also run failed before this PR, which has been recorded in [JDK-8333140](https://bugs.openjdk.org/browse/JDK-8333140) > - [x] linux x86_64 run all testcases in serviceability/jvmti, all testcases run successed. This pull request has now been integrated. Changeset: 51b2f806 Author: SendaoYan Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/51b2f80627adc1ca9f8335c3c028109a7018a8be Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8332923: ObjectMonitorUsage.java failed with unexpected waiter_count Co-authored-by: Jiawei Tang Reviewed-by: sspitsyn, alanb, amitkumar ------------- PR: https://git.openjdk.org/jdk/pull/19405 From syan at openjdk.org Sat Jun 1 13:54:10 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 1 Jun 2024 13:54:10 GMT Subject: RFR: 8332923: ObjectMonitorUsage.java failed with unexpected waiter_count [v3] In-Reply-To: References: Message-ID: <6lJ1bv5aSLSCB2AUeiypAg67xrOerBllnuw_8w08nPY=.510f8ac1-2fe9-4877-9f79-35ada77ad722@github.com> On Thu, 30 May 2024 01:13:20 GMT, SendaoYan wrote: >> Hi all, >> ObjectMonitorUsage.java failed with `unexpected waiter_count` after [JDK-8328083](https://bugs.openjdk.org/browse/JDK-8328083) on linux x86_32. >> There are two changes in this PR: >> 1. In `JvmtiEnvBase::get_object_monitor_usage` function, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. >> 2. In `Threads::get_pending_threads(ThreadsList *, int, address)` function of threads.cpp file, change from `java_lang_VirtualThread::is_instance(thread_oop)` to `thread_oop->is_a(vmClasses::BaseVirtualThread_klass())`to support the alternative implementation. This modified function only used by `JvmtiEnvBase::get_object_monitor_usage(JavaThread*, jobject, jvmtiMonitorUsage*)`, so the risk of the modified on threads.cpp file is low. >> >> >> >> Additional testing: >> - [x] linux x86_32 run all testcases in serviceability/jvmti, all testcases run successed expect `serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default` run failed. This test also run failed before this PR, which has been recorded in [JDK-8333140](https://bugs.openjdk.org/browse/JDK-8333140) >> - [x] linux x86_64 run all testcases in serviceability/jvmti, all testcases run successed. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > change from java_lang_VirtualThread::is_instance(thread_oop) to hread_oop->is_a(vmClasses::BaseVirtualThread_klass()) in Threads::get_pending_threads() Thanks all for the review and sponsor ------------- PR Comment: https://git.openjdk.org/jdk/pull/19405#issuecomment-2143456567 From duke at openjdk.org Sat Jun 1 16:45:03 2024 From: duke at openjdk.org (Abdelhak Zaaim) Date: Sat, 1 Jun 2024 16:45:03 GMT Subject: RFR: 8333353: Delete extra empty line in CodeBlob.java In-Reply-To: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com> References: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com> Message-ID: <7Z3wkb-5ttUOzxS4dq-MEvj6CPW3AkyFvKQ7G0CGyno=.3b92d4ff-8d67-4840-a5e3-5973923f23fe@github.com> On Fri, 31 May 2024 12:29:59 GMT, SendaoYan wrote: > Hi all, > This trivial fix, delete the extra empty line before `getOopMaps` function in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java` file. > No risk. Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/19499#pullrequestreview-2092139463 From lmesnik at openjdk.org Sat Jun 1 20:59:01 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 1 Jun 2024 20:59:01 GMT Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share In-Reply-To: References: Message-ID: On Fri, 31 May 2024 19:55:56 GMT, Chris Plummer wrote: >> The fix removes finalization cleanup from vmTestbase. >> The last to classes that use it are: DebugeeBinder and SocketIOPipe. >> The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources. >> The SocketIOPipe is used directly in AOD tests where it should be closed after test execution. >> >> The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in DebugeeProcess.waitFor(). >> >> The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. >> >> I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. >> Additionally, run all vmTestbase tests to verify there are no failures, > > test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 215: > >> 213: if (binder != null) { >> 214: binder.close(); >> 215: } > > Won't this be skipped if there is an exception during `waitForDebugee` or `waitForRedirectors`? Really, this all code is not going to work if any exception thrown. The adding The process is not destroyed, and the 'waitForRedirectors' is skipped in exception in waitForDebugee happens. The 'waitForRedirectors' tries to close 3 redirectors and fail to close all of them if exception happens. So all failure handling logic should be updated. I changed it to try/finally so it close pipe, binder and destroy process. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19505#discussion_r1623281071 From lmesnik at openjdk.org Sat Jun 1 21:11:26 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 1 Jun 2024 21:11:26 GMT Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share [v2] In-Reply-To: References: Message-ID: > The fix removes finalization cleanup from vmTestbase. > The last to classes that use it are: DebugeeBinder and SocketIOPipe. > The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources. > The SocketIOPipe is used directly in AOD tests where it should be closed after test execution. > > The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in DebugeeProcess.waitFor(). > > The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. > > I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. > Additionally, run all vmTestbase tests to verify there are no failures, Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed try/finally ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19505/files - new: https://git.openjdk.org/jdk/pull/19505/files/151a36d5..0ce8772f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19505&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19505&range=00-01 Stats: 42 lines in 2 files changed: 20 ins; 12 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/19505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19505/head:pull/19505 PR: https://git.openjdk.org/jdk/pull/19505 From duke at openjdk.org Sun Jun 2 16:04:08 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Sun, 2 Jun 2024 16:04:08 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v3] In-Reply-To: <2bsbTtQdRtS8h0ZORSgd163bHp1PZNTNiUiF_SGelZY=.618a5098-4111-4eb4-ac8d-1c02538d6a80@github.com> References: <2bsbTtQdRtS8h0ZORSgd163bHp1PZNTNiUiF_SGelZY=.618a5098-4111-4eb4-ac8d-1c02538d6a80@github.com> Message-ID: On Wed, 22 May 2024 19:04:22 GMT, Larry Cable wrote: >> Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove unused `SELF_PID_NS` >> - Rewrite in line with suggestion from Larry Cable > > On 5/22/24 11:58 AM, Sebastian L?vdahl wrote: >> >> I haven't but I will BTW which linux capabilities should be >> enabled in order to prevent a /proc/... style attach due to lack >> of permissions to access target's /proc fs? Rgds - Larry >> >> I know for sure that |CAP_NET_BIND_SERVICE| prevents access to >> |/proc//root| at least. I don't know if there's any distinction >> between the different privileges a process can have to be honest, but >> I somehow got the impression that having /any/ privilege restricts >> access to |/proc//root| (among others). But right now I cannot >> recall what gave me that impression. There's a long list of >> capabilities though: >> https://man7.org/linux/man-pages/man7/capabilities.7.html >> >> >> it lives ...it lives!!! >> >> I love it when a patch comes together! >> >> :) >> >> thx for testing this before my 1dt cup of coffee! >> >> Great feeling indeed! Ah, the best cup of the day, have a good one :) >> > > likewise Slainte Mhath! > > - Larry > >> ? >> Reply to this email directly, view it on GitHub >> , >> or unsubscribe >> . >> You are receiving this because you were mentioned.Message ID: >> ***@***.***> >> > > --------------Rdb42IWaMAGxS5O004yPY6ws > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > > > > >
>
>
On 5/22/24 11:58 AM, Sebastian L?vdahl > wrote:
>
>
> >
>

I haven't but I will BTW which linux capabilities > should be enabled in order to prevent a /proc/... style attach > due to lack of permissions to access target's /pro... @larry-cable gentle ping, did you get a chance to test it any further? Maybe @jerboaa and/or @kevinjwalls that reviewed #17628 / [JDK-8226919](https://bugs.openjdk.org/browse/JDK-8226919) would like to take a look at this fix as well? Maybe it's getting a bit late now, but it would be really awesome if we could get this to land before RDP 1 (on Thursday the 6th), so we avoid regressing any use-cases in the upcoming JDK 23. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2143912533 From lmesnik at openjdk.org Mon Jun 3 01:01:14 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 3 Jun 2024 01:01:14 GMT Subject: RFR: 8332259: JvmtiTrace::safe_get_thread_name fails if current thread is in native state [v5] In-Reply-To: References: <2Aorg4EW1Sl5s0tplzUb89ZNUeZg2xsPj3VkJQflzN4=.9072eee0-c481-4da9-ade9-5595ab78030f@github.com> Message-ID: On Wed, 29 May 2024 01:18:57 GMT, Serguei Spitsyn wrote: >> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: >> >> - fixed space. >> - The result is updated. > > src/hotspot/share/prims/jvmtiTrace.cpp line 284: > >> 282: JavaThreadState current_state = JavaThread::cast(Thread::current())->thread_state(); >> 283: if (current_state == _thread_in_native || current_state == _thread_blocked) { >> 284: return "not readable"; > > Nit: I'd suggest to make it more detailed, something like like this: > "" or "" @sspitsyn, @dholmes-ora Thanks for the naming suggestion, looks to long in the report. Let me try to use logging and see if it makes sense to make more improvements. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19275#discussion_r1623691234 From duke at openjdk.org Mon Jun 3 07:23:15 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 07:23:15 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v2] In-Reply-To: References: Message-ID: > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: Remove duplicated Carrying statement and indent vthread stack ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/1a75277e..ae690b25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=00-01 Stats: 12 lines in 2 files changed: 2 ins; 7 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From duke at openjdk.org Mon Jun 3 07:23:16 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 07:23:16 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump In-Reply-To: References: Message-ID: On Thu, 30 May 2024 14:13:34 GMT, Inigo Mediavilla Saiz wrote: > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. In https://github.com/openjdk/jdk/pull/19482/commits/ae690b255c9456f3db534be11fbc932648907ead I've : - Removed the duplicated "Carrying" sentence. - Indented the virtual thread stack ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2144454481 From duke at openjdk.org Mon Jun 3 07:40:35 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 07:40:35 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v3] In-Reply-To: References: Message-ID: <4GGyaGSsNMwlIfwAUEr7MAeyBp3rgm9vsMhw55lONSc=.3cc0a40d-f6be-416b-85eb-379fa0318071@github.com> > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz 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 remote-tracking branch 'upstream/master' into txominpelu_8330846_add_stack_vthreads - Remove duplicated Carrying statement and indent vthread stack - 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/ae690b25..47d77461 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=01-02 Stats: 7531 lines in 244 files changed: 4287 ins; 2457 del; 787 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From dholmes at openjdk.org Mon Jun 3 08:04:18 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 3 Jun 2024 08:04:18 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v4] In-Reply-To: <778pi5AHHgXZdUEBV45R0Npj1wZPeuAHwWdrygWR830=.d67d6249-0dcd-4fef-976f-6911432d53f8@github.com> References: <778pi5AHHgXZdUEBV45R0Npj1wZPeuAHwWdrygWR830=.d67d6249-0dcd-4fef-976f-6911432d53f8@github.com> Message-ID: On Fri, 31 May 2024 08:07:36 GMT, Serguei Spitsyn wrote: >> The following RFE was fixed recently: >> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code >> >> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++. >> This update is to make it clear that `nullptr` is C programming language `null` pointer. >> >> I think we do not need a CSR for this fix. >> >> Testing: N/A (not needed) > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: more null pointer corrections The general rules are to either say "a null pointer" (possibly with capital A depending on context), or just "null". And in most cases you could choose either. I made various suggestions but really it is up to you. It is hard to get a sense of consistency from these small fragments. The word "null" should never be in code font as it is not a programming language entity. Thanks for your patience and perseverance on this. src/hotspot/share/prims/jvmti.xml line 1101: > 1099: > 1100: On return, a pointer to the beginning of the allocated memory. > 1101: If size is zero, null pointer is returned. If saying "null pointer" then it should be "a null pointer". src/hotspot/share/prims/jvmti.xml line 1533: > 1531: > 1532: > 1533: On return, points to the current thread, or null. remove code font src/hotspot/share/prims/jvmti.xml line 1996: > 1994: > 1995: The thread group to which this thread belongs. > 1996: null pointer if the thread has terminated. Just "Null if ..." src/hotspot/share/prims/jvmti.xml line 2142: > 2140: > 2141: On return, filled with the current contended monitor, or > 2142: null pointer if there is none. Just "null" src/hotspot/share/prims/jvmti.xml line 2262: > 2260: > 2261: > 2262: null pointer is passed to the start function A null ... src/hotspot/share/prims/jvmti.xml line 2353: > 2351: If thread-local storage has not been set with > 2352: the returned > 2353: pointer is null. Remove code font src/hotspot/share/prims/jvmti.xml line 4277: > 4275: , > 4276: or . > 4277: Otherwise null pointer. a null ... src/hotspot/share/prims/jvmti.xml line 4322: > 4320: points to the zero if the referrer > 4321: object is not tagged. > 4322: null pointer if the referrer in not an object (that is, Null if ... src/hotspot/share/prims/jvmti.xml line 4769: > 4767: > 4768: > 4769: null pointer is passed as the user supplied data a null pointer src/hotspot/share/prims/jvmti.xml line 4945: > 4943: > 4944: > 4945: null pointer is passed as the user supplied data a null pointer src/hotspot/share/prims/jvmti.xml line 5593: > 5591: > 5592: > 5593: null pointer is passed as the user supplied data a null pointer src/hotspot/share/prims/jvmti.xml line 5637: > 5635: callback will not be called until the appropriate callback has been called > 5636: for all roots. If the callback is > 5637: specified as null pointer then this function returns after Just "as null then" src/hotspot/share/prims/jvmti.xml line 5692: > 5690: > 5691: >null pointer is passed as the user supplied data > 5692: a null pointer src/hotspot/share/prims/jvmti.xml line 5750: > 5748: > 5749: > 5750: null pointer is passed as the user supplied data a null pointer src/hotspot/share/prims/jvmti.xml line 6770: > 6768: If a named module is defined to the class loader and it > 6769: contains the package then that named module is returned, > 6770: otherwise null pointer is returned. Just "null" src/hotspot/share/prims/jvmti.xml line 6803: > 6801: > 6802: On return, points to a java.lang.Module object > 6803: or points to null. Remove code font src/hotspot/share/prims/jvmti.xml line 7264: > 7262: modified UTF-8 string. > 7263: If there is no generic signature attribute for the class, then, > 7264: on return, points to null. Remove code font src/hotspot/share/prims/jvmti.xml line 7794: > 7792: If the class was not created by a class loader > 7793: or if the class loader is the bootstrap class loader, > 7794: points to null. Remove code font src/hotspot/share/prims/jvmti.xml line 8414: > 8412: modified UTF-8 string. > 8413: If there is no generic signature attribute for the field, then, > 8414: on return, points to null. Remove code font src/hotspot/share/prims/jvmti.xml line 8607: > 8605: modified UTF-8 string. > 8606: If there is no generic signature attribute for the method, then, > 8607: on return, points to null. Remove code font src/hotspot/share/prims/jvmti.xml line 9243: > 9241: of 1. > 9242: Calling SetNativeMethodPrefix with > 9243: null pointer is the same as calling this function with a null pointer src/hotspot/share/prims/jvmti.xml line 11657: > 11655: > 11656: > 11657: value is set to null Remove code font src/hotspot/share/prims/jvmti.xml line 11951: > 11949: > 11950: > 11951: Pointer is unexpectedly null. Remove code font. src/hotspot/share/prims/jvmti.xml line 12458: > 12456: > 12457: Object with the field being accessed if the field is an > 12458: instance field; null pointer otherwise a null pointer src/hotspot/share/prims/jvmti.xml line 12528: > 12526: > 12527: Object with the field being modified if the field is an > 12528: instance field; null pointer otherwise a null pointer src/hotspot/share/prims/jvmti.xml line 12879: > 12877: > 12878: > 12879: Class that will catch the exception, or null pointer if no known catch Just "null" src/hotspot/share/prims/jvmti.xml line 12885: > 12883: > 12884: > 12885: Method that will catch the exception, or null pointer if no known catch Just "null" src/hotspot/share/prims/jvmti.xml line 13397: > 13395: redefined or > 13396: retransformed. > 13397: null pointer if sent by class load. A null pointer src/hotspot/share/prims/jvmti.xml line 13404: > 13402: > 13403: The class loader loading the class. > 13404: null pointer if the bootstrap class loader. A null pointer src/hotspot/share/prims/jvmti.xml line 13414: > 13412: modified UTF-8 string. > 13413: Note: if the class is defined with a null pointer name or > 13414: without a name specified, name will be null. How do you not specify a name other than by passing "null" for the name?? src/hotspot/share/prims/jvmti.xml line 13632: > 13630: > 13631: to start_address-1 of the next entry. > 13632: null pointer if mapping information cannot be supplied. A null pointer src/hotspot/share/prims/jvmti.xml line 14695: > 14693: > 14694: > 14695: Allow null pointer as RunAgentThread arg. Just "null" src/hotspot/share/prims/jvmti.xml line 14705: > 14703: > 14704: > 14705: Change GetFieldName to allow null pointer like GetMethodName. Just null src/hotspot/share/prims/jvmti.xml line 14814: > 14812: Clarify semantics of raw monitors. > 14813: Change flags on GetThreadStatus. > 14814: GetClassLoader return null pointer for the bootstrap class loader. a null pointer src/hotspot/share/prims/jvmti.xml line 14824: > 14822: > 14823: Define the data type jvmtiEventCallbacks. > 14824: Zero length allocations return null pointer. a null pointer src/hotspot/share/prims/jvmti.xml line 14846: > 14844: remove GetHeapRoots, add reachable iterators, > 14845: and rename "annotation" to "tag". > 14846: null pointer thread parameter on most functions is current A null pointer src/hotspot/share/prims/jvmti.xsl line 1589: > 1587: > 1588: is > 1589: null pointer Remove code font src/hotspot/share/prims/jvmtiEnv.xsl line 139: > 137: > 138: > 139: // method - pre-checked for validity, but may be null pointer meaning obsolete method Just "null" src/hotspot/share/prims/jvmtiEnv.xsl line 169: > 167: // > 168: > 169: - pre-checked for null pointer Just null src/hotspot/share/prims/jvmtiEnv.xsl line 175: > 173: // > 174: > 175: - null pointer is a valid value, must be checked Just null src/hotspot/share/prims/jvmtiLib.xsl line 180: > 178: > 179: is > 180: null pointer, . Just null (no code font) src/hotspot/share/prims/jvmtiLib.xsl line 381: > 379: > 380: is > 381: null pointer, the current thread is used. Just null (no code font) ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19257#pullrequestreview-2093011060 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623916928 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623917438 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623918169 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623920264 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623920788 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623921174 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623922170 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623923033 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623923386 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623923954 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623924658 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623925443 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623925864 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623926064 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623926453 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623926975 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623927420 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623927827 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623928337 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623928549 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623928967 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623930079 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623930308 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623931169 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623931569 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623932080 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623932303 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623932917 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623933143 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623934935 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623935320 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623935750 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623936049 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623936478 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623936755 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623937128 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623938553 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623938932 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623939238 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623939410 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623940127 PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1623941054 From syan at openjdk.org Mon Jun 3 08:15:07 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 3 Jun 2024 08:15:07 GMT Subject: Integrated: 8333353: Delete extra empty line in CodeBlob.java In-Reply-To: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com> References: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com> Message-ID: On Fri, 31 May 2024 12:29:59 GMT, SendaoYan wrote: > Hi all, > This trivial fix, delete the extra empty line before `getOopMaps` function in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java` file. > No risk. This pull request has now been integrated. Changeset: 91101f0d Author: SendaoYan Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/91101f0d4fc8e06d0d74e06361db6ac87efeeb8e Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8333353: Delete extra empty line in CodeBlob.java Reviewed-by: cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/19499 From duke at openjdk.org Mon Jun 3 08:30:15 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 08:30:15 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v4] In-Reply-To: References: Message-ID: > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: Add missing header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/47d77461..76e6e58c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From stuefe at openjdk.org Mon Jun 3 08:37:03 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 3 Jun 2024 08:37:03 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v4] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 08:30:15 GMT, Inigo Mediavilla Saiz wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: > > Add missing header I also find the duplication of the stack printing code unfortunate. It would be nice to reuse`JavaThread::print_vthread_stack_on`. I don't understand why it cannot be const? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2144599582 From dholmes at openjdk.org Mon Jun 3 08:37:03 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 3 Jun 2024 08:37:03 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump In-Reply-To: References: Message-ID: On Fri, 31 May 2024 02:07:25 GMT, David Holmes wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > I'd probably give preference to the stack of the virtual thread, as the stack of the carrier when a vthread is mounted is generally quite uninteresting: > > "ForkJoinPool-1-worker-1" #25 [33795] daemon prio=5 os_prio=31 cpu=46574.42ms elapsed=47.15s tid=0x00007f81670d1a00 [0x000070000e9a4000] > Carrying virtual thread #24 > at Main.lambda$main$0(Main.java:7) > at java.lang.VirtualThread.run(java.base/VirtualThread.java:381) > at jdk.internal.vm.Continuation.run(java.base/Continuation.java:262) > at java.lang.VirtualThread.runContinuation(java.base/VirtualThread.java:283) > at java.lang.VirtualThread$$Lambda/0x00000001220b2868.run(java.base/Unknown Source) > at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1726) > at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base/ForkJoinTask.java:1717) > at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base/ForkJoinTask.java:1641) > at java.util.concurrent.ForkJoinTask.doExec(java.base/ForkJoinTask.java:507) > at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base/ForkJoinPool.java:1455) > at java.util.concurrent.ForkJoinPool.runWorker(java.base/ForkJoinPool.java:2031) > at java.util.concurrent.ForkJoinWorkerThread.run(java.base/ForkJoinWorkerThread.java:189) > > * The format proposed by @dholmes-ora definitely makes sense > > You will different get different opinions on how it is presented. Can you also try putting a new section that lists the mounted virtual threads and their stack trace. If the virtual thread has a name then it can be shown too. That suggests to me that we have to iterate the list of all threads twice ?? If so that seems not ideal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2144602366 From dholmes at openjdk.org Mon Jun 3 08:37:04 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 3 Jun 2024 08:37:04 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v4] In-Reply-To: References: Message-ID: <9JBg_8MOUMYPv3S-9qvNwZ8of_2cCS2ZPkXF5t-oD9Y=.afa851bb-8d63-48df-a914-b2535cd94d65@github.com> On Mon, 3 Jun 2024 08:31:46 GMT, Thomas Stuefe wrote: > I also find the duplication of the stack printing code unfortunate. It would be nice to reuse`JavaThread::print_vthread_stack_on`. I don't understand why it cannot be const? Just what I was about to query :) I'm not sure what the const issue is. Printing a stack certainly should not modify anything. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2144606292 From syan at openjdk.org Mon Jun 3 08:38:09 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 3 Jun 2024 08:38:09 GMT Subject: RFR: 8333353: Delete extra empty line in CodeBlob.java In-Reply-To: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com> References: <0T1my_A1NwUhQqrv5PmT66qGTTTvtAEyren-LmOAtqE=.0e2f329a-1319-41a9-9bd3-5b5bcca9ac48@github.com> Message-ID: On Fri, 31 May 2024 12:29:59 GMT, SendaoYan wrote: > Hi all, > This trivial fix, delete the extra empty line before `getOopMaps` function in `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java` file. > No risk. Thanks all for the review and sponsor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19499#issuecomment-2144609919 From aturbanov at openjdk.org Mon Jun 3 09:04:04 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 3 Jun 2024 09:04:04 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v4] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 08:30:15 GMT, Inigo Mediavilla Saiz wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: > > Add missing header test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 84: > 82: void compute() { > 83: started.countDown(); > 84: while(true) { Suggestion: while (true) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1624070607 From duke at openjdk.org Mon Jun 3 09:16:08 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 09:16:08 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v4] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 09:01:52 GMT, Andrey Turbanov wrote: >> Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing header > > test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 84: > >> 82: void compute() { >> 83: started.countDown(); >> 84: while(true) { > > Suggestion: > > while (true) { Thanks ! Regarding formatting, are there public code formatters for openjdk code that can be used from IntelliJ or other editors ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1624090018 From sgehwolf at openjdk.org Mon Jun 3 09:23:12 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 3 Jun 2024 09:23:12 GMT Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container [v3] In-Reply-To: References: Message-ID: On Fri, 3 May 2024 16:05:30 GMT, Severin Gehwolf 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? > > Severin Gehwolf 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 12 additional commits since the last revision: > > - Add doc for mountinfo scanning. > - Unify naming of variables > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - 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 > - ... and 2 more: https://git.openjdk.org/jdk/compare/88976cae...434430ca Keep open bot. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2144706137 From sspitsyn at openjdk.org Mon Jun 3 09:58:38 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Jun 2024 09:58:38 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: References: Message-ID: > The following RFE was fixed recently: > [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code > > It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++. > This update is to make it clear that `nullptr` is C programming language `null` pointer. > > I think we do not need a CSR for this fix. > > Testing: N/A (not needed) Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: consistency and stylistical corrections ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19257/files - new: https://git.openjdk.org/jdk/pull/19257/files/48ba8f5d..ed2eff27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19257&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19257&range=03-04 Stats: 43 lines in 4 files changed: 0 ins; 0 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/19257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19257/head:pull/19257 PR: https://git.openjdk.org/jdk/pull/19257 From sspitsyn at openjdk.org Mon Jun 3 09:58:38 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Jun 2024 09:58:38 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v4] In-Reply-To: References: <778pi5AHHgXZdUEBV45R0Npj1wZPeuAHwWdrygWR830=.d67d6249-0dcd-4fef-976f-6911432d53f8@github.com> Message-ID: On Mon, 3 Jun 2024 08:01:25 GMT, David Holmes wrote: > The general rules are to either say "a null pointer" (possibly with capital A depending on context), or just "null". And in most cases you could choose either. I made various suggestions but really it is up to you. It is hard to get a sense of consistency from these small fragments. > > The word "null" should never be in code font as it is not a programming language entity. Thank you, David. This is really useful. I've pushed an update with all changes you suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19257#issuecomment-2144777338 From ihse at openjdk.org Mon Jun 3 10:07:05 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 3 Jun 2024 10:07:05 GMT Subject: Integrated: 8333301: Remove static builds using --enable-static-build In-Reply-To: References: Message-ID: On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie wrote: > The original way of building static libraries in the JDK was to use the configure argument --enable-static-build, which set the value of the make variable STATIC_BUILD. (Note that this is not the same as the source code definition STATIC_BUILD, which will be set by other means as well.) > > This method only ever worked on macOS, and has long since stopped working. It was originally introduced for the Mobile Project, but I've now learn that not even they use it anymore. > > It just adds clutter to the build system, and should be removed. This pull request has now been integrated. Changeset: f0bffbce Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/f0bffbce35bb06e724857e8651dd429c4f9df284 Stats: 218 lines in 14 files changed: 4 ins; 206 del; 8 mod 8333301: Remove static builds using --enable-static-build Reviewed-by: sgehwolf, erikj ------------- PR: https://git.openjdk.org/jdk/pull/19487 From duke at openjdk.org Mon Jun 3 11:22:12 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 11:22:12 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v5] In-Reply-To: References: Message-ID: > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz has updated the pull request incrementally with two additional commits since the last revision: - Update test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java Co-authored-by: Andrey Turbanov - Use JavaThread::print_vthread_stack_on ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/76e6e58c..12a41a54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=03-04 Stats: 19 lines in 2 files changed: 0 ins; 17 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From duke at openjdk.org Mon Jun 3 11:26:27 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 11:26:27 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v6] In-Reply-To: References: Message-ID: > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: Add indentation for virtual thread stack ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/12a41a54..6a3b779f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=04-05 Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From duke at openjdk.org Mon Jun 3 11:26:27 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 11:26:27 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v5] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 11:22:12 GMT, Inigo Mediavilla Saiz wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > Inigo Mediavilla Saiz has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java > > Co-authored-by: Andrey Turbanov > - Use JavaThread::print_vthread_stack_on Sorry, I don't know what I did wrong last week, but when I tried to rely on `print_vthread_stack_on` I was getting compilation errors. In any case, it seems to be working now with https://github.com/openjdk/jdk/pull/19482/commits/59b18db4833cc5b7a9c3a79e707efeb13ce84f86. Thanks for insisting, and sorry for the confusion. > > I also find the duplication of the stack printing code unfortunate. It would be nice to reuse`JavaThread::print_vthread_stack_on`. I don't understand why it cannot be const? > > Just what I was about to query :) I'm not sure what the const issue is. Printing a stack certainly should not modify anything. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2144945530 From duke at openjdk.org Mon Jun 3 11:30:02 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 11:30:02 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v4] In-Reply-To: <9JBg_8MOUMYPv3S-9qvNwZ8of_2cCS2ZPkXF5t-oD9Y=.afa851bb-8d63-48df-a914-b2535cd94d65@github.com> References: <9JBg_8MOUMYPv3S-9qvNwZ8of_2cCS2ZPkXF5t-oD9Y=.afa851bb-8d63-48df-a914-b2535cd94d65@github.com> Message-ID: On Mon, 3 Jun 2024 08:34:11 GMT, David Holmes wrote: >> I also find the duplication of the stack printing code unfortunate. It would be nice to reuse`JavaThread::print_vthread_stack_on`. I don't understand why it cannot be const? > >> I also find the duplication of the stack printing code unfortunate. It would be nice to reuse`JavaThread::print_vthread_stack_on`. I don't understand why it cannot be const? > > Just what I was about to query :) I'm not sure what the const issue is. Printing a stack certainly should not modify anything. > > > * The format proposed by @dholmes-ora definitely makes sense > > > > > > You will different get different opinions on how it is presented. Can you also try putting a new section that lists the mounted virtual threads and their stack trace. If the virtual thread has a name then it can be shown too. > > That suggests to me that we have to iterate the list of all threads twice ?? If so that seems not ideal. I think that both approaches suggested by @AlanBateman would work, but I personally like the fact that having the virtual thread being displayed on top of the carrier thread allows seeing the full stack trace together. I've tried to preserve that approach while calling `print_vthread_stack_on` in 6a3b779f521. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2144953866 From rpressler at openjdk.org Mon Jun 3 13:11:05 2024 From: rpressler at openjdk.org (Ron Pressler) Date: Mon, 3 Jun 2024 13:11:05 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v6] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 11:26:27 GMT, Inigo Mediavilla Saiz wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: > > Add indentation for virtual thread stack About the output format: 1. The text Carrying virtual thread #N should appear, as it does, in the header of the output for the platform thread. 2. The stack for the mounted virtual thread should appear, indented *after* the stack of the platform thread, with the header `Mounted virtual thread #N`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2145162783 From alanb at openjdk.org Mon Jun 3 13:17:02 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 3 Jun 2024 13:17:02 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v6] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 11:26:27 GMT, Inigo Mediavilla Saiz wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: > > Add indentation for virtual thread stack I don't think showing the frames of the mounted virtual thread before the carrier thread frames is the best way to show this. For one thing, it appears immediately after the carrier's thread name/details and state. So I think Ron's suggestion to clearly label it as the mounted virtual thread after the carrier stack trace would be good to try. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2145174545 From duke at openjdk.org Mon Jun 3 13:31:16 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 13:31:16 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v7] In-Reply-To: References: Message-ID: <9lc4sCQvq1bo5VEaIXPINF-jDXvJZ2ub2F8f8ZgYVb0=.bbdb1cf0-24f5-47e6-b098-859dd3ecf4a2@github.com> > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: Print mounted virtual thread after carrier ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/6a3b779f..9acbf29d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=05-06 Stats: 11 lines in 2 files changed: 7 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From duke at openjdk.org Mon Jun 3 13:31:16 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 3 Jun 2024 13:31:16 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v6] In-Reply-To: References: Message-ID: <7WyhcfGjzeiYWQ4N_vyRgQ5DA59bOfSfJg4eTTFDt7U=.9c5e0191-1458-494c-a92d-a9688d7e5149@github.com> On Mon, 3 Jun 2024 13:13:55 GMT, Alan Bateman wrote: >> Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: >> >> Add indentation for virtual thread stack > > I don't think showing the frames of the mounted virtual thread before the carrier thread frames is the best way to show this. For one thing, it appears immediately after the carrier's thread name/details and state. So I think Ron's suggestion to clearly label it as the mounted virtual thread after the carrier stack trace would be good to try. Thanks @AlanBateman and @pron ! Based on your comments I've added https://github.com/openjdk/jdk/pull/19482/commits/9acbf29da37c4f6c143a150635a09c711300a4c7. That provides the following output: "ForkJoinPool-1-worker-1" #21 [27907] daemon prio=5 os_prio=31 cpu=29561.73ms elapsed=29.71s tid=0x0000000147089c10 [0x000000017178d000] Carrying virtual thread #20 Thread: 0x0000000147089c10 [0x6d03] State: _at_safepoint _at_poll_safepoint 1 JavaThread state: _thread_blocked at jdk.internal.vm.Continuation.run(java.base at 23-internal/Continuation.java:248) at java.lang.VirtualThread.runContinuation(java.base at 23-internal/VirtualThread.java:245) at java.lang.VirtualThread$$Lambda/0x0000300001046740.run(java.base at 23-internal/Unknown Source) at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-internal/ForkJoinTask.java:1726) at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-internal/ForkJoinTask.java:1717) at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base at 23-internal/ForkJoinTask.java:1641) at java.util.concurrent.ForkJoinTask.doExec(java.base at 23-internal/ForkJoinTask.java:507) at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base at 23-internal/ForkJoinPool.java:1489) at java.util.concurrent.ForkJoinPool.scan(java.base at 23-internal/ForkJoinPool.java:2071) at java.util.concurrent.ForkJoinPool.runWorker(java.base at 23-internal/ForkJoinPool.java:2033) at java.util.concurrent.ForkJoinWorkerThread.run(java.base at 23-internal/ForkJoinWorkerThread.java:189) Mounted virtual thread #20 at Main$FunkyLambda.compute(Main.java:38) at Main$FunkyLambda.computeFunkyName(Main.java:31) at Main$$Lambda/0x0000300001000c50.run(Unknown Source) at java.lang.Thread.runWith(java.base at 23-internal/Thread.java:1588) at java.lang.VirtualThread.run(java.base at 23-internal/VirtualThread.java:329) at java.lang.VirtualThread$VThreadContinuation$1.run(java.base at 23-internal/VirtualThread.java:209) at jdk.internal.vm.Continuation.enter0(java.base at 23-internal/Continuation.java:320) at jdk.internal.vm.Continuation.enter(java.base at 23-internal/Continuation.java:312) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2145205780 From duke at openjdk.org Mon Jun 3 15:41:09 2024 From: duke at openjdk.org (Larry Cable) Date: Mon, 3 Jun 2024 15:41:09 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v3] In-Reply-To: References: Message-ID: On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl wrote: >> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) > > Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision: > > - Remove unused `SELF_PID_NS` > - Rewrite in line with suggestion from Larry Cable Hi Sebastian, sadly no I haven't. :( it would be good to get it in, it would be good if @kevinjwalls could take a look. as with regressions, I think as long as it passes the current set of tests then there are unlikely to be any regressions. we really need a test to validate: 1) attach to elevated JVM 2) attach across container boundary ??? a) to elevated JVM - Larry On 6/2/24 9:02 AM, Sebastian L?vdahl wrote: > > @larry-cable > > gentle ping, did you get a chance to test it any further? > > Maybe @jerboaa > > and/or @kevinjwalls > > that reviewed #17628 > > / JDK-8226919 would like > to take a look at this fix as well? > > Maybe it's getting a bit late now, but it would be really awesome if > we could get this to land before RDP 1 (on Thursday the 6th), so we > avoid regressing any use-cases in the upcoming JDK 23. > > ? > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > --------------JJW8ycnoTBYUYFaUv43Mvg08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Sebastian, sadly no I haven't. :(

it would be good to get it in, it would be good if @kevinjwalls could take a look.

as with regressions, I think as long as it passes the current set of tests then there are unlikely to be any regressions.

we really need a test to validate:

1) attach to elevated JVM

2) attach across container boundary
    a) to elevated JVM

- Larry

On 6/2/24 9:02 AM, Sebastian L?vdahl wrote:

gentle ping, did you get a chance to test it any further?

Maybe and/or that reviewed #17628 / JDK-8226919 would like to take a look at this fix as well?

Maybe it's getting a bit late now, but it would be really awesome if we could get this to land before RDP 1 (on Thursday the 6th), so we avoid regressing any use-cases in the upcoming JDK 23.

?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <openjdk/jdk/pull/19055/c2143912533@github.com>


--------------JJW8ycnoTBYUYFaUv43Mvg08-- ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2145536184 From duke at openjdk.org Mon Jun 3 17:27:05 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Mon, 3 Jun 2024 17:27:05 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v3] In-Reply-To: References: Message-ID: On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl wrote: >> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) > > Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision: > > - Remove unused `SELF_PID_NS` > - Rewrite in line with suggestion from Larry Cable Hi Larry, no worries. :) I can try to look into writing some tests for the elevated use-cases. but it will be quite much treading of new ground for me, so it could take some time to get it done. What's your take, do we need the new tests in this PR, or could it be done in a follow-up? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2145749773 From sspitsyn at openjdk.org Mon Jun 3 19:01:36 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Jun 2024 19:01:36 GMT Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes [v3] In-Reply-To: References: Message-ID: On Sat, 1 Jun 2024 00:22:45 GMT, Alex Menkov wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: refactored def and use of process_pending_interp_only() > > test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 40: > >> 38: >> 39: static const char* CTHREAD_NAME_START = "ForkJoinPool"; >> 40: static const size_t CTHREAD_NAME_START_LEN = (int)strlen("ForkJoinPool"); > > `(int)` cast is not needed Thanks, fixed now. > test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 58: > >> 56: cthreads[ct_cnt++] = jni->NewGlobalRef(thread); >> 57: } >> 58: deallocate(jvmti, jni, (void*)tname); > > cast to `void*` is not needed Why do you think, the cast is not needed? This is the `deallocate()` function in the `jvmti_common.hpp`: static void deallocate(jvmtiEnv *jvmti, JNIEnv* jni, void* ptr) { jvmtiError err = jvmti->Deallocate((unsigned char*)ptr); check_jvmti_status(jni, err, "deallocate: error in JVMTI Deallocate call"); } > test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp line 96: > >> 94: } >> 95: jvmtiError err = jvmti->Deallocate((unsigned char*)carrier_threads); >> 96: check_jvmti_status(jni, err, "deallocate: error in JVMTI Deallocate call"); > > replace with `deallocate(jvmti, jni, carrier_threads);` ? Thanks, fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1624909747 PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1624911862 PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1624914083 From amenkov at openjdk.org Mon Jun 3 20:27:32 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 3 Jun 2024 20:27:32 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v3] In-Reply-To: References: Message-ID: On Sat, 1 Jun 2024 07:41:29 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? >> >> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. >> >> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). >> >> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. >> >> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. >> >> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. >> >> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alex's input - simplify the test by using ClassFileInstaller test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 86: > 84: Can-Set-Native-Method-Prefix: true > 85: """ > 86: + "Boot-Class-Path: " + bootClassesDir.toString().replace(File.separatorChar, '/') + "/" AFAIU Boot-Class-Path is needed only because the agent needs bootreporter.StringIdCallbackReporter I don't see much point in separate bootreporter dir. So we can set Boot-Class-Path to System.getProperty("test.classes") and drop createBootClassesDir() logic test/jdk/java/lang/instrument/RetransformApp.java line 81: > 79: final OutputAnalyzer oa = ProcessTools.executeTestJava( > 80: "--enable-preview", // due to usage of ClassFile API PreviewFeature in the agent > 81: "-XX:+UnlockDiagnosticVMOptions", "-XX:-CheckIntrinsics", This `-XX` flags were not present for this test (and I don't think they are needed for NativeMethodPrefix test too) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1625009748 PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1624969611 From duke at openjdk.org Mon Jun 3 20:50:32 2024 From: duke at openjdk.org (Larry Cable) Date: Mon, 3 Jun 2024 20:50:32 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v3] In-Reply-To: References: Message-ID: On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl wrote: >> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) > > Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision: > > - Remove unused `SELF_PID_NS` > - Rewrite in line with suggestion from Larry Cable going to take a look at a couple of the "containers" tests to see if I can "quickly" clone them to provide a bootstrap for this patch... - Larry On 6/3/24 10:24 AM, Sebastian L?vdahl wrote: > > Hi Larry, no worries. :) > > I can try to look into writing some tests for the elevated use-cases. > but it will be quite much treading of new ground for me, so it could > take some time to get it done. > > What's your take, do we need the new tests in this PR, or could it be > done in a follow-up? > > ? > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > --------------XIGzXIQgYm0WtZy9a5FZZTYy Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit going to take a look at a couple of the "containers" tests to see if I can "quickly" clone them to provide a bootstrap for this patch...

- Larry

On 6/3/24 10:24 AM, Sebastian L?vdahl wrote:

Hi Larry, no worries. :)

I can try to look into writing some tests for the elevated use-cases. but it will be quite much treading of new ground for me, so it could take some time to get it done.

What's your take, do we need the new tests in this PR, or could it be done in a follow-up?

?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <openjdk/jdk/pull/19055/c2145749773@github.com>


--------------XIGzXIQgYm0WtZy9a5FZZTYy-- ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2146095382 From duke at openjdk.org Mon Jun 3 21:15:34 2024 From: duke at openjdk.org (Larry Cable) Date: Mon, 3 Jun 2024 21:15:34 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v3] In-Reply-To: References: Message-ID: <7B6_QVhh51E8s-zVebpI01M0yaMPs-DGUpPr83JKrnc=.b82d6deb-59c0-44d9-9b4a-a3dc2a90416e@github.com> On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl wrote: >> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) > > Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision: > > - Remove unused `SELF_PID_NS` > - Rewrite in line with suggestion from Larry Cable On 6/3/24 10:24 AM, Sebastian L?vdahl wrote: > > Hi Larry, no worries. :) > > I can try to look into writing some tests for the elevated use-cases. > but it will be quite much treading of new ground for me, so it could > take some time to get it done. > given that the patch passes all the 'serviceability' and 'container' test cases including the sidecar test - all that appears to be needed is an elevated test case ... looking into that to see if one of the existing container test cases can be extended ... > What's your take, do we need the new tests in this PR, or could it be > done in a follow-up? > > ? > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > --------------geZr7l60uuZilPFq9LUV0FJ6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 6/3/24 10:24 AM, Sebastian L?vdahl wrote:

Hi Larry, no worries. :)

I can try to look into writing some tests for the elevated use-cases. but it will be quite much treading of new ground for me, so it could take some time to get it done.


given that the patch passes all the 'serviceability' and 'container' test cases including the sidecar test - all that appears to be needed is an elevated test case ... looking into that to see if one of the existing container test cases can
be extended ...

What's your take, do we need the new tests in this PR, or could it be done in a follow-up?

?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <openjdk/jdk/pull/19055/c2145749773@github.com>


--------------geZr7l60uuZilPFq9LUV0FJ6-- ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2146133176 From cjplummer at openjdk.org Mon Jun 3 22:05:52 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 3 Jun 2024 22:05:52 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 09:58:38 GMT, Serguei Spitsyn wrote: >> The following RFE was fixed recently: >> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code >> >> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++. >> This update is to make it clear that `nullptr` is C programming language `null` pointer. >> >> I think we do not need a CSR for this fix. >> >> Testing: N/A (not needed) > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: consistency and stylistical corrections src/hotspot/share/prims/jvmti.xml line 1007: > 1005: explicitly deallocate. This is indicated in the individual > 1006: function descriptions. Empty lists, arrays, sequences, etc are > 1007: returned as a null pointer (C NULL or C++ nullptr). Why describe what is meant by a "null pointer" here when it is not done elsewhere? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1625105918 From cjplummer at openjdk.org Mon Jun 3 22:11:43 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 3 Jun 2024 22:11:43 GMT Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share [v2] In-Reply-To: References: Message-ID: On Sat, 1 Jun 2024 21:11:26 GMT, Leonid Mesnik wrote: >> The fix removes finalization cleanup from vmTestbase. >> The last to classes that use it are: DebugeeBinder and SocketIOPipe. >> The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources. >> The SocketIOPipe is used directly in AOD tests where it should be closed after test execution. >> >> The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in DebugeeProcess.waitFor(). >> >> The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. >> >> I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. >> Additionally, run all vmTestbase tests to verify there are no failures, > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed try/finally test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 201: > 199: try { > 200: int exitCode = waitForDebugee(); > 201: return exitCode; I don't think I've ever run across a try block with a return statement before, especially when there is also a finally block. The reader is likely to miss the fact that before the return is done the finally block is executed. It's also odd because now there is no return statement at the end of the method. Although the compiler is smart enough to recognize that this is ok, it is another point of confusion for the reader. Any reason not to just instead do the return at the end of the method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19505#discussion_r1625109575 From sspitsyn at openjdk.org Mon Jun 3 22:55:24 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Jun 2024 22:55:24 GMT Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes [v4] In-Reply-To: References: Message-ID: > Please, review the following `interp-only` issue related to carrier threads. > There are 3 problems fixed here: > - The `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter. > - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. > - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted. > > The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio. > > Testing: > - Ran new test case locally > - Ran mach5 tiers 1-6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: get rid of unneeded casts in new test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19438/files - new: https://git.openjdk.org/jdk/pull/19438/files/19e4d8fa..01304354 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19438&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19438&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19438.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19438/head:pull/19438 PR: https://git.openjdk.org/jdk/pull/19438 From sspitsyn at openjdk.org Mon Jun 3 22:55:24 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Jun 2024 22:55:24 GMT Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes [v3] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 23:55:20 GMT, Serguei Spitsyn wrote: >> Please, review the following `interp-only` issue related to carrier threads. >> There are 3 problems fixed here: >> - The `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter. >> - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. >> - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted. >> >> The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio. >> >> Testing: >> - Ran new test case locally >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: refactored def and use of process_pending_interp_only() > I'm not sure I follow the test logic. Its summary says "Verifies that MethodExit events are delivered on both carrier and virtual threads", but now it just ignores MethodExit requested for carrier thread in breakpoint_hit1. Then there is no sense to request the event on carrier thread. > Per the test summary I'd expect the test should test MethodExit for carrier thread, but then java part needs to force unmount. As we already agreed I've filed the cleanup test bug: [8333459](https://bugs.openjdk.org/browse/JDK-8333459) cleanup and check MethodExit events are posted on carrier threads in MethodExitTest ------------- PR Comment: https://git.openjdk.org/jdk/pull/19438#issuecomment-2146254345 From lmesnik at openjdk.org Mon Jun 3 23:02:28 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 3 Jun 2024 23:02:28 GMT Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share [v3] In-Reply-To: References: Message-ID: > The fix removes finalization cleanup from vmTestbase. > The last to classes that use it are: DebugeeBinder and SocketIOPipe. > The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources. > The SocketIOPipe is used directly in AOD tests where it should be closed after test execution. > > The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in DebugeeProcess.waitFor(). > > The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. > > I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. > Additionally, run all vmTestbase tests to verify there are no failures, Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: moved return out of try/catch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19505/files - new: https://git.openjdk.org/jdk/pull/19505/files/0ce8772f..6b051e41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19505&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19505&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19505/head:pull/19505 PR: https://git.openjdk.org/jdk/pull/19505 From lmesnik at openjdk.org Mon Jun 3 23:02:28 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 3 Jun 2024 23:02:28 GMT Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share [v3] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 19:58:34 GMT, Chris Plummer wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> moved return out of try/catch > > test/hotspot/jtreg/vmTestbase/nsk/share/aod/DummyTargetApplication.java line 68: > >> 66: if ((signal == null) || !signal.equals(AODTestRunner.SIGNAL_FINISH)) >> 67: throw new TestBug("Unexpected signal: '" + signal + "'"); >> 68: pipe.close(); > > Exceptions can be thrown before you get here. Thanks, updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19505#discussion_r1623281376 From lmesnik at openjdk.org Mon Jun 3 23:02:29 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 3 Jun 2024 23:02:29 GMT Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share [v2] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 22:08:46 GMT, Chris Plummer wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed try/finally > > test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 201: > >> 199: try { >> 200: int exitCode = waitForDebugee(); >> 201: return exitCode; > > I don't think I've ever run across a try block with a return statement before, especially when there is also a finally block. The reader is likely to miss the fact that before the return is done the finally block is executed. It's also odd because now there is no return statement at the end of the method. Although the compiler is smart enough to recognize that this is ok, it is another point of confusion for the reader. Any reason not to just instead do the return at the end of the method? Yes, the code become too unreadable. Moved return out of try/catch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19505#discussion_r1625141478 From duke at openjdk.org Mon Jun 3 23:09:09 2024 From: duke at openjdk.org (Larry Cable) Date: Mon, 3 Jun 2024 23:09:09 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v3] In-Reply-To: References: Message-ID: On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl wrote: >> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) > > Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision: > > - Remove unused `SELF_PID_NS` > - Rewrite in line with suggestion from Larry Cable it looks as though I can take an existing jcmd test in the container tests and quite quickly implement an 'elevated' sidecar test... I'll work on that today and tomorrow, lets aim to get the 'fix' and the test in before Thu!!! Rgds - Larry On 6/3/24 10:24 AM, Sebastian L?vdahl wrote: > > Hi Larry, no worries. :) > > I can try to look into writing some tests for the elevated use-cases. > but it will be quite much treading of new ground for me, so it could > take some time to get it done. > > What's your take, do we need the new tests in this PR, or could it be > done in a follow-up? > > ? > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > --------------2ZFegatR1DQpyr1B5InvHtns Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit it looks as though I can take an existing jcmd test in the container tests and quite quickly implement an 'elevated' sidecar test...

I'll work on that today and tomorrow, lets aim to get the 'fix' and the test in before Thu!!!

Rgds

- Larry

On 6/3/24 10:24 AM, Sebastian L?vdahl wrote:

Hi Larry, no worries. :)

I can try to look into writing some tests for the elevated use-cases. but it will be quite much treading of new ground for me, so it could take some time to get it done.

What's your take, do we need the new tests in this PR, or could it be done in a follow-up?

?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <openjdk/jdk/pull/19055/c2145749773@github.com>


--------------2ZFegatR1DQpyr1B5InvHtns-- ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2146272805 From amenkov at openjdk.org Mon Jun 3 23:31:12 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 3 Jun 2024 23:31:12 GMT Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes [v4] In-Reply-To: References: Message-ID: <3noeBAjVIGN-pBWZvASA4c9hMMs0agvhinOAPbUy1-8=.ab468618-a05c-4b20-a61d-463a698034c0@github.com> On Mon, 3 Jun 2024 22:55:24 GMT, Serguei Spitsyn wrote: >> Please, review the following `interp-only` issue related to carrier threads. >> There are 3 problems fixed here: >> - The `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter. >> - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. >> - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted. >> >> The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio. >> >> Testing: >> - Ran new test case locally >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: get rid of unneeded casts in new test Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19438#pullrequestreview-2095027750 From cjplummer at openjdk.org Tue Jun 4 00:42:08 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Jun 2024 00:42:08 GMT Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share [v3] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 23:02:28 GMT, Leonid Mesnik wrote: >> The fix removes finalization cleanup from vmTestbase. >> The last to classes that use it are: DebugeeBinder and SocketIOPipe. >> The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources. >> The SocketIOPipe is used directly in AOD tests where it should be closed after test execution. >> >> The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in DebugeeProcess.waitFor(). >> >> The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. >> >> I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. >> Additionally, run all vmTestbase tests to verify there are no failures, > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > moved return out of try/catch test/hotspot/jtreg/vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001t.java line 50: > 48: } catch (OutOfMemoryError e) { > 49: isOutOfMemory = true; > 50: buf = null; Do you think maybe it is worth logging "Got OOME" or something like that? Also, I think this could use a comment, and `buf` could use a more descriptive name. Maybe "reservedMem". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19505#discussion_r1625192562 From jpai at openjdk.org Tue Jun 4 01:34:40 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 4 Jun 2024 01:34:40 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v3] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 20:24:49 GMT, Alex Menkov wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Alex's input - simplify the test by using ClassFileInstaller > > test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 86: > >> 84: Can-Set-Native-Method-Prefix: true >> 85: """ >> 86: + "Boot-Class-Path: " + bootClassesDir.toString().replace(File.separatorChar, '/') + "/" > > AFAIU Boot-Class-Path is needed only because the agent needs bootreporter.StringIdCallbackReporter > I don't see much point in separate bootreporter dir. > So we can set Boot-Class-Path to System.getProperty("test.classes") and drop createBootClassesDir() logic Hello Alex, I have updated the PR to add "test.classes" to Boot-Class-Path instead of just those 2 classes. Tests in the updated PR continue to pass. > test/jdk/java/lang/instrument/RetransformApp.java line 81: > >> 79: final OutputAnalyzer oa = ProcessTools.executeTestJava( >> 80: "--enable-preview", // due to usage of ClassFile API PreviewFeature in the agent >> 81: "-XX:+UnlockDiagnosticVMOptions", "-XX:-CheckIntrinsics", > > This `-XX` flags were not present for this test (and I don't think they are needed for NativeMethodPrefix test too) You are right - it was a copy/paste error on my part to have include these flags for the `RetransformApp`. Based on your suggestion, I have removed them from the other test too. The tests continue to pass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1625219101 PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1625219542 From jpai at openjdk.org Tue Jun 4 01:34:39 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 4 Jun 2024 01:34:39 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v4] In-Reply-To: References: Message-ID: <_UAw03zQS4rSSkaIFsUoeLZRaPvRuVQuXhr8sNntjfs=.d1eb94ff-8ddb-470d-a51e-8f3de1c04fbb@github.com> > Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? > > There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. > > In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). > > This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. > > So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. > > The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. > > The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: - Alex suggestion - remove -XX:-CheckIntrinsics from NativeMethodPrefixApp test too - Alex's suggestion - no need to include only the bootreporter classes in boot classpath - RetransformApp test did not previously use -XX:-CheckIntrinsics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19495/files - new: https://git.openjdk.org/jdk/pull/19495/files/3c7512b2..3342dda7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=02-03 Stats: 23 lines in 2 files changed: 0 ins; 21 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19495.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19495/head:pull/19495 PR: https://git.openjdk.org/jdk/pull/19495 From dholmes at openjdk.org Tue Jun 4 04:51:17 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Jun 2024 04:51:17 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 22:03:13 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: consistency and stylistical corrections > > src/hotspot/share/prims/jvmti.xml line 1007: > >> 1005: explicitly deallocate. This is indicated in the individual >> 1006: function descriptions. Empty lists, arrays, sequences, etc are >> 1007: returned as a null pointer (C NULL or C++ nullptr). > > Why describe what is meant by a "null pointer" here when it is not done elsewhere? The intent is to provide a definition of what a null pointer is, for both C and C++ programs. Is there a better place to do that so that elsewhere the spec can simply to refer to "a null pointer" or "null"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1625338781 From dholmes at openjdk.org Tue Jun 4 05:53:05 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Jun 2024 05:53:05 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v7] In-Reply-To: <9lc4sCQvq1bo5VEaIXPINF-jDXvJZ2ub2F8f8ZgYVb0=.bbdb1cf0-24f5-47e6-b098-859dd3ecf4a2@github.com> References: <9lc4sCQvq1bo5VEaIXPINF-jDXvJZ2ub2F8f8ZgYVb0=.bbdb1cf0-24f5-47e6-b098-859dd3ecf4a2@github.com> Message-ID: On Mon, 3 Jun 2024 13:31:16 GMT, Inigo Mediavilla Saiz wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: > > Print mounted virtual thread after carrier FWIW I considered the mounted VT to be effectively part of the carrier thread's state so it made sense to me to have it's stack first (and it is the more interesting stack). But if Alan and Ron want it this way so be it. I don't understand the logic you are using to get the indentation though. src/hotspot/share/runtime/javaThread.cpp line 1832: > 1830: st->print("\t"); > 1831: indentation--; > 1832: } Suggestion: while (indentation-- > 0) { st->print("\t"); } Though not sure using `\t` is the best way to indent this as stream indentation is based on spaces. test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 2: > 1: /* > 2: * Copyright (c) 2015, 2024, Oracle and/or its affiliates. All rights reserved. New file should only have current year in copyright notice. test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 24: > 22: */ > 23: > 24: import com.beust.ah.A; ??? test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 37: > 35: import java.util.concurrent.atomic.AtomicBoolean; > 36: import java.util.concurrent.locks.ReentrantLock; > 37: import java.util.regex.Pattern; Seems to be a number of unneeded imports here. test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 46: > 44: * java.compiler > 45: * java.management > 46: * jdk.internal.jvmstat/sun.jvmstat.monitor These don't all seem necessary. test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 52: > 50: > 51: public void run(CommandExecutor executor) throws InterruptedException { > 52: var shouldStop = new AtomicBoolean(); You never set this to stop the thread. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19482#pullrequestreview-2095343672 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625365087 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625370894 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625371025 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625371252 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625371685 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625373779 From dholmes at openjdk.org Tue Jun 4 05:53:06 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Jun 2024 05:53:06 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v7] In-Reply-To: References: <9lc4sCQvq1bo5VEaIXPINF-jDXvJZ2ub2F8f8ZgYVb0=.bbdb1cf0-24f5-47e6-b098-859dd3ecf4a2@github.com> Message-ID: On Tue, 4 Jun 2024 05:27:48 GMT, David Holmes wrote: >> Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: >> >> Print mounted virtual thread after carrier > > src/hotspot/share/runtime/javaThread.cpp line 1832: > >> 1830: st->print("\t"); >> 1831: indentation--; >> 1832: } > > Suggestion: > > while (indentation-- > 0) { > st->print("\t"); > } > > Though not sure using `\t` is the best way to indent this as stream indentation is based on spaces. Actually I'm not sure what this indentation actually does at this location and its affect on other user's of this API. I would have expected the caller to set up the necessary indentation in the stream that gets passed in. I see you inc the indentation but then use the current indentation to insert multiple tabs - which should not be necessary if the stream indentation works correctly. ??? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625368549 From sspitsyn at openjdk.org Tue Jun 4 06:41:06 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Jun 2024 06:41:06 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v2] In-Reply-To: <5OI8D0PhkM19awFsxnm6RTlJkaDxkUyvW75D3q-wK0Q=.a2a0262e-9d3c-4380-aafd-e6b7cfc4393a@github.com> References: <6Sb8kKpbkh4ylD4u5Zayx2fV0ZaC5aVNicqoX6g_UNA=.7831eabc-905f-489b-87da-68953ec03412@github.com> <5OI8D0PhkM19awFsxnm6RTlJkaDxkUyvW75D3q-wK0Q=.a2a0262e-9d3c-4380-aafd-e6b7cfc4393a@github.com> Message-ID: On Fri, 17 May 2024 03:49:21 GMT, Quan Anh Mai wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: corrected the nullptr clarification > > src/hotspot/share/prims/jvmti.xml line 1007: > >> 1005: explicitly deallocate. This is indicated in the individual >> 1006: function descriptions. Empty lists, arrays, sequences, etc are >> 1007: returned as a null pointer (C NULL or C++ nullptr). > > This may be a little unnecessary rigor, but I believe that `nullptr` is not a null pointer. `nullptr` is the pointer literal that can be implicitly converted to a null pointer value of any pointer type and any pointer to member type. And I think the thing returned here is a null pointer, not `nullptr`. I'm not sure I understand this comment. Sorry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1625430986 From sspitsyn at openjdk.org Tue Jun 4 06:41:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Jun 2024 06:41:08 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 04:48:04 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmti.xml line 1007: >> >>> 1005: explicitly deallocate. This is indicated in the individual >>> 1006: function descriptions. Empty lists, arrays, sequences, etc are >>> 1007: returned as a null pointer (C NULL or C++ nullptr). >> >> Why describe what is meant by a "null pointer" here when it is not done elsewhere? > > The intent is to provide a definition of what a null pointer is, for both C and C++ programs. Is there a better place to do that so that elsewhere the spec can simply to refer to "a null pointer" or "null"? Thanks, David. I also feel this clarification is still useful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1625432133 From sspitsyn at openjdk.org Tue Jun 4 06:46:17 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Jun 2024 06:46:17 GMT Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes [v4] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 22:55:24 GMT, Serguei Spitsyn wrote: >> Please, review the following `interp-only` issue related to carrier threads. >> There are 3 problems fixed here: >> - The `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter. >> - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. >> - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted. >> >> The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio. >> >> Testing: >> - Ran new test case locally >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: get rid of unneeded casts in new test Thank you for review, Alex! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19438#issuecomment-2146732081 From alanb at openjdk.org Tue Jun 4 07:04:02 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 4 Jun 2024 07:04:02 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 06:38:36 GMT, Serguei Spitsyn wrote: >> The intent is to provide a definition of what a null pointer is, for both C and C++ programs. Is there a better place to do that so that elsewhere the spec can simply to refer to "a null pointer" or "null"? > > Thanks, David. I also feel this clarification is still useful. I think this is the right place but it is only for return values. There are a few functions where a parameter value can be a null pointer, e.g. in GetThreadState, SuspendThread, GetOwnedMonitorInfo the thread parameter can be a null pointer to mean the current thread. I don't think the introduction section has anywhere right now to say what a null pointer means. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1625458511 From sspitsyn at openjdk.org Tue Jun 4 07:19:19 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Jun 2024 07:19:19 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v4] In-Reply-To: <_UAw03zQS4rSSkaIFsUoeLZRaPvRuVQuXhr8sNntjfs=.d1eb94ff-8ddb-470d-a51e-8f3de1c04fbb@github.com> References: <_UAw03zQS4rSSkaIFsUoeLZRaPvRuVQuXhr8sNntjfs=.d1eb94ff-8ddb-470d-a51e-8f3de1c04fbb@github.com> Message-ID: On Tue, 4 Jun 2024 01:34:39 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? >> >> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. >> >> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). >> >> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. >> >> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. >> >> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. >> >> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. > > Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: > > - Alex suggestion - remove -XX:-CheckIntrinsics from NativeMethodPrefixApp test too > - Alex's suggestion - no need to include only the bootreporter classes in boot classpath > - RetransformApp test did not previously use -XX:-CheckIntrinsics I've posted just a question and a nit. Otherwise, the fix looks good. Thank you for taking care about this refactoring! test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java line 34: > 32: * @modules java.management > 33: * java.instrument > 34: * @run shell/timeout=240 MakeJAR2.sh NativeMethodPrefixAgent NativeMethodPrefixApp 'Can-Retransform-Classes: true' 'Can-Set-Native-Method-Prefix: true' Just a question. The original test had a timeout:`timeout=240`. My guess is that the default timeout was not enough. Do you think, it is not needed anymore or you just missed to add it? The same question applies to the other test. test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 26: > 24: > 25: import java.io.File; > 26: import java.nio.file.Files; Nit: It seems the import at line 26 is not needed. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19495#pullrequestreview-2095508509 PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1625470816 PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1625472194 From duke at openjdk.org Tue Jun 4 07:25:41 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Tue, 4 Jun 2024 07:25:41 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v8] In-Reply-To: References: Message-ID: > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz has updated the pull request incrementally with two additional commits since the last revision: - Cleanup test - Stop virtualthread - Remove unneeded imports - Remove modules that are not needed - Fix copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/9acbf29d..b122cc05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=06-07 Stats: 18 lines in 1 file changed: 1 ins; 9 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From duke at openjdk.org Tue Jun 4 07:25:41 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Tue, 4 Jun 2024 07:25:41 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v7] In-Reply-To: References: <9lc4sCQvq1bo5VEaIXPINF-jDXvJZ2ub2F8f8ZgYVb0=.bbdb1cf0-24f5-47e6-b098-859dd3ecf4a2@github.com> Message-ID: On Tue, 4 Jun 2024 05:33:47 GMT, David Holmes wrote: >> Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: >> >> Print mounted virtual thread after carrier > > test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2015, 2024, Oracle and/or its affiliates. All rights reserved. > > New file should only have current year in copyright notice. Thanks, I've updated it. > test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 24: > >> 22: */ >> 23: >> 24: import com.beust.ah.A; > > ??? Wait, I don't know where that's coming from. I've removed it as well as the other imports that are not being used. > test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 37: > >> 35: import java.util.concurrent.atomic.AtomicBoolean; >> 36: import java.util.concurrent.locks.ReentrantLock; >> 37: import java.util.regex.Pattern; > > Seems to be a number of unneeded imports here. Thanks, I've removed them here: b122cc05ff953a890e4f604d37785f06e13e2ff6 > test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 46: > >> 44: * java.compiler >> 45: * java.management >> 46: * jdk.internal.jvmstat/sun.jvmstat.monitor > > These don't all seem necessary. Thanks, I've removed them. > test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 52: > >> 50: >> 51: public void run(CommandExecutor executor) throws InterruptedException { >> 52: var shouldStop = new AtomicBoolean(); > > You never set this to stop the thread. I've fixed it in: b122cc05ff953a890e4f604d37785f06e13e2ff6 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625478440 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625478212 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625481515 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625481097 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625481256 From sspitsyn at openjdk.org Tue Jun 4 07:39:14 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Jun 2024 07:39:14 GMT Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share [v3] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 23:02:28 GMT, Leonid Mesnik wrote: >> The fix removes finalization cleanup from vmTestbase. >> The last to classes that use it are: DebugeeBinder and SocketIOPipe. >> The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources. >> The SocketIOPipe is used directly in AOD tests where it should be closed after test execution. >> >> The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in DebugeeProcess.waitFor(). >> >> The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. >> >> I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. >> Additionally, run all vmTestbase tests to verify there are no failures, > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > moved return out of try/catch Looks good. Thank you for polishing it with Chris. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19505#pullrequestreview-2095566908 From dholmes at openjdk.org Tue Jun 4 07:45:06 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Jun 2024 07:45:06 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v8] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 07:25:41 GMT, Inigo Mediavilla Saiz wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > Inigo Mediavilla Saiz has updated the pull request incrementally with two additional commits since the last revision: > > - Cleanup test > > - Stop virtualthread > - Remove unneeded imports > - Remove modules that are not needed > - Fix copyright year Test updates look okay. Thanks. ------------- PR Review: https://git.openjdk.org/jdk/pull/19482#pullrequestreview-2095581013 From syan at openjdk.org Tue Jun 4 07:51:36 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 4 Jun 2024 07:51:36 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles Message-ID: Hi all, This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. Thanks. ------------- Commit messages: - 8333477: Delete extra empty spaces in Makefiles Changes: https://git.openjdk.org/jdk/pull/19537/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19537&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333477 Stats: 9 lines in 4 files changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/19537.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19537/head:pull/19537 PR: https://git.openjdk.org/jdk/pull/19537 From alanb at openjdk.org Tue Jun 4 08:09:04 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 4 Jun 2024 08:09:04 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v8] In-Reply-To: References: Message-ID: <27dIMbrC5Y41jusR7af89D-1hd4XSCc0IKudmba0XpM=.279a7a74-1737-4249-85bd-ae3ac699ebc2@github.com> On Tue, 4 Jun 2024 07:25:41 GMT, Inigo Mediavilla Saiz wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > Inigo Mediavilla Saiz has updated the pull request incrementally with two additional commits since the last revision: > > - Cleanup test > > - Stop virtualthread > - Remove unneeded imports > - Remove modules that are not needed > - Fix copyright year I think the presentation of the carrier the mounted virtual thread in update (b122cc05) looks quite good. I think it would be helpful to include the thread name too. Many virtual threads are unnamed so it will show as "" but that is okay. In addition to being useful it means the format of the "Mounted virtual thread ..." line will be consistent the first part of the line for platform threads. I'm wondering if we should remove the existing "Carrying virtual thread ..." line as part of this. It's redundant now, @pron ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2146875861 From jpai at openjdk.org Tue Jun 4 08:50:18 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 4 Jun 2024 08:50:18 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v5] In-Reply-To: References: Message-ID: > Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? > > There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. > > In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). > > This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. > > So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. > > The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. > > The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19495/files - new: https://git.openjdk.org/jdk/pull/19495/files/3342dda7..51c20928 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19495.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19495/head:pull/19495 PR: https://git.openjdk.org/jdk/pull/19495 From jpai at openjdk.org Tue Jun 4 08:50:18 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 4 Jun 2024 08:50:18 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v4] In-Reply-To: References: <_UAw03zQS4rSSkaIFsUoeLZRaPvRuVQuXhr8sNntjfs=.d1eb94ff-8ddb-470d-a51e-8f3de1c04fbb@github.com> Message-ID: <4e-sbeIz-pdk3GVcK2eIdliFuurY1g_27VNuYdOTiB0=.38726557-6764-4b26-bc20-e90e37dd4ca6@github.com> On Tue, 4 Jun 2024 07:13:39 GMT, Serguei Spitsyn wrote: >> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: >> >> - Alex suggestion - remove -XX:-CheckIntrinsics from NativeMethodPrefixApp test too >> - Alex's suggestion - no need to include only the bootreporter classes in boot classpath >> - RetransformApp test did not previously use -XX:-CheckIntrinsics > > test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 26: > >> 24: >> 25: import java.io.File; >> 26: import java.nio.file.Files; > > Nit: It seems the import at line 26 is not needed. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1625617051 From jpai at openjdk.org Tue Jun 4 08:57:07 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 4 Jun 2024 08:57:07 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v5] In-Reply-To: References: <_UAw03zQS4rSSkaIFsUoeLZRaPvRuVQuXhr8sNntjfs=.d1eb94ff-8ddb-470d-a51e-8f3de1c04fbb@github.com> Message-ID: On Tue, 4 Jun 2024 07:12:27 GMT, Serguei Spitsyn wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> unused import > > test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java line 34: > >> 32: * @modules java.management >> 33: * java.instrument >> 34: * @run shell/timeout=240 MakeJAR2.sh NativeMethodPrefixAgent NativeMethodPrefixApp 'Can-Retransform-Classes: true' 'Can-Set-Native-Method-Prefix: true' > > Just a question. The original test had a timeout:`timeout=240`. My guess is that the default timeout was not enough. Do you think, it is not needed anymore or you just missed to add it? > The same question applies to the other test. Hello Serguei, that `timeout=240` appears to have been added as part of https://bugs.openjdk.org/browse/JDK-6528548 to several of these tests back in Java 7 days because the `shell` test which was creating the jar file was timing out. The actual test itself, the one which uses the generated jar to run the agent, was completing within a second or two. With the current state of the PR I have run tier3 in our CI and there too both these tests complete within a second on all platforms. So I decided not to copy over this timeout as part of this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1625628639 From stuefe at openjdk.org Tue Jun 4 09:03:16 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 4 Jun 2024 09:03:16 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v7] In-Reply-To: References: <9lc4sCQvq1bo5VEaIXPINF-jDXvJZ2ub2F8f8ZgYVb0=.bbdb1cf0-24f5-47e6-b098-859dd3ecf4a2@github.com> Message-ID: On Tue, 4 Jun 2024 05:30:36 GMT, David Holmes wrote: >> src/hotspot/share/runtime/javaThread.cpp line 1832: >> >>> 1830: st->print("\t"); >>> 1831: indentation--; >>> 1832: } >> >> Suggestion: >> >> while (indentation-- > 0) { >> st->print("\t"); >> } >> >> Though not sure using `\t` is the best way to indent this as stream indentation is based on spaces. > > Actually I'm not sure what this indentation actually does at this location and its affect on other user's of this API. I would have expected the caller to set up the necessary indentation in the stream that gets passed in. I see you inc the indentation but then use the current indentation to insert multiple tabs - which should not be necessary if the stream indentation works correctly. ??? Note that We are in the process of adding better and saner auto-indentation to outputStream. See https://github.com/openjdk/jdk/pull/19461 . I don't think that PR is going to take long. If you don't want to wait, please: - As David wrote, use spaces, not tabs - Today's pattern for using outputStream indentation is: - set up indentation, preferably with streamIndentor, not manually with inc/dec - then, before printing each line, call stream->indent() This pattern would also help us to later identify and remove this manual indentation pattern if auto-indent becomes a thing. But really, waiting for https://github.com/openjdk/jdk/pull/19461 would be preferable. Then, all you have to do is place a streamIndentor around stack printing. Sub-function printing is then indented automatically. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625622263 From stuefe at openjdk.org Tue Jun 4 09:03:18 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 4 Jun 2024 09:03:18 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v8] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 07:25:41 GMT, Inigo Mediavilla Saiz wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > Inigo Mediavilla Saiz has updated the pull request incrementally with two additional commits since the last revision: > > - Cleanup test > > - Stop virtualthread > - Remove unneeded imports > - Remove modules that are not needed > - Fix copyright year src/hotspot/share/runtime/threads.cpp line 1334: > 1332: if (thread_oop != nullptr) { > 1333: if (p->is_vthread_mounted()) { > 1334: oop vt = p->vthread(); const src/hotspot/share/runtime/threads.cpp line 1335: > 1333: if (p->is_vthread_mounted()) { > 1334: oop vt = p->vthread(); > 1335: assert(vt != nullptr, ""); Please provide a valid assert string. src/hotspot/share/runtime/threads.cpp line 1336: > 1334: oop vt = p->vthread(); > 1335: assert(vt != nullptr, ""); > 1336: st->print_cr(" \tMounted virtual thread #" INT64_FORMAT, (int64_t)java_lang_Thread::thread_id(vt)); Please no manual indentation, see remarks above. src/hotspot/share/runtime/threads.cpp line 1337: > 1335: assert(vt != nullptr, ""); > 1336: st->print_cr(" \tMounted virtual thread #" INT64_FORMAT, (int64_t)java_lang_Thread::thread_id(vt)); > 1337: st->inc(); Use streamIndentor, please test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 52: > 50: output.shouldMatch(".*at " + Pattern.quote(DummyRunnable.class.getName()) + "\\.run.*"); > 51: output.shouldMatch(".*at " + Pattern.quote(DummyRunnable.class.getName()) + "\\.compute.*"); > 52: shouldFinish.compareAndSet(false, true); Why not just set? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625622959 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625623415 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625624052 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625622718 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1625634146 From lancea at openjdk.org Tue Jun 4 11:29:06 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 4 Jun 2024 11:29:06 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v5] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 08:50:18 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? >> >> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. >> >> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). >> >> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. >> >> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. >> >> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. >> >> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > unused import Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19495#pullrequestreview-2096103232 From sspitsyn at openjdk.org Tue Jun 4 11:51:15 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Jun 2024 11:51:15 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v5] In-Reply-To: References: <_UAw03zQS4rSSkaIFsUoeLZRaPvRuVQuXhr8sNntjfs=.d1eb94ff-8ddb-470d-a51e-8f3de1c04fbb@github.com> Message-ID: On Tue, 4 Jun 2024 08:54:40 GMT, Jaikiran Pai wrote: >> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java line 34: >> >>> 32: * @modules java.management >>> 33: * java.instrument >>> 34: * @run shell/timeout=240 MakeJAR2.sh NativeMethodPrefixAgent NativeMethodPrefixApp 'Can-Retransform-Classes: true' 'Can-Set-Native-Method-Prefix: true' >> >> Just a question. The original test had a timeout:`timeout=240`. My guess is that the default timeout was not enough. Do you think, it is not needed anymore or you just missed to add it? >> The same question applies to the other test. > > Hello Serguei, that `timeout=240` appears to have been added as part of https://bugs.openjdk.org/browse/JDK-6528548 to several of these tests back in Java 7 days because the `shell` test which was creating the jar file was timing out. The actual test itself, the one which uses the generated jar to run the agent, was completing within a second or two. > > With the current state of the PR I have run tier3 in our CI and there too both these tests complete within a second on all platforms. So I decided not to copy over this timeout as part of this change. My guess is these tests were timed out when executed with some specific options like -Xint, -Xcomp or any other that can slow down the execution (e.g. DeoptimizeALot). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1625855573 From jpai at openjdk.org Tue Jun 4 12:35:33 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 4 Jun 2024 12:35:33 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v6] In-Reply-To: References: Message-ID: > Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? > > There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. > > In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). > > This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. > > So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. > > The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. > > The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Serguei's suggestion - use a higher timeout for the test to match what was being used for the shell test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19495/files - new: https://git.openjdk.org/jdk/pull/19495/files/51c20928..aae8b0ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19495&range=04-05 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19495.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19495/head:pull/19495 PR: https://git.openjdk.org/jdk/pull/19495 From jpai at openjdk.org Tue Jun 4 12:35:33 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 4 Jun 2024 12:35:33 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v6] In-Reply-To: References: <_UAw03zQS4rSSkaIFsUoeLZRaPvRuVQuXhr8sNntjfs=.d1eb94ff-8ddb-470d-a51e-8f3de1c04fbb@github.com> Message-ID: On Tue, 4 Jun 2024 11:47:25 GMT, Serguei Spitsyn wrote: >> Hello Serguei, that `timeout=240` appears to have been added as part of https://bugs.openjdk.org/browse/JDK-6528548 to several of these tests back in Java 7 days because the `shell` test which was creating the jar file was timing out. The actual test itself, the one which uses the generated jar to run the agent, was completing within a second or two. >> >> With the current state of the PR I have run tier3 in our CI and there too both these tests complete within a second on all platforms. So I decided not to copy over this timeout as part of this change. > > My guess is these tests were timed out when executed with some specific options like -Xint, -Xcomp or any other that can slow down the execution (e.g. DeoptimizeALot). I have now updated the PR to use the same timeout that was used for the `shell` test before the changes in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1625919837 From duke at openjdk.org Tue Jun 4 12:57:07 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Tue, 4 Jun 2024 12:57:07 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v3] In-Reply-To: References: Message-ID: On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl wrote: >> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) > > Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision: > > - Remove unused `SELF_PID_NS` > - Rewrite in line with suggestion from Larry Cable This is awesome, Larry. You're my hero :) Thanks a lot in advance! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2147462603 From syan at openjdk.org Tue Jun 4 12:58:11 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 4 Jun 2024 12:58:11 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote: > Hi all, > This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. > > Thanks. > /label build Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2147467980 From erikj at openjdk.org Tue Jun 4 13:01:12 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 4 Jun 2024 13:01:12 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles In-Reply-To: References: Message-ID: <-zitWvnM2OMNoksPkobR-GY7ydETAQyBLwcrdcoiLWE=.c1e182c2-7b34-43e9-a96f-e3bf1b367f8f@github.com> On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote: > Hi all, > This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. > > Thanks. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2096319123 From duke at openjdk.org Tue Jun 4 13:27:46 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Tue, 4 Jun 2024 13:27:46 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v9] In-Reply-To: References: Message-ID: > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz has updated the pull request incrementally with two additional commits since the last revision: - Remove dead code - Remove extra indentation (leave it for the next PR) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/b122cc05..7a57d05d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=07-08 Stats: 8 lines in 2 files changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From duke at openjdk.org Tue Jun 4 13:27:46 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Tue, 4 Jun 2024 13:27:46 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v7] In-Reply-To: References: <9lc4sCQvq1bo5VEaIXPINF-jDXvJZ2ub2F8f8ZgYVb0=.bbdb1cf0-24f5-47e6-b098-859dd3ecf4a2@github.com> Message-ID: On Tue, 4 Jun 2024 08:50:25 GMT, Thomas Stuefe wrote: >> Actually I'm not sure what this indentation actually does at this location and its affect on other user's of this API. I would have expected the caller to set up the necessary indentation in the stream that gets passed in. I see you inc the indentation but then use the current indentation to insert multiple tabs - which should not be necessary if the stream indentation works correctly. ??? > > Note that We are in the process of adding better and saner auto-indentation to outputStream. See https://github.com/openjdk/jdk/pull/19461 . I don't think that PR is going to take long. > > If you don't want to wait, please: > - As David wrote, use spaces, not tabs > - Today's pattern for using outputStream indentation is: > - set up indentation, preferably with streamIndentor, not manually with inc/dec > - then, before printing each line, call stream->indent() > > This pattern would also help us to later identify and remove this manual indentation pattern if auto-indent becomes a thing. > > But really, waiting for https://github.com/openjdk/jdk/pull/19461 would be preferable. Then, all you have to do is place a streamIndentor around stack printing. Sub-function printing is then indented automatically. Thanks ! Your PR looks very promising @tstuefe, I would indeed prefer to wait for your changes as a way to add additional indentation to the stack of the virtual thread. What do you think if I leave the current PR with the indentation that is already used for the stack of the carrier thread and I create a separate PR based on yours to add the additional indentation ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1626005247 From duke at openjdk.org Tue Jun 4 13:31:50 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Tue, 4 Jun 2024 13:31:50 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v10] In-Reply-To: References: Message-ID: > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: Incorporate @tstuefe's remarks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/7a57d05d..a483113a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=08-09 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From duke at openjdk.org Tue Jun 4 13:31:50 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Tue, 4 Jun 2024 13:31:50 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v8] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 08:50:53 GMT, Thomas Stuefe wrote: >> Inigo Mediavilla Saiz has updated the pull request incrementally with two additional commits since the last revision: >> >> - Cleanup test >> >> - Stop virtualthread >> - Remove unneeded imports >> - Remove modules that are not needed >> - Fix copyright year > > src/hotspot/share/runtime/threads.cpp line 1334: > >> 1332: if (thread_oop != nullptr) { >> 1333: if (p->is_vthread_mounted()) { >> 1334: oop vt = p->vthread(); > > const Thanks ! I've fixed that in: a483113a7ff381860dec3d52a45e18d8a0fdc929 > src/hotspot/share/runtime/threads.cpp line 1335: > >> 1333: if (p->is_vthread_mounted()) { >> 1334: oop vt = p->vthread(); >> 1335: assert(vt != nullptr, ""); > > Please provide a valid assert string. Thanks ! I've fixed that in: a483113a7ff381860dec3d52a45e18d8a0fdc929 > test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 52: > >> 50: output.shouldMatch(".*at " + Pattern.quote(DummyRunnable.class.getName()) + "\\.run.*"); >> 51: output.shouldMatch(".*at " + Pattern.quote(DummyRunnable.class.getName()) + "\\.compute.*"); >> 52: shouldFinish.compareAndSet(false, true); > > Why not just set? Thanks ! I've fixed that in: a483113a7ff381860dec3d52a45e18d8a0fdc929 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1626012756 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1626012662 PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1626012524 From duke at openjdk.org Tue Jun 4 13:50:47 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Tue, 4 Jun 2024 13:50:47 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v11] In-Reply-To: References: Message-ID: > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: Include virtual thread name in output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/a483113a..a97184c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From duke at openjdk.org Tue Jun 4 13:50:47 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Tue, 4 Jun 2024 13:50:47 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v8] In-Reply-To: References: Message-ID: <72CRKwPvqLmopCjtAevfxYXpGg2ZxuDiXUyXLbHIlq8=.e3932757-87ba-404a-98ca-a7e7294071ff@github.com> On Tue, 4 Jun 2024 08:51:40 GMT, Thomas Stuefe wrote: >> Inigo Mediavilla Saiz has updated the pull request incrementally with two additional commits since the last revision: >> >> - Cleanup test >> >> - Stop virtualthread >> - Remove unneeded imports >> - Remove modules that are not needed >> - Fix copyright year > > src/hotspot/share/runtime/threads.cpp line 1336: > >> 1334: oop vt = p->vthread(); >> 1335: assert(vt != nullptr, ""); >> 1336: st->print_cr(" \tMounted virtual thread #" INT64_FORMAT, (int64_t)java_lang_Thread::thread_id(vt)); > > Please no manual indentation, see remarks above. I'm leaving minimal indentation and I will update the code on a new PR to rely on your changes if it's OK for you @tstuefe ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1626049632 From chagedorn at openjdk.org Tue Jun 4 16:11:03 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 4 Jun 2024 16:11:03 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote: > Hi all, > This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. > > Thanks. Looks good! Somehow the integrate command did not work. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2096615859 From syan at openjdk.org Tue Jun 4 16:11:05 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 4 Jun 2024 16:11:05 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote: > Hi all, > This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. > > Thanks. Thanks for the review. Thanks all for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2147523325 PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2147711173 From duke at openjdk.org Tue Jun 4 16:11:38 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Tue, 4 Jun 2024 16:11:38 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v10] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 13:31:50 GMT, Inigo Mediavilla Saiz wrote: >> Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. > > Inigo Mediavilla Saiz has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate @tstuefe's remarks Current status: I'm leaving the PR without additional indentation for the Vthread stack on purpose because I plan to add a new PR to include @tstuefe's changes (unless those changes get merged very quickly) @AlanBateman I've included the vthread's name in the output as per your suggestion. This what the output looks like at the moment: "ForkJoinPool-1-worker-1" #21 [28163] daemon prio=5 os_prio=31 cpu=7320.43ms elapsed=7.39s tid=0x000000012d02f210 [0x0000000171b31000] Carrying virtual thread #20 Thread: 0x000000012d02f210 [0x6e03] State: _at_safepoint _at_poll_safepoint 1 JavaThread state: _thread_blocked at jdk.internal.vm.Continuation.run(java.base at 23-internal/Continuation.java:248) at java.lang.VirtualThread.runContinuation(java.base at 23-internal/VirtualThread.java:245) at java.lang.VirtualThread$$Lambda/0x000003c001046740.run(java.base at 23-internal/Unknown Source) at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-internal/ForkJoinTask.java:1726) at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute(java.base at 23-internal/ForkJoinTask.java:1717) at java.util.concurrent.ForkJoinTask$InterruptibleTask.exec(java.base at 23-internal/ForkJoinTask.java:1641) at java.util.concurrent.ForkJoinTask.doExec(java.base at 23-internal/ForkJoinTask.java:507) at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base at 23-internal/ForkJoinPool.java:1489) at java.util.concurrent.ForkJoinPool.scan(java.base at 23-internal/ForkJoinPool.java:2071) at java.util.concurrent.ForkJoinPool.runWorker(java.base at 23-internal/ForkJoinPool.java:2033) at java.util.concurrent.ForkJoinWorkerThread.run(java.base at 23-internal/ForkJoinWorkerThread.java:189) Mounted virtual thread "Dummy Vthread" #20 at Main$FunkyLambda.compute(Main.java:38) at Main$FunkyLambda.computeFunkyName(Main.java:31) at Main$$Lambda/0x000003c001000c50.run(Unknown Source) at java.lang.Thread.runWith(java.base at 23-internal/Thread.java:1588) at java.lang.VirtualThread.run(java.base at 23-internal/VirtualThread.java:329) at java.lang.VirtualThread$VThreadContinuation$1.run(java.base at 23-internal/VirtualThread.java:209) at jdk.internal.vm.Continuation.enter0(java.base at 23-internal/Continuation.java:320) at jdk.internal.vm.Continuation.enter(java.base at 23-internal/Continuation.java:312) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2147589255 From lmesnik at openjdk.org Tue Jun 4 17:31:34 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Jun 2024 17:31:34 GMT Subject: RFR: 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 Message-ID: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> The kill sends async exception that is thrown somewhere during log.display(...) method. The log shows that it is thrown while PrintStream locking moving it into an inconsistent state. So the fix is to use some method that could be safely interrupted by async exception. ------------- Commit messages: - dot added. - 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 Changes: https://git.openjdk.org/jdk/pull/19547/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19547&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333235 Stats: 14 lines in 1 file changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19547/head:pull/19547 PR: https://git.openjdk.org/jdk/pull/19547 From lmesnik at openjdk.org Tue Jun 4 18:02:13 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Jun 2024 18:02:13 GMT Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share [v4] In-Reply-To: References: Message-ID: <0u0R4RTWP-uhkyUSiUl4eeeODok3GPXqdvA38DMTzJc=.f237b451-1349-4696-bb00-27a10e1a3c3c@github.com> > The fix removes finalization cleanup from vmTestbase. > The last to classes that use it are: DebugeeBinder and SocketIOPipe. > The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources. > The SocketIOPipe is used directly in AOD tests where it should be closed after test execution. > > The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in DebugeeProcess.waitFor(). > > The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. > > I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. > Additionally, run all vmTestbase tests to verify there are no failures, Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: added message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19505/files - new: https://git.openjdk.org/jdk/pull/19505/files/6b051e41..2b877797 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19505&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19505&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19505/head:pull/19505 PR: https://git.openjdk.org/jdk/pull/19505 From amenkov at openjdk.org Tue Jun 4 18:52:00 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 4 Jun 2024 18:52:00 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v6] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 12:35:33 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? >> >> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. >> >> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). >> >> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. >> >> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. >> >> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. >> >> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Serguei's suggestion - use a higher timeout for the test to match what was being used for the shell test Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19495#pullrequestreview-2097164263 From amenkov at openjdk.org Tue Jun 4 18:52:00 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 4 Jun 2024 18:52:00 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v6] In-Reply-To: References: <_UAw03zQS4rSSkaIFsUoeLZRaPvRuVQuXhr8sNntjfs=.d1eb94ff-8ddb-470d-a51e-8f3de1c04fbb@github.com> Message-ID: On Tue, 4 Jun 2024 12:31:13 GMT, Jaikiran Pai wrote: >> My guess is these tests were timed out when executed with some specific options like -Xint, -Xcomp or any other that can slow down the execution (e.g. DeoptimizeALot). > > I have now updated the PR to use the same timeout that was used for the `shell` test before the changes in this PR. I think `timeout`s are not needed for the refactored tests. Per JDK-6528548 the shell action has timed out using a network mounted JDK (MakeJAR2.sh run `javac` 3 times and `jar` 1 time). But I don't see big problem here - up to the author to keep or remove them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1626468824 From cjplummer at openjdk.org Tue Jun 4 19:03:00 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Jun 2024 19:03:00 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 07:01:54 GMT, Alan Bateman wrote: >> Thanks, David. I also feel this clarification is still useful. > > I think this is the right place but it is only for return values. There are a few functions where a parameter value can be a null pointer, e.g. in GetThreadState, SuspendThread, GetOwnedMonitorInfo the thread parameter can be a null pointer to mean the current thread. I don't think the introduction section has anywhere right now to say what a null pointer means. Yes, my point was that this section is only for return values. The section is titled "Function Return Values". Maybe we should add another short section just before this one to describe what is meant by "null pointer". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1626480428 From cjplummer at openjdk.org Tue Jun 4 19:08:57 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Jun 2024 19:08:57 GMT Subject: RFR: 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 In-Reply-To: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> References: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> Message-ID: On Tue, 4 Jun 2024 17:25:04 GMT, Leonid Mesnik wrote: > The kill sends async exception that is thrown somewhere during log.display(...) method. > The log shows that it is thrown while PrintStream locking moving it into an inconsistent state. > So the fix is to use some method that could be safely interrupted by async exception. test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001a.java line 153: > 151: } > 152: } > 153: Have you tried an empty method? I don't think it's a matter of how much time you spend in the method, but just whether or not a JVM async exception polling point is reached. I suspect the method call or return will be a polling point, but I'm unsure what happens if the method call is elided by the JIT because it does nothing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19547#discussion_r1626486192 From cjplummer at openjdk.org Tue Jun 4 19:11:58 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Jun 2024 19:11:58 GMT Subject: RFR: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share [v4] In-Reply-To: <0u0R4RTWP-uhkyUSiUl4eeeODok3GPXqdvA38DMTzJc=.f237b451-1349-4696-bb00-27a10e1a3c3c@github.com> References: <0u0R4RTWP-uhkyUSiUl4eeeODok3GPXqdvA38DMTzJc=.f237b451-1349-4696-bb00-27a10e1a3c3c@github.com> Message-ID: On Tue, 4 Jun 2024 18:02:13 GMT, Leonid Mesnik wrote: >> The fix removes finalization cleanup from vmTestbase. >> The last to classes that use it are: DebugeeBinder and SocketIOPipe. >> The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources. >> The SocketIOPipe is used directly in AOD tests where it should be closed after test execution. >> >> The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in DebugeeProcess.waitFor(). >> >> The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. >> >> I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. >> Additionally, run all vmTestbase tests to verify there are no failures, > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > added message Looks good. Thanks for cleanup. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19505#pullrequestreview-2097199005 From lmesnik at openjdk.org Tue Jun 4 19:21:06 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Jun 2024 19:21:06 GMT Subject: Integrated: 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share In-Reply-To: References: Message-ID: On Fri, 31 May 2024 18:22:47 GMT, Leonid Mesnik wrote: > The fix removes finalization cleanup from vmTestbase. > The last to classes that use it are: DebugeeBinder and SocketIOPipe. > The DebugeeBinder is used in jdi and jdwp tests and is always linked with debuggee process. So the DebugeeProcess.waitFor() is the good place to close binder and free all it's resources. > The SocketIOPipe is used directly in AOD tests where it should be closed after test execution. > > The OPipe (child of SocketIOPipe) also used in jdi and jdwp tests where it is connected directly in tests. However is also connected with debuggee and could be closed in DebugeeProcess.waitFor(). > > The VMOutOfMemoryException001 test is fixed to release some memory after throwing OOME so Sytem.exit() could complete successfully. Previously some memory freed during VM shutdown hook. > > I verified that cleanup printed that corresponding 'close' method has been already called before VM shutdown phase for debugger process. > Additionally, run all vmTestbase tests to verify there are no failures, This pull request has now been integrated. Changeset: 244f6ac2 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/244f6ac222fa98fba4fb99bf5bccd36e3e6c5de1 Stats: 314 lines in 10 files changed: 24 ins; 271 del; 19 mod 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/19505 From alanb at openjdk.org Tue Jun 4 19:27:58 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 4 Jun 2024 19:27:58 GMT Subject: RFR: 8332070: Convert package.html files in `java.management` to package-info.java [v2] In-Reply-To: References: Message-ID: On Mon, 27 May 2024 09:01:48 GMT, Nizar Benalla wrote: >> This is a simple noreg cleanup. The motivation was that I noticed javac doesn't recognise package.html files well. >> >> Some of the contents of the `package.html` files (and code in the package) may be outdated, but I think it is out of scope for this PR. >> >> I have also changed three `{@link }` usages with the `href` that would have been in the generated HTML. >> Because referencing an element from an other module wouldn't work even when using the `module/package.class#member`, if the `module-info.java` file does not have "require ``". >> >> I am referring to line 69 in >> `src/java.management/share/classes/javax/management/monitor/package-info.java` >> and lines 90 and 120 in >> `src/java.management/share/classes/javax/management/remote/package-info.java` >> >> Adding 2 dependencies just for 3 links didn't seem right. >> >> edit: passes all tests, the failing test is a github actions issue > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > better indentation - no content changes Looks okay, just notice that classes/java/lang/management/package-info.java still has the double space. Not a big deal but since you fixed the others then maybe do this one too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19399#issuecomment-2148243229 From imediava at gmail.com Tue Jun 4 20:52:02 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Tue, 4 Jun 2024 22:52:02 +0200 Subject: 8330846: (jstack) Add stacks of mounted virtual threads Message-ID: Hello, While there's ongoing work on: https://github.com/openjdk/jdk/pull/19482 to add the stack trace of mounted virtual threads to the `jcmd Thread.print` command, I'm starting to think about how I could do to print the stack trace for virtual threads from `jstack` but I'm not sure about what would be the best approach, so I'd be happy to get people's thoughts on the topic. Based on what I've seen `jstack` seems to fetch a ThreadList of JavaThreads and then relies on a bunch of Java code that uses attribute offsets to get the values of certain attributes of the JavaThread in the VM. With those attributes the java code can obtain the data that it requires about the threads, their monitors and also to get the latest frame in the stack to be able to iterate the stack. If I were to follow the same principle, I'd have to replicate the code that was added to the VM to read the stack chunks of virtual threads in Java, knowing that it looks like that the JVM code had to be written for multiple CPU architectures, I'm a bit concern about how complex following that approach would be. I considered following the approach used by `ThreadDumper.java`, that relies on `ThreadContainers` to get the virtual threads and then iterates over `Thread.getStackTrace` for the virtual thread. But I don't think that would work because I don't think the `ThreadContainers` can be accessed from `Jstack`. So I'm basically a bit blocked, and I think that I'd need some help from people that have followed loom more closely and have a clearer view of things and can probably provide me with hints on how to approach the problem differently. Thanks in advance for your help. Best ??igo Mediavilla Saiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmesnik at openjdk.org Tue Jun 4 21:07:56 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Jun 2024 21:07:56 GMT Subject: RFR: 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 In-Reply-To: References: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> Message-ID: On Tue, 4 Jun 2024 19:06:19 GMT, Chris Plummer wrote: >> The kill sends async exception that is thrown somewhere during log.display(...) method. >> The log shows that it is thrown while PrintStream locking moving it into an inconsistent state. >> So the fix is to use some method that could be safely interrupted by async exception. > > test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001a.java line 153: > >> 151: } >> 152: } >> 153: > > Have you tried an empty method? I don't think it's a matter of how much time you spend in the method, but just whether or not a JVM async exception polling point is reached. I suspect the method call or return will be a polling point, but I'm unsure what happens if the method call is elided by the JIT because it does nothing. The empty method is removed. So test failing with '-Xcomp /C2' and exception happens after try block. The log shows: reply[2]: main[1] Sending command: cont reply[0]: > reply[1]: Exception occurred: java.lang.NullPointerException (to be caught at: nsk.jdb.kill.kill001.MyThread.run(), line=165 bci=107)"thread=MyThread-1", nsk.jdb.kill.kill001.MyThread.run(), line=164 bci=100 reply[2]: 164 methodForException(); reply[3]: reply[4]: MyThread-1[1] Sending command: cont reply[0]: > reply[1]: Exception occurred: nsk.jdb.kill.kill001.MyException (uncaught) reply[2]: Exception occurred: nsk.jdb.kill.kill001.MyException (uncaught)"thread=MyThread-4", nsk.jdb.kill.kill001.MyThread.run(), line=178 bci=187 reply[3]: 178 kill001a.log.display(ThreadFinished); reply[4]: reply[5]: MyThread-4[1] Sending command: cont reply[0]: > reply[1]: Exception occurred: com.sun.jdi.IncompatibleThreadStateException (uncaught) reply[2]: Exception occurred: com.sun.jdi.IncompatibleThreadStateException (uncaught)"thread=MyThread-3", nsk.share.Log.display(), line=327 bci=9 reply[3]: 327 doPrint(message.toString()); reply[4]: reply[5]: MyThread-3[1] Sending command: cont reply[0]: > Thread MyThread-1 caught expected async exception: java.lang.NullPointerException: kill001a's Exception reply[1]: Thread finished: MyThread-1 reply[2]: reply[3]: Exception occurred: java.lang.ThreadDeath (uncaught) reply[4]: Exception occurred: java.lang.ThreadDeath (uncaught)"thread=MyThread-0", nsk.share.Log.doPrint(), line=495 bci=1 reply[5]: 495 PrintStream stream = findOutStream(); reply[6]: reply[7]: MyThread-0[1] Sending command: cont reply[0]: > reply[1]: Exception occurred: java.lang.SecurityException (uncaught) reply[2]: Exception occurred: java.lang.SecurityException (uncaught)"thread=MyThread-2", nsk.share.Log.doPrint(), line=495 bci=1 reply[3]: 495 PrintStream stream = findOutStream(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19547#discussion_r1626603001 From sspitsyn at openjdk.org Tue Jun 4 21:18:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Jun 2024 21:18:56 GMT Subject: RFR: 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 In-Reply-To: References: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> Message-ID: <7ou-qLIfHA-nAtdNFgjnHieqd-SIs-3aEVdw9SpN3iM=.431c7989-8d3f-4c23-ae8a-89d4ee0dbc96@github.com> On Tue, 4 Jun 2024 21:05:40 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001a.java line 153: >> >>> 151: } >>> 152: } >>> 153: >> >> Have you tried an empty method? I don't think it's a matter of how much time you spend in the method, but just whether or not a JVM async exception polling point is reached. I suspect the method call or return will be a polling point, but I'm unsure what happens if the method call is elided by the JIT because it does nothing. > > The empty method is removed. So test failing with '-Xcomp /C2' and exception happens after try block. > > The log shows: > reply[2]: main[1] > Sending command: cont > reply[0]: > > reply[1]: Exception occurred: java.lang.NullPointerException (to be caught at: nsk.jdb.kill.kill001.MyThread.run(), line=165 bci=107)"thread=MyThread-1", nsk.jdb.kill.kill001.MyThread.run(), line=164 bci=100 > reply[2]: 164 methodForException(); > reply[3]: > reply[4]: MyThread-1[1] > Sending command: cont > reply[0]: > > reply[1]: Exception occurred: nsk.jdb.kill.kill001.MyException (uncaught) > reply[2]: Exception occurred: nsk.jdb.kill.kill001.MyException (uncaught)"thread=MyThread-4", nsk.jdb.kill.kill001.MyThread.run(), line=178 bci=187 > reply[3]: 178 kill001a.log.display(ThreadFinished); > reply[4]: > reply[5]: MyThread-4[1] > Sending command: cont > reply[0]: > > reply[1]: Exception occurred: com.sun.jdi.IncompatibleThreadStateException (uncaught) > reply[2]: Exception occurred: com.sun.jdi.IncompatibleThreadStateException (uncaught)"thread=MyThread-3", nsk.share.Log.display(), line=327 bci=9 > reply[3]: 327 doPrint(message.toString()); > reply[4]: > reply[5]: MyThread-3[1] > Sending command: cont > reply[0]: > Thread MyThread-1 caught expected async exception: java.lang.NullPointerException: kill001a's Exception > reply[1]: Thread finished: MyThread-1 > reply[2]: > reply[3]: Exception occurred: java.lang.ThreadDeath (uncaught) > reply[4]: Exception occurred: java.lang.ThreadDeath (uncaught)"thread=MyThread-0", nsk.share.Log.doPrint(), line=495 bci=1 > reply[5]: 495 PrintStream stream = findOutStream(); > reply[6]: > reply[7]: MyThread-0[1] > Sending command: cont > reply[0]: > > reply[1]: Exception occurred: java.lang.SecurityException (uncaught) > reply[2]: Exception occurred: java.lang.SecurityException (uncaught)"thread=MyThread-2", nsk.share.Log.doPrint(), line=495 bci=1 > reply[3]: 495 PrintStream stream = findOutStream(); Empty method could work but the JIT compiler can optimize it out with inlining. But the loop is not needed. Something like this would work: static public int trash; void methodForException() { trash = 10; } But I'm not sure if the static variable value needs to be used from outside of this method. I'm afraid, the Escape Analysis can spoil this. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19547#discussion_r1626612160 From cjplummer at openjdk.org Tue Jun 4 21:28:56 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Jun 2024 21:28:56 GMT Subject: RFR: 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 In-Reply-To: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> References: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> Message-ID: On Tue, 4 Jun 2024 17:25:04 GMT, Leonid Mesnik wrote: > The kill sends async exception that is thrown somewhere during log.display(...) method. > The log shows that it is thrown while PrintStream locking moving it into an inconsistent state. > So the fix is to use some method that could be safely interrupted by async exception. Ok. Looks good then. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19547#pullrequestreview-2097415752 From robaho at icloud.com Tue Jun 4 21:16:41 2024 From: robaho at icloud.com (Robert Engels) Date: Tue, 4 Jun 2024 16:16:41 -0500 Subject: 8330846: (jstack) Add stacks of mounted virtual threads In-Reply-To: References: Message-ID: I looked through this, and I don?t think the there is anything needed other than this PR. Eventually jstack creates a VM_PrintThreads command which calls the threads.cpp code. > On Jun 4, 2024, at 3:52 PM, I?igo Mediavilla wrote: > > Hello, > > While there's ongoing work on: > > https://github.com/openjdk/jdk/pull/19482 > > to add the stack trace of mounted virtual threads to the `jcmd Thread.print` command, I'm starting to think about how I could do to print the stack trace for virtual threads from `jstack` but I'm not sure about what would be the best approach, so I'd be happy to get people's thoughts on the topic. > > Based on what I've seen `jstack` seems to fetch a ThreadList of JavaThreads and then relies on a bunch of Java code that uses attribute offsets to get the values of certain attributes of the JavaThread in the VM. With those attributes the java code can obtain the data that it requires about the threads, their monitors and also to get the latest frame in the stack to be able to iterate the stack. If I were to follow the same principle, I'd have to replicate the code that was added to the VM to read the stack chunks of virtual threads in Java, knowing that it looks like that the JVM code had to be written for multiple CPU architectures, I'm a bit concern about how complex following that approach would be. > > I considered following the approach used by `ThreadDumper.java`, that relies on `ThreadContainers` to get the virtual threads and then iterates over `Thread.getStackTrace` for the virtual thread. But I don't think that would work because I don't think the `ThreadContainers` can be accessed from `Jstack`. > > So I'm basically a bit blocked, and I think that I'd need some help from people that have followed loom more closely and have a clearer view of things and can probably provide me with hints on how to approach the problem differently. > > Thanks in advance for your help. > > Best > > ??igo Mediavilla Saiz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry.cable at oracle.com Tue Jun 4 22:45:48 2024 From: larry.cable at oracle.com (Laurence Cable) Date: Tue, 4 Jun 2024 15:45:48 -0700 Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v3] In-Reply-To: References: Message-ID: On 6/4/24 5:57 AM, Sebastian L?vdahl wrote: > On Tue, 21 May 2024 17:10:15 GMT, Sebastian L?vdahl wrote: > >>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) >> Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove unused `SELF_PID_NS` >> - Rewrite in line with suggestion from Larry Cable > This is awesome, Larry. You're my hero :) Thanks a lot in advance! I modified the container test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java to also perform a "non root user" test of an elevated JVM from a sidecar. - Larry > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2147462603 -------------- next part -------------- diff --git a/test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java b/test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java index f38adcf8b47..35749a1da55 100644 --- a/test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java +++ b/test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java @@ -38,13 +38,19 @@ * @build EventGeneratorLoop * @run driver TestJcmdWithSideCar */ +import java.io.BufferedReader; +import java.io.IOException; +import java.io.InputStreamReader; import java.nio.file.Paths; import java.util.Arrays; import java.util.ArrayList; +import java.util.Collections; import java.util.EnumSet; import java.util.List; +import java.util.Optional; import java.util.concurrent.TimeUnit; import java.util.function.Consumer; +import java.util.regex.Pattern; import java.util.stream.Collectors; import jdk.test.lib.Container; import jdk.test.lib.Utils; @@ -61,6 +67,31 @@ public class TestJcmdWithSideCar { private static final long TIME_TO_WAIT_FOR_MAIN_METHOD_START = 50 * 1000; // milliseconds private static final String MAIN_CONTAINER_NAME = "test-container-main"; + private static final String UID = "uid"; + private static final String GID = "gid"; + + private static final Pattern ID_PATTERN = Pattern.compile("uid=(?<" + UID + ">\\d+)\\([^\\)]+\\)\\s+gid=(?<" + GID + ">\\d+).*"); + + private static final Optional USER = ProcessHandle.current().info().user().map( + user -> { + try (var br = new BufferedReader(new InputStreamReader(new ProcessBuilder("id", user).start().getInputStream()))) { + for (final var line : br.lines().collect(Collectors.toUnmodifiableList())){ + final var m = ID_PATTERN.matcher(line); + + if (m.matches()) { + return "--user=" +m.group(UID) + ":" + m.group(GID); + } + } + } catch (IOException e) { + // do nothing... + } + + return null; + } + ); + + private static final String NET_BIND_SERVICE = "--cap-add=NET_BIND_SERVICE"; + public static void main(String[] args) throws Exception { if (!DockerTestUtils.canTestDocker()) { return; @@ -69,26 +100,28 @@ public static void main(String[] args) throws Exception { DockerTestUtils.buildJdkContainerImage(IMAGE_NAME); try { - // Start the loop process in the "main" container, then run test cases - // using a sidecar container. - MainContainer mainContainer = new MainContainer(); - mainContainer.start(); - mainContainer.waitForMainMethodStart(TIME_TO_WAIT_FOR_MAIN_METHOD_START); - - for (AttachStrategy attachStrategy : EnumSet.allOf(AttachStrategy.class)) { - long mainProcPid = testCase01(attachStrategy); - - // Excluding the test case below until JDK-8228850 is fixed - // JDK-8228850: jhsdb jinfo fails with ClassCastException: - // s.j.h.oops.TypeArray cannot be cast to s.j.h.oops.Instance - // mainContainer.assertIsAlive(); - // testCase02(mainProcPid, attachStrategy); - - mainContainer.assertIsAlive(); - testCase03(mainProcPid, attachStrategy); - } - - mainContainer.waitForAndCheck(TIME_TO_RUN_MAIN_PROCESS * 1000); + for (final boolean elevated : USER.isPresent() ? new Boolean[] { false, true } : new Boolean[]{ false }) { + // Start the loop process in the "main" container, then run test cases + // using a sidecar container. + MainContainer mainContainer = new MainContainer(); + mainContainer.start(elevated); + mainContainer.waitForMainMethodStart(TIME_TO_WAIT_FOR_MAIN_METHOD_START); + + for (AttachStrategy attachStrategy : EnumSet.allOf(AttachStrategy.class)) { + long mainProcPid = testCase01(attachStrategy, elevated); + + // Excluding the test case below until JDK-8228850 is fixed + // JDK-8228850: jhsdb jinfo fails with ClassCastException: + // s.j.h.oops.TypeArray cannot be cast to s.j.h.oops.Instance + // mainContainer.assertIsAlive(); + // testCase02(mainProcPid, attachStrategy, elevated); + + mainContainer.assertIsAlive(); + testCase03(mainProcPid, attachStrategy, elevated); + } + + mainContainer.waitForAndCheck(TIME_TO_RUN_MAIN_PROCESS * 1000); + } } finally { DockerTestUtils.removeDockerImage(IMAGE_NAME); } @@ -96,8 +129,8 @@ public static void main(String[] args) throws Exception { // Run "jcmd -l" in a sidecar container, find a target process. - private static long testCase01(AttachStrategy attachStrategy) throws Exception { - OutputAnalyzer out = runSideCar(MAIN_CONTAINER_NAME, attachStrategy, "/jdk/bin/jcmd", "-l") + private static long testCase01(AttachStrategy attachStrategy, boolean elevated) throws Exception { + OutputAnalyzer out = runSideCar(MAIN_CONTAINER_NAME, attachStrategy, elevated, "/jdk/bin/jcmd", "-l") .shouldHaveExitValue(0) .shouldContain("sun.tools.jcmd.JCmd"); long pid = findProcess(out, "EventGeneratorLoop"); @@ -109,8 +142,8 @@ private static long testCase01(AttachStrategy attachStrategy) throws Exception { } // run jhsdb jinfo (jhsdb uses PTRACE) - private static void testCase02(long pid, AttachStrategy attachStrategy) throws Exception { - runSideCar(MAIN_CONTAINER_NAME, attachStrategy, "/jdk/bin/jhsdb", "jinfo", "--pid", "" + pid) + private static void testCase02(long pid, AttachStrategy attachStrategy, boolean elevated) throws Exception { + runSideCar(MAIN_CONTAINER_NAME, attachStrategy, elevated, "/jdk/bin/jhsdb", "jinfo", "--pid", "" + pid) .shouldHaveExitValue(0) .shouldContain("Java System Properties") .shouldContain("VM Flags"); @@ -118,11 +151,11 @@ private static void testCase02(long pid, AttachStrategy attachStrategy) throws E // test jcmd with some commands (help, start JFR recording) // JCMD will use signal mechanism and Unix Socket - private static void testCase03(long pid, AttachStrategy attachStrategy) throws Exception { - runSideCar(MAIN_CONTAINER_NAME, attachStrategy, "/jdk/bin/jcmd", "" + pid, "help") + private static void testCase03(long pid, AttachStrategy attachStrategy, boolean elevated) throws Exception { + runSideCar(MAIN_CONTAINER_NAME, attachStrategy, elevated, "/jdk/bin/jcmd", "" + pid, "help") .shouldHaveExitValue(0) .shouldContain("VM.version"); - runSideCar(MAIN_CONTAINER_NAME, attachStrategy, "/jdk/bin/jcmd", "" + pid, "JFR.start") + runSideCar(MAIN_CONTAINER_NAME, attachStrategy, elevated, "/jdk/bin/jcmd", "" + pid, "JFR.start") .shouldHaveExitValue(0) .shouldContain("Started recording"); } @@ -134,9 +167,8 @@ private static void testCase03(long pid, AttachStrategy attachStrategy) throws E // we have two options: // 1. mount /tmp from the main container using --volumes-from. // 2. access /tmp from the main container via /proc//root/tmp. - private static OutputAnalyzer runSideCar(String mainContainerName, AttachStrategy attachStrategy, String whatToRun, - String... args) throws Exception { - System.out.println("Attach strategy " + attachStrategy); + private static OutputAnalyzer runSideCar(String mainContainerName, AttachStrategy attachStrategy, boolean elevated, String whatToRun, String... args) throws Exception { + System.out.println("Attach strategy " + attachStrategy); List initialCommands = List.of( Container.ENGINE_COMMAND, "run", @@ -150,12 +182,15 @@ private static OutputAnalyzer runSideCar(String mainContainerName, AttachStrateg case ACCESS_TMP_VIA_PROC_ROOT -> List.of(); }; + List elevatedOpts = elevated && USER.isPresent() ? List.of(NET_BIND_SERVICE, USER.get()) : Collections.emptyList(); + List imageAndCommand = List.of( IMAGE_NAME, whatToRun ); List cmd = new ArrayList<>(); cmd.addAll(initialCommands); + cmd.addAll(elevatedOpts); cmd.addAll(attachStrategyCommands); cmd.addAll(imageAndCommand); cmd.addAll(Arrays.asList(args)); @@ -204,9 +239,15 @@ static class MainContainer { } }; - public Process start() throws Exception { + public Process start(final boolean elevated) throws Exception { // start "main" container (the observee) DockerRunOptions opts = commonDockerOpts("EventGeneratorLoop"); + + if (elevated && USER.isPresent()) { + opts.addDockerOpts(USER.get()); + opts.addDockerOpts(NET_BIND_SERVICE); + } + opts.addDockerOpts("--cap-add=SYS_PTRACE") .addDockerOpts("--name", MAIN_CONTAINER_NAME) .addDockerOpts("--volume", "/tmp") From lmesnik at openjdk.org Tue Jun 4 23:12:56 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Jun 2024 23:12:56 GMT Subject: RFR: 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 In-Reply-To: <7ou-qLIfHA-nAtdNFgjnHieqd-SIs-3aEVdw9SpN3iM=.431c7989-8d3f-4c23-ae8a-89d4ee0dbc96@github.com> References: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> <7ou-qLIfHA-nAtdNFgjnHieqd-SIs-3aEVdw9SpN3iM=.431c7989-8d3f-4c23-ae8a-89d4ee0dbc96@github.com> Message-ID: On Tue, 4 Jun 2024 21:16:08 GMT, Serguei Spitsyn wrote: >> The empty method is removed. So test failing with '-Xcomp /C2' and exception happens after try block. >> >> The log shows: >> reply[2]: main[1] >> Sending command: cont >> reply[0]: > >> reply[1]: Exception occurred: java.lang.NullPointerException (to be caught at: nsk.jdb.kill.kill001.MyThread.run(), line=165 bci=107)"thread=MyThread-1", nsk.jdb.kill.kill001.MyThread.run(), line=164 bci=100 >> reply[2]: 164 methodForException(); >> reply[3]: >> reply[4]: MyThread-1[1] >> Sending command: cont >> reply[0]: > >> reply[1]: Exception occurred: nsk.jdb.kill.kill001.MyException (uncaught) >> reply[2]: Exception occurred: nsk.jdb.kill.kill001.MyException (uncaught)"thread=MyThread-4", nsk.jdb.kill.kill001.MyThread.run(), line=178 bci=187 >> reply[3]: 178 kill001a.log.display(ThreadFinished); >> reply[4]: >> reply[5]: MyThread-4[1] >> Sending command: cont >> reply[0]: > >> reply[1]: Exception occurred: com.sun.jdi.IncompatibleThreadStateException (uncaught) >> reply[2]: Exception occurred: com.sun.jdi.IncompatibleThreadStateException (uncaught)"thread=MyThread-3", nsk.share.Log.display(), line=327 bci=9 >> reply[3]: 327 doPrint(message.toString()); >> reply[4]: >> reply[5]: MyThread-3[1] >> Sending command: cont >> reply[0]: > Thread MyThread-1 caught expected async exception: java.lang.NullPointerException: kill001a's Exception >> reply[1]: Thread finished: MyThread-1 >> reply[2]: >> reply[3]: Exception occurred: java.lang.ThreadDeath (uncaught) >> reply[4]: Exception occurred: java.lang.ThreadDeath (uncaught)"thread=MyThread-0", nsk.share.Log.doPrint(), line=495 bci=1 >> reply[5]: 495 PrintStream stream = findOutStream(); >> reply[6]: >> reply[7]: MyThread-0[1] >> Sending command: cont >> reply[0]: > >> reply[1]: Exception occurred: java.lang.SecurityException (uncaught) >> reply[2]: Exception occurred: java.lang.SecurityException (uncaught)"thread=MyThread-2", nsk.share.Log.doPrint(), line=495 bci=1 >> reply[3]: 495 PrintStream stream = findOutStream(); > > Empty method could work but the JIT compiler can optimize it out with inlining. > But the loop is not needed. Something like this could work: > > static public int trash; > void methodForException() { > trash = 10; > } > > But I'm not sure if the static variable needs to be used outside of this method. I'm afraid, that Escape Analysis (EA) can spoil this. I wonder if `Thread.yield()`, Thread.sleep(), or something alike can be used here instead of `methodForException()`. I'm afraid it could be just inlined into try block. The public static variables might be read globally and should be optimized. However, really safer is jut to use them explicitly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19547#discussion_r1626732823 From sspitsyn at openjdk.org Tue Jun 4 23:56:59 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Jun 2024 23:56:59 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 19:00:32 GMT, Chris Plummer wrote: >> I think this is the right place but it is only for return values. There are a few functions where a parameter value can be a null pointer, e.g. in GetThreadState, SuspendThread, GetOwnedMonitorInfo the thread parameter can be a null pointer to mean the current thread. I don't think the introduction section has anywhere right now to reference for parameters that can be NULL/nullptr. > > Yes, my point was that this section is only for return values. The section is titled "Function Return Values". Maybe we should add another short section just before this one to describe what is meant by "null pointer". Okay, thanks. What about the following: : diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml index a6ebd0d42c5..a81014c70bb 100644 --- a/src/hotspot/share/prims/jvmti.xml +++ b/src/hotspot/share/prims/jvmti.xml @@ -995,7 +995,10 @@ jvmtiEnv *jvmti; across threads and are created dynamically. - + + There are a few functions where a parameter value can be a null pointer + (C NULL or C++ nullptr), e.g. the thread parameter + can be a null pointer to mean the current thread. functions always return an error code via the function return value. @@ -1004,7 +1007,7 @@ jvmtiEnv *jvmti; In some cases, functions allocate memory that your program must explicitly deallocate. This is indicated in the individual function descriptions. Empty lists, arrays, sequences, etc are - returned as a null pointer (C NULL or C++ nullptr). + returned as a null pointer.

In the event that the function encounters an error (any return value other than JVMTI_ERROR_NONE) the values I can try to add a couple of more examples where a null pointer can be passed as a parameter value if it is desirable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1626756885 From liach at openjdk.org Wed Jun 5 00:55:03 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 5 Jun 2024 00:55:03 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote: > Hi all, > This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. > > Thanks. @altrisi As trivial and low-effort as this seems, this is actually fixing some technical debt for legacy Makefiles last changed before 8e7a855ee8f085cee080395058f79c8a75bfef40 when trailing whitespace checks applied to Makefiles. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2148641237 From jpai at openjdk.org Wed Jun 5 01:21:04 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 5 Jun 2024 01:21:04 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v6] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 12:35:33 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which addresses https://bugs.openjdk.org/browse/JDK-8333130? >> >> There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under `test/jdk/java/lang/instrument/` which launch the app/test with a `-javaagent:` pointing to a test specific jar. The test, launched with that `javaagent`, then verifies the test specific details. >> >> In their current form, in order to construct the agent `.jar` and make it available to the jtreg test that's launched, they `@run` a jtreg `shell` test. This `shell` test uses the `MakeJAR2.sh` script to generate the jar file. The contents of the script is relatively straightforward - it compiles (using `javac`) some boot classpath classes, some agent specific classes and then generates a jar file with the agent classes and a `MANIFEST.MF` which points to the boot classpath classes along with test specific manifest attributes. In a recent PR the `MakeJAR2.sh` script was updated to pass `--enable-preview --release 23` since one of the existing agent class was updated to use the ClassFile API PreviewFeature (https://github.com/openjdk/jdk/pull/13009). >> >> This generated agent jar then is passed as `-javaagent:` to the subsequent `@run main` test which does the actual testing. >> >> So essentially the `shell` test which uses the `MakeJAR2.sh` is merely there to create a jar file that's needed by the actual test. Within the JDK we have several tests which compile other classes and generate jar files using in-process test libraries and the `java.util.spi.ToolProvider` implementations. These 2 tests too can be updated to use a similar technique, to completely get rid of the `MakeJAR2.sh`. Removing the `MakeJAR2.sh` will simplify the ability to pass around value for `--release` when using `--enable-preview`. >> >> The commit in this PR updates these 2 tests to use `@run driver` which then compiles relevant classes (maintaining the semantics of `MakeJAR2.sh`) and generates the agent jar file and then finally launching the test process. As part of the update, I did not retain the `@author` tag from the 2 test definitions, since it's my understanding that we no longer use those. I will add them back if we should retain them. >> >> The tests continue to pass locally with this change. I've also triggered tier testing in our CI for this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Serguei's suggestion - use a higher timeout for the test to match what was being used for the shell test Thank you everyone for the help in refactoring this test and the reviews. I will go ahead and integrate this today in the next few hours. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19495#issuecomment-2148684740 From jpai at openjdk.org Wed Jun 5 01:21:05 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 5 Jun 2024 01:21:05 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v6] In-Reply-To: References: <_UAw03zQS4rSSkaIFsUoeLZRaPvRuVQuXhr8sNntjfs=.d1eb94ff-8ddb-470d-a51e-8f3de1c04fbb@github.com> Message-ID: On Tue, 4 Jun 2024 18:49:03 GMT, Alex Menkov wrote: >> I have now updated the PR to use the same timeout that was used for the `shell` test before the changes in this PR. > > I think `timeout`s are not needed for the refactored tests. > Per JDK-6528548 the shell action has timed out using a network mounted JDK (MakeJAR2.sh run `javac` 3 times and `jar` 1 time). > But I don't see big problem here - up to the author to keep or remove them. Hello Alex, I agree that the timeout may not be needed. I haven't run the higher tiers in our CI where `-Xcomp` and other options might slow tests down in general. So, given Serguei's input, I'll let the timeout stay for now and once we see how this behaves in higher tiers, then we can remove the timeout in a subsequent PR if necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1626802777 From nbenalla at openjdk.org Wed Jun 5 01:21:36 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 5 Jun 2024 01:21:36 GMT Subject: RFR: 8332070: Convert package.html files in `java.management` to package-info.java [v3] In-Reply-To: References: Message-ID: <91qhud9Kk6dvfLvsQDIJO8BP0u8le6YWpoFDS94M_Pw=.8daf520d-48d5-46e7-a877-3e1e046a4dd8@github.com> > This is a simple noreg cleanup. The motivation was that I noticed javac doesn't recognise package.html files well. > > Some of the contents of the `package.html` files (and code in the package) may be outdated, but I think it is out of scope for this PR. > > I have also changed three `{@link }` usages with the `href` that would have been in the generated HTML. > Because referencing an element from an other module wouldn't work even when using the `module/package.class#member`, if the `module-info.java` file does not have "require ``". > > I am referring to line 69 in > `src/java.management/share/classes/javax/management/monitor/package-info.java` > and lines 90 and 120 in > `src/java.management/share/classes/javax/management/remote/package-info.java` > > Adding 2 dependencies just for 3 links didn't seem right. > > edit: passes all tests, the failing test is a github actions issue Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: remove double spacing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19399/files - new: https://git.openjdk.org/jdk/pull/19399/files/c5d3147a..963ff90f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19399&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19399&range=01-02 Stats: 211 lines in 1 file changed: 0 ins; 0 del; 211 mod Patch: https://git.openjdk.org/jdk/pull/19399.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19399/head:pull/19399 PR: https://git.openjdk.org/jdk/pull/19399 From sspitsyn at openjdk.org Wed Jun 5 01:29:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Jun 2024 01:29:56 GMT Subject: RFR: 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 In-Reply-To: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> References: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> Message-ID: On Tue, 4 Jun 2024 17:25:04 GMT, Leonid Mesnik wrote: > The kill sends async exception that is thrown somewhere during log.display(...) method. > The log shows that it is thrown while PrintStream locking moving it into an inconsistent state. > So the fix is to use some method that could be safely interrupted by async exception. Looks okay to me. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19547#pullrequestreview-2097695938 From sspitsyn at openjdk.org Wed Jun 5 01:33:00 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Jun 2024 01:33:00 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v6] In-Reply-To: References: <_UAw03zQS4rSSkaIFsUoeLZRaPvRuVQuXhr8sNntjfs=.d1eb94ff-8ddb-470d-a51e-8f3de1c04fbb@github.com> Message-ID: On Wed, 5 Jun 2024 01:17:37 GMT, Jaikiran Pai wrote: >> I think `timeout`s are not needed for the refactored tests. >> Per JDK-6528548 the shell action has timed out using a network mounted JDK (MakeJAR2.sh run `javac` 3 times and `jar` 1 time). >> But I don't see big problem here - up to the author to keep or remove them. > > Hello Alex, I agree that the timeout may not be needed. I haven't run the higher tiers in our CI where `-Xcomp` and other options might slow tests down in general. So, given Serguei's input, I'll let the timeout stay for now and once we see how this behaves in higher tiers, then we can remove the timeout in a subsequent PR if necessary. Agreed. Keeping the timeout for now is more safe at this stage of the release cycle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1626809583 From alanb at openjdk.org Wed Jun 5 04:24:56 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 5 Jun 2024 04:24:56 GMT Subject: RFR: 8332070: Convert package.html files in `java.management` to package-info.java [v3] In-Reply-To: <91qhud9Kk6dvfLvsQDIJO8BP0u8le6YWpoFDS94M_Pw=.8daf520d-48d5-46e7-a877-3e1e046a4dd8@github.com> References: <91qhud9Kk6dvfLvsQDIJO8BP0u8le6YWpoFDS94M_Pw=.8daf520d-48d5-46e7-a877-3e1e046a4dd8@github.com> Message-ID: On Wed, 5 Jun 2024 01:21:36 GMT, Nizar Benalla wrote: >> This is a simple noreg cleanup. The motivation was that I noticed javac doesn't recognise package.html files well. >> >> Some of the contents of the `package.html` files (and code in the package) may be outdated, but I think it is out of scope for this PR. >> >> I have also changed three `{@link }` usages with the `href` that would have been in the generated HTML. >> Because referencing an element from an other module wouldn't work even when using the `module/package.class#member`, if the `module-info.java` file does not have "require ``". >> >> I am referring to line 69 in >> `src/java.management/share/classes/javax/management/monitor/package-info.java` >> and lines 90 and 120 in >> `src/java.management/share/classes/javax/management/remote/package-info.java` >> >> Adding 2 dependencies just for 3 links didn't seem right. >> >> edit: passes all tests, the failing test is a github actions issue > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > remove double spacing Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19399#pullrequestreview-2098000999 From Alan.Bateman at oracle.com Wed Jun 5 04:52:29 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Jun 2024 05:52:29 +0100 Subject: 8330846: (jstack) Add stacks of mounted virtual threads In-Reply-To: References: Message-ID: <67efe07c-e0fe-42be-b94b-6e92da02a419@oracle.com> On 04/06/2024 21:52, I?igo Mediavilla wrote: > Hello, > > While there's ongoing work on: > > https://github.com/openjdk/jdk/pull/19482 > > to add the stack trace of mounted virtual threads to the `jcmd > Thread.print` command, I'm starting to think about how I could do to > print the stack trace for virtual threads from `jstack` but I'm not > sure about what would be the best approach, so I'd be happy to get > people's thoughts on the topic. JDK-8330846 is about showing the stack traces of mounted virtual threads, I don't think pull/19482 should be expanded to do anything else. For the PR then I think you are just waiting for Thomas Stuefe's change with support for automatic indentation and of course converging on some details of the output. If you are asking if it should include the stack traces of unmounted virtual threads then we decided some time ago to not do that. The Thread.print commands runs as a VM operation so the at a safepoint. Adding more work to that, to walk the heap to find virtual thread objects, would just increase the STW time. The other issue is that the output (text format) doesn't scale to hundreds of thousands of threads. You might ask about de-duplication but that is just adding more overhead to the thread dump and may be better left to tools that process the thread dump. These are issues/reasons for Thread.dump_to_file. It uses the tree of thread groupings to find all threads. -Alan From duke at openjdk.org Wed Jun 5 06:22:17 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Wed, 5 Jun 2024 06:22:17 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v4] In-Reply-To: References: Message-ID: > 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: Add test for the elevated privileges case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19055/files - new: https://git.openjdk.org/jdk/pull/19055/files/c57b4598..c625411b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19055&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19055&range=02-03 Stats: 83 lines in 1 file changed: 54 ins; 13 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/19055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19055/head:pull/19055 PR: https://git.openjdk.org/jdk/pull/19055 From duke at openjdk.org Wed Jun 5 06:22:17 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Wed, 5 Jun 2024 06:22:17 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v3] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 23:07:00 GMT, Larry Cable wrote: >> Sebastian L?vdahl has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove unused `SELF_PID_NS` >> - Rewrite in line with suggestion from Larry Cable > > it looks as though I can take an existing jcmd test in the container > tests and quite quickly implement an 'elevated' sidecar test... > > I'll work on that today and tomorrow, lets aim to get the 'fix' and the > test in before Thu!!! > > Rgds > > - Larry > > On 6/3/24 10:24 AM, Sebastian L?vdahl wrote: >> >> Hi Larry, no worries. :) >> >> I can try to look into writing some tests for the elevated use-cases. >> but it will be quite much treading of new ground for me, so it could >> take some time to get it done. >> >> What's your take, do we need the new tests in this PR, or could it be >> done in a follow-up? >> >> ? >> Reply to this email directly, view it on GitHub >> , >> or unsubscribe >> . >> You are receiving this because you were mentioned.Message ID: >> ***@***.***> >> > > --------------2ZFegatR1DQpyr1B5InvHtns > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > > > > > it looks as though I can take an existing jcmd test in the container > tests and quite quickly implement an 'elevated' sidecar test...
>
> I'll work on that today and tomorrow, lets aim to get the 'fix' and > the test in before Thu!!!
>
> Rgds
>
> - Larry
>
>

On 6/3/24 10:24 AM, Sebastian L?vdahl > wrote:
>
>
>

Hi Larry, no worries. :)

>

I can try to look into writing some tests for the > elevated use-cases. but it will be quite much treading of new > ground for me, so it could take some time to get it done.

>

What's your take, do we need the new tests in this > PR, or could it be done in a follow-up?

>

?
> Reply to this email directly, `". >> >> I am referring to line 69 in >> `src/java.management/share/classes/javax/management/monitor/package-info.java` >> and lines 90 and 120 in >> `src/java.management/share/classes/javax/management/remote/package-info.java` >> >> Adding 2 dependencies just for 3 links didn't seem right. >> >> edit: passes all tests, the failing test is a github actions issue > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > remove double spacing Thank you ------------- PR Comment: https://git.openjdk.org/jdk/pull/19399#issuecomment-2149468616 From mbaesken at openjdk.org Wed Jun 5 13:09:33 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 5 Jun 2024 13:09:33 GMT Subject: RFR: 8333178: ubsan: jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null Message-ID: With ubsan enabled binaries we run into the following issue in HS :tier4 tests : e.g. vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/TestDescription.jtr /jdk/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null #0 0x7fa7a1049482 in add_option test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149 #1 0x7fa7a1049482 in nsk_jvmti_parseOptions test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:242 #2 0x7fa7a10634cd in Agent_Initialize test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp:216 #3 0x7fa79a9dbb36 in invoke_Agent_OnLoad src/hotspot/share/prims/jvmtiAgent.cpp:609 #4 0x7fa79a9dbb36 in JvmtiAgent::load(outputStream*) src/hotspot/share/prims/jvmtiAgent.cpp:623 #5 0x7fa79a9defd4 in load_agents src/hotspot/share/prims/jvmtiAgentList.cpp:179 #6 0x7fa79a9defd4 in JvmtiAgentList::load_agents() src/hotspot/share/prims/jvmtiAgentList.cpp:190 #7 0x7fa79bdad503 in Threads::create_vm(JavaVMInitArgs*, bool*) src/hotspot/share/runtime/threads.cpp:505 #8 0x7fa79a6e531f in JNI_CreateJavaVM_inner src/hotspot/share/prims/jni.cpp:3581 #9 0x7fa79a6e531f in JNI_CreateJavaVM src/hotspot/share/prims/jni.cpp:3672 #10 0x7fa7a11277d5 in InitializeJVM src/java.base/share/native/libjli/java.c:1550 #11 0x7fa7a11277d5 in JavaMain src/java.base/share/native/libjli/java.c:491 #12 0x7fa7a1130f68 in ThreadJavaMain src/java.base/unix/native/libjli/java_md.c:653 #13 0x7fa7a10df6e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73) #14 0x7fa7a071550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37) ------------- Commit messages: - JDK-8333178 Changes: https://git.openjdk.org/jdk/pull/19557/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19557&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333178 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19557.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19557/head:pull/19557 PR: https://git.openjdk.org/jdk/pull/19557 From pchilanomate at openjdk.org Wed Jun 5 14:27:59 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 5 Jun 2024 14:27:59 GMT Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes [v4] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 22:55:24 GMT, Serguei Spitsyn wrote: >> Please, review the following `interp-only` issue related to carrier threads. >> There are 3 problems fixed here: >> - The `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter. >> - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. >> - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted. >> >> The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio. >> >> Testing: >> - Ran new test case locally >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: get rid of unneeded casts in new test Thanks Serguei, looks good to me. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19438#pullrequestreview-2099384221 From stuefe at openjdk.org Wed Jun 5 16:00:58 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 5 Jun 2024 16:00:58 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v7] In-Reply-To: References: <9lc4sCQvq1bo5VEaIXPINF-jDXvJZ2ub2F8f8ZgYVb0=.bbdb1cf0-24f5-47e6-b098-859dd3ecf4a2@github.com> Message-ID: On Tue, 4 Jun 2024 13:23:59 GMT, Inigo Mediavilla Saiz wrote: >> Note that We are in the process of adding better and saner auto-indentation to outputStream. See https://github.com/openjdk/jdk/pull/19461 . I don't think that PR is going to take long. >> >> If you don't want to wait, please: >> - As David wrote, use spaces, not tabs >> - Today's pattern for using outputStream indentation is: >> - set up indentation, preferably with streamIndentor, not manually with inc/dec >> - then, before printing each line, call stream->indent() >> >> This pattern would also help us to later identify and remove this manual indentation pattern if auto-indent becomes a thing. >> >> But really, waiting for https://github.com/openjdk/jdk/pull/19461 would be preferable. Then, all you have to do is place a streamIndentor around stack printing. Sub-function printing is then indented automatically. > > Thanks ! > > Your PR looks very promising @tstuefe, I would indeed prefer to wait for your changes as a way to add additional indentation to the stack of the virtual thread. > > What do you think if I leave the current PR with the indentation that is already used for the stack of the carrier thread and I create a separate PR based on yours to add the additional indentation ? Okay for me, if other reviewers are okay with it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1628042032 From szaldana at openjdk.org Wed Jun 5 16:02:01 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 5 Jun 2024 16:02:01 GMT Subject: Integrated: 8332785: Replace naked uses of UseSharedSpaces with CDSConfig::is_using_archive In-Reply-To: References: Message-ID: On Wed, 29 May 2024 18:12:25 GMT, Sonia Zaldana Calles wrote: > Hi folks, > > This PR addresses [8332785](https://bugs.openjdk.org/browse/JDK-8332785) replacing all naked uses for ```UseSharedSpaces``` with ```CDSConfig::is_using_archive```. > > Testing: > - [x] Tier 1 with GHA. > > Thanks, > Sonia This pull request has now been integrated. Changeset: 438121be Author: Sonia Zaldana Calles Committer: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/438121be6bdb085fa13ad14ec53b09ecdbd4757d Stats: 113 lines in 35 files changed: 8 ins; 0 del; 105 mod 8332785: Replace naked uses of UseSharedSpaces with CDSConfig::is_using_archive Reviewed-by: dholmes, stuefe, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/19463 From lmesnik at openjdk.org Wed Jun 5 16:08:00 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 5 Jun 2024 16:08:00 GMT Subject: Integrated: 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 In-Reply-To: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> References: <_y4znuTlovq2cgaKqRSPgjL_C23WGwt9PcoZinGrxDU=.4b9fd06b-91b5-4da2-a6af-6295856ea353@github.com> Message-ID: On Tue, 4 Jun 2024 17:25:04 GMT, Leonid Mesnik wrote: > The kill sends async exception that is thrown somewhere during log.display(...) method. > The log shows that it is thrown while PrintStream locking moving it into an inconsistent state. > So the fix is to use some method that could be safely interrupted by async exception. This pull request has now been integrated. Changeset: f73922b2 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/f73922b27d126314fc3127ee25aa40b6258c8a6b Stats: 14 lines in 1 file changed: 11 ins; 0 del; 3 mod 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/19547 From cjplummer at openjdk.org Wed Jun 5 16:37:57 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Jun 2024 16:37:57 GMT Subject: RFR: 8333178: ubsan: jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 13:04:03 GMT, Matthias Baesken wrote: > With ubsan enabled binaries we run into the following issue in HS :tier4 tests : > e.g. vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/TestDescription.jtr > > /jdk/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null > #0 0x7fa7a1049482 in add_option test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149 > #1 0x7fa7a1049482 in nsk_jvmti_parseOptions test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:242 > #2 0x7fa7a10634cd in Agent_Initialize test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp:216 > #3 0x7fa79a9dbb36 in invoke_Agent_OnLoad src/hotspot/share/prims/jvmtiAgent.cpp:609 > #4 0x7fa79a9dbb36 in JvmtiAgent::load(outputStream*) src/hotspot/share/prims/jvmtiAgent.cpp:623 > #5 0x7fa79a9defd4 in load_agents src/hotspot/share/prims/jvmtiAgentList.cpp:179 > #6 0x7fa79a9defd4 in JvmtiAgentList::load_agents() src/hotspot/share/prims/jvmtiAgentList.cpp:190 > #7 0x7fa79bdad503 in Threads::create_vm(JavaVMInitArgs*, bool*) src/hotspot/share/runtime/threads.cpp:505 > #8 0x7fa79a6e531f in JNI_CreateJavaVM_inner src/hotspot/share/prims/jni.cpp:3581 > #9 0x7fa79a6e531f in JNI_CreateJavaVM src/hotspot/share/prims/jni.cpp:3672 > #10 0x7fa7a11277d5 in InitializeJVM src/java.base/share/native/libjli/java.c:1550 > #11 0x7fa7a11277d5 in JavaMain src/java.base/share/native/libjli/java.c:491 > #12 0x7fa7a1130f68 in ThreadJavaMain src/java.base/unix/native/libjli/java_md.c:653 > #13 0x7fa7a10df6e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73) > #14 0x7fa7a071550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37) Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19557#pullrequestreview-2099719890 From cjplummer at openjdk.org Wed Jun 5 17:02:59 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Jun 2024 17:02:59 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 23:52:36 GMT, Serguei Spitsyn wrote: >> Yes, my point was that this section is only for return values. The section is titled "Function Return Values". Maybe we should add another short section just before this one to describe what is meant by "null pointer". > > Okay, thanks. What about the following: : > > diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml > index a6ebd0d42c5..a81014c70bb 100644 > --- a/src/hotspot/share/prims/jvmti.xml > +++ b/src/hotspot/share/prims/jvmti.xml > @@ -995,7 +995,10 @@ jvmtiEnv *jvmti; > across threads and are created dynamically. > > > - > + > + There are a few functions where a parameter value can be a null pointer > + (C NULL or C++ nullptr), e.g. the thread parameter > + can be a null pointer to mean the current thread. > functions always return an > error code via the > function return value. > @@ -1004,7 +1007,7 @@ jvmtiEnv *jvmti; > In some cases, functions allocate memory that your program must > explicitly deallocate. This is indicated in the individual > function descriptions. Empty lists, arrays, sequences, etc are > - returned as a null pointer (C NULL or C++ nullptr). > + returned as a null pointer. >

> In the event that the function encounters > an error (any return value other than JVMTI_ERROR_NONE) the values > > > I can try to add a couple of more examples where a null pointer can be passed as a parameter value if it is desirable. I'm still not sure this works. It seems kind of muddled. Rather than trying to retrofit in the clarifying text, why not start from scratch. That should result in better organization and clearer descriptions. For example, I think first you should clarify what is meant by a "null pointer". Maybe even make that a separate section. I can take a stab at this later today if you want. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1628123917 From sspitsyn at openjdk.org Wed Jun 5 17:25:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Jun 2024 17:25:56 GMT Subject: RFR: 8333178: ubsan: jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 13:04:03 GMT, Matthias Baesken wrote: > With ubsan enabled binaries we run into the following issue in HS :tier4 tests : > e.g. vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/TestDescription.jtr > > /jdk/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null > #0 0x7fa7a1049482 in add_option test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149 > #1 0x7fa7a1049482 in nsk_jvmti_parseOptions test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:242 > #2 0x7fa7a10634cd in Agent_Initialize test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp:216 > #3 0x7fa79a9dbb36 in invoke_Agent_OnLoad src/hotspot/share/prims/jvmtiAgent.cpp:609 > #4 0x7fa79a9dbb36 in JvmtiAgent::load(outputStream*) src/hotspot/share/prims/jvmtiAgent.cpp:623 > #5 0x7fa79a9defd4 in load_agents src/hotspot/share/prims/jvmtiAgentList.cpp:179 > #6 0x7fa79a9defd4 in JvmtiAgentList::load_agents() src/hotspot/share/prims/jvmtiAgentList.cpp:190 > #7 0x7fa79bdad503 in Threads::create_vm(JavaVMInitArgs*, bool*) src/hotspot/share/runtime/threads.cpp:505 > #8 0x7fa79a6e531f in JNI_CreateJavaVM_inner src/hotspot/share/prims/jni.cpp:3581 > #9 0x7fa79a6e531f in JNI_CreateJavaVM src/hotspot/share/prims/jni.cpp:3672 > #10 0x7fa7a11277d5 in InitializeJVM src/java.base/share/native/libjli/java.c:1550 > #11 0x7fa7a11277d5 in JavaMain src/java.base/share/native/libjli/java.c:491 > #12 0x7fa7a1130f68 in ThreadJavaMain src/java.base/unix/native/libjli/java_md.c:653 > #13 0x7fa7a10df6e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73) > #14 0x7fa7a071550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37) Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19557#pullrequestreview-2099819278 From sspitsyn at openjdk.org Wed Jun 5 17:27:58 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Jun 2024 17:27:58 GMT Subject: RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes [v4] In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 22:55:24 GMT, Serguei Spitsyn wrote: >> Please, review the following `interp-only` issue related to carrier threads. >> There are 3 problems fixed here: >> - The `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter. >> - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. >> - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted. >> >> The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio. >> >> Testing: >> - Ran new test case locally >> - Ran mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: get rid of unneeded casts in new test Thank you for review, Patricio! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19438#issuecomment-2150584829 From alanb at openjdk.org Wed Jun 5 17:42:58 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 5 Jun 2024 17:42:58 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v7] In-Reply-To: References: <9lc4sCQvq1bo5VEaIXPINF-jDXvJZ2ub2F8f8ZgYVb0=.bbdb1cf0-24f5-47e6-b098-859dd3ecf4a2@github.com> Message-ID: On Wed, 5 Jun 2024 15:58:28 GMT, Thomas Stuefe wrote: >> Thanks ! >> >> Your PR looks very promising @tstuefe, I would indeed prefer to wait for your changes as a way to add additional indentation to the stack of the virtual thread. >> >> What do you think if I leave the current PR with the indentation that is already used for the stack of the carrier thread and I create a separate PR based on yours to add the additional indentation ? > > Okay for me, if other reviewers are okay with it. I think it would be better if the stack trace of the mounted virtual thread didn't align/indent the same as the carrier as it kinda looks like it's one larger stack trace. That said, no objection if there is a follow-on PR to do that, in which case might be better to wait until after the fork for JDK 23 so that the two PRs go into the same release. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1628172341 From sspitsyn at openjdk.org Wed Jun 5 21:49:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Jun 2024 21:49:56 GMT Subject: Integrated: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes In-Reply-To: References: Message-ID: On Tue, 28 May 2024 22:24:53 GMT, Serguei Spitsyn wrote: > Please, review the following `interp-only` issue related to carrier threads. > There are 3 problems fixed here: > - The `EnterInterpOnlyModeClosure::do_threads` is taking the `JvmtiThreadState` with the `jt->jvmti_thread_state()` which is incorrect when we have a deal with a carrier thread. The target state is known at the point when the `HandshakeClosure` is set, so the fix is to pass it as a constructor parameter. > - The `state->is_pending_interp_only_mode())` was processed at mounts only but it has to be processed for unmounts as well. > - The test `test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp` has a wrong assumption that there can't be `MethodExit` event on the carrier thread when the function `breakpoint_hit1` is being executed. However, it can happen if the virtual thread gets unmounted. > > The fix also includes new test case `vthread/CarrierThreadEventNotification` developed by Patricio. > > Testing: > - Ran new test case locally > - Ran mach5 tiers 1-6 This pull request has now been integrated. Changeset: 60ea17e8 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/60ea17e8482936a6acbc442bb1be199e01008072 Stats: 251 lines in 9 files changed: 229 ins; 12 del; 10 mod 8311177: Switching to interpreter only mode in carrier thread can lead to crashes Reviewed-by: pchilanomate, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/19438 From cjplummer at openjdk.org Wed Jun 5 22:52:45 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Jun 2024 22:52:45 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 17:00:34 GMT, Chris Plummer wrote: >> Okay, thanks. What about the following: : >> >> diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml >> index a6ebd0d42c5..a81014c70bb 100644 >> --- a/src/hotspot/share/prims/jvmti.xml >> +++ b/src/hotspot/share/prims/jvmti.xml >> @@ -995,7 +995,10 @@ jvmtiEnv *jvmti; >> across threads and are created dynamically. >> >> >> - >> + >> + There are a few functions where a parameter value can be a null pointer >> + (C NULL or C++ nullptr), e.g. the thread parameter >> + can be a null pointer to mean the current thread. >> functions always return an >> error code via the >> function return value. >> @@ -1004,7 +1007,7 @@ jvmtiEnv *jvmti; >> In some cases, functions allocate memory that your program must >> explicitly deallocate. This is indicated in the individual >> function descriptions. Empty lists, arrays, sequences, etc are >> - returned as a null pointer (C NULL or C++ nullptr). >> + returned as a null pointer. >>

>> In the event that the function encounters >> an error (any return value other than JVMTI_ERROR_NONE) the values >> >> >> I can try to add a couple of more examples where a null pointer can be passed as a parameter value if it is desirable. > > I'm still not sure this works. It seems kind of muddled. Rather than trying to retrofit in the clarifying text, why not start from scratch. That should result in better organization and clearer descriptions. For example, I think first you should clarify what is meant by a "null pointer". Maybe even make that a separate section. I can take a stab at this later today if you want. How about undoing the changes in this subsection and then just add the following as a preceding subsection: **Null Pointers** Parts of this specification refer to a "null pointer" as a possible function parameter or return value. A "null pointer" is C `NULL` or C++ `nullptr`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1628532037 From sspitsyn at openjdk.org Wed Jun 5 23:49:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Jun 2024 23:49:08 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v6] In-Reply-To: References: Message-ID: > The following RFE was fixed recently: > [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code > > It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++. > This update is to make it clear that `nullptr` is C programming language `null` pointer. > > I think we do not need a CSR for this fix. > > Testing: N/A (not needed) Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge - review: consistency and stylistical corrections - review: more null pointer corrections - review: replace nullptr with null pointer in the docs - review: corrected the nullptr clarification - 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers ------------- Changes: https://git.openjdk.org/jdk/pull/19257/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19257&range=05 Stats: 82 lines in 4 files changed: 0 ins; 0 del; 82 mod Patch: https://git.openjdk.org/jdk/pull/19257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19257/head:pull/19257 PR: https://git.openjdk.org/jdk/pull/19257 From sspitsyn at openjdk.org Wed Jun 5 23:49:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Jun 2024 23:49:08 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: References: Message-ID: <5_UvYEgMkoAnMFEEyAziKgFLgMz8HVfUK6a0t1_4RgU=.844286cd-8529-4875-8938-6da37d86c6b1@github.com> On Wed, 5 Jun 2024 22:49:51 GMT, Chris Plummer wrote: >> I'm still not sure this works. It seems kind of muddled. Rather than trying to retrofit in the clarifying text, why not start from scratch. That should result in better organization and clearer descriptions. For example, I think first you should clarify what is meant by a "null pointer". Maybe even make that a separate section. I can take a stab at this later today if you want. > > How about undoing the changes in this subsection and then just add the following as a preceding subsection: > > **Null Pointers** > > Parts of this specification refer to a "null pointer" as a possible function parameter or return value. A "null pointer" is C `NULL` or C++ `nullptr`. Good suggestion, thanks! Will add it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1628565113 From sspitsyn at openjdk.org Wed Jun 5 23:57:02 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Jun 2024 23:57:02 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v7] In-Reply-To: References: Message-ID: > The following RFE was fixed recently: > [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code > > It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++. > This update is to make it clear that `nullptr` is C programming language `null` pointer. > > I think we do not need a CSR for this fix. > > Testing: N/A (not needed) Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: add a sub-section: Null Pointers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19257/files - new: https://git.openjdk.org/jdk/pull/19257/files/6275df3a..16cea131 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19257&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19257&range=05-06 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19257/head:pull/19257 PR: https://git.openjdk.org/jdk/pull/19257 From cjplummer at openjdk.org Thu Jun 6 00:00:52 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 6 Jun 2024 00:00:52 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v7] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 23:57:02 GMT, Serguei Spitsyn wrote: >> The following RFE was fixed recently: >> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code >> >> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++. >> This update is to make it clear that `nullptr` is C programming language `null` pointer. >> >> I think we do not need a CSR for this fix. >> >> Testing: N/A (not needed) > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: add a sub-section: Null Pointers Looks good. Thanks for the changes. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19257#pullrequestreview-2100483644 From sspitsyn at openjdk.org Thu Jun 6 00:12:51 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 6 Jun 2024 00:12:51 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v7] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 23:57:02 GMT, Serguei Spitsyn wrote: >> The following RFE was fixed recently: >> [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code >> >> It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++. >> This update is to make it clear that `nullptr` is C programming language `null` pointer. >> >> I think we do not need a CSR for this fix. >> >> Testing: N/A (not needed) > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: add a sub-section: Null Pointers Thanks you for review, Kim Chris! Alan, Kim, David and Chris et all, thanks for the discussion and suggestion! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19257#issuecomment-2151151302 From amenkov at openjdk.org Thu Jun 6 02:20:02 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 6 Jun 2024 02:20:02 GMT Subject: RFR: 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect" Message-ID: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> The fix updates com/sun/tools/attach/BasicTests.java to listen and connect using loopback addresses Testing: run the test on all Oracle-supported platforms ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/19571/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19571&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333680 Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/19571.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19571/head:pull/19571 PR: https://git.openjdk.org/jdk/pull/19571 From sspitsyn at openjdk.org Thu Jun 6 03:01:54 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 6 Jun 2024 03:01:54 GMT Subject: RFR: 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect" In-Reply-To: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> References: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> Message-ID: On Thu, 6 Jun 2024 02:12:11 GMT, Alex Menkov wrote: > The fix updates com/sun/tools/attach/BasicTests.java to listen and connect using loopback addresses > > Testing: run the test on all Oracle-supported platforms Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19571#pullrequestreview-2100712779 From qamai at openjdk.org Thu Jun 6 03:43:44 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 6 Jun 2024 03:43:44 GMT Subject: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v5] In-Reply-To: <5_UvYEgMkoAnMFEEyAziKgFLgMz8HVfUK6a0t1_4RgU=.844286cd-8529-4875-8938-6da37d86c6b1@github.com> References: <5_UvYEgMkoAnMFEEyAziKgFLgMz8HVfUK6a 0t1_4RgU=.844286cd-8529-4875-8938-6da37d86c6b1@github.com> Message-ID: On Wed, 5 Jun 2024 23:43:20 GMT, Serguei Spitsyn wrote: >> How about undoing the changes in this subsection and then just add the following as a preceding subsection: >> >> **Null Pointers** >> >> Parts of this specification refer to a "null pointer" as a possible function parameter or return value. A "null pointer" is C `NULL` or C++ `nullptr`. > > Good suggestion, thanks! Updated now. A "null pointer" is well-defined in the language itself so I don't think there is any need to clarify it here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1628735822 From sspitsyn at openjdk.org Thu Jun 6 04:24:48 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 6 Jun 2024 04:24:48 GMT Subject: Integrated: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers In-Reply-To: References: Message-ID: On Thu, 16 May 2024 02:37:40 GMT, Serguei Spitsyn wrote: > The following RFE was fixed recently: > [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with nullptr in JVMTI generated code > > It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI agents can be developed in C or C++. > This update is to make it clear that `nullptr` is C programming language `null` pointer. > > I think we do not need a CSR for this fix. > > Testing: N/A (not needed) This pull request has now been integrated. Changeset: 30894126 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/30894126a4ba8bc41c333c923ff3007503257688 Stats: 87 lines in 4 files changed: 5 ins; 0 del; 82 mod 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers Reviewed-by: kbarrett, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/19257 From nbenalla at openjdk.org Thu Jun 6 07:30:55 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 6 Jun 2024 07:30:55 GMT Subject: Integrated: 8332070: Convert package.html files in `java.management` to package-info.java In-Reply-To: References: Message-ID: On Fri, 24 May 2024 18:11:18 GMT, Nizar Benalla wrote: > This is a simple noreg cleanup. The motivation was that I noticed javac doesn't recognise package.html files well. > > Some of the contents of the `package.html` files (and code in the package) may be outdated, but I think it is out of scope for this PR. > > I have also changed three `{@link }` usages with the `href` that would have been in the generated HTML. > Because referencing an element from an other module wouldn't work even when using the `module/package.class#member`, if the `module-info.java` file does not have "require ``". > > I am referring to line 69 in > `src/java.management/share/classes/javax/management/monitor/package-info.java` > and lines 90 and 120 in > `src/java.management/share/classes/javax/management/remote/package-info.java` > > Adding 2 dependencies just for 3 links didn't seem right. > > edit: passes all tests, the failing test is a github actions issue This pull request has now been integrated. Changeset: c7d2841f Author: Nizar Benalla Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/c7d2841fb4ac97c0edec175cf37abd90167ea56e Stats: 3089 lines in 18 files changed: 1524 ins; 1565 del; 0 mod 8332070: Convert package.html files in `java.management` to package-info.java Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/19399 From mbaesken at openjdk.org Thu Jun 6 07:48:46 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Jun 2024 07:48:46 GMT Subject: RFR: 8333178: ubsan: jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 13:04:03 GMT, Matthias Baesken wrote: > With ubsan enabled binaries we run into the following issue in HS :tier4 tests : > e.g. vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/TestDescription.jtr > > /jdk/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null > #0 0x7fa7a1049482 in add_option test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149 > #1 0x7fa7a1049482 in nsk_jvmti_parseOptions test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:242 > #2 0x7fa7a10634cd in Agent_Initialize test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp:216 > #3 0x7fa79a9dbb36 in invoke_Agent_OnLoad src/hotspot/share/prims/jvmtiAgent.cpp:609 > #4 0x7fa79a9dbb36 in JvmtiAgent::load(outputStream*) src/hotspot/share/prims/jvmtiAgent.cpp:623 > #5 0x7fa79a9defd4 in load_agents src/hotspot/share/prims/jvmtiAgentList.cpp:179 > #6 0x7fa79a9defd4 in JvmtiAgentList::load_agents() src/hotspot/share/prims/jvmtiAgentList.cpp:190 > #7 0x7fa79bdad503 in Threads::create_vm(JavaVMInitArgs*, bool*) src/hotspot/share/runtime/threads.cpp:505 > #8 0x7fa79a6e531f in JNI_CreateJavaVM_inner src/hotspot/share/prims/jni.cpp:3581 > #9 0x7fa79a6e531f in JNI_CreateJavaVM src/hotspot/share/prims/jni.cpp:3672 > #10 0x7fa7a11277d5 in InitializeJVM src/java.base/share/native/libjli/java.c:1550 > #11 0x7fa7a11277d5 in JavaMain src/java.base/share/native/libjli/java.c:491 > #12 0x7fa7a1130f68 in ThreadJavaMain src/java.base/unix/native/libjli/java_md.c:653 > #13 0x7fa7a10df6e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73) > #14 0x7fa7a071550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37) Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19557#issuecomment-2151620741 From mbaesken at openjdk.org Thu Jun 6 07:48:46 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Jun 2024 07:48:46 GMT Subject: Integrated: 8333178: ubsan: jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 13:04:03 GMT, Matthias Baesken wrote: > With ubsan enabled binaries we run into the following issue in HS :tier4 tests : > e.g. vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/TestDescription.jtr > > /jdk/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null > #0 0x7fa7a1049482 in add_option test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:149 > #1 0x7fa7a1049482 in nsk_jvmti_parseOptions test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp:242 > #2 0x7fa7a10634cd in Agent_Initialize test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp:216 > #3 0x7fa79a9dbb36 in invoke_Agent_OnLoad src/hotspot/share/prims/jvmtiAgent.cpp:609 > #4 0x7fa79a9dbb36 in JvmtiAgent::load(outputStream*) src/hotspot/share/prims/jvmtiAgent.cpp:623 > #5 0x7fa79a9defd4 in load_agents src/hotspot/share/prims/jvmtiAgentList.cpp:179 > #6 0x7fa79a9defd4 in JvmtiAgentList::load_agents() src/hotspot/share/prims/jvmtiAgentList.cpp:190 > #7 0x7fa79bdad503 in Threads::create_vm(JavaVMInitArgs*, bool*) src/hotspot/share/runtime/threads.cpp:505 > #8 0x7fa79a6e531f in JNI_CreateJavaVM_inner src/hotspot/share/prims/jni.cpp:3581 > #9 0x7fa79a6e531f in JNI_CreateJavaVM src/hotspot/share/prims/jni.cpp:3672 > #10 0x7fa7a11277d5 in InitializeJVM src/java.base/share/native/libjli/java.c:1550 > #11 0x7fa7a11277d5 in JavaMain src/java.base/share/native/libjli/java.c:491 > #12 0x7fa7a1130f68 in ThreadJavaMain src/java.base/unix/native/libjli/java_md.c:653 > #13 0x7fa7a10df6e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 2f8d3c2d0f4d7888c2598d2ff6356537f5708a73) > #14 0x7fa7a071550e in clone (/lib64/libc.so.6+0x11850e) (BuildId: f732026552f6adff988b338e92d466bc81a01c37) This pull request has now been integrated. Changeset: 880c6b42 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/880c6b42ba74884690daa5c23f6605876f29aece Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8333178: ubsan: jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/19557 From kevinw at openjdk.org Thu Jun 6 08:21:44 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 6 Jun 2024 08:21:44 GMT Subject: RFR: 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect" In-Reply-To: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> References: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> Message-ID: On Thu, 6 Jun 2024 02:12:11 GMT, Alex Menkov wrote: > The fix updates com/sun/tools/attach/BasicTests.java to listen and connect using loopback addresses > > Testing: run the test on all Oracle-supported platforms Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19571#pullrequestreview-2101206359 From cjplummer at openjdk.org Thu Jun 6 14:40:44 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 6 Jun 2024 14:40:44 GMT Subject: RFR: 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect" In-Reply-To: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> References: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> Message-ID: On Thu, 6 Jun 2024 02:12:11 GMT, Alex Menkov wrote: > The fix updates com/sun/tools/attach/BasicTests.java to listen and connect using loopback addresses > > Testing: run the test on all Oracle-supported platforms You have an interesting warning about the fixVersion being 24 but .jcheck/conf is 23. I'm not sure, but you may need to merge with the current master in order to avoid a 23 backport being created. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19571#issuecomment-2152706365 From cjplummer at openjdk.org Thu Jun 6 14:49:45 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 6 Jun 2024 14:49:45 GMT Subject: RFR: 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect" In-Reply-To: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> References: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> Message-ID: <7Sfzhp2FBo8HkS9l_Hjj0jbicJ59z-jHMVMjNkXt4pw=.9c312e6e-1ecf-4b0c-b3ce-58c3229ff489@github.com> On Thu, 6 Jun 2024 02:12:11 GMT, Alex Menkov wrote: > The fix updates com/sun/tools/attach/BasicTests.java to listen and connect using loopback addresses > > Testing: run the test on all Oracle-supported platforms Actually it looks like .jcheck/conf in master has not been updated to 24 yet. Not sure if once it is updated this warning will automatically go away or if you will also have to merge with master. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19571#issuecomment-2152727812 From duke at openjdk.org Thu Jun 6 15:56:07 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Thu, 6 Jun 2024 15:56:07 GMT Subject: RFR: 8332400: isspace argument should be a valid unsigned char Message-ID: ### Summary This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html). `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. **Testing** - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly. - tier1 ------------- Commit messages: - Prevent undefined behaviour when calling isspace. Changes: https://git.openjdk.org/jdk/pull/19567/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19567&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332400 Stats: 31 lines in 8 files changed: 20 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/19567.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19567/head:pull/19567 PR: https://git.openjdk.org/jdk/pull/19567 From liach at openjdk.org Thu Jun 6 17:51:44 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 6 Jun 2024 17:51:44 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote: > Hi all, > This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. > > Thanks. Changes requested by liach (Author). test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1: > 1: # This file change is dubious: 1. It does not have any trailing whitespace that can fail the skara checks. 2. If the duplicate blank lines in the end of this Makefile is indeed problematic (as fixed here), please fix the only other occasion in the JDK, which is the Makefile in the parent directory. (Checked with `\n$^\n$\Z` pattern in all Makefiles) Recommended actions: Either 1. Revert changes in this file; 2. Also update `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` to remove the trailing blank line. ------------- PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2102735910 PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1629981196 From cslucas at openjdk.org Thu Jun 6 19:15:55 2024 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 6 Jun 2024 19:15:55 GMT Subject: RFR: 8333566: Remove unused methods Message-ID: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. ------------- Commit messages: - Temove trailing whitespace. - Removing unused methods in aarch64 - Merge remote-tracking branch 'origin/main' into unused-methods - Merge remote-tracking branch 'origin/main' into unused-methods - Remove defined but unused methods. Changes: https://git.openjdk.org/jdk/pull/19550/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19550&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333566 Stats: 1398 lines in 139 files changed: 1 ins; 1290 del; 107 mod Patch: https://git.openjdk.org/jdk/pull/19550.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19550/head:pull/19550 PR: https://git.openjdk.org/jdk/pull/19550 From amitkumar at openjdk.org Thu Jun 6 19:15:56 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 6 Jun 2024 19:15:56 GMT Subject: RFR: 8333566: Remove unused methods In-Reply-To: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> References: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Message-ID: On Tue, 4 Jun 2024 20:51:52 GMT, Cesar Soares Lucas wrote: > Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. > > Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 > > Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. src/hotspot/cpu/s390/vm_version_s390.hpp line 516: > 514: static void set_has_CompareTrap() { _features[0] |= GnrlInstrExtFacilityMask; } > 515: static void set_has_RelativeLoadStore() { _features[0] |= GnrlInstrExtFacilityMask; } > 516: static void set_has_GnrlInstrExtensions() { _features[0] |= GnrlInstrExtFacilityMask; } I know this PR is still in draft state. Just a thought: I would like to keep the methods in `vm_version_s390.hpp` file for now. I'm planning to remove the checks applicable to older hardware. So it would be better, If I clean these methods as a part of that PR :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19550#discussion_r1628627936 From cslucas at openjdk.org Thu Jun 6 19:15:56 2024 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 6 Jun 2024 19:15:56 GMT Subject: RFR: 8333566: Remove unused methods In-Reply-To: References: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Message-ID: <_Nv0J1Vf3F9z9S9N-eKLMy0JOOt9KHBa7l6D7OepBjc=.9a24926d-33ec-469d-bdee-5c0efed17fb5@github.com> On Thu, 6 Jun 2024 01:28:00 GMT, Amit Kumar wrote: >> Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. >> >> Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 >> >> Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. > > src/hotspot/cpu/s390/vm_version_s390.hpp line 516: > >> 514: static void set_has_CompareTrap() { _features[0] |= GnrlInstrExtFacilityMask; } >> 515: static void set_has_RelativeLoadStore() { _features[0] |= GnrlInstrExtFacilityMask; } >> 516: static void set_has_GnrlInstrExtensions() { _features[0] |= GnrlInstrExtFacilityMask; } > > I know this PR is still in draft state. Just a thought: I would like to keep the methods in `vm_version_s390.hpp` file for now. I'm planning to remove the checks applicable to older hardware. So it would be better, If I clean these methods as a part of that PR :-) Sounds good to me! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19550#discussion_r1629762442 From amitkumar at openjdk.org Thu Jun 6 19:23:46 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 6 Jun 2024 19:23:46 GMT Subject: RFR: 8333566: Remove unused methods In-Reply-To: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> References: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Message-ID: On Tue, 4 Jun 2024 20:51:52 GMT, Cesar Soares Lucas wrote: > Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. > > Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 > > Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. src/hotspot/cpu/s390/vm_version_s390.hpp line 516: > 514: static void set_has_CompareTrap() { _features[0] |= GnrlInstrExtFacilityMask; } > 515: static void set_has_RelativeLoadStore() { _features[0] |= GnrlInstrExtFacilityMask; } > 516: static void set_has_ProcessorAssist() { _features[0] |= ProcessorAssistMask; } This looks incorrect; there exist a second definition below; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19550#discussion_r1630102121 From kvn at openjdk.org Thu Jun 6 19:31:48 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 6 Jun 2024 19:31:48 GMT Subject: RFR: 8333566: Remove unused methods In-Reply-To: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> References: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Message-ID: On Tue, 4 Jun 2024 20:51:52 GMT, Cesar Soares Lucas wrote: > Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. > > Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 > > Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. src/hotspot/cpu/x86/macroAssembler_x86.hpp line 992: > 990: // * No condition for this * void ALWAYSINLINE jecxz(Label& L, bool maybe_short = true) { jcc(Assembler::cxz, L, maybe_short); } > 991: > 992: // Short versions of the above These all branch instructions were added recently [#18893](https://github.com/openjdk/jdk/pull/18893) for JDK-8320448 which is not pushed yet. So I will suggest to not remove them. src/hotspot/cpu/x86/vm_version_x86.hpp line 666: > 664: // Feature identification which can be affected by VM settings > 665: // > 666: static bool supports_cpuid() { return _features != 0; } I suggest to not touch this file. Some CPU features could used in a future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19550#discussion_r1630110159 PR Review Comment: https://git.openjdk.org/jdk/pull/19550#discussion_r1630112304 From dholmes at openjdk.org Thu Jun 6 21:24:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Jun 2024 21:24:12 GMT Subject: RFR: 8332400: isspace argument should be a valid unsigned char In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 20:08:10 GMT, Robert Toyonaga wrote: > ### Summary > This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html). `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". > > Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. > > **Testing** > - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly. > - tier1 Sorry I think this is well-intentioned but unnecessary in nearly all cases. If you pass a char there is no potential problem. Only passing an actual int could be a problem. src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 664: > 662: char after_key = line[key_len]; > 663: if (strncmp(line, key, key_len) == 0 > 664: && os::is_space(after_key) != 0 I think this is excessive. The value is a char so cannot be a problem. The only calls to isspace that need checking are those that actually pass an int, and even then there could be adequate safeguards in place. src/hotspot/os/linux/os_linux.cpp line 1356: > 1354: if (s) { > 1355: // Skip blank chars > 1356: do { s++; } while (s && os::is_space(*s)); Again not needed. ------------- PR Review: https://git.openjdk.org/jdk/pull/19567#pullrequestreview-2103234054 PR Review Comment: https://git.openjdk.org/jdk/pull/19567#discussion_r1630265925 PR Review Comment: https://git.openjdk.org/jdk/pull/19567#discussion_r1630266490 From jpai at openjdk.org Fri Jun 7 01:09:29 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Jun 2024 01:09:29 GMT Subject: RFR: 8333130: MakeJAR2.sh uses hard-coded JDK version [v3] In-Reply-To: References: Message-ID: <_EoVivsJabR8JkXitfVUntzseJSrSX46jELq-1jbSXg=.cc459cf5-7fb4-42aa-bfbc-2e649659cf39@github.com> On Tue, 4 Jun 2024 01:30:55 GMT, Jaikiran Pai wrote: >> test/jdk/java/lang/instrument/RetransformApp.java line 81: >> >>> 79: final OutputAnalyzer oa = ProcessTools.executeTestJava( >>> 80: "--enable-preview", // due to usage of ClassFile API PreviewFeature in the agent >>> 81: "-XX:+UnlockDiagnosticVMOptions", "-XX:-CheckIntrinsics", >> >> This `-XX` flags were not present for this test (and I don't think they are needed for NativeMethodPrefix test too) > > You are right - it was a copy/paste error on my part to have include these flags for the `RetransformApp`. Based on your suggestion, I have removed them from the other test too. The tests continue to pass. It turns out we do need the `-XX:-CheckIntrinsics` for the `NativeMethodPrefix` test. Without that we have a test failure in a higher tier https://bugs.openjdk.org/browse/JDK-8333756. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19495#discussion_r1630482492 From stuefe at openjdk.org Fri Jun 7 06:10:12 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 7 Jun 2024 06:10:12 GMT Subject: RFR: 8332400: isspace argument should be a valid unsigned char In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 21:21:23 GMT, David Holmes wrote: >> ### Summary >> This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html). `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". >> >> Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. >> >> **Testing** >> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly. >> - tier1 > > Sorry I think this is well-intentioned but unnecessary in nearly all cases. If you pass a char there is no potential problem. Only passing an actual int could be a problem. @dholmes-ora > Sorry I think this is well-intentioned but unnecessary in nearly all cases. If you pass a char there is no potential problem. Only passing an actual int could be a problem. Note that the issue was motivated by an Oracle engineer complaining about me using isspace on a char. That caused me to look up its behavior. Recently, we seem intent on eliminating UB, so why not. That said, I agree that we probably don't need the wrapper. And casting to int feels awkward. I propose - input from trusted sources, e.g. proc fs, don't need casting - input from other sources should be casted to unsigned char (see recommendation here: https://en.cppreference.com/w/cpp/string/byte/isspace "To use these functions safely with plain chars (or signed chars), the argument should first be converted to unsigned char") ------------- PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2154146793 From syan at openjdk.org Fri Jun 7 07:29:39 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Jun 2024 07:29:39 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: References: Message-ID: > Hi all, > This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. > > Thanks. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19537/files - new: https://git.openjdk.org/jdk/pull/19537/files/0d2be363..e80b98da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19537&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19537&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19537.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19537/head:pull/19537 PR: https://git.openjdk.org/jdk/pull/19537 From syan at openjdk.org Fri Jun 7 07:29:39 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Jun 2024 07:29:39 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: References: Message-ID: <9rsVuFT4B5tg9CFepE9m-CsdBHMsfEPu4pWsWxZhkCk=.f3db4eff-1335-4c4f-a7d6-5970c4a544f7@github.com> On Thu, 6 Jun 2024 17:49:08 GMT, Chen Liang wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile > > test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1: > >> 1: # > > This file change is dubious: > 1. It does not have any trailing whitespace that can fail the skara checks. > 2. If the duplicate blank lines in the end of this Makefile is indeed problematic (as fixed here), please fix the only other occasion in the JDK, which is the Makefile in the parent directory. (Checked with `\n$^\n$\Z` pattern in all Makefiles) > > Recommended actions: Either > 1. Revert changes in this file; > 2. Also update `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` to remove the trailing blank line. Thanks for the suggestion, the trailing blank line of `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` has been removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1630767547 From jpai at openjdk.org Fri Jun 7 10:39:39 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Jun 2024 10:39:39 GMT Subject: RFR: 8333756: java/lang/instrument/NativeMethodPrefixApp.java failed due to missing intrinsic Message-ID: Can I please get a review of this test-only change which fixes an issue that was introduced due to the refactoring that we did in https://bugs.openjdk.org/browse/JDK-8333130? This PR addresses the failure reported in https://bugs.openjdk.org/browse/JDK-8333756. The `NativeMethodPrefixApp` test uses a `javaagent` `NativeMethodPrefixAgent` which modifies the name of the native methods using the `java.lang.instrument.Instrumentation` instance: public static void premain (String agentArgs, Instrumentation instArg) { inst = instArg; System.out.println("Premain"); ... instArg.setNativeMethodPrefix(t0, "wrapped_tr0_"); instArg.setNativeMethodPrefix(t1, "wrapped_tr1_"); instArg.setNativeMethodPrefix(t2, "wrapped_tr2_"); The Hotspot VM allows for methods on a class to be annotated with an (VM internal) `jdk.internal.vm.annotation.IntrinsicCandidate` annotation. When a class that contains any methods that are annotated with `@IntrinsicCandidate` is loaded, the VM checks that the corresponding method(s) have an intrinsic available. It uses the method name to check for the presence of the intrinsic. In the absence of an intrinsic for a `@IntrinsicCandidate` method, the VM throws an error and exits. This behaviour is controlled by the `-XX:+/-CheckIntrinsics` option. By default that option is enabled, implying that an error will be thrown if the intrinsic isn't found. In the case where/when this test fails, it so happens that the JVM loads a class which has a `@IntrinsicCandidate` on a `native` Java method. For example, on the failing host, I could see this class loading sequence: tr2: Loading java/util/Date tr1: Loading java/util/Date tr0: Loading java/util/Date tr2: Loading sun/util/calendar/CalendarSystem tr1: Loading sun/util/calendar/CalendarSystem tr0: Loading sun/util/calendar/CalendarSystem tr2: Loading sun/util/calendar/CalendarSystem$GregorianHolder tr1: Loading sun/util/calendar/CalendarSystem$GregorianHolder tr0: Loading sun/util/calendar/CalendarSystem$GregorianHolder ... tr2: Loading sun/util/calendar/ZoneInfoFile$Checksum tr1: Loading sun/util/calendar/ZoneInfoFile$Checksum tr0: Loading sun/util/calendar/ZoneInfoFile$Checksum tr2: Loading java/util/zip/Checksum tr1: Loading java/util/zip/Checksum tr0: Loading java/util/zip/Checksum tr2: Loading java/util/zip/CRC32 tr1: Loading java/util/zip/CRC32 tr0: Loading java/util/zip/CRC32 Method [java.util.zip.CRC32.wrapped_tr2_update(II)I] is annotated with @IntrinsicCandidate, but no compiler intrinsic is defined for the method. Exiting. So a class loading sequence lead to loading of the `java.util.zip.CRC32` class which has a `native` method annotated with `@IntrinsicCandidate`: @IntrinsicCandidate private static native int update(int crc, int b); Since the `NativeMethodPrefixAgent` modifies the native method names, the VM thus cannot find a matching intrinsic and thus fails with that error. The reason why this wasn't uncovered during the testing of changes for https://bugs.openjdk.org/browse/JDK-8333130 is purely incidental. Even now, the test fails only intermittently. That's because it's only triggered if some class with a `native` method with `@IntrinsicCandidate` gets loadded. As an additional reference, I also found https://bugs.openjdk.org/browse/JDK-8151100 which is when the `-XX:-CheckIntrinsics` was introduced in this test and that too explains this same issue. The commit in this PR fixes the issue by reintroducing the `"-XX:+UnlockDiagnosticVMOptions", "-XX:-CheckIntrinsics"` when launching the test program. Additionally, the test program now intentionally loads the `CRC32` class to make the test more deterministic for cases like these and to prevent any accidental removal of the `-XX:-CheckIntrinsics` in future. tier testing is currently in progress with this change in our CI. ------------- Commit messages: - 8333756: java/lang/instrument/NativeMethodPrefixApp.java failed due to missing intrinsic Changes: https://git.openjdk.org/jdk/pull/19595/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19595&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333756 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19595.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19595/head:pull/19595 PR: https://git.openjdk.org/jdk/pull/19595 From liach at openjdk.org Fri Jun 7 10:58:13 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 7 Jun 2024 10:58:13 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote: >> Hi all, >> This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. >> >> Thanks. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile Thank you for the fix. ------------- Marked as reviewed by liach (Author). PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2104241367 From lucy at openjdk.org Fri Jun 7 11:14:23 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 7 Jun 2024 11:14:23 GMT Subject: RFR: 8333566: Remove unused methods In-Reply-To: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> References: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Message-ID: On Tue, 4 Jun 2024 20:51:52 GMT, Cesar Soares Lucas wrote: > Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. > > Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 > > Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. I feel very uncomfortable with this PR, at least as far as s390 is concerned. Many of the methods now set to be removed have been implemented with "implementation completeness" in mind. Not being used currently does not allow the implication of being obsolete. The approach on s390 has always been to provide support for potentially useful new instructions once they become available. Later exploitation can then focus on the use, without bloating the PR with low-level assembler* declarations. There are a few exceptions, though. One is the code around `_atomic_memory_operation_lock`. That seems to be a leftover which simply was forgotten. Same seems true for `pd_relocate_CodeBlob` ------------- Changes requested by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19550#pullrequestreview-2104286082 From jsjolen at openjdk.org Fri Jun 7 11:52:12 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 7 Jun 2024 11:52:12 GMT Subject: RFR: 8333566: Remove unused methods In-Reply-To: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> References: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Message-ID: On Tue, 4 Jun 2024 20:51:52 GMT, Cesar Soares Lucas wrote: > Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. > > Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 > > Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. Hi, Removing dead code is great, but it has to be done with reasoning behind it and preferably in smaller batches, so as to be reviewable. I also don't understand why you comment out tests. If you can make these into smaller and more localized PRs, then I'll be happy to take a look if I think I'm the right person to review it. All the best, Johan ------------- PR Comment: https://git.openjdk.org/jdk/pull/19550#issuecomment-2154676801 From eosterlund at openjdk.org Fri Jun 7 12:15:18 2024 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 7 Jun 2024 12:15:18 GMT Subject: RFR: 8333566: Remove unused methods In-Reply-To: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> References: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Message-ID: On Tue, 4 Jun 2024 20:51:52 GMT, Cesar Soares Lucas wrote: > Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. > > Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 > > Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. Some parts of the code, such as the assemblers, can be seen as tools that we have in our shed so that we can write other powerful code. If you have a shed full of tools, then naturally you can go through the shed and get rid of the tools we don't seem to currently use. Who needs a spade anyway? Nobody has used that spade for a year! Except that eventually, the day always comes when you need a spade. Since you have now thrown away the only spade in the shed, you will find yourself with the option to either 1) try to make do with a trowel, which is horrible but might work as a hack. Or 2) you have to make a new spade yet again. And no, we can't buy a ready made spade. It can be very annoying when you have what would seemingly be a trivial patch, but then you find out you won the lottery and you are apparently the first person in a while that needed a testl with a memory operand comparing against a 32 bit immediate, and have to go and read ISA manuals to figure out how to encode this thing correctly. It adds a large amount of extra work to add support for something that we should be able to take for granted. I'm not a big fan of throwing away all the tools we have in the shed just because they haven't been used in a while. I don't want to dig my next hole with a trowel, nor do I want to build a new spade that we already have. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19550#issuecomment-2154709857 From syan at openjdk.org Fri Jun 7 12:31:13 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Jun 2024 12:31:13 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote: >> Hi all, >> This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. >> >> Thanks. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile Thanks all for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2154735598 From jwaters at openjdk.org Fri Jun 7 12:40:13 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 7 Jun 2024 12:40:13 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: References: Message-ID: <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com> On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote: >> Hi all, >> This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. >> >> Thanks. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile Marked as reviewed by jwaters (Committer). test/jdk/java/rmi/reliability/benchmark/bench/Makefile line 50: > 48: clean: > 49: rm -f *.class .classes > 50: Hmm, shouldn't this newline at EOF be kept? Asking @ all the people who've reviewed this so far, no need to change it just yet ------------- PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2104439647 PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631140418 From jwaters at openjdk.org Fri Jun 7 12:40:14 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 7 Jun 2024 12:40:14 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: <9rsVuFT4B5tg9CFepE9m-CsdBHMsfEPu4pWsWxZhkCk=.f3db4eff-1335-4c4f-a7d6-5970c4a544f7@github.com> References: <9rsVuFT4B5tg9CFepE9m-CsdBHMsfEPu4pWsWxZhkCk=.f3db4eff-1335-4c4f-a7d6-5970c4a544f7@github.com> Message-ID: On Fri, 7 Jun 2024 07:26:39 GMT, SendaoYan wrote: >> test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1: >> >>> 1: # >> >> This file change is dubious: >> 1. It does not have any trailing whitespace that can fail the skara checks. >> 2. If the duplicate blank lines in the end of this Makefile is indeed problematic (as fixed here), please fix the only other occasion in the JDK, which is the Makefile in the parent directory. (Checked with `\n$^\n$\Z` pattern in all Makefiles) >> >> Recommended actions: Either >> 1. Revert changes in this file; >> 2. Also update `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` to remove the trailing blank line. > > Thanks for the suggestion, the trailing blank line of `test/jdk/java/rmi/reliability/benchmark/bench/Makefile` has been removed. Hmm, I'm inclined to keep the newlines at the EOF for both, what do the rest of you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631140457 From erikj at openjdk.org Fri Jun 7 12:51:16 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 7 Jun 2024 12:51:16 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: References: Message-ID: <_nZVUUX4_1rgtwNp8seD0YoqxnZLtORfjVz9m0VFNrQ=.315a1692-b84c-4eed-95db-3843f438431a@github.com> On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote: >> Hi all, >> This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. >> >> Thanks. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19537#pullrequestreview-2104463763 From erikj at openjdk.org Fri Jun 7 12:51:17 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 7 Jun 2024 12:51:17 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com> References: <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com> Message-ID: <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com> On Fri, 7 Jun 2024 12:37:48 GMT, Julian Waters wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile > > test/jdk/java/rmi/reliability/benchmark/bench/Makefile line 50: > >> 48: clean: >> 49: rm -f *.class .classes >> 50: > > Hmm, shouldn't this newline at EOF be kept? Asking @ all the people who've reviewed this so far, no need to change it just yet No, it's an extra newline. A file should end with a newline but one is enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631152127 From liach at openjdk.org Fri Jun 7 12:56:19 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 7 Jun 2024 12:56:19 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com> References: <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com> <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com> Message-ID: On Fri, 7 Jun 2024 12:47:39 GMT, Erik Joelsson wrote: >> test/jdk/java/rmi/reliability/benchmark/bench/Makefile line 50: >> >>> 48: clean: >>> 49: rm -f *.class .classes >>> 50: >> >> Hmm, shouldn't this newline at EOF be kept? Asking @ all the people who've reviewed this so far, no need to change it just yet > > No, it's an extra newline. A file should end with a newline but one is enough. As confusing as they are, unfortunately GitHub UI does not render extra trailing newlines. This is the only one I could find with grepWin. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631159094 From sgehwolf at openjdk.org Fri Jun 7 12:59:26 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 7 Jun 2024 12:59:26 GMT Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container [v4] In-Reply-To: References: Message-ID: > 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? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'master' into jdk-8261242-is-containerized-fix - Add doc for mountinfo scanning. - Unify naming of variables - Merge branch 'master' into jdk-8261242-is-containerized-fix - Merge branch 'master' into jdk-8261242-is-containerized-fix - jcheck fixes - Fix tests - Implement Metrics.isContainerized() - Some clean-up - Drop cgroups testing on plain Linux - ... and 3 more: https://git.openjdk.org/jdk/compare/40b2fbd8...02884c70 ------------- Changes: https://git.openjdk.org/jdk/pull/18201/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18201&range=03 Stats: 406 lines in 19 files changed: 301 ins; 78 del; 27 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 syan at openjdk.org Fri Jun 7 13:04:18 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Jun 2024 13:04:18 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: References: <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com> <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com> Message-ID: On Fri, 7 Jun 2024 12:53:46 GMT, Chen Liang wrote: >> No, it's an extra newline. A file should end with a newline but one is enough. > > As confusing as they are, unfortunately GitHub UI does not render extra trailing newlines. This is the only one I could find with grepWin. I find the extra trailing newlines through below shell command: for i in `find . -iname "Makefile*" | sed "/./build/d"` ; do tail -n 2 $i | grep -c "^$" | grep -q "^1$" ; if [[ 0 -eq $? ]] ; then echo $i ; fi ; done There are only two files has been found: ./test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile ./test/jdk/java/rmi/reliability/benchmark/bench/Makefile ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631168243 From jwilhelm at openjdk.org Fri Jun 7 13:20:13 2024 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Fri, 7 Jun 2024 13:20:13 GMT Subject: RFR: 8333566: Remove unused methods In-Reply-To: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> References: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Message-ID: On Tue, 4 Jun 2024 20:51:52 GMT, Cesar Soares Lucas wrote: > Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. > > Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 > > Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. This seems to me like a classic case of not reading the instructions. @JohnTortugo, please read the [OpenJDK Developers' Guide](https://openjdk.org/guide/) before posting a PR with a huge change. There are sections in there that covers this exact case. The section [Contributing to an OpenJDK Project](https://openjdk.org/guide/#contributing-to-an-openjdk-project) really is mandatory reading before doing anything in OpenJDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19550#issuecomment-2154820179 From jwaters at openjdk.org Fri Jun 7 13:39:19 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 7 Jun 2024 13:39:19 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: References: <4cHhBehMcwLWREUH2qT-iK-uUHwJ0x5bMhyUnwL2gq8=.b9b607ff-f8e3-4e40-8ed7-4096d7e5ce50@github.com> <5YlIH2IloSdbb0dSta1qr9sb2e5Uyred24oKrMTvZFE=.b99a6c68-32f1-43d7-89f7-5205129f8e1f@github.com> Message-ID: On Fri, 7 Jun 2024 13:01:15 GMT, SendaoYan wrote: >> As confusing as they are, unfortunately GitHub UI does not render extra trailing newlines. This is the only one I could find with grepWin. > > I find the extra trailing newlines through below shell command: > > for i in `find . -iname "Makefile*" | sed "/./build/d"` ; do tail -n 2 $i | grep -c "^$" | grep -q "^1$" ; if [[ 0 -eq $? ]] ; then echo $i ; fi ; done > > > There are only two files has been found: > > ./test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile > ./test/jdk/java/rmi/reliability/benchmark/bench/Makefile Ah, I had not realized that there was more than 1 newline. GitHub's UI confused me here, so we're good to go ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19537#discussion_r1631213656 From syan at openjdk.org Fri Jun 7 13:39:20 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Jun 2024 13:39:20 GMT Subject: Integrated: 8333477: Delete extra empty spaces in Makefiles In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote: > Hi all, > This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. > > Thanks. This pull request has now been integrated. Changeset: d130d2f4 Author: SendaoYan Committer: Julian Waters URL: https://git.openjdk.org/jdk/commit/d130d2f4f46d37a2b924343de19d012c129b0a55 Stats: 11 lines in 5 files changed: 0 ins; 2 del; 9 mod 8333477: Delete extra empty spaces in Makefiles Reviewed-by: erikj, chagedorn, liach, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/19537 From syan at openjdk.org Fri Jun 7 14:17:19 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Jun 2024 14:17:19 GMT Subject: RFR: 8333477: Delete extra empty spaces in Makefiles [v2] In-Reply-To: References: Message-ID: <5PwXrAonDGIth_VkfWPZMDl-XFCPTLAIRunMUPsp_4g=.45fa1560-bcfb-4ac0-9bd7-03734547b09d@github.com> On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote: >> Hi all, >> This PR several extra empty spaces and extra empty lines in several Makefiles. It's trivial fix, no risk. >> >> Thanks. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > delete extra empty trailing blank line in test/jdk/java/rmi/reliability/benchmark/bench/Makefile Thanks all for the review and sponsor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19537#issuecomment-2154937099 From lmesnik at openjdk.org Fri Jun 7 17:46:13 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Jun 2024 17:46:13 GMT Subject: RFR: 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect" In-Reply-To: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> References: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> Message-ID: On Thu, 6 Jun 2024 02:12:11 GMT, Alex Menkov wrote: > The fix updates com/sun/tools/attach/BasicTests.java to listen and connect using loopback addresses > > Testing: run the test on all Oracle-supported platforms Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19571#pullrequestreview-2105081330 From cslucas at openjdk.org Fri Jun 7 19:19:19 2024 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 7 Jun 2024 19:19:19 GMT Subject: RFR: 8333566: Remove unused methods In-Reply-To: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> References: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Message-ID: On Tue, 4 Jun 2024 20:51:52 GMT, Cesar Soares Lucas wrote: > Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. > > Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 > > Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. Closing this as not relevant. Thank you for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19550#issuecomment-2155383826 From cslucas at openjdk.org Fri Jun 7 19:19:19 2024 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 7 Jun 2024 19:19:19 GMT Subject: Withdrawn: 8333566: Remove unused methods In-Reply-To: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> References: <3vCVNjjgFzEw_YgoboTLXemBuzwht9uEeZxC8yg5Zog=.a7600184-c4ca-4a93-8b76-74df7bdff405@github.com> Message-ID: On Tue, 4 Jun 2024 20:51:52 GMT, Cesar Soares Lucas wrote: > Please, consider this patch to remove unused methods from the code base. To the best of my knowledge, these methods are only defined but never used. > > Here is a list with names of delete methods: https://gist.github.com/JohnTortugo/fccc29781a1b584c03162aa4e160e874 > > Tested with Linux x86_64 tier1-4, GHA, and only cross building to other platforms. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/19550 From amenkov at openjdk.org Fri Jun 7 19:32:13 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Jun 2024 19:32:13 GMT Subject: RFR: 8333756: java/lang/instrument/NativeMethodPrefixApp.java failed due to missing intrinsic In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 10:31:22 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which fixes an issue that was introduced due to the refactoring that we did in https://bugs.openjdk.org/browse/JDK-8333130? This PR addresses the failure reported in https://bugs.openjdk.org/browse/JDK-8333756. > > The `NativeMethodPrefixApp` test uses a `javaagent` `NativeMethodPrefixAgent` which modifies the name of the native methods using the `java.lang.instrument.Instrumentation` instance: > > public static void premain (String agentArgs, Instrumentation instArg) { > inst = instArg; > System.out.println("Premain"); > > ... > instArg.setNativeMethodPrefix(t0, "wrapped_tr0_"); > instArg.setNativeMethodPrefix(t1, "wrapped_tr1_"); > instArg.setNativeMethodPrefix(t2, "wrapped_tr2_"); > > > The Hotspot VM allows for methods on a class to be annotated with an (VM internal) `jdk.internal.vm.annotation.IntrinsicCandidate` annotation. When a class that contains any methods that are annotated with `@IntrinsicCandidate` is loaded, the VM checks that the corresponding method(s) have an intrinsic available. It uses the method name to check for the presence of the intrinsic. In the absence of an intrinsic for a `@IntrinsicCandidate` method, the VM throws an error and exits. This behaviour is controlled by the `-XX:+/-CheckIntrinsics` option. By default that option is enabled, implying that an error will be thrown if the intrinsic isn't found. > > In the case where/when this test fails, it so happens that the JVM loads a class which has a `@IntrinsicCandidate` on a `native` Java method. For example, on the failing host, I could see this class loading sequence: > > > tr2: Loading java/util/Date > tr1: Loading java/util/Date > tr0: Loading java/util/Date > tr2: Loading sun/util/calendar/CalendarSystem > tr1: Loading sun/util/calendar/CalendarSystem > tr0: Loading sun/util/calendar/CalendarSystem > tr2: Loading sun/util/calendar/CalendarSystem$GregorianHolder > tr1: Loading sun/util/calendar/CalendarSystem$GregorianHolder > tr0: Loading sun/util/calendar/CalendarSystem$GregorianHolder > ... > tr2: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr1: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr0: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr2: Loading java/util/zip/Checksum > tr1: Loading java/util/zip/Checksum > tr0: Loading java/util/zip/Checksum > tr2: Loading java/util/zip/CRC32 > tr1: Loading java/util/zip/CRC32 > tr0: Loading java/util/zip/CRC32 > Method [java.util.zip.CRC32.wrapped_tr2_update(II)I] is annotated with @IntrinsicCandidate, but no... Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19595#pullrequestreview-2105238174 From amenkov at openjdk.org Fri Jun 7 19:33:18 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Jun 2024 19:33:18 GMT Subject: Integrated: 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect" In-Reply-To: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> References: <79T_TxahXD5hjWnQ-B9vcqXQG9j1M0nxiclg7WZHe3s=.a00e117b-18ab-499c-a401-9fd776b40c44@github.com> Message-ID: On Thu, 6 Jun 2024 02:12:11 GMT, Alex Menkov wrote: > The fix updates com/sun/tools/attach/BasicTests.java to listen and connect using loopback addresses > > Testing: run the test on all Oracle-supported platforms This pull request has now been integrated. Changeset: 17bd483f Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/17bd483ff01e463cef45824f0c1296a8f3e782c8 Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect" Reviewed-by: sspitsyn, kevinw, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/19571 From cjplummer at openjdk.org Fri Jun 7 20:47:34 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 7 Jun 2024 20:47:34 GMT Subject: RFR: 8333813: Seviceability tests fail due to stderr containing Temporarily processing option UseNotificationThread Message-ID: Allow warning messages such as the following to appear in stderr: Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option UseNotificationThread; support is scheduled for removal in 24.0 Tested by running CI tier5, which reproduced the issue. ------------- Commit messages: - Allow warning messages about obsolete flags Changes: https://git.openjdk.org/jdk/pull/19606/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19606&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333813 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19606.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19606/head:pull/19606 PR: https://git.openjdk.org/jdk/pull/19606 From amenkov at openjdk.org Fri Jun 7 22:09:16 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Jun 2024 22:09:16 GMT Subject: RFR: 8333813: Seviceability tests fail due to stderr containing Temporarily processing option UseNotificationThread In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 19:56:03 GMT, Chris Plummer wrote: > Allow warning messages such as the following to appear in stderr: > > Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option UseNotificationThread; support is scheduled for removal in 24.0 > > Tested by running CI tier5, which reproduced the issue. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19606#pullrequestreview-2105446403 From sspitsyn at openjdk.org Sat Jun 8 00:31:13 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 8 Jun 2024 00:31:13 GMT Subject: RFR: 8333813: Seviceability tests fail due to stderr containing Temporarily processing option UseNotificationThread In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 19:56:03 GMT, Chris Plummer wrote: > Allow warning messages such as the following to appear in stderr: > > Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option UseNotificationThread; support is scheduled for removal in 24.0 > > Tested by running CI tier5, which reproduced the issue. Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19606#pullrequestreview-2105518837 From dholmes at openjdk.org Sat Jun 8 02:24:21 2024 From: dholmes at openjdk.org (David Holmes) Date: Sat, 8 Jun 2024 02:24:21 GMT Subject: RFR: 8333813: Seviceability tests fail due to stderr containing Temporarily processing option UseNotificationThread In-Reply-To: References: Message-ID: <4UbTpavuQ4MaYscL9WiymmJ253qD4TCu1hQJ-ZOhOPQ=.99c4f8ea-3bf4-4c07-b1e0-8de7741ef72c@github.com> On Fri, 7 Jun 2024 19:56:03 GMT, Chris Plummer wrote: > Allow warning messages such as the following to appear in stderr: > > Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option UseNotificationThread; support is scheduled for removal in 24.0 > > Tested by running CI tier5, which reproduced the issue. test/lib/jdk/test/lib/process/OutputAnalyzer.java line 187: > 185: * If stderr was not empty > 186: */ > 187: public OutputAnalyzer stderrShouldBeEmptyIgnoreDeprecatedWarnings() { Maybe this should be renamed to reflect that it is about VM option warnings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19606#discussion_r1631825632 From jpai at openjdk.org Sat Jun 8 06:22:20 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 8 Jun 2024 06:22:20 GMT Subject: RFR: 8333756: java/lang/instrument/NativeMethodPrefixApp.java failed due to missing intrinsic In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 10:31:22 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which fixes an issue that was introduced due to the refactoring that we did in https://bugs.openjdk.org/browse/JDK-8333130? This PR addresses the failure reported in https://bugs.openjdk.org/browse/JDK-8333756. > > The `NativeMethodPrefixApp` test uses a `javaagent` `NativeMethodPrefixAgent` which modifies the name of the native methods using the `java.lang.instrument.Instrumentation` instance: > > public static void premain (String agentArgs, Instrumentation instArg) { > inst = instArg; > System.out.println("Premain"); > > ... > instArg.setNativeMethodPrefix(t0, "wrapped_tr0_"); > instArg.setNativeMethodPrefix(t1, "wrapped_tr1_"); > instArg.setNativeMethodPrefix(t2, "wrapped_tr2_"); > > > The Hotspot VM allows for methods on a class to be annotated with an (VM internal) `jdk.internal.vm.annotation.IntrinsicCandidate` annotation. When a class that contains any methods that are annotated with `@IntrinsicCandidate` is loaded, the VM checks that the corresponding method(s) have an intrinsic available. It uses the method name to check for the presence of the intrinsic. In the absence of an intrinsic for a `@IntrinsicCandidate` method, the VM throws an error and exits. This behaviour is controlled by the `-XX:+/-CheckIntrinsics` option. By default that option is enabled, implying that an error will be thrown if the intrinsic isn't found. > > In the case where/when this test fails, it so happens that the JVM loads a class which has a `@IntrinsicCandidate` on a `native` Java method. For example, on the failing host, I could see this class loading sequence: > > > tr2: Loading java/util/Date > tr1: Loading java/util/Date > tr0: Loading java/util/Date > tr2: Loading sun/util/calendar/CalendarSystem > tr1: Loading sun/util/calendar/CalendarSystem > tr0: Loading sun/util/calendar/CalendarSystem > tr2: Loading sun/util/calendar/CalendarSystem$GregorianHolder > tr1: Loading sun/util/calendar/CalendarSystem$GregorianHolder > tr0: Loading sun/util/calendar/CalendarSystem$GregorianHolder > ... > tr2: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr1: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr0: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr2: Loading java/util/zip/Checksum > tr1: Loading java/util/zip/Checksum > tr0: Loading java/util/zip/Checksum > tr2: Loading java/util/zip/CRC32 > tr1: Loading java/util/zip/CRC32 > tr0: Loading java/util/zip/CRC32 > Method [java.util.zip.CRC32.wrapped_tr2_update(II)I] is annotated with @IntrinsicCandidate, but no... tier1 through tier6 testing completed without related issues with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19595#issuecomment-2155833037 From cjplummer at openjdk.org Sat Jun 8 06:56:11 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 8 Jun 2024 06:56:11 GMT Subject: RFR: 8333813: Seviceability tests fail due to stderr containing Temporarily processing option UseNotificationThread In-Reply-To: <4UbTpavuQ4MaYscL9WiymmJ253qD4TCu1hQJ-ZOhOPQ=.99c4f8ea-3bf4-4c07-b1e0-8de7741ef72c@github.com> References: <4UbTpavuQ4MaYscL9WiymmJ253qD4TCu1hQJ-ZOhOPQ=.99c4f8ea-3bf4-4c07-b1e0-8de7741ef72c@github.com> Message-ID: On Sat, 8 Jun 2024 02:21:34 GMT, David Holmes wrote: >> Allow warning messages such as the following to appear in stderr: >> >> Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option UseNotificationThread; support is scheduled for removal in 24.0 >> >> Tested by running CI tier5, which reproduced the issue. > > test/lib/jdk/test/lib/process/OutputAnalyzer.java line 187: > >> 185: * If stderr was not empty >> 186: */ >> 187: public OutputAnalyzer stderrShouldBeEmptyIgnoreDeprecatedWarnings() { > > Maybe this should be renamed to reflect that it is about VM option warnings. Possibly. It means updating 15 tests. Also need to come up with a new name. Any suggestions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19606#discussion_r1631916321 From jpai at openjdk.org Sat Jun 8 07:10:11 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 8 Jun 2024 07:10:11 GMT Subject: RFR: 8333813: Seviceability tests fail due to stderr containing Temporarily processing option UseNotificationThread In-Reply-To: References: <4UbTpavuQ4MaYscL9WiymmJ253qD4TCu1hQJ-ZOhOPQ=.99c4f8ea-3bf4-4c07-b1e0-8de7741ef72c@github.com> Message-ID: On Sat, 8 Jun 2024 06:53:21 GMT, Chris Plummer wrote: >> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 187: >> >>> 185: * If stderr was not empty >>> 186: */ >>> 187: public OutputAnalyzer stderrShouldBeEmptyIgnoreDeprecatedWarnings() { >> >> Maybe this should be renamed to reflect that it is about VM option warnings. > > Possibly. It means updating 15 tests. Also need to come up with a new name. Any suggestions? Hello Chris, given these similary named methods in this class, perhaps we should instead just have one single `stderrShouldBeEmptyIgnoring(...)` method which takes the messages that should be ignored. Something like: public static final String VM_WARNING_MSG = ".* VM warning:.*"; public static final String VM_WARNING_DEPRECATED_MSG = ".* VM warning:.* deprecated.*"; ... public OutputAnalyzer stderrShouldBeEmptyIgnoring(String ignoreMsg, String... additionalIgnoreMsgs) { String stdErrContent = getStderr().replaceAll(ignoreMsg + "\\R", ""); if (additionalIgnoreMsgs != null) { for (String additionalIgnore : additionalIgnoreMsgs) { stdErrContent = getStderr().replaceAll(additionalIgnore + "\\R", ""); } } if (!stdErrContent.isEmpty()) { reportDiagnosticSummary(); throw new RuntimeException("stderr was not empty"); } return this; } We make those private fields in OutputAnalyzer public and have the caller pass them: oa.stderrShouldBeEmptyIgnoring(OutputAnalyzer.VM_WARNING_DEPRECATED_MSG) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19606#discussion_r1631923540 From cjplummer at openjdk.org Sat Jun 8 07:20:11 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 8 Jun 2024 07:20:11 GMT Subject: RFR: 8333813: Seviceability tests fail due to stderr containing Temporarily processing option UseNotificationThread In-Reply-To: References: <4UbTpavuQ4MaYscL9WiymmJ253qD4TCu1hQJ-ZOhOPQ=.99c4f8ea-3bf4-4c07-b1e0-8de7741ef72c@github.com> Message-ID: On Sat, 8 Jun 2024 07:07:41 GMT, Jaikiran Pai wrote: >> Possibly. It means updating 15 tests. Also need to come up with a new name. Any suggestions? > > Hello Chris, given these similary named methods in this class, perhaps we should instead just have one single `stderrShouldBeEmptyIgnoring(...)` method which takes the messages that should be ignored. Something like: > > > public static final String VM_WARNING_MSG = ".* VM warning:.*"; > > public static final String VM_WARNING_DEPRECATED_MSG = ".* VM warning:.* deprecated.*"; > ... > > public OutputAnalyzer stderrShouldBeEmptyIgnoring(String ignoreMsg, String... additionalIgnoreMsgs) { > String stdErrContent = getStderr().replaceAll(ignoreMsg + "\\R", ""); > if (additionalIgnoreMsgs != null) { > for (String additionalIgnore : additionalIgnoreMsgs) { > stdErrContent = stdErrContent.replaceAll(additionalIgnore + "\\R", ""); > } > } > if (!stdErrContent.isEmpty()) { > reportDiagnosticSummary(); > throw new RuntimeException("stderr was not empty"); > } > return this; > } > > > We make those private fields in OutputAnalyzer public and have the caller pass them: > > > oa.stderrShouldBeEmptyIgnoring(OutputAnalyzer.VM_WARNING_DEPRECATED_MSG) That seems like a lot of busy work and over abstraction for trying to solve a rather trivial issue that already has a very simple solution, but maybe could use a better API name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19606#discussion_r1631928608 From jpai at openjdk.org Sat Jun 8 07:38:15 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 8 Jun 2024 07:38:15 GMT Subject: RFR: 8333813: Seviceability tests fail due to stderr containing Temporarily processing option UseNotificationThread In-Reply-To: References: <4UbTpavuQ4MaYscL9WiymmJ253qD4TCu1hQJ-ZOhOPQ=.99c4f8ea-3bf4-4c07-b1e0-8de7741ef72c@github.com> Message-ID: On Sat, 8 Jun 2024 07:17:55 GMT, Chris Plummer wrote: >> Hello Chris, given these similary named methods in this class, perhaps we should instead just have one single `stderrShouldBeEmptyIgnoring(...)` method which takes the messages that should be ignored. Something like: >> >> >> public static final String VM_WARNING_MSG = ".* VM warning:.*"; >> >> public static final String VM_WARNING_DEPRECATED_MSG = ".* VM warning:.* deprecated.*"; >> ... >> >> public OutputAnalyzer stderrShouldBeEmptyIgnoring(String ignoreMsg, String... additionalIgnoreMsgs) { >> String stdErrContent = getStderr().replaceAll(ignoreMsg + "\\R", ""); >> if (additionalIgnoreMsgs != null) { >> for (String additionalIgnore : additionalIgnoreMsgs) { >> stdErrContent = stdErrContent.replaceAll(additionalIgnore + "\\R", ""); >> } >> } >> if (!stdErrContent.isEmpty()) { >> reportDiagnosticSummary(); >> throw new RuntimeException("stderr was not empty"); >> } >> return this; >> } >> >> >> We make those private fields in OutputAnalyzer public and have the caller pass them: >> >> >> oa.stderrShouldBeEmptyIgnoring(OutputAnalyzer.VM_WARNING_DEPRECATED_MSG) > > That seems like a lot of busy work and over abstraction for trying to solve a rather trivial issue that already has a very simple solution, but maybe could use a better API name. In that case, would `stderrShouldBeEmptyIgnoreVMOptionDeprecations` be OK? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19606#discussion_r1631938967 From lmesnik at openjdk.org Sat Jun 8 17:04:32 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 8 Jun 2024 17:04:32 GMT Subject: RFR: 8333841: Add more logging into setfldw001 tests. Message-ID: Tests SetFieldAccessWatch/setfldw001 SetFieldModificationWatch/setfmodw001 intermittently fail with Xcomp. I was unable to reproduce the problem. The fix adds more checks and variants with jvmti logging. The goal is to understand why the test fails. 1. Confirm that the event is not sent. Currently, the test doesn't differ between sending "NULL" event and not sending an event at all. 2. Check if the interpreter-only mode is switched too late in Thread-1. The jvmti logging shows when field events are enabled and when each thread actually switches to interpreter-only and enables event handling. The plan is to try to reproduce the failure and remove '@test id=logging' after https://bugs.openjdk.org/browse/JDK-8205957 is fixed. ------------- Commit messages: - 8333841: Add more logging into setfldw001 tests. Changes: https://git.openjdk.org/jdk/pull/19612/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19612&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333841 Stats: 35 lines in 5 files changed: 31 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19612.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19612/head:pull/19612 PR: https://git.openjdk.org/jdk/pull/19612 From dholmes at openjdk.org Sun Jun 9 21:54:11 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 9 Jun 2024 21:54:11 GMT Subject: RFR: 8333813: Seviceability tests fail due to stderr containing Temporarily processing option UseNotificationThread In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 19:56:03 GMT, Chris Plummer wrote: > Allow warning messages such as the following to appear in stderr: > > Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option UseNotificationThread; support is scheduled for removal in 24.0 > > Tested by running CI tier5, which reproduced the issue. This is the wrong fix. The tests should not be being run with the problematic option. We should not be hiding that by extending the "ignore warnings" support. This is an issue with our CI task definitions. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19606#pullrequestreview-2106373613 From dholmes at openjdk.org Mon Jun 10 02:38:25 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 10 Jun 2024 02:38:25 GMT Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 Message-ID: Sets the version to 24/24-ea and the copyright year to 2025. Content changes related to the start of release (e.g. for removed options in java.1) are handled separately. This initial generation also picks up the unpublished changes from: - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC - JDK-8284500: Typo in Supported Named Extensions - BasicContraints - JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class Thanks ------------- Commit messages: - 8330205: Initial troff manpage generation for JDK 24 Changes: https://git.openjdk.org/jdk/pull/19617/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8330205 Stats: 66 lines in 28 files changed: 12 ins; 13 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/19617.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617 PR: https://git.openjdk.org/jdk/pull/19617 From stuefe at openjdk.org Mon Jun 10 05:04:18 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 10 Jun 2024 05:04:18 GMT Subject: RFR: 8322811: jcmd System.dump_map help info has conflicting statements Message-ID: @dholmes-ora this is one of yours. This was a tad annoying to fix (fix is simple though), since the jcmd framework has no good way to allow for default parameters that are not used literally. E.g. in this case, the real value for the file name will contain the process pid, which of course cannot be hard-coded. New output: Syntax : System.dump_map [options] Options: (options must be specified using the or = syntax) -H : [optional] Human readable format (BOOLEAN, false) -F : [optional] file path (STRING, vm_memory_map_.txt) ------------- Commit messages: - JDK-8322811-jcmd-System-dump_map-help-info-has-conflicting-statements Changes: https://git.openjdk.org/jdk/pull/19596/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19596&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322811 Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19596.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19596/head:pull/19596 PR: https://git.openjdk.org/jdk/pull/19596 From cjplummer at openjdk.org Mon Jun 10 05:46:24 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 10 Jun 2024 05:46:24 GMT Subject: Withdrawn: 8333813: Seviceability tests fail due to stderr containing Temporarily processing option UseNotificationThread In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 19:56:03 GMT, Chris Plummer wrote: > Allow warning messages such as the following to appear in stderr: > > Java HotSpot(TM) 64-Bit Server VM warning: Temporarily processing option UseNotificationThread; support is scheduled for removal in 24.0 > > Tested by running CI tier5, which reproduced the issue. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/19606 From jpai at openjdk.org Mon Jun 10 05:51:11 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 10 Jun 2024 05:51:11 GMT Subject: RFR: 8333756: java/lang/instrument/NativeMethodPrefixApp.java failed due to missing intrinsic In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 10:31:22 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which fixes an issue that was introduced due to the refactoring that we did in https://bugs.openjdk.org/browse/JDK-8333130? This PR addresses the failure reported in https://bugs.openjdk.org/browse/JDK-8333756. > > The `NativeMethodPrefixApp` test uses a `javaagent` `NativeMethodPrefixAgent` which modifies the name of the native methods using the `java.lang.instrument.Instrumentation` instance: > > public static void premain (String agentArgs, Instrumentation instArg) { > inst = instArg; > System.out.println("Premain"); > > ... > instArg.setNativeMethodPrefix(t0, "wrapped_tr0_"); > instArg.setNativeMethodPrefix(t1, "wrapped_tr1_"); > instArg.setNativeMethodPrefix(t2, "wrapped_tr2_"); > > > The Hotspot VM allows for methods on a class to be annotated with an (VM internal) `jdk.internal.vm.annotation.IntrinsicCandidate` annotation. When a class that contains any methods that are annotated with `@IntrinsicCandidate` is loaded, the VM checks that the corresponding method(s) have an intrinsic available. It uses the method name to check for the presence of the intrinsic. In the absence of an intrinsic for a `@IntrinsicCandidate` method, the VM throws an error and exits. This behaviour is controlled by the `-XX:+/-CheckIntrinsics` option. By default that option is enabled, implying that an error will be thrown if the intrinsic isn't found. > > In the case where/when this test fails, it so happens that the JVM loads a class which has a `@IntrinsicCandidate` on a `native` Java method. For example, on the failing host, I could see this class loading sequence: > > > tr2: Loading java/util/Date > tr1: Loading java/util/Date > tr0: Loading java/util/Date > tr2: Loading sun/util/calendar/CalendarSystem > tr1: Loading sun/util/calendar/CalendarSystem > tr0: Loading sun/util/calendar/CalendarSystem > tr2: Loading sun/util/calendar/CalendarSystem$GregorianHolder > tr1: Loading sun/util/calendar/CalendarSystem$GregorianHolder > tr0: Loading sun/util/calendar/CalendarSystem$GregorianHolder > ... > tr2: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr1: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr0: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr2: Loading java/util/zip/Checksum > tr1: Loading java/util/zip/Checksum > tr0: Loading java/util/zip/Checksum > tr2: Loading java/util/zip/CRC32 > tr1: Loading java/util/zip/CRC32 > tr0: Loading java/util/zip/CRC32 > Method [java.util.zip.CRC32.wrapped_tr2_update(II)I] is annotated with @IntrinsicCandidate, but no... Looking for a second review of this PR, please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19595#issuecomment-2157319670 From alanb at openjdk.org Mon Jun 10 07:18:11 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 10 Jun 2024 07:18:11 GMT Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 In-Reply-To: References: Message-ID: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com> On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote: > Sets the version to 24/24-ea and the copyright year to 2025. > > Content changes related to the start of release (e.g. for removed options in java.1) are handled separately. > > This initial generation also picks up the unpublished changes from: > > - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC > - JDK-8284500: Typo in Supported Named Extensions - BasicContraints > - JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class > > Thanks Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118 From duke at openjdk.org Mon Jun 10 07:36:50 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 10 Jun 2024 07:36:50 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v12] In-Reply-To: References: Message-ID: > Print the stack traces of mounted virtual threads when calling `jcmd Thread.print`. Inigo Mediavilla Saiz 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 15 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into txominpelu_8330846_add_stack_vthreads - Include virtual thread name in output - Incorporate @tstuefe's remarks - Remove dead code - Remove extra indentation (leave it for the next PR) - Cleanup test - Stop virtualthread - Remove unneeded imports - Remove modules that are not needed - Fix copyright year - Print mounted virtual thread after carrier - Add indentation for virtual thread stack - Update test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java Co-authored-by: Andrey Turbanov - ... and 5 more: https://git.openjdk.org/jdk/compare/ab51e287...ba3385a4 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19482/files - new: https://git.openjdk.org/jdk/pull/19482/files/a97184c3..ba3385a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19482&range=10-11 Stats: 26276 lines in 507 files changed: 19189 ins; 4947 del; 2140 mod Patch: https://git.openjdk.org/jdk/pull/19482.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19482/head:pull/19482 PR: https://git.openjdk.org/jdk/pull/19482 From dholmes at openjdk.org Mon Jun 10 07:39:15 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 10 Jun 2024 07:39:15 GMT Subject: RFR: 8322811: jcmd System.dump_map help info has conflicting statements In-Reply-To: References: Message-ID: <3cAkhOgeghew6loNfXI-deHX79_lchKQu1LMEt_SRs4=.4558a026-165d-4216-a785-62fa0225a2d8@github.com> On Fri, 7 Jun 2024 10:40:07 GMT, Thomas Stuefe wrote: > @dholmes-ora this is one of yours. > > This was a tad annoying to fix (fix is simple though), since the jcmd framework has no good way to allow for default parameters that are not used literally. E.g. in this case, the real value for the file name will contain the process pid, which of course cannot be hard-coded. > > New output: > > > Syntax : System.dump_map [options] > > Options: (options must be specified using the or = syntax) > -H : [optional] Human readable format (BOOLEAN, false) > -F : [optional] file path (STRING, vm_memory_map_.txt) That seems a good solution. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19596#pullrequestreview-2106891649 From dholmes at openjdk.org Mon Jun 10 08:04:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 10 Jun 2024 08:04:12 GMT Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 In-Reply-To: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com> References: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com> Message-ID: On Mon, 10 Jun 2024 07:15:51 GMT, Alan Bateman wrote: >> Sets the version to 24/24-ea and the copyright year to 2025. >> >> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately. >> >> This initial generation also picks up the unpublished changes from: >> >> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC >> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints >> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class >> >> Thanks > > Marked as reviewed by alanb (Reviewer). Thanks for the review @AlanBateman ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2157606095 From dholmes at openjdk.org Mon Jun 10 08:23:13 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 10 Jun 2024 08:23:13 GMT Subject: RFR: 8332400: isspace argument should be a valid unsigned char In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 06:07:17 GMT, Thomas Stuefe wrote: > "To use these functions safely with plain chars (or signed chars), the argument should first be converted to unsigned char" @tstuefe wow! Okay. That is a surprise to me. A cast to unsigned char doesn't actually do anything. Every char is "representable" as an unsigned char because it holds a bit pattern between 0x00 and 0xff i.e. the function is well defined if the incoming int is either EOF (int -1) or else in the range 0x00 to 0xff. But I did a bit of searching and it seems it comes down to potential arithmetic operations on the "char" the might behave differently depending on the signed-ness. :( ------------- PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2157677944 From kevinw at openjdk.org Mon Jun 10 08:38:11 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 10 Jun 2024 08:38:11 GMT Subject: RFR: 8322811: jcmd System.dump_map help info has conflicting statements In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 10:40:07 GMT, Thomas Stuefe wrote: > @dholmes-ora this is one of yours. > > This was a tad annoying to fix (fix is simple though), since the jcmd framework has no good way to allow for default parameters that are not used literally. E.g. in this case, the real value for the file name will contain the process pid, which of course cannot be hard-coded. > > New output: > > > Syntax : System.dump_map [options] > > Options: (options must be specified using the or = syntax) > -H : [optional] Human readable format (BOOLEAN, false) > -F : [optional] file path (STRING, vm_memory_map_.txt) Looks good to me, yes non-literal defaults are a bit awkward here. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19596#pullrequestreview-2107075791 From stuefe at openjdk.org Mon Jun 10 08:38:13 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 10 Jun 2024 08:38:13 GMT Subject: RFR: 8332400: isspace argument should be a valid unsigned char In-Reply-To: References: Message-ID: <2wSWEMk4oW4U2wYJQZq5AXgxIrCqAtuEt11kVDVTJ2E=.4e61e441-ef51-4e5d-b286-952174312e2e@github.com> On Mon, 10 Jun 2024 08:20:38 GMT, David Holmes wrote: > > "To use these functions safely with plain chars (or signed chars), the argument should first be converted to unsigned char" > > @tstuefe wow! Okay. That is a surprise to me. A cast to unsigned char doesn't actually do anything. Every char is "representable" as an unsigned char because it holds a bit pattern between 0x00 and 0xff i.e. the function is well defined if the incoming int is either EOF (int -1) or else in the range 0x00 to 0xff. But I did a bit of searching and it seems it comes down to potential arithmetic operations on the "char" the might behave differently depending on the signed-ness. :( I was surprised as well. Turns out you can use something for 20+ years and not notice :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2157711653 From stuefe at openjdk.org Mon Jun 10 09:02:14 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 10 Jun 2024 09:02:14 GMT Subject: RFR: 8322811: jcmd System.dump_map help info has conflicting statements In-Reply-To: References: Message-ID: <0Cg9hzZmBtOzEXSPdms6KwtM-ylywHhr5VBYdoQEDxQ=.2808ecb7-e5d7-4ea5-aead-b53a7036cba8@github.com> On Mon, 10 Jun 2024 08:35:06 GMT, Kevin Walls wrote: >> @dholmes-ora this is one of yours. >> >> This was a tad annoying to fix (fix is simple though), since the jcmd framework has no good way to allow for default parameters that are not used literally. E.g. in this case, the real value for the file name will contain the process pid, which of course cannot be hard-coded. >> >> New output: >> >> >> Syntax : System.dump_map [options] >> >> Options: (options must be specified using the or = syntax) >> -H : [optional] Human readable format (BOOLEAN, false) >> -F : [optional] file path (STRING, vm_memory_map_.txt) > > Looks good to me, yes non-literal defaults are a bit awkward here. Thanks @kevinjwalls, @dholmes-ora ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19596#issuecomment-2157761743 From stuefe at openjdk.org Mon Jun 10 09:02:15 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 10 Jun 2024 09:02:15 GMT Subject: Integrated: 8322811: jcmd System.dump_map help info has conflicting statements In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 10:40:07 GMT, Thomas Stuefe wrote: > @dholmes-ora this is one of yours. > > This was a tad annoying to fix (fix is simple though), since the jcmd framework has no good way to allow for default parameters that are not used literally. E.g. in this case, the real value for the file name will contain the process pid, which of course cannot be hard-coded. > > New output: > > > Syntax : System.dump_map [options] > > Options: (options must be specified using the or = syntax) > -H : [optional] Human readable format (BOOLEAN, false) > -F : [optional] file path (STRING, vm_memory_map_.txt) This pull request has now been integrated. Changeset: 83b34410 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/83b34410e326c47f357a37c3a337b7dedb8cbbda Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod 8322811: jcmd System.dump_map help info has conflicting statements Reviewed-by: dholmes, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/19596 From jsjolen at openjdk.org Mon Jun 10 09:05:13 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 10 Jun 2024 09:05:13 GMT Subject: RFR: 8332400: isspace argument should be a valid unsigned char In-Reply-To: References: Message-ID: <-yrsMojgotrB89wb1ePgtP_iqPDbLCp3VhMhpaDWGh0=.55afc438-1f30-4ac7-9ed2-ffebc35a5083@github.com> On Wed, 5 Jun 2024 20:08:10 GMT, Robert Toyonaga wrote: > ### Summary > This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html). `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". > > Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. > > **Testing** > - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly. > - tier1 Hi Robert, Here's a third opinion: The wrapper is fine, but it should mimic the name of the function it wraps exactly: `os::isspace`. It's also good that it does the range check as regular code as opposed to an assert, as this function is used to parse external input. It's fine to be excessive when parsing strings as those parts of the code are not really performance critical. All the best, Johan src/hotspot/share/runtime/os.cpp line 96: > 94: DEBUG_ONLY(bool os::_mutex_init_done = false;) > 95: > 96: int os::is_space(int c) { `os::isspace` test/hotspot/gtest/runtime/test_os.cpp line 43: > 41: > 42: # include > 43: Not necessary. ------------- PR Review: https://git.openjdk.org/jdk/pull/19567#pullrequestreview-2107152152 PR Review Comment: https://git.openjdk.org/jdk/pull/19567#discussion_r1632873691 PR Review Comment: https://git.openjdk.org/jdk/pull/19567#discussion_r1632873309 From duke at openjdk.org Mon Jun 10 09:23:14 2024 From: duke at openjdk.org (Inigo Mediavilla Saiz) Date: Mon, 10 Jun 2024 09:23:14 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v8] In-Reply-To: <27dIMbrC5Y41jusR7af89D-1hd4XSCc0IKudmba0XpM=.279a7a74-1737-4249-85bd-ae3ac699ebc2@github.com> References: <27dIMbrC5Y41jusR7af89D-1hd4XSCc0IKudmba0XpM=.279a7a74-1737-4249-85bd-ae3ac699ebc2@github.com> Message-ID: On Tue, 4 Jun 2024 08:06:28 GMT, Alan Bateman wrote: >> Inigo Mediavilla Saiz has updated the pull request incrementally with two additional commits since the last revision: >> >> - Cleanup test >> >> - Stop virtualthread >> - Remove unneeded imports >> - Remove modules that are not needed >> - Fix copyright year > > I think the presentation of the carrier the mounted virtual thread in update (b122cc05) looks quite good. > > I think it would be helpful to include the thread name too. Many virtual threads are unnamed so it will show as "" but that is okay. In addition to being useful it means the format of the "Mounted virtual thread ..." line will be consistent the first part of the line for platform threads. > > I'm wondering if we should remove the existing "Carrying virtual thread ..." line as part of this. It's redundant now, @pron ? @AlanBateman @dholmes-ora would you be OK with leaving the current PR as-is and handling the indentation topic in a separate PR ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2157813209 From stuefe at openjdk.org Mon Jun 10 09:29:16 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 10 Jun 2024 09:29:16 GMT Subject: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v8] In-Reply-To: <72CRKwPvqLmopCjtAevfxYXpGg2ZxuDiXUyXLbHIlq8=.e3932757-87ba-404a-98ca-a7e7294071ff@github.com> References: <72CRKwPvqLmopCjtAevfxYXpGg2ZxuDiXUyXLbHIlq8=.e3932757-87ba-404a-98ca-a7e7294071ff@github.com> Message-ID: <_nu-dkNnk3_85CpgwL95wLAZ2EfkjlOUxTN2AHjMQRw=.a8efc20c-bc15-4ffb-910c-c6e6d169b4d5@github.com> On Tue, 4 Jun 2024 13:46:16 GMT, Inigo Mediavilla Saiz wrote: >> src/hotspot/share/runtime/threads.cpp line 1336: >> >>> 1334: oop vt = p->vthread(); >>> 1335: assert(vt != nullptr, ""); >>> 1336: st->print_cr(" \tMounted virtual thread #" INT64_FORMAT, (int64_t)java_lang_Thread::thread_id(vt)); >> >> Please no manual indentation, see remarks above. > > I'm leaving minimal indentation and I will update the code on a new PR to rely on your changes if it's OK for you @tstuefe Okay, that works. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1632931400 From jwaters at openjdk.org Mon Jun 10 13:07:48 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 10 Jun 2024 13:07:48 GMT Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis [v3] In-Reply-To: References: Message-ID: > WIP > > This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now. Julian Waters 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: - Capstone Support - Add check for compiler in configure - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18915/files - new: https://git.openjdk.org/jdk/pull/18915/files/09fb3d65..b0b088e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=01-02 Stats: 121745 lines in 2137 files changed: 85534 ins; 24227 del; 11984 mod Patch: https://git.openjdk.org/jdk/pull/18915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915 PR: https://git.openjdk.org/jdk/pull/18915 From duke at openjdk.org Mon Jun 10 13:39:13 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Mon, 10 Jun 2024 13:39:13 GMT Subject: RFR: 8332400: isspace argument should be a valid unsigned char In-Reply-To: References: Message-ID: <4AzGl1zKsp5sPygdzdbG1WFTgsdNBJrF4FLSUxuhcQQ=.50d7ebb8-fd74-43db-9b4c-4cb02f82f2f0@github.com> On Wed, 5 Jun 2024 20:08:10 GMT, Robert Toyonaga wrote: > ### Summary > This change ensures we don't get undefined behavior when calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html). `isspace` accepts an `int` argument that "the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF.". > > Previously, there was no checking of the values passed to `isspace`. I've replaced direct calls with a new wrapper `os::is_space` that performs a range check and prevents the possibility of undefined behavior from happening. For instances outside of Hotspot, I've added casts to `unsigned char`. > > **Testing** > - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check `os::is_space` is working correctly. > - tier1 Thanks for the feedback everyone! > But I did a bit of searching and it seems it comes down to potential arithmetic operations on the "char" the might behave differently depending on the signed-ness. :( Ok, so it seems like we ought to cast to unsigned char whenever char is passed, even if the representable range is the same. One more argument in favor of the current wrapper approach is that it makes it easy to at-a-glance confirm `isspace` is being used correctly everywhere. However, I am fine with just using casts wherever there is char and removing the wrapper. This is simpler and also avoids the cast to int. But what about when an int is passed to `isspace`? Maybe having the range check here would be better than casting to unsigned char or leaving as is? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2158401790 From kevinw at openjdk.org Mon Jun 10 14:28:34 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 10 Jun 2024 14:28:34 GMT Subject: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed Message-ID: JMX uses APIs related to the Security Mananger which are deprecated. Use of AccessControlContext will be removed when Security Manager is removed. Until then, updates are needed to not require setting -Djava.security.manager=allow to use JMX authentication. ------------- Commit messages: - Additional test combination, old getSubject call with sm=allow - Test updates - whitespace - Merge remote-tracking branch 'upstream/master' into 8333344_JMX_Subject - 8333344: JMX attaching of Subject does not work when security manager not allowed Changes: https://git.openjdk.org/jdk/pull/19624/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333344 Stats: 160 lines in 19 files changed: 109 ins; 10 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/19624.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624 PR: https://git.openjdk.org/jdk/pull/19624 From kevinw at openjdk.org Mon Jun 10 14:28:34 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 10 Jun 2024 14:28:34 GMT Subject: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed In-Reply-To: References: Message-ID: On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls wrote: > JMX uses APIs related to the Security Mananger which are deprecated. Use of AccessControlContext will be removed when Security Manager is removed. > > Until then, updates are needed to not require setting -Djava.security.manager=allow to use JMX authentication. When SecurityManager is not permitted, which is the default, use the Subject.current() call. If SM is permitted, due to -Djava.security.manager=allow then the old Subject.getSubject(AccessController.getContext()) call is used. Tests are updated to not require -Djava.security.manager=allow and will test with and without that setting. Also additionally update tests to use Subject.current(), but also have a setting to test the old Subject.getSubject(AccessController.getContext()) call with -Djava.security.manager=allow (see ThreadPoolAccTest and test/jdk/javax/management/remote/mandatory/passwordAuthenticator). ------------- PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2158515271 From alanb at openjdk.org Mon Jun 10 14:31:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 10 Jun 2024 14:31:12 GMT Subject: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed In-Reply-To: References: Message-ID: <98jFZxRQloFmqxvUlo20WiICow96XWt1ZiDkFsuj728=.760dcba6-ddd6-4e36-a59f-079b6dc414fe@github.com> On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls wrote: > JMX uses APIs related to the Security Mananger which are deprecated. Use of AccessControlContext will be removed when Security Manager is removed. > > Until then, updates are needed to not require setting -Djava.security.manager=allow to use JMX authentication. src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1634: > 1632: } else { > 1633: // We have ACC therefore SM is permitted, and Subject must be non-null: > 1634: return Subject.doAs(subject, (PrivilegedExceptionAction) () -> AccessController.doPrivileged((PrivilegedExceptionAction) () -> wrappedClass.cast(mo.get()), acc)); This is not readable. If you create the PAEs explicitly then the casts will go away and it will be much easier to read. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1633351429 From kevinw at openjdk.org Mon Jun 10 15:37:14 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 10 Jun 2024 15:37:14 GMT Subject: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed In-Reply-To: <98jFZxRQloFmqxvUlo20WiICow96XWt1ZiDkFsuj728=.760dcba6-ddd6-4e36-a59f-079b6dc414fe@github.com> References: <98jFZxRQloFmqxvUlo20WiICow96XWt1ZiDkFsuj728=.760dcba6-ddd6-4e36-a59f-079b6dc414fe@github.com> Message-ID: On Mon, 10 Jun 2024 14:28:25 GMT, Alan Bateman wrote: >> JMX uses APIs related to the Security Mananger which are deprecated. Use of AccessControlContext will be removed when Security Manager is removed. >> >> Until then, updates are needed to not require setting -Djava.security.manager=allow to use JMX authentication. > > src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1634: > >> 1632: } else { >> 1633: // We have ACC therefore SM is permitted, and Subject must be non-null: >> 1634: return Subject.doAs(subject, (PrivilegedExceptionAction) () -> AccessController.doPrivileged((PrivilegedExceptionAction) () -> wrappedClass.cast(mo.get()), acc)); > > This is not readable. If you create the PAEs explicitly then the casts will go away and it will be much easier to read. Yes will simplify this! This style was actually from the idea of moving to Subject.callAs, and nesting calls to keep the doPrivileged, but I don't think it will be necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1633455244 From kevinw at openjdk.org Mon Jun 10 16:52:26 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 10 Jun 2024 16:52:26 GMT Subject: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed [v2] In-Reply-To: References: Message-ID: > JMX uses APIs related to the Security Mananger which are deprecated. Use of AccessControlContext will be removed when Security Manager is removed. > > Until then, updates are needed to not require setting -Djava.security.manager=allow to use JMX authentication. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: More consistent style of calls and comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19624/files - new: https://git.openjdk.org/jdk/pull/19624/files/22424a8e..d43f9a34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19624&range=00-01 Stats: 12 lines in 1 file changed: 5 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/19624.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19624/head:pull/19624 PR: https://git.openjdk.org/jdk/pull/19624 From cjplummer at openjdk.org Mon Jun 10 17:23:16 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 10 Jun 2024 17:23:16 GMT Subject: RFR: 8322811: jcmd System.dump_map help info has conflicting statements In-Reply-To: References: Message-ID: <8j3Rf64IfyWX0hZHCxp1uwFuZlPyNstYdUfBZeI56rE=.e73c02c6-b513-4d90-ace2-bca8acb64db0@github.com> On Fri, 7 Jun 2024 10:40:07 GMT, Thomas Stuefe wrote: > @dholmes-ora this is one of yours. > > This was a tad annoying to fix (fix is simple though), since the jcmd framework has no good way to allow for default parameters that are not used literally. E.g. in this case, the real value for the file name will contain the process pid, which of course cannot be hard-coded. > > New output: > > > Syntax : System.dump_map [options] > > Options: (options must be specified using the or = syntax) > -H : [optional] Human readable format (BOOLEAN, false) > -F : [optional] file path (STRING, vm_memory_map_.txt) jcmd.l should also have been fixed. It currently reads: options: -H: (Optional) Human readable format (BOOLEAN, false) -F: (Optional) File path (STRING, "vm_memory_map_.txt") Note thet `` is missing. You can use the changes for [JDK-8323546](https://bugs.openjdk.org/browse/JDK-8323546) as a model on how to specify and describe the default parameter. src/hotspot/share/services/diagnosticCommand.cpp line 1211: > 1209: } else { > 1210: name = _filename.value(); > 1211: } This code should be considering if a default it specified or not, in case the specified value is identical to what is contained in `default_filename`. With the current solution, if the user literally specifies vm_memory_map_.txt, the part will be expanded to the actual pid. See how [JDK-8323546](https://bugs.openjdk.org/browse/JDK-8323546) handled this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19596#issuecomment-2158908825 PR Review Comment: https://git.openjdk.org/jdk/pull/19596#discussion_r1633575756 From iris at openjdk.org Mon Jun 10 17:30:15 2024 From: iris at openjdk.org (Iris Clark) Date: Mon, 10 Jun 2024 17:30:15 GMT Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 In-Reply-To: References: Message-ID: On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote: > Sets the version to 24/24-ea and the copyright year to 2025. > > Content changes related to the start of release (e.g. for removed options in java.1) are handled separately. > > This initial generation also picks up the unpublished changes from: > > - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC > - JDK-8284500: Typo in Supported Named Extensions - BasicContraints > - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class > > Thanks Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2108383696 From cjplummer at openjdk.org Mon Jun 10 19:03:11 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 10 Jun 2024 19:03:11 GMT Subject: RFR: 8333841: Add more logging into setfldw001 tests. In-Reply-To: References: Message-ID: On Sat, 8 Jun 2024 17:00:04 GMT, Leonid Mesnik wrote: > Tests > SetFieldAccessWatch/setfldw001 > SetFieldModificationWatch/setfmodw001 > intermittently fail with Xcomp. I was unable to reproduce the problem. > The fix adds more checks and variants with jvmti logging. > > The goal is to understand why the test fails. > 1. Confirm that the event is not sent. Currently, the test doesn't differ between sending "NULL" event and not sending an event at all. > 2. Check if the interpreter-only mode is switched too late in Thread-1. The jvmti logging shows when field events are enabled and when each thread actually switches to interpreter-only and enables event handling. > > The plan is to try to reproduce the failure and remove '@test id=logging' after https://bugs.openjdk.org/browse/JDK-8205957 is fixed. Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19612#pullrequestreview-2108557198 From cjplummer at openjdk.org Mon Jun 10 19:08:12 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 10 Jun 2024 19:08:12 GMT Subject: RFR: 8333756: java/lang/instrument/NativeMethodPrefixApp.java failed due to missing intrinsic In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 10:31:22 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which fixes an issue that was introduced due to the refactoring that we did in https://bugs.openjdk.org/browse/JDK-8333130? This PR addresses the failure reported in https://bugs.openjdk.org/browse/JDK-8333756. > > The `NativeMethodPrefixApp` test uses a `javaagent` `NativeMethodPrefixAgent` which modifies the name of the native methods using the `java.lang.instrument.Instrumentation` instance: > > public static void premain (String agentArgs, Instrumentation instArg) { > inst = instArg; > System.out.println("Premain"); > > ... > instArg.setNativeMethodPrefix(t0, "wrapped_tr0_"); > instArg.setNativeMethodPrefix(t1, "wrapped_tr1_"); > instArg.setNativeMethodPrefix(t2, "wrapped_tr2_"); > > > The Hotspot VM allows for methods on a class to be annotated with an (VM internal) `jdk.internal.vm.annotation.IntrinsicCandidate` annotation. When a class that contains any methods that are annotated with `@IntrinsicCandidate` is loaded, the VM checks that the corresponding method(s) have an intrinsic available. It uses the method name to check for the presence of the intrinsic. In the absence of an intrinsic for a `@IntrinsicCandidate` method, the VM throws an error and exits. This behaviour is controlled by the `-XX:+/-CheckIntrinsics` option. By default that option is enabled, implying that an error will be thrown if the intrinsic isn't found. > > In the case where/when this test fails, it so happens that the JVM loads a class which has a `@IntrinsicCandidate` on a `native` Java method. For example, on the failing host, I could see this class loading sequence: > > > tr2: Loading java/util/Date > tr1: Loading java/util/Date > tr0: Loading java/util/Date > tr2: Loading sun/util/calendar/CalendarSystem > tr1: Loading sun/util/calendar/CalendarSystem > tr0: Loading sun/util/calendar/CalendarSystem > tr2: Loading sun/util/calendar/CalendarSystem$GregorianHolder > tr1: Loading sun/util/calendar/CalendarSystem$GregorianHolder > tr0: Loading sun/util/calendar/CalendarSystem$GregorianHolder > ... > tr2: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr1: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr0: Loading sun/util/calendar/ZoneInfoFile$Checksum > tr2: Loading java/util/zip/Checksum > tr1: Loading java/util/zip/Checksum > tr0: Loading java/util/zip/Checksum > tr2: Loading java/util/zip/CRC32 > tr1: Loading java/util/zip/CRC32 > tr0: Loading java/util/zip/CRC32 > Method [java.util.zip.CRC32.wrapped_tr2_update(II)I] is annotated with @IntrinsicCandidate, but no... test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 103: > 101: // the native method names, which then causes a failure in the VM check > 102: // for the presence of an intrinsic on a @IntrinsicCandidate native method > 103: "-XX:+UnlockDiagnosticVMOptions", "-XX:-CheckIntrinsics", Can you update both comments to begin with a capital letter and end with a period. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19595#discussion_r1633711272 From dnguyen at openjdk.org Mon Jun 10 20:05:33 2024 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 10 Jun 2024 20:05:33 GMT Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update Message-ID: This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n: https://cr.openjdk.org/~dnguyen/output2/ ------------- Commit messages: - Review comment edits - Initial localization changes Changes: https://git.openjdk.org/jdk/pull/19609/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333827 Stats: 239 lines in 39 files changed: 133 ins; 57 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/19609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19609/head:pull/19609 PR: https://git.openjdk.org/jdk/pull/19609 From achung at openjdk.org Mon Jun 10 20:05:33 2024 From: achung at openjdk.org (Alisen Chung) Date: Mon, 10 Jun 2024 20:05:33 GMT Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. > > The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. > > Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n: > https://cr.openjdk.org/~dnguyen/output2/ Just a question about the reverted translations, otherwise LGTM > The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. Any particular reason you know that the tool had the definitions adjusted? I see some of the changes look like like command line options not being translated, but it's a bit hard to tell. Do you know if the reverted words should be translated (and possibly will be re-translated in future drops?) or should they be left untranslated? ------------- PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2105526180 PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2155723513 From jlu at openjdk.org Mon Jun 10 20:05:33 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 10 Jun 2024 20:05:33 GMT Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com> On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated. > > The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed. > > Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n: > https://cr.openjdk.org/~dnguyen/output2/ Cannot speak to the translations themselves, but in general the changes LGTM pending the comments. src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 1: > 1: # It looks like these .properties files need to have their copyright years bumped. I believe since the original was not bumped, the translation tool did not reflect the correct year in the localized versions. src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 66: > 64: label.size=??(&Z): > 65: label.source=??(&C): > 66: label.outputbins=????(&P)? Looks like the translation tool changed this from a colon (U+003A) to a full width colon (U+FF1A). There are l10n rules when it comes to punctuation, I am not sure if this is a result of that. It looks like the surrounding key/values are simply using (U+003A) colons. If we decide to revert this colon change, we need to also probably file a bug against the translation tool. src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278: > 276: UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}". > 277: UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden. > 278: ENTITYFailedInitializeGrammar = ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool. src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 285: > 283: VIRTUAL_MACHINE=Virtuelle Maschine > 284: VM_ARGUMENTS=VM-Argumente > 285: VMINTERNAL_FRAME_ACCESSIBLE_DESCRIPTION=Innerer Frame f?r das Monitoring einer Java Virtual Machine This one-off change is consistent with the change in _src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java_. src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183: > 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts > 182: > 183: help.usage = Verwendung: jshell