From sspitsyn at openjdk.java.net  Sun May  1 09:37:33 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sun, 1 May 2022 09:37:33 GMT
Subject: RFR: 8279358:
 vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java
 fails with usage tracker
In-Reply-To: <H2nOQAQKQUnG_m6DlQz6RRhcLSJUFppJ9DU8FvFC0nY=.a82934ea-be49-4f5e-bb81-d165249a075f@github.com>
References: <H2nOQAQKQUnG_m6DlQz6RRhcLSJUFppJ9DU8FvFC0nY=.a82934ea-be49-4f5e-bb81-d165249a075f@github.com>
Message-ID: <iPOImhd2tYpLw0fsyjIJzt1Y5AJyYbQkx7LjHC9sf1w=.e6d61654-2def-4dd2-a85c-ce42bb94f6ad@github.com>

On Fri, 29 Apr 2022 21:39:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test counts calls of intercepted JNI functions, but doesn't completely filter out calls from other threads.
> Function isThreadExpected is used only for ExceptionOccurred function and the function checks only some known JFR/Graal threads.
> 
> The change:
>  - updates the test to count only the calls on the test thread;
>  - adds verbose output.

It looks good.
It needs to be coordinated with Chris who is in process of fixing similar issue in Loom but for different nsk.jvmti test: ji01t001. As I see you already have some comment exchange.

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8475

From alanb at openjdk.java.net  Mon May  2 06:24:21 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 2 May 2022 06:24:21 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v9]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <LXp0tyaigLgDbl9mb2IudAI3T6CKbp5FsHbuaEhus64=.8320aa51-38bb-430d-983c-56b9036827a5@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
 - Merge with jdk-19+19
 - Refresh
 - Refresh
 - Refresh
 - Refresh
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/16a8ebbf...51bc652d

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=08
  Stats: 103888 lines in 1143 files changed: 93996 ins; 4227 del; 5665 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Mon May  2 06:33:22 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 2 May 2022 06:33:22 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <zi26K5BcvOD4orgtEdUoZJ3YtSkQq2LG9bsqo73bAsc=.a437c818-7bb5-4e43-835c-49fa6c4ec510@github.com>
 <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com>
Message-ID: <Hy7L4hTspFwCHXS0TokPH_lBEMMBcZjTAC6D7MJW3uM=.09fb5f13-c986-4ca5-a20b-a289d78d4edb@github.com>

On Fri, 29 Apr 2022 20:57:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> test/jdk/jdk/jfr/api/consumer/TestManyRecordings.java line 57:
>> 
>>> 55:         int classLoaderCount = Integer.parseInt(args[0]);
>>> 56:         int classCount = Integer.parseInt(args[1]);
>>> 57:         for (int i = 0; i <classCount; i++) {
>> 
>> Did you mean classLoaderCount here instead of classCount? Also, please make sure there is a space between < and classLoaderCount.
>
> The JFR "tests" look strange. I would expect a test called TestManyRecording to start recordings, not create a lot of classes, similar to TestManyClasses. How is this related to Loom?  Could this be a merge gone bad?
> 
> Also, in TestActiveSettingEvent.java
> 
> +settingValues.put(EventNames.VirtualThreadPinned + "#threshold", "20 ms");
> 
> The reason to exclude a setting (threshold or stackTrace) from a .jfc file is if it doesn't make sense to configure. For example, if the event is always instantaneous (so duration is always 0) or periodic (so the stack trace only show JFR internals) then "threshold" and "stackTrace" can be removed from the configuration file, but needs to be added to test to avoid false positive.
> 
> The value "20 ms" seems like something a user might want to configure. If the event is instant, then the value should be "0 ms".

It seems that test/jdk/jdk/jfr/api/consumer/TestManyClasses.java, TestManyRecordings.java, and TestParse.java were added for another JFR event (nothing to do with VirtualThreadPinned). @egahlin has contributed some cleanup and these files are removed.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Mon May  2 06:33:23 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 2 May 2022 06:33:23 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ycstoIkpgIuaPPuUzJJl0WbTB9d2fgNzsmMGAkaLg5g=.b596ebbd-0f27-4911-a1f4-f0e6c98dcbe9@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ycstoIkpgIuaPPuUzJJl0WbTB9d2fgNzsmMGAkaLg5g=.b596ebbd-0f27-4911-a1f4-f0e6c98dcbe9@github.com>
Message-ID: <Ihkc2WEFbT66Mp-11wmQKxr7tb2FAnCWUX-AEOFKogg=.5f0069b9-6bff-44e4-b78e-dc261b7719b2@github.com>

On Fri, 29 Apr 2022 23:14:45 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/lib/jdk/test/lib/thread/VThreadRunner.java line 61:
> 
>> 59:     /**
>> 60:      * Run a task in a virtual thread and wait for it to terminate.
>> 61:      * If the task completse with an exception then it is thrown by this method.
> 
> typo: completse --> completes

Thanks, it seems this typo was repeated several times in the test.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From mseledtsov at openjdk.java.net  Mon May  2 16:05:19 2022
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 2 May 2022 16:05:19 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v9]
In-Reply-To: <LXp0tyaigLgDbl9mb2IudAI3T6CKbp5FsHbuaEhus64=.8320aa51-38bb-430d-983c-56b9036827a5@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <LXp0tyaigLgDbl9mb2IudAI3T6CKbp5FsHbuaEhus64=.8320aa51-38bb-430d-983c-56b9036827a5@github.com>
Message-ID: <q-gQnc_5PSoqmpwJzQeU3OBmPHuB_6VvOPe6DgZ7NMo=.686d086e-933b-4b1a-967d-b08193d998ca@github.com>

On Mon, 2 May 2022 06:24:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - Refresh
>  - Refresh
>  - Refresh
>  - Refresh
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/16a8ebbf...51bc652d

Thank you for addressing my review feedback. HotSpot/Runtime, test library, common test and JFR test changes look good to me.

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

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From lmesnik at openjdk.java.net  Mon May  2 17:24:13 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 17:24:13 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ToZrjWwHwDBwSBGMmN4GhwGvTEhcPFSVF40moxWLKwQ=.f6d14c2c-02f5-4655-808e-431bca9b386e@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ToZrjWwHwDBwSBGMmN4GhwGvTEhcPFSVF40moxWLKwQ=.f6d14c2c-02f5-4655-808e-431bca9b386e@github.com>
Message-ID: <ojMUwaa-wbzazU8JX6_xaqDrJ9ASDlPApVC1iux2ncA=.19af44cd-1114-417e-b08e-c5e5a97e12e3@github.com>

On Fri, 29 Apr 2022 05:48:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 66:
> 
>> 64:   for (i = 0; i < METH_NUM; i++)
>> 65:     bpEvents[i] = 0;
>> 66: }
> 
> Leonid, thank you for converting these tests from nsk.jvmti to provide test coverage for virtual threads!
> As I understand all new tests are C++ based.
> So, I'd suggest to always use C++ style of loops:
>   for (int i = 0; i < METH_NUM; i++)
> 
> This suggestion applies to all new tests in the serviceability/jvmti folder.
> One reason to keep old style would be to keep these tests comparable with the matching nsk.jvmti tests.
> However, I tried to compare and found out that the difference is already pretty big.
> You can consider this clean up after integration though.

fixed in all ported tests were applicable

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From lmesnik at openjdk.java.net  Mon May  2 17:33:45 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 17:33:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ZIbvg5mqBKnDkPqj_VXglNgLvfgXGoXXQeKkCdXEpog=.222d1b6a-ba31-4b24-8087-8939d91f6b40@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ZIbvg5mqBKnDkPqj_VXglNgLvfgXGoXXQeKkCdXEpog=.222d1b6a-ba31-4b24-8087-8939d91f6b40@github.com>
Message-ID: <htZ8N0SehZt8GFsN3GD8d0lvFbFlfjHdLv-PonqMYBI=.79c09d37-e6db-4746-b608-702eeca04539@github.com>

On Fri, 29 Apr 2022 06:09:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139:
> 
>> 137:            thr_info.name,        (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel",
>> 138:         (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user");
>> 139:   }
> 
> I'd suggest to add locals (their names are up to you):
>    const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel";
>    const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user";
> 
> It is better to place togeter lines: 129+130.
> Line 137 is not aligned, and there are many unneeded spaces.
> The '()' around conditions are not needed. At least, I do not see them increasing readability.

fixed

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From lmesnik at openjdk.java.net  Mon May  2 20:04:59 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 20:04:59 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TcJvhtqkkhHL32dEDwwEwxpShTFQTt39RsQo4wyHfJo=.4c9533a1-0540-4545-8293-74aa6168d085@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <TcJvhtqkkhHL32dEDwwEwxpShTFQTt39RsQo4wyHfJo=.4c9533a1-0540-4545-8293-74aa6168d085@github.com>
Message-ID: <WkOg5zdfmYpJZrFNKGUgfrtEA2OTK1NZZMvPV3wSpBI=.063bc28c-2147-4173-892e-87287939ac7c@github.com>

On Fri, 29 Apr 2022 06:43:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp line 287:
> 
>> 285:   }
>> 286: 
>> 287:   eventsCount = 0;
> 
> Counters are not protected with locks.
> I'm not sure it is a real problem here but would be better to double-check.

The variable eventsCount seems to be used in the sinlge thread only. I looked on the several tests with same variable and similar logic.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From lmesnik at openjdk.java.net  Mon May  2 20:16:01 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 20:16:01 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <YzgjmX7Q5pE2ckM4tdOY0tfh-TepCovgtzJKqxylvlo=.132db6f6-864d-4230-bdf9-7098512f0984@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <YzgjmX7Q5pE2ckM4tdOY0tfh-TepCovgtzJKqxylvlo=.132db6f6-864d-4230-bdf9-7098512f0984@github.com>
Message-ID: <7mvqatvgF_tC9fZB1rci31SVIh7q0JVtwGPXlWfiH9Y=.b58e30aa-101c-48d4-bed2-bcb7bf20a160@github.com>

On Fri, 29 Apr 2022 06:33:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 59:
> 
>> 57: static jvmtiEventCallbacks callbacks;
>> 58: static jint result = PASSED;
>> 59: static volatile size_t eventsCount = 0; // TODO these 2 vars mofified from different threads in getReady/check. What to DO???
> 
> I'd suggest to use RawMonitorLocker with event_lock or counter_lock to protect updates of these counters.
> You can remove this comment then.

The variable eventsCount seems to be used in the sinlge thread only. I looked on the several tests with same variable and similar logic.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From amenkov at openjdk.java.net  Mon May  2 23:28:52 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 2 May 2022 23:28:52 GMT
Subject: RFR: 8284027: [LOOM] vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing
Message-ID: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>

The test counts all "system" threads before the execution and expects that this number remains the same during test execution.
This makes the test fragile - JVM may start internal threads, some threads may end.

The fix updates the test:
- the test checks only test threads, and verify that the live threads are reported by GetAllThreads and terminated threads are not reported;
- dropped "system" thread counting stuff;
- added proper deallocation of GetThreadInfo results.

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

Commit messages:
 - Fixed allthr001 test

Changes: https://git.openjdk.java.net/jdk/pull/8512/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8512&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284027
  Stats: 109 lines in 3 files changed: 46 ins; 41 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8512.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8512/head:pull/8512

PR: https://git.openjdk.java.net/jdk/pull/8512

From sspitsyn at openjdk.java.net  Tue May  3 01:39:18 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 3 May 2022 01:39:18 GMT
Subject: RFR: 8284027: [LOOM] vmTestbase/nsk/jvmti/GetAllThreads/allthr001/
 is failing
In-Reply-To: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
Message-ID: <0go2hwobqgH9A1XvNTZeguWs1saBjsYOZiigAQFBXTo=.3c351002-5b08-485e-9d37-dc205686eda6@github.com>

On Mon, 2 May 2022 23:20:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test counts all "system" threads before the execution and expects that this number remains the same during test execution.
> This makes the test fragile - JVM may start internal threads, some threads may end.
> 
> The fix updates the test:
> - the test checks only test threads, and verify that the live threads are reported by GetAllThreads and terminated threads are not reported;
> - dropped "system" thread counting stuff;
> - added proper deallocation of GetThreadInfo results.

Alex,
It looks good to me.
Thank you for taking care about this!
Serguei

Should we remove prefix "[LOOM] " from the bug title?

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8512

From duke at openjdk.java.net  Tue May  3 07:31:14 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 3 May 2022 07:31:14 GMT
Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via
 JavaThread::thread_from_jni_environment [v3]
In-Reply-To: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
References: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
Message-ID: <gnY8UxEQo7NAtgGZJ65_21RdjkcazQRab_ZowYUtOhQ=.058a2d8c-5f13-4f89-8840-4060437d1b30@github.com>

> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. 
> 
> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Use JavaThread::cast

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8446/files
  - new: https://git.openjdk.java.net/jdk/pull/8446/files/1e2885e6..e77e4665

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8446

From dholmes at openjdk.java.net  Tue May  3 07:40:10 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 3 May 2022 07:40:10 GMT
Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via
 JavaThread::thread_from_jni_environment [v2]
In-Reply-To: <hdAuuc7UUiZ61vymy6rBf0vv2LdbeweXGRTqBUxnRHs=.93290846-a40b-4c87-bc70-7bb9f27fc2da@github.com>
References: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
 <hnQRQRRHeu9Tn2tCIf0JBnpORlm7Gg55enVBgFGU294=.09a3b976-9b35-4f1f-aa7a-54060e33cff3@github.com>
 <e2ydF03NnSYKw8nJCiVy5JkuDsfJ_QKwUhRaExAQkqg=.3675b952-e947-4dcb-83c7-f2194e22b937@github.com>
 <FxogtC9y_HvVoMNXOV7C6U4U3rpeaO6QYdlc9uKny6U=.cf37bca9-37ee-4d26-906c-f99c0cb2aa36@github.com>
 <hdAuuc7UUiZ61vymy6rBf0vv2LdbeweXGRTqBUxnRHs=.93290846-a40b-4c87-bc70-7bb9f27fc2da@github.com>
Message-ID: <feeuC0G9b9d-oK-5Ld0jg33mJx8tGBgC6jRTBQ2h-bA=.d8dc87ed-6fd7-4ca8-9068-3cd9bba40cdc@github.com>

On Sat, 30 Apr 2022 10:54:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> this method does not exist
>
> Sorry I meant: `JavaThread::cast(rawThread)`

You missed changing the cast here. You could also save the result for use below.

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

PR: https://git.openjdk.java.net/jdk/pull/8446

From mbaesken at openjdk.java.net  Tue May  3 07:55:40 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 3 May 2022 07:55:40 GMT
Subject: RFR: JDK-8285921:
 serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java fails on Alpine
Message-ID: <g_KpGEisN4MlTAtEjzEAnQV26n192oykVw-RICnuB3g=.e3dd794c-478e-435d-8523-aa3a7f108338@github.com>

The test  serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java fails on Alpine Linux using musl.
Reason is the difference how dlclose is done 
https://wiki.musl-libc.org/functional-differences-from-glibc.html
"musl?s dynamic loader loads libraries permanently for the lifetime of the process, until it exits or calls exec. dlclose is a no-op. "

This leads to "libReturnError.so found in stdout" when running the test on Alpine/musl , unlike on other Linux versions without musl.

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

Commit messages:
 - JDK-8285921

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

PR: https://git.openjdk.java.net/jdk/pull/8515

From duke at openjdk.java.net  Tue May  3 08:02:57 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 3 May 2022 08:02:57 GMT
Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via
 JavaThread::thread_from_jni_environment [v4]
In-Reply-To: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
References: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
Message-ID: <m3txKMlM0WGif0OfyERtoJbU7LDi-RM6t_xx4ejgohI=.e094bdd4-deae-4315-96fa-11df614eca12@github.com>

> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. 
> 
> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Merge cast into condition

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8446/files
  - new: https://git.openjdk.java.net/jdk/pull/8446/files/e77e4665..8d4b60eb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=02-03

  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8446.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8446/head:pull/8446

PR: https://git.openjdk.java.net/jdk/pull/8446

From duke at openjdk.java.net  Tue May  3 08:02:57 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 3 May 2022 08:02:57 GMT
Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via
 JavaThread::thread_from_jni_environment [v2]
In-Reply-To: <feeuC0G9b9d-oK-5Ld0jg33mJx8tGBgC6jRTBQ2h-bA=.d8dc87ed-6fd7-4ca8-9068-3cd9bba40cdc@github.com>
References: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
 <hnQRQRRHeu9Tn2tCIf0JBnpORlm7Gg55enVBgFGU294=.09a3b976-9b35-4f1f-aa7a-54060e33cff3@github.com>
 <e2ydF03NnSYKw8nJCiVy5JkuDsfJ_QKwUhRaExAQkqg=.3675b952-e947-4dcb-83c7-f2194e22b937@github.com>
 <FxogtC9y_HvVoMNXOV7C6U4U3rpeaO6QYdlc9uKny6U=.cf37bca9-37ee-4d26-906c-f99c0cb2aa36@github.com>
 <hdAuuc7UUiZ61vymy6rBf0vv2LdbeweXGRTqBUxnRHs=.93290846-a40b-4c87-bc70-7bb9f27fc2da@github.com>
 <feeuC0G9b9d-oK-5Ld0jg33mJx8tGBgC6jRTBQ2h-bA=.d8dc87ed-6fd7-4ca8-9068-3cd9bba40cdc@github.com>
Message-ID: <77RFHswbfyDzpRaulp8oqDzQ29lA27pCABf1gDp1QCU=.f603a0c2-e533-426d-ab83-6c4fcbe2253f@github.com>

On Tue, 3 May 2022 07:36:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sorry I meant: `JavaThread::cast(rawThread)`
>
> You missed changing the cast here. You could also save the result for use below.

You're right, I missed that cast.

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

PR: https://git.openjdk.java.net/jdk/pull/8446

From alanb at openjdk.java.net  Tue May  3 08:11:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 3 May 2022 08:11:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v10]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <C12QFWDYSwfwhM2JV6cdT5duNy-3F7mmYy9eTCItmtM=.ccd6fb59-f1ee-4cd2-b24f-7d439d636b09@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
 - Merge with jdk-19+19
 - Refresh
 - Refresh
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/cfcba1fc...f41b3131

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=09
  Stats: 102769 lines in 1140 files changed: 92907 ins; 4216 del; 5646 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Tue May  3 08:11:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 3 May 2022 08:11:47 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <htZ8N0SehZt8GFsN3GD8d0lvFbFlfjHdLv-PonqMYBI=.79c09d37-e6db-4746-b608-702eeca04539@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ZIbvg5mqBKnDkPqj_VXglNgLvfgXGoXXQeKkCdXEpog=.222d1b6a-ba31-4b24-8087-8939d91f6b40@github.com>
 <htZ8N0SehZt8GFsN3GD8d0lvFbFlfjHdLv-PonqMYBI=.79c09d37-e6db-4746-b608-702eeca04539@github.com>
Message-ID: <fkmUI64vg-G_ILxioCOP_NqlP2O5LvNK1v9_vj1xvt8=.1e5cef3c-d532-4050-8860-4425d5acd5c2@github.com>

On Mon, 2 May 2022 17:29:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139:
>> 
>>> 137:            thr_info.name,        (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel",
>>> 138:         (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user");
>>> 139:   }
>> 
>> I'd suggest to add locals (their names are up to you):
>>    const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel";
>>    const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user";
>> 
>> It is better to place togeter lines: 129+130.
>> Line 137 is not aligned, and there are many unneeded spaces.
>> The '()' around conditions are not needed. At least, I do not see them increasing readability.
>
> fixed

Thanks, I'll mark all the comments related to the JVMTI event tests as resolved.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From stuefe at openjdk.java.net  Tue May  3 09:10:20 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 3 May 2022 09:10:20 GMT
Subject: RFR: JDK-8285921:
 serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java fails on Alpine
In-Reply-To: <g_KpGEisN4MlTAtEjzEAnQV26n192oykVw-RICnuB3g=.e3dd794c-478e-435d-8523-aa3a7f108338@github.com>
References: <g_KpGEisN4MlTAtEjzEAnQV26n192oykVw-RICnuB3g=.e3dd794c-478e-435d-8523-aa3a7f108338@github.com>
Message-ID: <gln8-aeVfyMn59vLB6jwE5RshbD4bFwLmDkumsvwOno=.23f34dee-407a-4795-8aa3-b9fa6edddbc5@github.com>

On Tue, 3 May 2022 07:47:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test  serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java fails on Alpine Linux using musl.
> Reason is the difference how dlclose is done 
> https://wiki.musl-libc.org/functional-differences-from-glibc.html
> "musl?s dynamic loader loads libraries permanently for the lifetime of the process, until it exits or calls exec. dlclose is a no-op. "
> 
> This leads to "libReturnError.so found in stdout" when running the test on Alpine/musl , unlike on other Linux versions without musl.

Looks good.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8515

From dholmes at openjdk.java.net  Tue May  3 09:55:45 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 3 May 2022 09:55:45 GMT
Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via
 JavaThread::thread_from_jni_environment [v4]
In-Reply-To: <m3txKMlM0WGif0OfyERtoJbU7LDi-RM6t_xx4ejgohI=.e094bdd4-deae-4315-96fa-11df614eca12@github.com>
References: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
 <m3txKMlM0WGif0OfyERtoJbU7LDi-RM6t_xx4ejgohI=.e094bdd4-deae-4315-96fa-11df614eca12@github.com>
Message-ID: <fzmh-ODbqAC6km2zVz5_uqk3i5-2uK2uXlRi7WL3bIY=.dd604405-7bc8-4f3d-9314-43826b92ee2e@github.com>

On Tue, 3 May 2022 08:02:57 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. 
>> 
>> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge cast into condition

Looks good.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8446

From dholmes at openjdk.java.net  Tue May  3 09:58:40 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 3 May 2022 09:58:40 GMT
Subject: RFR: JDK-8285921:
 serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java fails on Alpine
In-Reply-To: <g_KpGEisN4MlTAtEjzEAnQV26n192oykVw-RICnuB3g=.e3dd794c-478e-435d-8523-aa3a7f108338@github.com>
References: <g_KpGEisN4MlTAtEjzEAnQV26n192oykVw-RICnuB3g=.e3dd794c-478e-435d-8523-aa3a7f108338@github.com>
Message-ID: <Te2AY3Czh6tTpMag-vo3qe44lZXfFPHF4xdnUahtMDA=.ddfbde94-2c98-4277-be78-50c6d12c8544@github.com>

On Tue, 3 May 2022 07:47:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test  serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java fails on Alpine Linux using musl.
> Reason is the difference how dlclose is done 
> https://wiki.musl-libc.org/functional-differences-from-glibc.html
> "musl?s dynamic loader loads libraries permanently for the lifetime of the process, until it exits or calls exec. dlclose is a no-op. "
> 
> This leads to "libReturnError.so found in stdout" when running the test on Alpine/musl , unlike on other Linux versions without musl.

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8515

From mbaesken at openjdk.java.net  Tue May  3 11:25:24 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 3 May 2022 11:25:24 GMT
Subject: Integrated: JDK-8285921:
 serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java fails on Alpine
In-Reply-To: <g_KpGEisN4MlTAtEjzEAnQV26n192oykVw-RICnuB3g=.e3dd794c-478e-435d-8523-aa3a7f108338@github.com>
References: <g_KpGEisN4MlTAtEjzEAnQV26n192oykVw-RICnuB3g=.e3dd794c-478e-435d-8523-aa3a7f108338@github.com>
Message-ID: <YXA-KNMRgeXuBNUbXVIMQHOcf404ziyH3Rb2ybYjfX8=.2363a1de-9b5f-41c7-9af3-a1ac7be002e0@github.com>

On Tue, 3 May 2022 07:47:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test  serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java fails on Alpine Linux using musl.
> Reason is the difference how dlclose is done 
> https://wiki.musl-libc.org/functional-differences-from-glibc.html
> "musl?s dynamic loader loads libraries permanently for the lifetime of the process, until it exits or calls exec. dlclose is a no-op. "
> 
> This leads to "libReturnError.so found in stdout" when running the test on Alpine/musl , unlike on other Linux versions without musl.

This pull request has now been integrated.

Changeset: 0f62cb6f
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0f62cb6fcc75e0b8cc2d623f67273114233a40ef
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8285921: serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java fails on Alpine

Reviewed-by: stuefe, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/8515

From amenkov at openjdk.java.net  Tue May  3 17:48:20 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 3 May 2022 17:48:20 GMT
Subject: RFR: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing
In-Reply-To: <0go2hwobqgH9A1XvNTZeguWs1saBjsYOZiigAQFBXTo=.3c351002-5b08-485e-9d37-dc205686eda6@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
 <0go2hwobqgH9A1XvNTZeguWs1saBjsYOZiigAQFBXTo=.3c351002-5b08-485e-9d37-dc205686eda6@github.com>
Message-ID: <nqGyKwiod_My8WI9cWEKK4xDpfWtFhmN-R9nNN9Y-cE=.18be5e48-6647-4ff3-a94e-f7d2ae8a3254@github.com>

On Tue, 3 May 2022 01:36:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Should we remove prefix "[LOOM] " from the bug title?

Done

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

PR: https://git.openjdk.java.net/jdk/pull/8512

From cjplummer at openjdk.java.net  Tue May  3 20:35:17 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 3 May 2022 20:35:17 GMT
Subject: RFR: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing
In-Reply-To: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
Message-ID: <pj01tyv8Xi2EN7Y4qaio5Pjq0BHuswJI0T1RbfKDzvc=.a4b483fb-8245-4ebf-833c-61d01d547746@github.com>

On Mon, 2 May 2022 23:20:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test counts all "system" threads before the execution and expects that this number remains the same during test execution.
> This makes the test fragile - JVM may start internal threads, some threads may end.
> 
> The fix updates the test:
> - the test checks only test threads, and verify that the live threads are reported by GetAllThreads and terminated threads are not reported;
> - dropped "system" thread counting stuff;
> - added proper deallocation of GetThreadInfo results.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr001/allthr001.cpp line 170:

> 168: }
> 169: 
> 170: void release(JNIEnv *env, jvmtiThreadInfo *info) {

How about "releaseThreadInfo"?

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr001/allthr001.cpp line 238:

> 236:         }
> 237:         if (printdump == JNI_TRUE) {
> 238:             printf(" >>> %s", inf.name);

Don't you want a newline here?

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr001/allthr001.cpp line 240:

> 238:             printf(" >>> %s", inf.name);
> 239:         }
> 240:         for (j = 0, found = 0; j < thrInfo[ind].unexpected.cnt && !found; j++) {

found = JNI_FALSE

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

PR: https://git.openjdk.java.net/jdk/pull/8512

From amenkov at openjdk.java.net  Tue May  3 23:20:28 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 3 May 2022 23:20:28 GMT
Subject: RFR: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing [v2]
In-Reply-To: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
Message-ID: <W0XJqGgMTsFqG5zzpkwYElKxsk4gLJ6ALD0zmrvkERY=.a4748b54-5859-4375-b295-715b6df1ed33@github.com>

> The test counts all "system" threads before the execution and expects that this number remains the same during test execution.
> This makes the test fragile - JVM may start internal threads, some threads may end.
> 
> The fix updates the test:
> - the test checks only test threads, and verify that the live threads are reported by GetAllThreads and terminated threads are not reported;
> - dropped "system" thread counting stuff;
> - added proper deallocation of GetThreadInfo results.

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

  feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8512/files
  - new: https://git.openjdk.java.net/jdk/pull/8512/files/a7ae12d8..1539460c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8512&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8512&range=00-01

  Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8512.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8512/head:pull/8512

PR: https://git.openjdk.java.net/jdk/pull/8512

From amenkov at openjdk.java.net  Tue May  3 23:20:31 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 3 May 2022 23:20:31 GMT
Subject: RFR: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing [v2]
In-Reply-To: <pj01tyv8Xi2EN7Y4qaio5Pjq0BHuswJI0T1RbfKDzvc=.a4b483fb-8245-4ebf-833c-61d01d547746@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
 <pj01tyv8Xi2EN7Y4qaio5Pjq0BHuswJI0T1RbfKDzvc=.a4b483fb-8245-4ebf-833c-61d01d547746@github.com>
Message-ID: <AtlTfqyhlQq2NR_CiFLc_vcosFJAk9699OgA7USl7ek=.8ab6ccf9-8713-4631-b8ad-0d9c131f0900@github.com>

On Tue, 3 May 2022 20:29:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr001/allthr001.cpp line 170:
> 
>> 168: }
>> 169: 
>> 170: void release(JNIEnv *env, jvmtiThreadInfo *info) {
> 
> How about "releaseThreadInfo"?

Done.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr001/allthr001.cpp line 238:
> 
>> 236:         }
>> 237:         if (printdump == JNI_TRUE) {
>> 238:             printf(" >>> %s", inf.name);
> 
> Don't you want a newline here?

No. This is pre-existing code.
The log looks like:
 >>> Check: 0
 >>> main >>> Reference Handler >>> Finalizer >>> Signal Dispatcher >>> Attach Listener >>> Notification Thread >>> Common-Cleaner >>> MainThread

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr001/allthr001.cpp line 240:
> 
>> 238:             printf(" >>> %s", inf.name);
>> 239:         }
>> 240:         for (j = 0, found = 0; j < thrInfo[ind].unexpected.cnt && !found; j++) {
> 
> found = JNI_FALSE

found is int, not jboolean.
I changed it to bool to be more C++-style

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

PR: https://git.openjdk.java.net/jdk/pull/8512

From dholmes at openjdk.java.net  Wed May  4 00:57:26 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 4 May 2022 00:57:26 GMT
Subject: RFR: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing [v2]
In-Reply-To: <W0XJqGgMTsFqG5zzpkwYElKxsk4gLJ6ALD0zmrvkERY=.a4748b54-5859-4375-b295-715b6df1ed33@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
 <W0XJqGgMTsFqG5zzpkwYElKxsk4gLJ6ALD0zmrvkERY=.a4748b54-5859-4375-b295-715b6df1ed33@github.com>
Message-ID: <dgIZhc6xblGmXugT-If7tsPf8OqsE44ZEc78UyRb4aE=.0420a490-bcbb-4a30-9987-74f402e32cb6@github.com>

On Tue, 3 May 2022 23:20:28 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test counts all "system" threads before the execution and expects that this number remains the same during test execution.
>> This makes the test fragile - JVM may start internal threads, some threads may end.
>> 
>> The fix updates the test:
>> - the test checks only test threads, and verify that the live threads are reported by GetAllThreads and terminated threads are not reported;
>> - dropped "system" thread counting stuff;
>> - added proper deallocation of GetThreadInfo results.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr001/allthr001.cpp line 184:

> 182:     jthread *threads;
> 183:     int i, j;
> 184:     bool found;

Nit: this isn't old style C code, we don't have to declare all variables up front. New variables should be declared where needed.

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

PR: https://git.openjdk.java.net/jdk/pull/8512

From amenkov at openjdk.java.net  Wed May  4 03:40:04 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 4 May 2022 03:40:04 GMT
Subject: RFR: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing [v2]
In-Reply-To: <dgIZhc6xblGmXugT-If7tsPf8OqsE44ZEc78UyRb4aE=.0420a490-bcbb-4a30-9987-74f402e32cb6@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
 <W0XJqGgMTsFqG5zzpkwYElKxsk4gLJ6ALD0zmrvkERY=.a4748b54-5859-4375-b295-715b6df1ed33@github.com>
 <dgIZhc6xblGmXugT-If7tsPf8OqsE44ZEc78UyRb4aE=.0420a490-bcbb-4a30-9987-74f402e32cb6@github.com>
Message-ID: <xtzny3CXaLcLgK8Cnfl7EAVbf1-DgPOCWDOGg1O3DRA=.a3cfde00-7a2f-41b3-b87b-1cff35fdae93@github.com>

On Wed, 4 May 2022 00:54:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr001/allthr001.cpp line 184:
> 
>> 182:     jthread *threads;
>> 183:     int i, j;
>> 184:     bool found;
> 
> Nit: this isn't old style C code, we don't have to declare all variables up front. New variables should be declared where needed.

ok :)
fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8512

From amenkov at openjdk.java.net  Wed May  4 03:40:03 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 4 May 2022 03:40:03 GMT
Subject: RFR: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing [v3]
In-Reply-To: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
Message-ID: <uImo-Cz7mcl6GEAhFN5BwJDYlauo1DbXVUvmYq7KG0o=.464393de-934b-412a-a300-16c33758b497@github.com>

> The test counts all "system" threads before the execution and expects that this number remains the same during test execution.
> This makes the test fragile - JVM may start internal threads, some threads may end.
> 
> The fix updates the test:
> - the test checks only test threads, and verify that the live threads are reported by GetAllThreads and terminated threads are not reported;
> - dropped "system" thread counting stuff;
> - added proper deallocation of GetThreadInfo results.

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

  decreased scope of the variables

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8512/files
  - new: https://git.openjdk.java.net/jdk/pull/8512/files/1539460c..aa74cf6d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8512&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8512&range=01-02

  Stats: 8 lines in 1 file changed: 2 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8512.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8512/head:pull/8512

PR: https://git.openjdk.java.net/jdk/pull/8512

From alanb at openjdk.java.net  Wed May  4 12:12:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 4 May 2022 12:12:48 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
 - Merge with jdk-19+19
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=10
  Stats: 102779 lines in 1140 files changed: 92909 ins; 4219 del; 5651 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From shade at openjdk.java.net  Wed May  4 16:05:06 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 4 May 2022 16:05:06 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
Message-ID: <Q3DstnYGNVgBXkn57bQirgdwlubtfPhnhkirhbjZMjk=.ad2e9a0f-b49c-47ad-b7c3-88037905f3ad@github.com>

On Wed, 4 May 2022 12:12:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75

> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.

So, does this PR pass current GHA checks? I see they are not enabled for this PR. It would be unfortunate for this large integration to break builds/tests for smaller PRs that would follow it.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From cjplummer at openjdk.java.net  Wed May  4 19:06:28 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 4 May 2022 19:06:28 GMT
Subject: RFR: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing [v3]
In-Reply-To: <uImo-Cz7mcl6GEAhFN5BwJDYlauo1DbXVUvmYq7KG0o=.464393de-934b-412a-a300-16c33758b497@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
 <uImo-Cz7mcl6GEAhFN5BwJDYlauo1DbXVUvmYq7KG0o=.464393de-934b-412a-a300-16c33758b497@github.com>
Message-ID: <3v6MIaAZ3s2Pefa9TkJceJsZyVABAkd8mQsrJHx7Nn8=.e440cbd8-bbfc-4419-a2b0-3bd6641602cf@github.com>

On Wed, 4 May 2022 03:40:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test counts all "system" threads before the execution and expects that this number remains the same during test execution.
>> This makes the test fragile - JVM may start internal threads, some threads may end.
>> 
>> The fix updates the test:
>> - the test checks only test threads, and verify that the live threads are reported by GetAllThreads and terminated threads are not reported;
>> - dropped "system" thread counting stuff;
>> - added proper deallocation of GetThreadInfo results.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   decreased scope of the variables

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8512

From sspitsyn at openjdk.java.net  Wed May  4 23:56:20 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 4 May 2022 23:56:20 GMT
Subject: RFR: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing [v3]
In-Reply-To: <uImo-Cz7mcl6GEAhFN5BwJDYlauo1DbXVUvmYq7KG0o=.464393de-934b-412a-a300-16c33758b497@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
 <uImo-Cz7mcl6GEAhFN5BwJDYlauo1DbXVUvmYq7KG0o=.464393de-934b-412a-a300-16c33758b497@github.com>
Message-ID: <1xsvLQhAa1pGZUabqbdi9duECgtGLO3PWMcCL37NV4A=.02bc1f0c-795d-4c7b-b100-10369734ea83@github.com>

On Wed, 4 May 2022 03:40:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test counts all "system" threads before the execution and expects that this number remains the same during test execution.
>> This makes the test fragile - JVM may start internal threads, some threads may end.
>> 
>> The fix updates the test:
>> - the test checks only test threads, and verify that the live threads are reported by GetAllThreads and terminated threads are not reported;
>> - dropped "system" thread counting stuff;
>> - added proper deallocation of GetThreadInfo results.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   decreased scope of the variables

Update looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8512

From sspitsyn at openjdk.java.net  Thu May  5 02:25:12 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 5 May 2022 02:25:12 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
Message-ID: <obecW-tlrdGOcntvR3ze475nlAw-kj12CKCVF-b_JlI=.3e70ef85-3112-416a-8cf5-978ced099032@github.com>

On Wed, 4 May 2022 12:12:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75

I've completed review of new vthread-related tests in the folder serviceability/jvmti.
It includes sub-folders:
 serviceability/jvmti/events
 serviceability/jvmti/negative
 serviceability/jvmti/thread
Thank you, Leonid, for resolving my comments!

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu May  5 09:35:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 09:35:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
 - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=11
  Stats: 99452 lines in 1130 files changed: 91184 ins; 3598 del; 4670 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From mdoerr at openjdk.java.net  Thu May  5 09:38:20 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 5 May 2022 09:38:20 GMT
Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via
 JavaThread::thread_from_jni_environment [v4]
In-Reply-To: <m3txKMlM0WGif0OfyERtoJbU7LDi-RM6t_xx4ejgohI=.e094bdd4-deae-4315-96fa-11df614eca12@github.com>
References: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
 <m3txKMlM0WGif0OfyERtoJbU7LDi-RM6t_xx4ejgohI=.e094bdd4-deae-4315-96fa-11df614eca12@github.com>
Message-ID: <L4Dc2f5zvE7qznOQqSk8UqVzwlvlwLhopzCIEYXMq6c=.a8d5b487-70a5-4de1-9ee9-ff0f8af71103@github.com>

On Tue, 3 May 2022 08:02:57 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. 
>> 
>> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge cast into condition

LGTM.

src/hotspot/share/prims/forte.cpp line 571:

> 569:   JavaThread* thread;
> 570: 
> 571:   if (trace->env_id == NULL || raw_thread == NULL || !raw_thread->is_Java_thread() || (thread = JavaThread::cast(raw_thread))->is_exiting()) {

Line is a bit long! (There are other long lines in this file, too, so, I can live with it.)

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8446

From alanb at openjdk.java.net  Thu May  5 09:47:38 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 09:47:38 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <Q3DstnYGNVgBXkn57bQirgdwlubtfPhnhkirhbjZMjk=.ad2e9a0f-b49c-47ad-b7c3-88037905f3ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
 <Q3DstnYGNVgBXkn57bQirgdwlubtfPhnhkirhbjZMjk=.ad2e9a0f-b49c-47ad-b7c3-88037905f3ad@github.com>
Message-ID: <gGcWBFyWAFSVEUgLsrurXb3OlGSwQT-jj0rOiQbcbUI=.406d3188-fa19-46a1-86cc-31d97c9812ce@github.com>

On Wed, 4 May 2022 16:02:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> So, does this PR pass current GHA checks? I see they are not enabled for this PR. It would be unfortunate for this large integration to break builds/tests for smaller PRs that would follow it.

I've enabled it on my fork and we'll see if it kicks in.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Thu May  5 10:29:07 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Thu, 5 May 2022 10:29:07 GMT
Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via
 JavaThread::thread_from_jni_environment [v5]
In-Reply-To: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
References: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
Message-ID: <GJWl0GpIPKtyGAGZS4j6Cu_K6TiHCiMDHAGlJ_sTIh0=.d0dd046c-d56d-46c4-9fd4-1f4a25e3954b@github.com>

> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. 
> 
> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Break long line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8446/files
  - new: https://git.openjdk.java.net/jdk/pull/8446/files/8d4b60eb..48f45e95

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/8446

From jbachorik at openjdk.java.net  Thu May  5 10:51:16 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 10:51:16 GMT
Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via
 JavaThread::thread_from_jni_environment [v5]
In-Reply-To: <GJWl0GpIPKtyGAGZS4j6Cu_K6TiHCiMDHAGlJ_sTIh0=.d0dd046c-d56d-46c4-9fd4-1f4a25e3954b@github.com>
References: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
 <GJWl0GpIPKtyGAGZS4j6Cu_K6TiHCiMDHAGlJ_sTIh0=.d0dd046c-d56d-46c4-9fd4-1f4a25e3954b@github.com>
Message-ID: <EVfronXai-o7YBHKdTeuV5K7cOPRaWVwY9kJUO6C8cw=.e31f801e-97cf-4035-869e-e3875aa79d4c@github.com>

On Thu, 5 May 2022 10:29:07 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. 
>> 
>> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Break long line

Marked as reviewed by jbachorik (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8446

From jbachorik at openjdk.java.net  Thu May  5 11:35:51 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 11:35:51 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee
Message-ID: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>

A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 

Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.

<hr>
Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.

<br><br>

_Note: This is a followup PR for #8061_

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

Commit messages:
 - 8283849: AsyncGetCallTrace may crash JVM on guarantee

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From duke at openjdk.java.net  Thu May  5 11:44:16 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Thu, 5 May 2022 11:44:16 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <To-MgwbOEvM04C-3UdLxs_O7ZgZEHb6hAvkin6CDBjw=.22aa5b0b-d7dc-4ba9-abb2-c7fa9aa64196@github.com>

On Thu, 5 May 2022 11:28:14 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

src/hotspot/share/code/codeCache.cpp line 658:

> 656:     // when in ASGCT handler things might get rough and not all guarantees are held
> 657:     // if the resolved blob is already a zombie return NULL instead of crashing on guarantee
> 658:     return result != NULL || result->is_zombie() ? NULL : result;

Could you add parentheses around the condition and possibly use `&&` instead of `||`?

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Thu May  5 11:51:47 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 11:51:47 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Make sure the code blob result check is correct

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/2f009671..ce15582a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From dholmes at openjdk.java.net  Thu May  5 12:05:20 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 5 May 2022 12:05:20 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
Message-ID: <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>

On Thu, 5 May 2022 11:51:47 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure the code blob result check is correct

Changes requested by dholmes (Reviewer).

src/hotspot/share/code/codeCache.cpp line 657:

> 655:   if (current_thread != NULL && current_thread->in_asgct()) {
> 656:     // when in ASGCT handler things might get rough and not all guarantees are held
> 657:     // if the resolved blob is already a zombie return NULL instead of crashing on guarantee

Suggestion:

// If called from ACGT the usual invariants may not apply so if we find
// a zombie method just return NULL.

src/hotspot/share/runtime/thread.hpp line 647:

> 645: #endif // __APPLE__ && AARCH64
> 646: 
> 647:  // support ASGCT

Nit: the abbreviation for AsyncGetCallTrace is AGCT not ASGCT

src/hotspot/share/runtime/thread.hpp line 649:

> 647:  // support ASGCT
> 648:  private:
> 649:   bool _in_asgct;

The position of this field may be significant. See if there are gaps in the Thread structure which this bool might be able to fill.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Thu May  5 12:13:18 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 12:13:18 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <KHJ8XYe2PDZQ-ctNweNdMnkcV5VQuEd_yWZPExrJH7E=.087782cb-3acd-4ee0-8ef9-60ec58d8ecda@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Naming and comments cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/ce15582a..71e5a919

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From duke at openjdk.java.net  Thu May  5 12:13:19 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Thu, 5 May 2022 12:13:19 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
 <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
Message-ID: <BxnEQX3eeC0l9aHa53lHzeMQY2jME9TKARge_Sety4Y=.da6ec5f3-767c-49dd-aa02-27b4e0885e31@github.com>

On Thu, 5 May 2022 11:59:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make sure the code blob result check is correct
>
> src/hotspot/share/runtime/thread.hpp line 647:
> 
>> 645: #endif // __APPLE__ && AARCH64
>> 646: 
>> 647:  // support ASGCT
> 
> Nit: the abbreviation for AsyncGetCallTrace is AGCT not ASGCT

I would like to disagree: The abbreviation "ASGCT" is used in multiple places in the JVM, especially in `forte.cpp` (where "AGCT" cannot be found).

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From duke at openjdk.java.net  Thu May  5 12:13:20 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Thu, 5 May 2022 12:13:20 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <BxnEQX3eeC0l9aHa53lHzeMQY2jME9TKARge_Sety4Y=.da6ec5f3-767c-49dd-aa02-27b4e0885e31@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
 <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
 <BxnEQX3eeC0l9aHa53lHzeMQY2jME9TKARge_Sety4Y=.da6ec5f3-767c-49dd-aa02-27b4e0885e31@github.com>
Message-ID: <Nycn5Q0dF71HobNY7eu3C7_5i0-vt8p7a3zNfxqOmpU=.09208861-76ae-4d69-9076-ff33b9b3a3a3@github.com>

On Thu, 5 May 2022 12:07:10 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> src/hotspot/share/runtime/thread.hpp line 647:
>> 
>>> 645: #endif // __APPLE__ && AARCH64
>>> 646: 
>>> 647:  // support ASGCT
>> 
>> Nit: the abbreviation for AsyncGetCallTrace is AGCT not ASGCT
>
> I would like to disagree: The abbreviation "ASGCT" is used in multiple places in the JVM, especially in `forte.cpp` (where "AGCT" cannot be found).

I found "AGCT" only in a method named "Java_MyPackage_ASGCTBaseTest_checkAsyncGetCallTraceCall".

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From dholmes at openjdk.java.net  Thu May  5 12:20:19 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 5 May 2022 12:20:19 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]
In-Reply-To: <KHJ8XYe2PDZQ-ctNweNdMnkcV5VQuEd_yWZPExrJH7E=.087782cb-3acd-4ee0-8ef9-60ec58d8ecda@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <KHJ8XYe2PDZQ-ctNweNdMnkcV5VQuEd_yWZPExrJH7E=.087782cb-3acd-4ee0-8ef9-60ec58d8ecda@github.com>
Message-ID: <XgQpdzN32LKR2tzGAuV9N4182HRUs6l2t-waUHyeRso=.4b3ee1e2-e653-447c-9810-982493aa4cf0@github.com>

On Thu, 5 May 2022 12:13:18 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naming and comments cleanup

Changes requested by dholmes (Reviewer).

src/hotspot/share/runtime/thread.hpp line 649:

> 647:  // support AGCT
> 648:  private:
> 649:   bool _in_agct;

This should actually be in JavaThread as AGCT only operates on JavaThreads.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From dholmes at openjdk.java.net  Thu May  5 12:20:20 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 5 May 2022 12:20:20 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <Nycn5Q0dF71HobNY7eu3C7_5i0-vt8p7a3zNfxqOmpU=.09208861-76ae-4d69-9076-ff33b9b3a3a3@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
 <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
 <BxnEQX3eeC0l9aHa53lHzeMQY2jME9TKARge_Sety4Y=.da6ec5f3-767c-49dd-aa02-27b4e0885e31@github.com>
 <Nycn5Q0dF71HobNY7eu3C7_5i0-vt8p7a3zNfxqOmpU=.09208861-76ae-4d69-9076-ff33b9b3a3a3@github.com>
Message-ID: <KEuGrVhaH0cm3w7_yMsI-RvnHpXxRgUPixrxGr--sKU=.cf3893c5-b08b-42c3-a73c-4ccb82bab1d9@github.com>

On Thu, 5 May 2022 12:08:54 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> I would like to disagree: The abbreviation "ASGCT" is used in multiple places in the JVM, especially in `forte.cpp` (where "AGCT" cannot be found).
>
> I found "AGCT" only in a method named "Java_MyPackage_ASGCTBaseTest_checkAsyncGetCallTraceCall".

My apologies. I've always referred to it by the obvious abbreviation. But if the existing code uses ASGCT then lets be consistent.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Thu May  5 12:24:16 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 12:24:16 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
 <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
Message-ID: <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com>

On Thu, 5 May 2022 12:00:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make sure the code blob result check is correct
>
> src/hotspot/share/runtime/thread.hpp line 649:
> 
>> 647:  // support ASGCT
>> 648:  private:
>> 649:   bool _in_asgct;
> 
> The position of this field may be significant. See if there are gaps in the Thread structure which this bool might be able to fill.

Just to clarify - you mean finding a gap due to padding and putting the field there?
The rest of the fields are usually clustered around the supported functionality so before I insert this flag somewhere in the middle of unrelated fields I want to be sure this is what we want.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Thu May  5 12:43:18 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 12:43:18 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]
In-Reply-To: <XgQpdzN32LKR2tzGAuV9N4182HRUs6l2t-waUHyeRso=.4b3ee1e2-e653-447c-9810-982493aa4cf0@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <KHJ8XYe2PDZQ-ctNweNdMnkcV5VQuEd_yWZPExrJH7E=.087782cb-3acd-4ee0-8ef9-60ec58d8ecda@github.com>
 <XgQpdzN32LKR2tzGAuV9N4182HRUs6l2t-waUHyeRso=.4b3ee1e2-e653-447c-9810-982493aa4cf0@github.com>
Message-ID: <LAH-BYh1iTyawUUIZBJXHheYtOQWhTvUliSewD0UAN4=.c75960d2-3728-43ec-8411-870c262230c9@github.com>

On Thu, 5 May 2022 12:13:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naming and comments cleanup
>
> src/hotspot/share/runtime/thread.hpp line 649:
> 
>> 647:  // support AGCT
>> 648:  private:
>> 649:   bool _in_agct;
> 
> This should actually be in JavaThread as AGCT only operates on JavaThreads.

I will have to do check/cast in `CodeCache::find_blob()` as that may get called from any thread, not just Java threads.
I would assume that having this flag defined at Thread level is a lesser of the evils - or am I wrong here?

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Thu May  5 13:02:58 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 13:02:58 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v4]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <IpUWZy3NvVZh-tSy32PoWV-FydbNqt7xFhrnPsVe9IE=.64bc570d-52a8-4812-9c9b-fd7809a9db06@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  AGCT -> ASGCT

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/71e5a919..caf43e39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=02-03

  Stats: 15 lines in 3 files changed: 4 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Thu May  5 13:02:59 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 13:02:59 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
 <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
 <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com>
Message-ID: <jyip1vb5zb5TM9psbfbn6UND-L4wbhXj6SZsuSowDFg=.444c3adf-df4d-48b4-9403-9061352aeba4@github.com>

On Thu, 5 May 2022 12:20:41 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.hpp line 649:
>> 
>>> 647:  // support ASGCT
>>> 648:  private:
>>> 649:   bool _in_asgct;
>> 
>> The position of this field may be significant. See if there are gaps in the Thread structure which this bool might be able to fill.
>
> Just to clarify - you mean finding a gap due to padding and putting the field there?
> The rest of the fields are usually clustered around the supported functionality so before I insert this flag somewhere in the middle of unrelated fields I want to be sure this is what we want.

I had tried identifying any gaps I might use but found none. Not saying they are none but it is rather difficult to spot anything with all the Thread related attributes spread across many lines, interspersed with the method declarations :(
Any trick or tool I might use to find the right place for this attribute?

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From duke at openjdk.java.net  Thu May  5 13:26:16 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Thu, 5 May 2022 13:26:16 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <jyip1vb5zb5TM9psbfbn6UND-L4wbhXj6SZsuSowDFg=.444c3adf-df4d-48b4-9403-9061352aeba4@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
 <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
 <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com>
 <jyip1vb5zb5TM9psbfbn6UND-L4wbhXj6SZsuSowDFg=.444c3adf-df4d-48b4-9403-9061352aeba4@github.com>
Message-ID: <PoC8IJ3cQ83AARLvvhMvqmERVFhnZLAjAhFzGuSOHN0=.2abeff7f-693a-420b-981a-e524a7aec2bf@github.com>

On Thu, 5 May 2022 12:55:31 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Just to clarify - you mean finding a gap due to padding and putting the field there?
>> The rest of the fields are usually clustered around the supported functionality so before I insert this flag somewhere in the middle of unrelated fields I want to be sure this is what we want.
>
> I had tried identifying any gaps I might use but found none. Not saying they are none but it is rather difficult to spot anything with all the Thread related attributes spread across many lines, interspersed with the method declarations :(
> Any trick or tool I might use to find the right place for this attribute?

An option would be to place it after https://github.com/openjdk/jdk/blob/ce15582a7570b529a4c9b3d500f60fa0a2dc772d/src/hotspot/share/runtime/thread.hpp#L901 but it would make the code less coherent.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Thu May  5 13:45:18 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 5 May 2022 13:45:18 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <PoC8IJ3cQ83AARLvvhMvqmERVFhnZLAjAhFzGuSOHN0=.2abeff7f-693a-420b-981a-e524a7aec2bf@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
 <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
 <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com>
 <jyip1vb5zb5TM9psbfbn6UND-L4wbhXj6SZsuSowDFg=.444c3adf-df4d-48b4-9403-9061352aeba4@github.com>
 <PoC8IJ3cQ83AARLvvhMvqmERVFhnZLAjAhFzGuSOHN0=.2abeff7f-693a-420b-981a-e524a7aec2bf@github.com>
Message-ID: <wE3UaskaPhapLQs9beZquyaV6ms1rtkpsVyapNHI1Wk=.388dbc76-57d6-42c2-bbe6-2919505a1b50@github.com>

On Thu, 5 May 2022 13:21:39 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> I had tried identifying any gaps I might use but found none. Not saying they are none but it is rather difficult to spot anything with all the Thread related attributes spread across many lines, interspersed with the method declarations :(
>> Any trick or tool I might use to find the right place for this attribute?
>
> An option would be to place it after https://github.com/openjdk/jdk/blob/ce15582a7570b529a4c9b3d500f60fa0a2dc772d/src/hotspot/share/runtime/thread.hpp#L901 but it would make the code less coherent.

Ok, moved it a bit around - now the bool field is after an int field which should make things slightly better, I guess.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From coffeys at openjdk.java.net  Thu May  5 16:08:38 2022
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Thu, 5 May 2022 16:08:38 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
Message-ID: <7N1fimic2Cdh1UG_lIkjdUZhX_r-zzC1equf9VbNU7U=.f43339fb-7797-4d84-9c87-472e6db02638@github.com>

On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

Studied the java.io package edits, the new JFR events and the new jcmd dump_to_file functionality. Looks good!

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

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From dcubed at openjdk.java.net  Thu May  5 16:51:18 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 5 May 2022 16:51:18 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v4]
In-Reply-To: <IpUWZy3NvVZh-tSy32PoWV-FydbNqt7xFhrnPsVe9IE=.64bc570d-52a8-4812-9c9b-fd7809a9db06@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <IpUWZy3NvVZh-tSy32PoWV-FydbNqt7xFhrnPsVe9IE=.64bc570d-52a8-4812-9c9b-fd7809a9db06@github.com>
Message-ID: <9y0sKLe1dZat_Av4yr-1u43ApyrnywRBzs_5OqfWD0I=.afb4105c-11ce-40f9-bb95-7f8b490660df@github.com>

On Thu, 5 May 2022 13:02:58 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AGCT -> ASGCT

> I would like to disagree: The abbreviation "ASGCT" is used in multiple places in the JVM,
> especially in `forte.cpp` (where "AGCT" cannot be found).

That was a very old mistake on my part. It should have been `AGCT` instead of `ASGCT`
and I never got around to fixing that.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From darcy at openjdk.java.net  Thu May  5 17:15:49 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 5 May 2022 17:15:49 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
Message-ID: <0ntcEQFUGJN5jQeKnIZrEqQR9CDgkt9aHi-1mzUcKP0=.959c2be4-16c1-4d21-8276-a273e5945658@github.com>

On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From shade at openjdk.java.net  Thu May  5 17:46:09 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 5 May 2022 17:46:09 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
Message-ID: <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>

On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

I am sorry to be a buzzkill here, but this integration would break lots of platforms even when Loom functionality is not enabled/used. For example, running `java -version` on RISC-V runs into many issues: `TemplateInterpreterGenerator::generate_Continuation_doYield_entry` runs into `Unimplemented()`, `UnsafeCopyMemory` asserts about UCM table size, `NativeDeoptInstruction::is_deopt` would run into `Unimplemented()` while being called from signal handler.

This effectively blocks development on those platforms, and it seems to be too much breakage for a preview feature. Are we really breaking these platforms? Do we have plans in place with maintainers of those platforms to fix all this in JDK 19 timeframe? I'd suggest holding off the integration until such a plan and agreement is in place.

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

Changes requested by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu May  5 19:00:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 19:00:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
 <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>
Message-ID: <IClQBci8WY_me9QbqEJc1YmrSDb69SSwbs30vvXk0FE=.1952a7e8-af0d-4c56-a6e3-16459a8026bf@github.com>

On Thu, 5 May 2022 17:43:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am sorry to be a buzzkill here, but this integration would break lots of platforms even when Loom functionality is not enabled/used. For example, running `java -version` on RISC-V runs into many issues: `TemplateInterpreterGenerator::generate_Continuation_doYield_entry` runs into `Unimplemented()`, `UnsafeCopyMemory` asserts about UCM table size, `NativeDeoptInstruction::is_deopt` would run into `Unimplemented()` while being called from signal handler.
> 
> This effectively blocks development on those platforms, and it seems to be too much breakage for a preview feature. Are we really breaking these platforms? Do we have plans in place with maintainers of those platforms to fix all this in JDK 19 timeframe? I'd suggest holding off the integration until such a plan and agreement is in place.

We mailed porters-dev in Sep 2021 to give a heads up that this feature would require porting work so it shouldn't be a surprise. We have been open to including other ports with the initial integration but it was never a goal to have all the ports done in advance of that.

Most of the new code in the VM is only used when running with --enable-preview. You'll see several places that test Continuations::enabled(). It should be possible to get these port running without -enable-preview without much effort. The feature has to be implemented to pass all the tests of course.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From amenkov at openjdk.java.net  Thu May  5 19:45:42 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 5 May 2022 19:45:42 GMT
Subject: Integrated: 8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
 failing
In-Reply-To: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
References: <o019LGsuI1IIwzGLWKNyYWNXSoURVK41ldnQuI-qQRU=.86a0cdf3-1230-4aed-b0c0-3ce884c05b84@github.com>
Message-ID: <t1nLZC0uSz8DhBE55MahKo3Anvxc4gSDS1fC4At9Bws=.282547e8-fc2a-4134-80d9-7b3316ed09f5@github.com>

On Mon, 2 May 2022 23:20:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test counts all "system" threads before the execution and expects that this number remains the same during test execution.
> This makes the test fragile - JVM may start internal threads, some threads may end.
> 
> The fix updates the test:
> - the test checks only test threads, and verify that the live threads are reported by GetAllThreads and terminated threads are not reported;
> - dropped "system" thread counting stuff;
> - added proper deallocation of GetThreadInfo results.

This pull request has now been integrated.

Changeset: 1bba6407
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1bba64070e03ae3e047dc70dca75caeb49813908
Stats:     114 lines in 3 files changed: 48 ins; 42 del; 24 mod

8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is failing

Reviewed-by: sspitsyn, cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/8512

From amenkov at openjdk.java.net  Thu May  5 21:01:47 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 5 May 2022 21:01:47 GMT
Subject: RFR: 8279358:
 vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java
 fails with usage tracker [v2]
In-Reply-To: <H2nOQAQKQUnG_m6DlQz6RRhcLSJUFppJ9DU8FvFC0nY=.a82934ea-be49-4f5e-bb81-d165249a075f@github.com>
References: <H2nOQAQKQUnG_m6DlQz6RRhcLSJUFppJ9DU8FvFC0nY=.a82934ea-be49-4f5e-bb81-d165249a075f@github.com>
Message-ID: <yHqlky0Vlx-XvKW4RiMXjC3W9M6XTTu65KoIgNPyrk4=.f65fb1d3-f27d-427d-92ef-03057eff354c@github.com>

> The test counts calls of intercepted JNI functions, but doesn't completely filter out calls from other threads.
> Function isThreadExpected is used only for ExceptionOccurred function and the function checks only some known JFR/Graal threads.
> 
> The change:
>  - updates the test to count only the calls on the test thread;
>  - adds verbose output.

Alex Menkov 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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into jni_intercept_test
 - Fix the test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8475/files
  - new: https://git.openjdk.java.net/jdk/pull/8475/files/eb4626bb..0356c759

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8475&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8475&range=00-01

  Stats: 22613 lines in 616 files changed: 14253 ins; 4094 del; 4266 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8475.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8475/head:pull/8475

PR: https://git.openjdk.java.net/jdk/pull/8475

From dholmes at openjdk.java.net  Fri May  6 01:21:48 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 May 2022 01:21:48 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]
In-Reply-To: <LAH-BYh1iTyawUUIZBJXHheYtOQWhTvUliSewD0UAN4=.c75960d2-3728-43ec-8411-870c262230c9@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <KHJ8XYe2PDZQ-ctNweNdMnkcV5VQuEd_yWZPExrJH7E=.087782cb-3acd-4ee0-8ef9-60ec58d8ecda@github.com>
 <XgQpdzN32LKR2tzGAuV9N4182HRUs6l2t-waUHyeRso=.4b3ee1e2-e653-447c-9810-982493aa4cf0@github.com>
 <LAH-BYh1iTyawUUIZBJXHheYtOQWhTvUliSewD0UAN4=.c75960d2-3728-43ec-8411-870c262230c9@github.com>
Message-ID: <RSo8VlAIS3JAdPaDSclLiiBaug6iKhbzxCRxHbjC8NE=.8dab82ef-5f7a-47a9-8f3c-fc15c8950edb@github.com>

On Thu, 5 May 2022 12:40:02 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.hpp line 649:
>> 
>>> 647:  // support AGCT
>>> 648:  private:
>>> 649:   bool _in_agct;
>> 
>> This should actually be in JavaThread as AGCT only operates on JavaThreads.
>
> I will have to do check/cast in `CodeCache::find_blob()` as that may get called from any thread, not just Java threads.
> I would assume that having this flag defined at Thread level is a lesser of the evils - or am I wrong here?

We have been actively moving JavaThread fields out of Thread.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From dholmes at openjdk.java.net  Fri May  6 01:34:00 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 May 2022 01:34:00 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <wE3UaskaPhapLQs9beZquyaV6ms1rtkpsVyapNHI1Wk=.388dbc76-57d6-42c2-bbe6-2919505a1b50@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
 <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
 <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com>
 <jyip1vb5zb5TM9psbfbn6UND-L4wbhXj6SZsuSowDFg=.444c3adf-df4d-48b4-9403-9061352aeba4@github.com>
 <PoC8IJ3cQ83AARLvvhMvqmERVFhnZLAjAhFzGuSOHN0=.2abeff7f-693a-420b-981a-e524a7aec2bf@github.com>
 <wE3UaskaPhapLQs9beZquyaV6ms1rtkpsVyapNHI1Wk=.388dbc76-57d6-42c2-bbe6-2919505a1b50@github.com>
Message-ID: <mCkLDZxyr2IDHMvIRrzNW-n60D-N0tBevaW-LByJdOs=.8896c441-c788-4ef1-b8f3-7506f1961d8e@github.com>

On Thu, 5 May 2022 13:42:12 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> An option would be to place it after https://github.com/openjdk/jdk/blob/ce15582a7570b529a4c9b3d500f60fa0a2dc772d/src/hotspot/share/runtime/thread.hpp#L901 but it would make the code less coherent.
>
> Ok, moved it a bit around - now the bool field is after an int field which should make things slightly better, I guess.

At the start of JavaThread we have:

 private:
  bool           _on_thread_list;                // Is set when this JavaThread is added to the Threads list
  OopHandle      _threadObj;                     // The Java level thread object

so adding it next to the existing bool seems good. The accessors don't have to be defined at the same place.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From alanb at openjdk.java.net  Fri May  6 06:48:46 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 6 May 2022 06:48:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v13]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <kw1r-eOnf3xU7xF1-qpb-ddASUTDT60FW0OXSNspvzs=.cd80786d-4dd4-4fbd-bafe-e5786b0d1afd@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3
 - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf
 - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
 - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/9425ab2b...6d968671

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=12
  Stats: 99456 lines in 1130 files changed: 91188 ins; 3598 del; 4670 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From shade at openjdk.java.net  Fri May  6 08:32:46 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 6 May 2022 08:32:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <IClQBci8WY_me9QbqEJc1YmrSDb69SSwbs30vvXk0FE=.1952a7e8-af0d-4c56-a6e3-16459a8026bf@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
 <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>
 <IClQBci8WY_me9QbqEJc1YmrSDb69SSwbs30vvXk0FE=.1952a7e8-af0d-4c56-a6e3-16459a8026bf@github.com>
Message-ID: <h0IQAD8PepuXk5NE_ddzyldmrGQHqYYDKRy_KECVo6E=.2476bbfa-0957-46a3-bd99-e0dee1046f35@github.com>

On Thu, 5 May 2022 18:54:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We mailed porters-dev in Sep 2021 to give a heads up that this feature would require porting work so it shouldn't be a surprise. We have been open to including other ports with the initial integration but it was never a goal to have all the ports done in advance of that.

It is understandable to ship the preview feature not implemented on all platforms. It is even understandable to ship the final product feature that breaks some platforms in an clearly understandable way, prompting platform maintainers to implement the agreed-upon, final Java feature. What I am seeing, though, is that just running `java -version` (!) after integrating a *preview feature* is broken!

> Most of the new code in the VM is only used when running with --enable-preview. You'll see several places that test Continuations::enabled(). It should be possible to get these port running without -enable-preview without much effort. The feature has to be implemented to pass all the tests of course.

It is not as clear-cut, unfortunately. I see there are substantial changes in deopt machinery with post-call NOPs -- and there maybe more stuff lurking after that one is implemented -- so it is not as simple as changing `Unimplemented()` to guarding with `Continuations::enabled()`. So this looks to me that the core deopt machinery is affected, whether Loom is enabled or not. Is the impact of that deopt machinery change on the VM stability and VM ports discussed, understood, documented somewhere?

I would have honestly expected those core changes to be heavily conditionalized with either `ifdef`-s, or runtime checks, or both, so that both unimplemented platforms had the old behavior *and* the implemented platforms had a fallback to old behavior if preview feature was broken. The current code is fine for experimental Loom repo, but I firmly believe mainline should have much stronger safety/reliability requirements.

My fear is that an integration like this would wreck JDK 19 release. So my question stands: Are we breaking those platforms? Are we sure the unconditional VM changes are problem-free, implementable everywhere, etc? The answer might be "Yes, we are integrating, let the chips fall where they may", but I also believe that should be the call made by responsible platform/VM architects, who should explicitly weigh in and accept the risk of wide JDK 19 breakage.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From jbachorik at openjdk.java.net  Fri May  6 08:54:31 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 6 May 2022 08:54:31 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v5]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <JcUJDKjAfGycfDaBcDo5P4esGvBz_uujOsyn72DniUE=.74ccab3f-ab28-4798-9b4d-939cd8e8f1c8@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Move 'in_asgct' flag to JavaThread

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/caf43e39..33ac63eb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=03-04

  Stats: 14 lines in 3 files changed: 7 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Fri May  6 08:54:31 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 6 May 2022 08:54:31 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2]
In-Reply-To: <mCkLDZxyr2IDHMvIRrzNW-n60D-N0tBevaW-LByJdOs=.8896c441-c788-4ef1-b8f3-7506f1961d8e@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <I-GGbIQ_hmFD6PH8ug4CsU_uVZZyqlUdSZtsmkAQ2wY=.cbb33c88-539f-4013-822e-87a2bf91a770@github.com>
 <mCnoC9C5e35TLUqwxe4rL2BQRBtvCQYqb3qdqXLOZmE=.6741e0b9-f1b5-43c6-9a05-f21e491130e4@github.com>
 <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com>
 <jyip1vb5zb5TM9psbfbn6UND-L4wbhXj6SZsuSowDFg=.444c3adf-df4d-48b4-9403-9061352aeba4@github.com>
 <PoC8IJ3cQ83AARLvvhMvqmERVFhnZLAjAhFzGuSOHN0=.2abeff7f-693a-420b-981a-e524a7aec2bf@github.com>
 <wE3UaskaPhapLQs9beZquyaV6ms1rtkpsVyapNHI1Wk=.388dbc76-57d6-42c2-bbe6-2919505a1b50@github.com>
 <mCkLDZxyr2IDHMvIRrzNW-n60D-N0tBevaW-LByJdOs=.8896c441-c788-4ef1-b8f3-7506f1961d8e@github.com>
Message-ID: <8MPK8xoBXqo46Kid6aLCoSB0pSLATvGRcoVnOPlmOmA=.2be3cfd5-3b4c-4c3f-9725-774413f414b4@github.com>

On Fri, 6 May 2022 01:30:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ok, moved it a bit around - now the bool field is after an int field which should make things slightly better, I guess.
>
> At the start of JavaThread we have:
> 
>  private:
>   bool           _on_thread_list;                // Is set when this JavaThread is added to the Threads list
>   OopHandle      _threadObj;                     // The Java level thread object
> 
> so adding it next to the existing bool seems good. The accessors don't have to be defined at the same place.

Ok. Done.
This requires an extra check and a static cast to `JavaThread` in `CodeCache::find_blob()` but it should not be that bad.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Fri May  6 08:54:32 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 6 May 2022 08:54:32 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3]
In-Reply-To: <RSo8VlAIS3JAdPaDSclLiiBaug6iKhbzxCRxHbjC8NE=.8dab82ef-5f7a-47a9-8f3c-fc15c8950edb@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <KHJ8XYe2PDZQ-ctNweNdMnkcV5VQuEd_yWZPExrJH7E=.087782cb-3acd-4ee0-8ef9-60ec58d8ecda@github.com>
 <XgQpdzN32LKR2tzGAuV9N4182HRUs6l2t-waUHyeRso=.4b3ee1e2-e653-447c-9810-982493aa4cf0@github.com>
 <LAH-BYh1iTyawUUIZBJXHheYtOQWhTvUliSewD0UAN4=.c75960d2-3728-43ec-8411-870c262230c9@github.com>
 <RSo8VlAIS3JAdPaDSclLiiBaug6iKhbzxCRxHbjC8NE=.8dab82ef-5f7a-47a9-8f3c-fc15c8950edb@github.com>
Message-ID: <2bq1e0fu0GA9-r2adZq1sy7LszW-Wbg_Cm1LshoALfw=.e78796d9-9769-49f5-ab44-2d6c7c1a6600@github.com>

On Fri, 6 May 2022 01:18:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I will have to do check/cast in `CodeCache::find_blob()` as that may get called from any thread, not just Java threads.
>> I would assume that having this flag defined at Thread level is a lesser of the evils - or am I wrong here?
>
> We have been actively moving JavaThread fields out of Thread.

Ok. Moved to `JavaThread`.
There is a small cost to pay in `CodeCache::find_blob()` where we need to check if the thread is a `JavaThread` because that function can be called also from non-java threads, AFAIK.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Fri May  6 09:40:37 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 6 May 2022 09:40:37 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Move 'in_asgct' flag to JavaThread

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/33ac63eb..949609c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From alanb at openjdk.java.net  Fri May  6 09:51:20 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 6 May 2022 09:51:20 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v13]
In-Reply-To: <kw1r-eOnf3xU7xF1-qpb-ddASUTDT60FW0OXSNspvzs=.cd80786d-4dd4-4fbd-bafe-e5786b0d1afd@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <kw1r-eOnf3xU7xF1-qpb-ddASUTDT60FW0OXSNspvzs=.cd80786d-4dd4-4fbd-bafe-e5786b0d1afd@github.com>
Message-ID: <apoi69wlbi5W27w85tRBUvBvU0od_yc6bHjTJRVmfZ0=.06215232-4cbb-43fe-bd43-4a0fc17a73e4@github.com>

On Fri, 6 May 2022 06:48:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3
>  - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/9425ab2b...6d968671

> It is understandable to ship the preview feature not implemented on all platforms. It is even understandable to ship the final product feature that breaks some platforms in an clearly understandable way, prompting platform maintainers to implement the agreed-upon, final Java feature. What I am seeing, though, is that just running `java -version` (!) after integrating a _preview feature_ is broken!

Preview features need to be implemented by a port before it can be released. For JDK 19 this means that the maintainers of ports will have work to do for both JEP 424 and JEP 425 (ifdef is not an option).

I think the issue that are concerned about is the interim period between the JEP 425 integration and the port/implementation of this feature to other architectures. I think the answer is that it will vary. It may be that some port maintainers decide to do something very short term so they can run without --enable-preview and buy time before they do the port/implementation for JDK 19. Good progress has been reported on at least ppc64le port and maybe that port be ready before others. So yes, some ports may crash until they receive attention, others (like zero) should be able to run tests that don't use --enable-preview. I've no doubt there will be a flurry of changes post integration.

The motivation for Continuations::enabled() was to reduce risk and disable a lot of the new code by default. The motivation wasn't porting but it may be helpful during the interim period. That is probably a topic for loom-dev rather here.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From dholmes at openjdk.java.net  Fri May  6 10:11:49 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 May 2022 10:11:49 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
Message-ID: <Hqgt282AGGOWI7PuVs97N-cyC-dD-SRODG8nDYWZWV0=.5b8d669e-e781-4598-9bc2-a3d82e548257@github.com>

On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Move 'in_asgct' flag to JavaThread

Functionally this looks good now - thanks.

The only concern is the overhead added to `find_blob` to account for this very special case. Can you do some benchmarking of this?

Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Fri May  6 14:23:51 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 6 May 2022 14:23:51 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <Hqgt282AGGOWI7PuVs97N-cyC-dD-SRODG8nDYWZWV0=.5b8d669e-e781-4598-9bc2-a3d82e548257@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
 <Hqgt282AGGOWI7PuVs97N-cyC-dD-SRODG8nDYWZWV0=.5b8d669e-e781-4598-9bc2-a3d82e548257@github.com>
Message-ID: <8VU_enlG3aCFUT3veoiW0n8n5OiM5vskYL0QJsbo1V0=.c786d6f7-8ce2-4f1e-938c-b7fefbca65d9@github.com>

On Fri, 6 May 2022 10:08:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Move 'in_asgct' flag to JavaThread
>
> Functionally this looks good now - thanks.
> 
> The only concern is the overhead added to `find_blob` to account for this very special case. Can you do some benchmarking of this?
> 
> Thanks.

Hi @dholmes-ora , thanks for taking time to review this.

I am running `jmh-jdk-microbenchmarks` now but I am going to be away for a week now so I will get back to you with the results only then.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From dlong at openjdk.java.net  Fri May  6 20:21:46 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 6 May 2022 20:21:46 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
Message-ID: <LomMgJk4PP-0m-9PzyW7gjcfIQl0iv1EwDiXs4zu-2A=.5c762994-a606-4db7-932b-786a10b216c9@github.com>

On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Move 'in_asgct' flag to JavaThread

It seems like you should be able to mitigate the extra overhead by only doing that extra work when we actually see a zombie method, which should be rare.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From amenkov at openjdk.java.net  Fri May  6 20:48:29 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 6 May 2022 20:48:29 GMT
Subject: RFR: 8279358:
 vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java
 fails with usage tracker [v3]
In-Reply-To: <H2nOQAQKQUnG_m6DlQz6RRhcLSJUFppJ9DU8FvFC0nY=.a82934ea-be49-4f5e-bb81-d165249a075f@github.com>
References: <H2nOQAQKQUnG_m6DlQz6RRhcLSJUFppJ9DU8FvFC0nY=.a82934ea-be49-4f5e-bb81-d165249a075f@github.com>
Message-ID: <VDB-7k311cYpI-8Wu4PAciRWPJAOlNQ482uzT6DtuQo=.b56c6a11-203d-4b57-9a86-50060d88ff0f@github.com>

> The test counts calls of intercepted JNI functions, but doesn't completely filter out calls from other threads.
> Function isThreadExpected is used only for ExceptionOccurred function and the function checks only some known JFR/Graal threads.
> 
> The change:
>  - updates the test to count only the calls on the test thread;
>  - adds verbose output.

Alex Menkov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'jni_intercept_test' of github.com:alexmenkov/jdk into jni_intercept_test
 - Merge branch 'openjdk:master' into jni_intercept_test
 - Fix the test
 - get rid of isThreadExpected
 - Fix the test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8475/files
  - new: https://git.openjdk.java.net/jdk/pull/8475/files/0356c759..0b5da592

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8475&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8475&range=01-02

  Stats: 2777 lines in 101 files changed: 2187 ins; 240 del; 350 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8475.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8475/head:pull/8475

PR: https://git.openjdk.java.net/jdk/pull/8475

From dholmes at openjdk.java.net  Fri May  6 23:14:39 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 May 2022 23:14:39 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <LomMgJk4PP-0m-9PzyW7gjcfIQl0iv1EwDiXs4zu-2A=.5c762994-a606-4db7-932b-786a10b216c9@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
 <LomMgJk4PP-0m-9PzyW7gjcfIQl0iv1EwDiXs4zu-2A=.5c762994-a606-4db7-932b-786a10b216c9@github.com>
Message-ID: <pZyLOy1wrusBmP5BBPwJLdtQYeUYsKOjEMkQcThCmy8=.c3fb9ff3-fee9-4988-a38c-ae1938f4458d@github.com>

On Fri, 6 May 2022 20:17:53 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Move 'in_asgct' flag to JavaThread
>
> It seems like you should be able to mitigate the extra overhead by only doing that extra work when we actually see a zombie method, which should be rare.

Yes good point @dean-long ! Check for the zombie first and only then do the expensive Thread::current_or_null_safe() etc.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From dholmes at openjdk.java.net  Fri May  6 23:22:52 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 May 2022 23:22:52 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
Message-ID: <qKd4Pi5TPkeVJ-8ZPUyPsydx7EvwrraVfdH4Js0OjEo=.75131bd2-e606-4146-b447-24cb5a05e710@github.com>

On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Move 'in_asgct' flag to JavaThread

Looking more closely this even be put in a new final clause in the guarantee:


guarantee(result == NULL || 
          !result->is_zombie() || 
          result->is_locked_by_vm() || 
          VMError::is_error_reported() ||
          result->is_zombie() && current_thread_in_asgct()
          , "unsafe access to zombie method");


where `current_thread_in_asgct()` is a static helper. That addresses all overhead concerns.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From dlong at openjdk.java.net  Sat May  7 00:09:46 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 7 May 2022 00:09:46 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
Message-ID: <nqOx4DNuSkpFz91NmY_4eEkbSxzuIGNrKDqT7VqdibA=.e1b55bea-3ba7-4bc8-8b65-df8cc1c541ee@github.com>

On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Move 'in_asgct' flag to JavaThread

David, your example has an extra || result->is_zombie(), but otherwise this sounds perfect.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From amenkov at openjdk.java.net  Sat May  7 00:59:41 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Sat, 7 May 2022 00:59:41 GMT
Subject: RFR: 8279358:
 vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java
 fails with usage tracker [v3]
In-Reply-To: <VDB-7k311cYpI-8Wu4PAciRWPJAOlNQ482uzT6DtuQo=.b56c6a11-203d-4b57-9a86-50060d88ff0f@github.com>
References: <H2nOQAQKQUnG_m6DlQz6RRhcLSJUFppJ9DU8FvFC0nY=.a82934ea-be49-4f5e-bb81-d165249a075f@github.com>
 <VDB-7k311cYpI-8Wu4PAciRWPJAOlNQ482uzT6DtuQo=.b56c6a11-203d-4b57-9a86-50060d88ff0f@github.com>
Message-ID: <3DdkLjG-1N8njbBLFGLyWL2NIQ5_O1_n69GNB26Syrk=.a14c1339-5a7d-47e2-9d3b-1d09a9e60ad2@github.com>

On Fri, 6 May 2022 20:48:29 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test counts calls of intercepted JNI functions, but doesn't completely filter out calls from other threads.
>> Function isThreadExpected is used only for ExceptionOccurred function and the function checks only some known JFR/Graal threads.
>> 
>> The change:
>>  - updates the test to count only the calls on the test thread;
>>  - adds verbose output.
>
> Alex Menkov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'jni_intercept_test' of github.com:alexmenkov/jdk into jni_intercept_test
>  - Merge branch 'openjdk:master' into jni_intercept_test
>  - Fix the test
>  - get rid of isThreadExpected
>  - Fix the test

I did something wrong with the PR, going to recreate it

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

PR: https://git.openjdk.java.net/jdk/pull/8475

From amenkov at openjdk.java.net  Sat May  7 00:59:42 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Sat, 7 May 2022 00:59:42 GMT
Subject: Withdrawn: 8279358:
 vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java
 fails with usage tracker
In-Reply-To: <H2nOQAQKQUnG_m6DlQz6RRhcLSJUFppJ9DU8FvFC0nY=.a82934ea-be49-4f5e-bb81-d165249a075f@github.com>
References: <H2nOQAQKQUnG_m6DlQz6RRhcLSJUFppJ9DU8FvFC0nY=.a82934ea-be49-4f5e-bb81-d165249a075f@github.com>
Message-ID: <Sj2e_UKDQx5pBr8wmVuSMfJ5k0cgjnJaI3zlc8NrwBU=.822f71ba-2a4b-44d0-a13a-aa5b01986151@github.com>

On Fri, 29 Apr 2022 21:39:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test counts calls of intercepted JNI functions, but doesn't completely filter out calls from other threads.
> Function isThreadExpected is used only for ExceptionOccurred function and the function checks only some known JFR/Graal threads.
> 
> The change:
>  - updates the test to count only the calls on the test thread;
>  - adds verbose output.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8475

From dholmes at openjdk.java.net  Sat May  7 02:11:44 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 7 May 2022 02:11:44 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
Message-ID: <TF3-bYD-XkvoUiRmWS_4rMORxU4nJZBO6NMHN8Pnfqw=.d012e7ae-c5f2-4f01-826d-ce5b2a3d961f@github.com>

On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Move 'in_asgct' flag to JavaThread

Good catch!

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From stuefe at openjdk.java.net  Sat May  7 03:46:45 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 7 May 2022 03:46:45 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <8VU_enlG3aCFUT3veoiW0n8n5OiM5vskYL0QJsbo1V0=.c786d6f7-8ce2-4f1e-938c-b7fefbca65d9@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
 <Hqgt282AGGOWI7PuVs97N-cyC-dD-SRODG8nDYWZWV0=.5b8d669e-e781-4598-9bc2-a3d82e548257@github.com>
 <8VU_enlG3aCFUT3veoiW0n8n5OiM5vskYL0QJsbo1V0=.c786d6f7-8ce2-4f1e-938c-b7fefbca65d9@github.com>
Message-ID: <Y7c2esj0kc4C24uD1rK9u3swBd0pMiYHgfT2I8BLgak=.5c39d15a-505d-4faf-8172-ca0c674ce315@github.com>

On Fri, 6 May 2022 14:20:30 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Functionally this looks good now - thanks.
>> 
>> The only concern is the overhead added to `find_blob` to account for this very special case. Can you do some benchmarking of this?
>> 
>> Thanks.
>
> Hi @dholmes-ora , thanks for taking time to review this.
> 
> I am running `jmh-jdk-microbenchmarks` now but I am going to be away for a week now so I will get back to you with the results only then.

Hi @jbachorik, thanks a lot for taking my suggestion. This looks way less intrusive now!

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From stuefe at openjdk.java.net  Sat May  7 05:02:35 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 7 May 2022 05:02:35 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
Message-ID: <6ikleowciR73wkChDKRAhEgUEuHH1ZtFXze7VjptS3Q=.29ab42a4-4926-420c-8ce8-8ed2db7ec8db@github.com>

On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Move 'in_asgct' flag to JavaThread

src/hotspot/share/prims/forte.cpp line 594:

> 592:   }
> 593: 
> 594:   thread->set_in_asgct(true);

Suggestion: Use a small RAII Mark object instead. That way you prevent future errors if someone should add a return in the mids of AGCT.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From alanb at openjdk.java.net  Sat May  7 06:04:51 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 7 May 2022 06:04:51 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v14]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <3Qd4HYCpL8oQztouBMiY7c_7lMBS16X23WTpP65FIzk=.6e4209ba-ce7f-4049-807b-5b6b6ad459ff@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Refresh 4e99b5185eef9398c4cc4e90544de4a3153d61a9
 - Merge with 5212535a276a92d96ca20bdcfccfbce956febdb1
 - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3
 - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf
 - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
 - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5212535a...df43e6fc

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=13
  Stats: 99468 lines in 1133 files changed: 91198 ins; 3598 del; 4672 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Sat May  7 08:09:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 7 May 2022 08:09:45 GMT
Subject: Integrated: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <qTZgwH4SV8Df3Gz9y3-k6b_F275b3pEmB7wGBYQScK4=.29139c98-29de-41e0-9541-2e686005cb31@github.com>

On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

This pull request has now been integrated.

Changeset: 9583e365
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9583e3657e43cc1c6f2101a64534564db2a9bd84
Stats:     99468 lines in 1133 files changed: 91198 ins; 3598 del; 4672 mod

8284161: Implementation of Virtual Threads (Preview)

Co-authored-by: Ron Pressler <rpressler at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Andrew Haley <aph at openjdk.org>
Co-authored-by: Rickard B?ckman <rbackman at openjdk.org>
Co-authored-by: Markus Gr?nlund <mgronlun at openjdk.org>
Co-authored-by: Leonid Mesnik <lmesnik at openjdk.org>
Co-authored-by: Serguei Spitsyn <sspitsyn at openjdk.org>
Co-authored-by: Chris Plummer <cjplummer at openjdk.org>
Co-authored-by: Coleen Phillimore <coleenp at openjdk.org>
Co-authored-by: Robbin Ehn <rehn at openjdk.org>
Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Co-authored-by: Thomas Schatzl <tschatzl at openjdk.org>
Co-authored-by: Sergey Kuksenko <skuksenko at openjdk.org>
Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From ayang at openjdk.java.net  Mon May  9 08:06:29 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 9 May 2022 08:06:29 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v6]
In-Reply-To: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
Message-ID: <6q2SxqnLGaxGSFuk-1LU2iRIjPFEugDVxiEBAkzToJA=.4708294b-9d73-4998-b5bc-30f6a92f3fc1@github.com>

> Simple rename and some comments update.
> 
> Test: build

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - merge
 - review
 - comment
 - Rework reference type initialization
   
   Signed-off-by: Albert Yang <albert.m.yang at oracle.com>
 - Remove REF_ enum for java.lang.ref.Reference
   
   Signed-off-by: Albert Yang <albert.m.yang at oracle.com>
 - review
 - ref-rename

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

Changes: https://git.openjdk.java.net/jdk/pull/8332/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=05
  Stats: 119 lines in 14 files changed: 81 ins; 31 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8332.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332

PR: https://git.openjdk.java.net/jdk/pull/8332

From duke at openjdk.java.net  Mon May  9 08:20:59 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 9 May 2022 08:20:59 GMT
Subject: Integrated: 8285794: AsyncGetCallTrace might acquire a lock via
 JavaThread::thread_from_jni_environment
In-Reply-To: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
References: <NwntBuBPe6wDPyQwl_CLJciHoKt9JeBW73CuzMFZkrg=.24bf7ef8-f219-4f16-b283-3bd3b93d0856@github.com>
Message-ID: <_BOhxnPQETIY7FOlNzMt85lE-mGHzT_hYRnrSFLeEFM=.33512418-56ff-4d54-bc9d-b9321a785bc8@github.com>

On Thu, 28 Apr 2022 09:38:30 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. 
> 
> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent.

This pull request has now been integrated.

Changeset: d4474b58
Author:    Johannes Bechberger <johannes.bechberger at sap.com>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d4474b5816c2ec8daaf1c905b77d8ba4e23c9439
Stats:     7 lines in 1 file changed: 4 ins; 0 del; 3 mod

8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment

Reviewed-by: dholmes, mdoerr, jbachorik

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

PR: https://git.openjdk.java.net/jdk/pull/8446

From asotona at openjdk.java.net  Mon May  9 16:05:46 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 9 May 2022 16:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound
 assignments
Message-ID: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>

Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.

The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.

The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 

Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.

Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.

Thanks for your review,
Adam

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244681
  Stats: 449 lines in 26 files changed: 444 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From erikj at openjdk.java.net  Mon May  9 16:33:56 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 9 May 2022 16:33:56 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <QMW2y8ihFHz3GPVQLMACiUV5aGbvwcreUKbGfVwaWGg=.2b5fe22c-6331-4ac2-a05d-44a1b65e85c0@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8599

From lmesnik at openjdk.java.net  Mon May  9 17:29:10 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 9 May 2022 17:29:10 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
Message-ID: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>

The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.

It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.

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

Commit messages:
 - 8285739: disable EA when both JVMTI and Preview are enabled

Changes: https://git.openjdk.java.net/jdk/pull/8589/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8589&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285739
  Stats: 10 lines in 3 files changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8589.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8589/head:pull/8589

PR: https://git.openjdk.java.net/jdk/pull/8589

From prr at openjdk.java.net  Mon May  9 17:55:55 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 May 2022 17:55:55 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cih52bus7vW_1tDS7D7szxNTdayfjQxSeHRJhL99DSc=.f5a417b9-844a-4a34-b0b4-8591ac4e28cb@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Marked as reviewed by prr (Reviewer).

test/langtools/tools/javac/lint/LossyConversions.java line 131:

> 129:     @SuppressWarnings("lossy-conversions")
> 130:     public void supressedLossyConversions() {
> 131:         byte a = 0;

you might want to spell suppressed correctly.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From lmesnik at openjdk.java.net  Mon May  9 18:03:08 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 9 May 2022 18:03:08 GMT
Subject: Withdrawn: 8285739: disable EA when both JVMTI and Preview are enabled
In-Reply-To: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
Message-ID: <o54q7DaUlM2_Ed6xXz5LRXbsJX-YJfai74iSXkH_v30=.e21d02dc-6209-4726-9e0c-84d522247f25@github.com>

On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
> 
> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From prr at openjdk.java.net  Mon May  9 18:36:59 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 May 2022 18:36:59 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <TNi7tutFJLMg6yutpu2AsFme3MkCanqOVXcfb4iSX0A=.431d79e6-1f09-4370-8057-3784d9a6864e@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From kvn at openjdk.java.net  Mon May  9 18:42:50 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 9 May 2022 18:42:50 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
In-Reply-To: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
Message-ID: <ECwHq2JwJ_wCfq_ycbjqeqhUvLosju3aVDpo-IDvc0k=.90a915c2-f0ee-45cc-a0b4-c307bad700a3@github.com>

On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
> 
> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8589

From cjplummer at openjdk.java.net  Mon May  9 19:46:57 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 9 May 2022 19:46:57 GMT
Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java
 failing with java.lang.AssertionError: Should have a hidden class [v2]
In-Reply-To: <fqSn47jxVZZMqCQ3scTdNWviQ_F5AVpW9GK6uhaSm4I=.77ff8bee-64e1-4a5a-91e7-3ea4da7b8c0a@github.com>
References: <VhLwLyEuWUoNnG9bTxeEJXqbyFs9UunjMcYlKM5D5Q8=.e81a5e18-b820-4261-83a5-cabb94579f11@github.com>
 <fqSn47jxVZZMqCQ3scTdNWviQ_F5AVpW9GK6uhaSm4I=.77ff8bee-64e1-4a5a-91e7-3ea4da7b8c0a@github.com>
Message-ID: <thBXSuv69syj4x1akxOB_anfXHiS_4HPriPpkUIHFwc=.8ff888a4-eb14-4f06-adc2-4e6e0115baac@github.com>

On Thu, 28 Apr 2022 21:58:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The test failed if GC happens somewhere between
>> Class<?> c = Class.forName("TestClass", true, dummyloader);
>> and
>> OutputAnalyzer output = executor.execute("VM.classloader_stats");
>> 
>> The fix is to make hc static as Chris proposed. 
>> 
>> To verfiy fix I add System.gc() before executor.execute("VM.classloader_stats");
>
> Leonid Mesnik 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:
> 
>  - comment fixed
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123
>  - fix

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8438

From darcy at openjdk.java.net  Mon May  9 20:26:56 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 9 May 2022 20:26:56 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <8O_QfMi1b_fhddBS7yzm9cwzf-l6nWbfNs6qFJWdtuU=.22f44b80-54e8-4249-8ece-d02be29f4267@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

I see there is already a bug filed to address situations found by the new warning in the JDK's libraries (JDK-8286374). As a matter of policy, I recommend the (potential) warnings be addressed in at least the java.base and java.desktop modules before the new warning is enabled. In other words, a priority should be given to keeping java.base and java.desktop compiling successfully with all warnings enabled.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From cjplummer at openjdk.java.net  Mon May  9 21:17:55 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 9 May 2022 21:17:55 GMT
Subject: RFR: 8286438: Add jhsdb jstack processing without --mixed in efh
In-Reply-To: <Gg3kYyHr2FVU5WMmrsfRhjB_3z-0-QyOvUMU4rO43oQ=.5cb2a8ad-c943-4ae2-a2c7-385fa197ce5a@github.com>
References: <Gg3kYyHr2FVU5WMmrsfRhjB_3z-0-QyOvUMU4rO43oQ=.5cb2a8ad-c943-4ae2-a2c7-385fa197ce5a@github.com>
Message-ID: <zfVMBybxqZXE0gUxRG3JXI0BR7ij96QvZZoTXOHESwE=.c9e878a2-f39d-4526-9a5e-22bff849cdd1@github.com>

On Mon, 9 May 2022 20:35:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The default is required only to set the same depth level in the tree on HTML page for default and mixed mode.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8610

From amenkov at openjdk.java.net  Mon May  9 21:33:20 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 9 May 2022 21:33:20 GMT
Subject: RFR: 8279358:
 vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java
 fails with usage tracker
Message-ID: <uu8mRgNuhwkn7dHQYFMxIrYDXVIDH-4E3cnzlyEtRjU=.fcfb44f5-d922-4bb2-8f7a-bfefaf5e722a@github.com>

isThreadExpected function checks only some known JFR/Graal threads.
This approach requires to keep this function up to date (add other internal threads like usage tracker, loom, etc).

To avoid this updated all tests which use it, now the tests filter out all unknown threads.

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

Commit messages:
 - fixed all isThreadExpected callers

Changes: https://git.openjdk.java.net/jdk/pull/8614/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8614&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279358
  Stats: 209 lines in 10 files changed: 131 ins; 40 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8614.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8614/head:pull/8614

PR: https://git.openjdk.java.net/jdk/pull/8614

From rrich at openjdk.java.net  Mon May  9 21:34:55 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 9 May 2022 21:34:55 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
In-Reply-To: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
Message-ID: <BQUCK_UVsWScuLJq-9rIDGg2vQMuuFcPYELldWiDNOU=.22b8fb9e-2369-4825-adec-f1301931e155@github.com>

On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
> 
> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.

Hi Leonid,

have you done some testing? [JDK-8227745](https://bugs.openjdk.java.net/browse/JDK-8227745) came with a bunch of tests. I wonder how they behave with your change.

Thanks, Richard.

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From lmesnik at openjdk.java.net  Mon May  9 21:51:56 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 9 May 2022 21:51:56 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
In-Reply-To: <BQUCK_UVsWScuLJq-9rIDGg2vQMuuFcPYELldWiDNOU=.22b8fb9e-2369-4825-adec-f1301931e155@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
 <BQUCK_UVsWScuLJq-9rIDGg2vQMuuFcPYELldWiDNOU=.22b8fb9e-2369-4825-adec-f1301931e155@github.com>
Message-ID: <Q1XCK6Yif2xdxgUdtvRXzwM9Cu9yHx5ImfbKBw53nGo=.c0326397-416a-48ec-8098-d637d26cbc41@github.com>

On Mon, 9 May 2022 21:31:12 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Hi Leonid,
> 
> have you done some testing? [JDK-8227745](https://bugs.openjdk.java.net/browse/JDK-8227745) came with a bunch of tests. I wonder how they behave with your change.
> 
> Thanks, Richard.

Thank you for looking on this.

The EA-related tests passed and still pass when are executed without any additional options.  There is a special mode when the test runs main() method in the virtual thread. Test IterateHeapWithEscapeAnalysisEnabled.java failed before the fix and start passing after my fix. It failed because before the fix EscapeBarrier was disabled while EA was enabled and we got incorrect data.
Unfortunately, I was unable to run EATests.java in this mode even before the fix. (Not all tests are compatible with this "wrapper" mode)

The goal is to restore the same behavior as it was before JDK-8227745 is implemented when virtual threads are enabled.

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From lmesnik at openjdk.java.net  Mon May  9 21:51:57 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 9 May 2022 21:51:57 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
In-Reply-To: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
Message-ID: <TxfYLxPubKbvz1NwaTkYaHf5x0CCYXWMizu63V1UA40=.65b807d6-debc-4420-8eb0-6c8890776e2f@github.com>

On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
> 
> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.

Also I run all our testing on the linux-x64-debug to ensure that there are no regressions.

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From lmesnik at openjdk.java.net  Mon May  9 22:05:05 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 9 May 2022 22:05:05 GMT
Subject: RFR: 8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak
 native memory
In-Reply-To: <JYzEvkOmGuug979lJ9LWBR9CXg1k7GiDfETlpCUPelw=.71dd5f3d-dcf1-428f-b89c-79349dacbfbd@github.com>
References: <JYzEvkOmGuug979lJ9LWBR9CXg1k7GiDfETlpCUPelw=.71dd5f3d-dcf1-428f-b89c-79349dacbfbd@github.com>
Message-ID: <5l5s-2txgF3FLxnQQkQ0_GfdYPTdtKs7D4p0phm9ym4=.86818859-37dc-4dbe-9c1d-c073b4d1bf77@github.com>

On Mon, 9 May 2022 20:15:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to nsk_jvmti_threadByName() to solve a native memory leak.
> 
> This fix has been stress tested with my StressWrapper60M_NMT_detail_suspendthrd003.java
> test and I did NMT detailed monitoring for the whole 60M run. Total committed memory has
> gone down from 1.17GB to 300MB. Prior to my last rebase, it was down to 239MB.
> 
> I ran the fix thru Mach5 Tier[1-7] with no failures. I just rebased the fix to the latest jdk/jdk
> and Mach5 Tier[1-3] have passed with no failures. Tier[45] are still running.

Marked as reviewed by lmesnik (Reviewer).

Yes, I agree, the fix is trivial.

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

PR: https://git.openjdk.java.net/jdk/pull/8609

From dcubed at openjdk.java.net  Mon May  9 22:05:06 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 9 May 2022 22:05:06 GMT
Subject: RFR: 8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak
 native memory
In-Reply-To: <5l5s-2txgF3FLxnQQkQ0_GfdYPTdtKs7D4p0phm9ym4=.86818859-37dc-4dbe-9c1d-c073b4d1bf77@github.com>
References: <JYzEvkOmGuug979lJ9LWBR9CXg1k7GiDfETlpCUPelw=.71dd5f3d-dcf1-428f-b89c-79349dacbfbd@github.com>
 <5l5s-2txgF3FLxnQQkQ0_GfdYPTdtKs7D4p0phm9ym4=.86818859-37dc-4dbe-9c1d-c073b4d1bf77@github.com>
Message-ID: <ccEj3CROUFGnOl_Y895PSNLUNLuVYhAR9-CXL-PGxHs=.81bc3a6f-df02-4c1f-9e16-210f101dae96@github.com>

On Mon, 9 May 2022 21:57:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> A trivial fix to nsk_jvmti_threadByName() to solve a native memory leak.
>> 
>> This fix has been stress tested with my StressWrapper60M_NMT_detail_suspendthrd003.java
>> test and I did NMT detailed monitoring for the whole 60M run. Total committed memory has
>> gone down from 1.17GB to 300MB. Prior to my last rebase, it was down to 239MB.
>> 
>> I ran the fix thru Mach5 Tier[1-7] with no failures. I just rebased the fix to the latest jdk/jdk
>> and Mach5 Tier[1-3] have passed with no failures. Tier[45] are still running.
>
> Marked as reviewed by lmesnik (Reviewer).

@lmesnik - Thanks for the review!

Do you agree that this is a trivial fix?

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

PR: https://git.openjdk.java.net/jdk/pull/8609

From dcubed at openjdk.java.net  Mon May  9 22:05:06 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 9 May 2022 22:05:06 GMT
Subject: RFR: 8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak
 native memory
In-Reply-To: <JYzEvkOmGuug979lJ9LWBR9CXg1k7GiDfETlpCUPelw=.71dd5f3d-dcf1-428f-b89c-79349dacbfbd@github.com>
References: <JYzEvkOmGuug979lJ9LWBR9CXg1k7GiDfETlpCUPelw=.71dd5f3d-dcf1-428f-b89c-79349dacbfbd@github.com>
Message-ID: <mktPvIgVj0I2rkrOWUnTwa4wilVxH3RMb-LlFxRgC5o=.253c72b8-44fb-4521-9ddb-6c4f8faa4f01@github.com>

On Mon, 9 May 2022 20:15:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to nsk_jvmti_threadByName() to solve a native memory leak.
> 
> This fix has been stress tested with my StressWrapper60M_NMT_detail_suspendthrd003.java
> test and I did NMT detailed monitoring for the whole 60M run. Total committed memory has
> gone down from 1.17GB to 300MB. Prior to my last rebase, it was down to 239MB.
> 
> I ran the fix thru Mach5 Tier[1-7] with no failures. I just rebased the fix to the latest jdk/jdk
> and Mach5 Tier[1-3] have passed with no failures. Tier[45] are still running.

Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8609

From dcubed at openjdk.java.net  Mon May  9 22:06:21 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 9 May 2022 22:06:21 GMT
Subject: Integrated: 8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak
 native memory
In-Reply-To: <JYzEvkOmGuug979lJ9LWBR9CXg1k7GiDfETlpCUPelw=.71dd5f3d-dcf1-428f-b89c-79349dacbfbd@github.com>
References: <JYzEvkOmGuug979lJ9LWBR9CXg1k7GiDfETlpCUPelw=.71dd5f3d-dcf1-428f-b89c-79349dacbfbd@github.com>
Message-ID: <dehRqj55bP0DNdjtiSpXnMInCZ5sbd7jjl14UzpI0_c=.fef21112-2073-43c1-a631-8925c4d3e8d4@github.com>

On Mon, 9 May 2022 20:15:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to nsk_jvmti_threadByName() to solve a native memory leak.
> 
> This fix has been stress tested with my StressWrapper60M_NMT_detail_suspendthrd003.java
> test and I did NMT detailed monitoring for the whole 60M run. Total committed memory has
> gone down from 1.17GB to 300MB. Prior to my last rebase, it was down to 239MB.
> 
> I ran the fix thru Mach5 Tier[1-7] with no failures. I just rebased the fix to the latest jdk/jdk
> and Mach5 Tier[1-3] have passed with no failures. Tier[45] are still running.

This pull request has now been integrated.

Changeset: 61450bb0
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/61450bb061ecda9700ddbd387a1f0659ebd1cced
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8283651: nsk/jvmti/SuspendThread/suspendthrd003 may leak native memory

Reviewed-by: lmesnik

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

PR: https://git.openjdk.java.net/jdk/pull/8609

From rrich at openjdk.java.net  Mon May  9 22:10:55 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 9 May 2022 22:10:55 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
In-Reply-To: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
Message-ID: <ICQM9atSuWoR5FDpwkgJTC7eRAyo9HaC_KiSP31vkgM=.60c1c6b9-7cb3-4466-b300-af3d8b6ed1ef@github.com>

On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
> 
> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.

Hi Leonid,

your changes look good to me.

Thanks, Richard.

Ok, thanks for letting me know.

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

Marked as reviewed by rrich (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8589

From iklam at openjdk.java.net  Tue May 10 04:09:57 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 10 May 2022 04:09:57 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
Message-ID: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>

The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.

It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.

I also cleaned up related code in the JDK and HotSpot.

Testing:
- Passed tiers 1 and 2
- Tiers 3, 4, 5 are in progress

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

Commit messages:
 - 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

Changes: https://git.openjdk.java.net/jdk/pull/8622/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8622&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286441
  Stats: 193 lines in 15 files changed: 0 ins; 144 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8622.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8622/head:pull/8622

PR: https://git.openjdk.java.net/jdk/pull/8622

From alanb at openjdk.java.net  Tue May 10 05:17:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 05:17:49 GMT
Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java
 failing with java.lang.AssertionError: Should have a hidden class [v2]
In-Reply-To: <fqSn47jxVZZMqCQ3scTdNWviQ_F5AVpW9GK6uhaSm4I=.77ff8bee-64e1-4a5a-91e7-3ea4da7b8c0a@github.com>
References: <VhLwLyEuWUoNnG9bTxeEJXqbyFs9UunjMcYlKM5D5Q8=.e81a5e18-b820-4261-83a5-cabb94579f11@github.com>
 <fqSn47jxVZZMqCQ3scTdNWviQ_F5AVpW9GK6uhaSm4I=.77ff8bee-64e1-4a5a-91e7-3ea4da7b8c0a@github.com>
Message-ID: <xIhANjDXynR1OiOsQQY1886kttZtdXyXI8xzPtMTX7I=.bee1807d-b421-431d-a4a3-aea23a0b1417@github.com>

On Thu, 28 Apr 2022 21:58:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The test failed if GC happens somewhere between
>> Class<?> c = Class.forName("TestClass", true, dummyloader);
>> and
>> OutputAnalyzer output = executor.execute("VM.classloader_stats");
>> 
>> The fix is to make hc static as Chris proposed. 
>> 
>> To verfiy fix I add System.gc() before executor.execute("VM.classloader_stats");
>
> Leonid Mesnik 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:
> 
>  - comment fixed
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123
>  - fix

I assume you'll remove this test from the-Xcomp exclude list (test/hotspot/jtreg/ProblemList-Xcomp.txt) as part of this change,

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

PR: https://git.openjdk.java.net/jdk/pull/8438

From asotona at openjdk.java.net  Tue May 10 08:46:45 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 10 May 2022 08:46:45 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <oWxFgbGHRAk_wFpGtPGtfrAlzLUVXctQCCRZ9pi43Mg=.ee995996-668b-4509-98c0-76337a2f9818@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

I agree with the priority to keep java.base and java.desktop clean from possibly lossy conversions, so the related issues should probably raise from P4 priority level.

However this lint warning as a part of the javac is critical to confirm that the situations have been correctly addressed.
If we want to avoid "blind" patching, we only two possible scenarios:
1. big homogenous patch including hundreds of fixed lines of code across many "moving-target" classes, together with lint warning implemented and enabled 
2. javac lint patch (disabled for affected JDK modules build) goes first, so each case can be resolved, reviewed and validated in individual patch 

>From complexity and cost perspective I prefer the second scenario.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Tue May 10 09:07:44 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 10 May 2022 09:07:44 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v2]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  8244681: Add a warning for possibly lossy conversion in compound assignments
  recommended correction of the warning wording
  fixed typo in test method name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/47779ba5..6b3942b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From dfuchs at openjdk.java.net  Tue May 10 11:16:48 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 10 May 2022 11:16:48 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230:

> 228:         List<SubRegistry> l = new ArrayList<>();
> 229:         for (Class<?> c : categoryMap.keySet()) {
> 230:             if (c.isInstance(provider)) {

Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE.

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From aturbanov at openjdk.java.net  Tue May 10 11:35:04 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 10 May 2022 11:35:04 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
 <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>
Message-ID: <iyPHYWiIL0mqxp3iaAaDT3pMp6tFWEpERqLGJ2sgiao=.1f3e0af5-0d64-4769-9282-c120201fe5e0@github.com>

On Tue, 10 May 2022 11:10:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>>   apply suggestion to avoid second Method.invoke call
>
> src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230:
> 
>> 228:         List<SubRegistry> l = new ArrayList<>();
>> 229:         for (Class<?> c : categoryMap.keySet()) {
>> 230:             if (c.isInstance(provider)) {
> 
> Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE.

No. This method is called from 3 places,  and there 3 null checks before the method call.

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From dfuchs at openjdk.java.net  Tue May 10 11:43:55 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 10 May 2022 11:43:55 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <iyPHYWiIL0mqxp3iaAaDT3pMp6tFWEpERqLGJ2sgiao=.1f3e0af5-0d64-4769-9282-c120201fe5e0@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
 <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>
 <iyPHYWiIL0mqxp3iaAaDT3pMp6tFWEpERqLGJ2sgiao=.1f3e0af5-0d64-4769-9282-c120201fe5e0@github.com>
Message-ID: <endEBOSOYQDoktP2AgDxXQDJK6XpeuHGvgATOffZHmo=.9635df10-a2c3-40be-81ea-aa4ffc80bdcb@github.com>

On Tue, 10 May 2022 11:31:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230:
>> 
>>> 228:         List<SubRegistry> l = new ArrayList<>();
>>> 229:         for (Class<?> c : categoryMap.keySet()) {
>>> 230:             if (c.isInstance(provider)) {
>> 
>> Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE.
>
> No. This method is called from 3 places,  and there 3 null checks before the method call.

Thanks for double checking! LGTM then.

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From sgehwolf at openjdk.java.net  Tue May 10 12:40:42 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 10 May 2022 12:40:42 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
Message-ID: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>

Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).

In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.

Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).

Testing:
- [x] Added unit tests
- [x] GHA
- [x] Container tests on cgroups v1 Linux. Continue to pass

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

Commit messages:
 - 8286212: Cgroup v1 initialization causes NPE on some systems

Changes: https://git.openjdk.java.net/jdk/pull/8629/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286212
  Stats: 267 lines in 7 files changed: 256 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8629.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8629/head:pull/8629

PR: https://git.openjdk.java.net/jdk/pull/8629

From lmesnik at openjdk.java.net  Tue May 10 19:02:49 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 10 May 2022 19:02:49 GMT
Subject: Integrated: 8286438: Add jhsdb jstack processing without --mixed in
 efh
In-Reply-To: <Gg3kYyHr2FVU5WMmrsfRhjB_3z-0-QyOvUMU4rO43oQ=.5cb2a8ad-c943-4ae2-a2c7-385fa197ce5a@github.com>
References: <Gg3kYyHr2FVU5WMmrsfRhjB_3z-0-QyOvUMU4rO43oQ=.5cb2a8ad-c943-4ae2-a2c7-385fa197ce5a@github.com>
Message-ID: <v9HdmTnKZ-gKezAs0oG1yA_yQe7FhHQ26Ohl0AI-JOM=.1e113c4c-5b08-48a7-b6a4-f9e6280a5411@github.com>

On Mon, 9 May 2022 20:35:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The default is required only to set the same depth level in the tree on HTML page for default and mixed mode.

This pull request has now been integrated.

Changeset: d347fc12
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d347fc127bec1bf2b3d939b4d9d898d99255eca4
Stats:     7 lines in 1 file changed: 2 ins; 0 del; 5 mod

8286438: Add jhsdb jstack processing without --mixed in efh

Reviewed-by: cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/8610

From lmesnik at openjdk.java.net  Tue May 10 19:05:59 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 10 May 2022 19:05:59 GMT
Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java
 failing with java.lang.AssertionError: Should have a hidden class [v2]
In-Reply-To: <xIhANjDXynR1OiOsQQY1886kttZtdXyXI8xzPtMTX7I=.bee1807d-b421-431d-a4a3-aea23a0b1417@github.com>
References: <VhLwLyEuWUoNnG9bTxeEJXqbyFs9UunjMcYlKM5D5Q8=.e81a5e18-b820-4261-83a5-cabb94579f11@github.com>
 <fqSn47jxVZZMqCQ3scTdNWviQ_F5AVpW9GK6uhaSm4I=.77ff8bee-64e1-4a5a-91e7-3ea4da7b8c0a@github.com>
 <xIhANjDXynR1OiOsQQY1886kttZtdXyXI8xzPtMTX7I=.bee1807d-b421-431d-a4a3-aea23a0b1417@github.com>
Message-ID: <VoKTUgbJnvxbdJieftPymUeM-q1u0KHuuKjz4WB-X_M=.8268d2c6-9d0c-4023-934b-a0564c46aa64@github.com>

On Tue, 10 May 2022 05:14:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you'll remove this test from the-Xcomp exclude list (test/hotspot/jtreg/ProblemList-Xcomp.txt) as part of this change,

Sure. The PR reminded me about this. But I need to push problemlist cleanup first and than merge chnges.

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

PR: https://git.openjdk.java.net/jdk/pull/8438

From lmesnik at openjdk.java.net  Tue May 10 19:21:44 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 10 May 2022 19:21:44 GMT
Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java
 failing with java.lang.AssertionError: Should have a hidden class [v3]
In-Reply-To: <VhLwLyEuWUoNnG9bTxeEJXqbyFs9UunjMcYlKM5D5Q8=.e81a5e18-b820-4261-83a5-cabb94579f11@github.com>
References: <VhLwLyEuWUoNnG9bTxeEJXqbyFs9UunjMcYlKM5D5Q8=.e81a5e18-b820-4261-83a5-cabb94579f11@github.com>
Message-ID: <cIeEYIqJk3YkUh1SA_DmzlvCMQGWe5cesdVDcKyQLjQ=.5f4c0057-b24e-4038-ac9c-291e59837a18@github.com>

> The test failed if GC happens somewhere between
> Class<?> c = Class.forName("TestClass", true, dummyloader);
> and
> OutputAnalyzer output = executor.execute("VM.classloader_stats");
> 
> The fix is to make hc static as Chris proposed. 
> 
> To verfiy fix I add System.gc() before executor.execute("VM.classloader_stats");

Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - test excluded
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123
 - comment fixed
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123
 - fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8438/files
  - new: https://git.openjdk.java.net/jdk/pull/8438/files/1e9d05a8..1ee94868

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8438&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8438&range=01-02

  Stats: 132683 lines in 1991 files changed: 112525 ins; 9911 del; 10247 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8438.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8438/head:pull/8438

PR: https://git.openjdk.java.net/jdk/pull/8438

From alanb at openjdk.java.net  Tue May 10 20:02:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 20:02:48 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
Message-ID: <dPmSVzIHGfwcmaJTIGwDS6O9Ppl0QAcBYbGDwqaFDJU=.480f6a7b-5da5-4fc9-8e13-2c678e605465@github.com>

On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
> 
> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
> 
> I also cleaned up related code in the JDK and HotSpot.
> 
> Testing:
> - Passed tiers 1 and 2
> - Tiers 3, 4, 5 are in progress

src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java line 60:

> 58:             FileChannel fc = new RandomAccessFile(f, "r").getChannel();
> 59:             ByteBuffer bb = fc.map(FileChannel.MapMode.READ_ONLY, 0L, (int)fc.size());
> 60:             fc.close();               // doesn't need to remain open

I think you can change this to:


        try (FileChannel fc = FileChannel.open(f.toPath())) {
            ByteBuffer bb = ...
            createPerfDataBuffer(bb, 0);
        }

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From alanb at openjdk.java.net  Tue May 10 20:06:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 20:06:47 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
Message-ID: <fJVbOoDRaDA37EScdewg0G4nCyTzYZ2M4ZXWY_ubpoQ=.1be2132e-0af9-4a36-a9ee-33cc182f745d@github.com>

On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
> 
> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
> 
> I also cleaned up related code in the JDK and HotSpot.
> 
> Testing:
> - Passed tiers 1 and 2
> - Tiers 3, 4, 5 are in progress

I skimmed through the changes and I think they look okay. In the distant past there were tools outside of the JDK that used the jvmstat API directly. It's possible that VisualVM still does but it would only compile/run if --add-exports is used to export the sun.jvmstat.* packages. So it might be that dropping the parameter from a method in RemoteHost is noticed and I think that is okay because this package is not exported and is not meant to be used by code outside of the JDK.

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From lmesnik at openjdk.java.net  Tue May 10 20:32:28 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 10 May 2022 20:32:28 GMT
Subject: RFR: 8283001: windows-x86-cmp-baseline fails in some jvmti native libs
Message-ID: <ufswzVwXh-JK9Ahz-rE8ovv-gPRV71Sk-m25Wuth7Eg=.c3f03de0-f30c-4ff9-ae35-d2f2b51ecda9@github.com>

8283001: windows-x86-cmp-baseline fails in some jvmti native libs

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

Commit messages:
 - 8283001

Changes: https://git.openjdk.java.net/jdk/pull/8641/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8641&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283001
  Stats: 85 lines in 41 files changed: 41 ins; 2 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8641.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8641/head:pull/8641

PR: https://git.openjdk.java.net/jdk/pull/8641

From redestad at openjdk.java.net  Tue May 10 21:47:50 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 10 May 2022 21:47:50 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
Message-ID: <5AjTeD3XkuyBV8Dux7QVRkJgDwTiJ4Et9303eiMLjNU=.84477522-bbdb-4215-976f-729910707634@github.com>

On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
> 
> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
> 
> I also cleaned up related code in the JDK and HotSpot.
> 
> Testing:
> - Passed tiers 1 and 2
> - Tiers 3, 4, 5 are in progress

Nice cleanup!

(Some stylistic suggestions inline, feel free to ignore)

src/hotspot/os/windows/perfMemory_windows.cpp line 1781:

> 1779: // address space.
> 1780: //
> 1781: void PerfMemory::attach(const char* user, int vmid,

One line?

src/hotspot/share/prims/perf.cpp line 84:

> 82: 
> 83:   // attach to the PerfData memory region for the specified VM
> 84:   PerfMemory::attach(user_utf, vmid,

One line?

src/hotspot/share/runtime/perfMemory.hpp line 146:

> 144:     // methods for attaching to and detaching from the PerfData
> 145:     // memory segment of another JVM process on the same system.
> 146:     static void attach(const char* user, int vmid,

One line?

src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java line 74:

> 72:         Integer v = lvmid;
> 73:         RemoteVm stub = null;
> 74:         StringBuilder sb = new StringBuilder();

Suggestion:

        String vmidStr = "local://" + lvmid + "@localhost";

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

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8622

From cjplummer at openjdk.java.net  Tue May 10 22:22:54 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 10 May 2022 22:22:54 GMT
Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java
 failing with java.lang.AssertionError: Should have a hidden class [v3]
In-Reply-To: <cIeEYIqJk3YkUh1SA_DmzlvCMQGWe5cesdVDcKyQLjQ=.5f4c0057-b24e-4038-ac9c-291e59837a18@github.com>
References: <VhLwLyEuWUoNnG9bTxeEJXqbyFs9UunjMcYlKM5D5Q8=.e81a5e18-b820-4261-83a5-cabb94579f11@github.com>
 <cIeEYIqJk3YkUh1SA_DmzlvCMQGWe5cesdVDcKyQLjQ=.5f4c0057-b24e-4038-ac9c-291e59837a18@github.com>
Message-ID: <rkOcAxuQ8cwYThDQfTLsrevPJ-7r74ETFTJZ1W_805w=.39f3d7a3-29c7-435b-b500-8d770219344c@github.com>

On Tue, 10 May 2022 19:21:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The test failed if GC happens somewhere between
>> Class<?> c = Class.forName("TestClass", true, dummyloader);
>> and
>> OutputAnalyzer output = executor.execute("VM.classloader_stats");
>> 
>> The fix is to make hc static as Chris proposed. 
>> 
>> To verfiy fix I add System.gc() before executor.execute("VM.classloader_stats");
>
> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - test excluded
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123
>  - comment fixed
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123
>  - fix

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8438

From lmesnik at openjdk.java.net  Tue May 10 22:31:51 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 10 May 2022 22:31:51 GMT
Subject: Integrated: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java
 failing with java.lang.AssertionError: Should have a hidden class
In-Reply-To: <VhLwLyEuWUoNnG9bTxeEJXqbyFs9UunjMcYlKM5D5Q8=.e81a5e18-b820-4261-83a5-cabb94579f11@github.com>
References: <VhLwLyEuWUoNnG9bTxeEJXqbyFs9UunjMcYlKM5D5Q8=.e81a5e18-b820-4261-83a5-cabb94579f11@github.com>
Message-ID: <aBEuH6V5aBbLGb1kb9x_2Rq8OP7QVvXIsh2kleDHDvU=.407a16ba-8876-4c67-9823-0b243bd79a0a@github.com>

On Wed, 27 Apr 2022 23:49:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test failed if GC happens somewhere between
> Class<?> c = Class.forName("TestClass", true, dummyloader);
> and
> OutputAnalyzer output = executor.execute("VM.classloader_stats");
> 
> The fix is to make hc static as Chris proposed. 
> 
> To verfiy fix I add System.gc() before executor.execute("VM.classloader_stats");

This pull request has now been integrated.

Changeset: aaeb08ec
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aaeb08eca422776eef5955473734aad75cb2829a
Stats:     6 lines in 2 files changed: 1 ins; 2 del; 3 mod

8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java failing with java.lang.AssertionError: Should have a hidden class

Reviewed-by: cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/8438

From sspitsyn at openjdk.java.net  Wed May 11 02:25:51 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 11 May 2022 02:25:51 GMT
Subject: RFR: 8283001: windows-x86-cmp-baseline fails in some jvmti native
 libs
In-Reply-To: <ufswzVwXh-JK9Ahz-rE8ovv-gPRV71Sk-m25Wuth7Eg=.c3f03de0-f30c-4ff9-ae35-d2f2b51ecda9@github.com>
References: <ufswzVwXh-JK9Ahz-rE8ovv-gPRV71Sk-m25Wuth7Eg=.c3f03de0-f30c-4ff9-ae35-d2f2b51ecda9@github.com>
Message-ID: <_im0xnRktzExHLT6sKG0LpBDjqdGkSJwxMtN3cr8aeA=.00bde365-9af2-46b3-9931-44adaef3572f@github.com>

On Tue, 10 May 2022 20:23:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8283001: windows-x86-cmp-baseline fails in some jvmti native libs

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8641

From iklam at openjdk.java.net  Wed May 11 02:43:21 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 02:43:21 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
Message-ID: <nJ3YUlzlAvMknJJxLkByfKxWQJ-2vYUFhJhC4DRyrCY=.9e4b5a6b-69cd-4792-89dc-94b3b1664d99@github.com>

> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
> 
> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
> 
> I also cleaned up related code in the JDK and HotSpot.
> 
> Testing:
> - Passed tiers 1 and 2
> - Tiers 3, 4, 5 are in progress

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8622/files
  - new: https://git.openjdk.java.net/jdk/pull/8622/files/22c22c30..34a01f71

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8622&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8622&range=00-01

  Stats: 14 lines in 5 files changed: 1 ins; 7 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8622.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8622/head:pull/8622

PR: https://git.openjdk.java.net/jdk/pull/8622

From iklam at openjdk.java.net  Wed May 11 02:43:24 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 02:43:24 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <5AjTeD3XkuyBV8Dux7QVRkJgDwTiJ4Et9303eiMLjNU=.84477522-bbdb-4215-976f-729910707634@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
 <5AjTeD3XkuyBV8Dux7QVRkJgDwTiJ4Et9303eiMLjNU=.84477522-bbdb-4215-976f-729910707634@github.com>
Message-ID: <h_uM9CtM8JppYGlFDCZ6-xLM2MWY7kB2K6yuFrwzCvU=.ae2e89b3-2862-48ba-82a9-17bfcc37d777@github.com>

On Tue, 10 May 2022 21:43:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> src/hotspot/os/windows/perfMemory_windows.cpp line 1781:
> 
>> 1779: // address space.
>> 1780: //
>> 1781: void PerfMemory::attach(const char* user, int vmid,
> 
> One line?

Fixed

> src/hotspot/share/prims/perf.cpp line 84:
> 
>> 82: 
>> 83:   // attach to the PerfData memory region for the specified VM
>> 84:   PerfMemory::attach(user_utf, vmid,
> 
> One line?

Fixed

> src/hotspot/share/runtime/perfMemory.hpp line 146:
> 
>> 144:     // methods for attaching to and detaching from the PerfData
>> 145:     // memory segment of another JVM process on the same system.
>> 146:     static void attach(const char* user, int vmid,
> 
> One line?

Fixed

> src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java line 74:
> 
>> 72:         Integer v = lvmid;
>> 73:         RemoteVm stub = null;
>> 74:         StringBuilder sb = new StringBuilder();
> 
> Suggestion:
> 
>         String vmidStr = "local://" + lvmid + "@localhost";

Fixed

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From iklam at openjdk.java.net  Wed May 11 02:43:25 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 02:43:25 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <dPmSVzIHGfwcmaJTIGwDS6O9Ppl0QAcBYbGDwqaFDJU=.480f6a7b-5da5-4fc9-8e13-2c678e605465@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
 <dPmSVzIHGfwcmaJTIGwDS6O9Ppl0QAcBYbGDwqaFDJU=.480f6a7b-5da5-4fc9-8e13-2c678e605465@github.com>
Message-ID: <BMNhbA9nWHe8hI992LIuX9duAoUDuVQjuvA5iJRG1I4=.39fc8993-d6ce-4019-ae82-2eb190c36683@github.com>

On Tue, 10 May 2022 19:59:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java line 60:
> 
>> 58:             FileChannel fc = new RandomAccessFile(f, "r").getChannel();
>> 59:             ByteBuffer bb = fc.map(FileChannel.MapMode.READ_ONLY, 0L, (int)fc.size());
>> 60:             fc.close();               // doesn't need to remain open
> 
> I think you can change this to:
> 
> 
>         try (FileChannel fc = FileChannel.open(f.toPath())) {
>             ByteBuffer bb = ...
>             createPerfDataBuffer(bb, 0);
>         }

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From iklam at openjdk.java.net  Wed May 11 02:52:47 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 02:52:47 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <fJVbOoDRaDA37EScdewg0G4nCyTzYZ2M4ZXWY_ubpoQ=.1be2132e-0af9-4a36-a9ee-33cc182f745d@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
 <fJVbOoDRaDA37EScdewg0G4nCyTzYZ2M4ZXWY_ubpoQ=.1be2132e-0af9-4a36-a9ee-33cc182f745d@github.com>
Message-ID: <t8HcObumyWDO7DRRif0BR4CLXxRE921QnzaVcUlYUew=.c26c55ad-a64a-4198-97d2-c3db486ba9c7@github.com>

On Tue, 10 May 2022 20:03:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I skimmed through the changes and I think they look okay. In the distant past there were tools outside of the JDK that used the jvmstat API directly. It's possible that VisualVM still does but it would only compile/run if --add-exports is used to export the sun.jvmstat.* packages. So it might be that dropping the parameter from a method in RemoteHost is noticed and I think that is okay because this package is not exported and is not meant to be used by code outside of the JDK.

The APIs changed by this PR are:

- sun.jvmstat.monitor.remote.RemoteHost::attachVm
- sun.jvmstat.monitor.VmIdentifier::getMode
- sun.jvmstat.monitor.HostIdentifier::getMode
- jdk.internal.perf.Perf::attach

I checked the latest VisualVM source code. Some of the above classes are referenced, but none of the affected APIs are called.

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From jrose at openjdk.java.net  Wed May 11 06:28:37 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 11 May 2022 06:28:37 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v2]
In-Reply-To: <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>
Message-ID: <sISfnxp1FBO9eR2lfA8D57iqvW-Xq2VFduvRezba1ok=.74a7448d-7f76-4be8-9180-d8b479d56c03@github.com>

On Tue, 10 May 2022 09:07:44 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8244681: Add a warning for possibly lossy conversion in compound assignments
>   recommended correction of the warning wording
>   fixed typo in test method name

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 210:

> 208: 
> 209: javac.opt.Xlint.desc.lossy-conversions=\
> 210:     Warn about compiler possible lossy conversions.

I like this warning.  But the documentation doesn't even parse as English.

I suggest this, as more grammatical and precise:

> Warn about possible lossy conversions in compound assignments

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 07:45:39 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 07:45:39 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  8244681: Add a warning for possibly lossy conversion in compound assignments
  recommended correction of the warning description

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/6b3942b8..f0729396

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From ihse at openjdk.java.net  Wed May 11 13:05:46 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 13:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
Message-ID: <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>

On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8244681: Add a warning for possibly lossy conversion in compound assignments
>   recommended correction of the warning description

Check updates on JDK-8286374 subtasks.

make/modules/jdk.jfr/Java.gmk line 26:

> 24: #
> 25: 
> 26: DISABLED_WARNINGS_java += exports lossy-conversions

Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 

In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.

(In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)

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

Changes requested by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Wed May 11 13:05:46 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 13:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
Message-ID: <PWtwdccbXVxNM6h8D5nH5AzTqjGk9y5se7lGEE-ToHU=.135fd8e6-f702-41c0-9397-e165c29adb77@github.com>

On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8244681: Add a warning for possibly lossy conversion in compound assignments
>   recommended correction of the warning description

Lossy conversion issues for jdk.jfr and jdk.management.jfr. have been fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Wed May 11 13:08:49 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 13:08:49 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
Message-ID: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>

On Wed, 11 May 2022 12:59:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8244681: Add a warning for possibly lossy conversion in compound assignments
>>   recommended correction of the warning description
>
> make/modules/jdk.jfr/Java.gmk line 26:
> 
>> 24: #
>> 25: 
>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
> 
> Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 
> 
> In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.
> 
> (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)

I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From ihse at openjdk.java.net  Wed May 11 13:13:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 13:13:43 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
Message-ID: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>

On Wed, 11 May 2022 13:05:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> make/modules/jdk.jfr/Java.gmk line 26:
>> 
>>> 24: #
>>> 25: 
>>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
>> 
>> Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 
>> 
>> In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.
>> 
>> (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)
>
> I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.

That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 13:30:43 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:30:43 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
Message-ID: <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>

On Wed, 11 May 2022 13:10:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.
>
> That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.

Thanks for quick reaction.
I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From rriggs at openjdk.java.net  Wed May 11 13:34:49 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 13:34:49 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
 <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
Message-ID: <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>

On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.
>
> Thanks for quick reaction.
> I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.

I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 13:41:30 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:41:30 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v4]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <3RgMbsaSwgdBXE2qlIwjVI680aN7Ovi6OOfu9eeNtJo=.a76eff60-8652-40ce-ae40-20f9095b1b93@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona 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 six additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/f0729396..a59dfa4f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02-03

  Stats: 9179 lines in 255 files changed: 5253 ins; 2422 del; 1504 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 13:41:30 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:41:30 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
 <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
 <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>
Message-ID: <6EkEbNxPc3RKNGprHlBhqM574oY7iPI9z3PpR91IMok=.9019963f-8085-49a8-951f-f8a2b2137fb0@github.com>

On Wed, 11 May 2022 13:31:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thanks for quick reaction.
>> I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.
>
> I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time.

Feel free to go ahead with the java.base PR as this one still needs CSR.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 14:45:12 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 14:45:12 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v5]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cJu_ULWgPS-KxeOlGeUXs0iYI7U7DjdxrITrg0vzoTQ=.057010a4-d66f-4df7-b982-7e0bee3519c4@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/a59dfa4f..32282515

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From alanb at openjdk.java.net  Wed May 11 18:12:53 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 18:12:53 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <nJ3YUlzlAvMknJJxLkByfKxWQJ-2vYUFhJhC4DRyrCY=.9e4b5a6b-69cd-4792-89dc-94b3b1664d99@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
 <nJ3YUlzlAvMknJJxLkByfKxWQJ-2vYUFhJhC4DRyrCY=.9e4b5a6b-69cd-4792-89dc-94b3b1664d99@github.com>
Message-ID: <_-q4dXADJO6xSX8M9-NhCN7WcPzea67b7Dr6VTru5Ug=.f06265df-c88e-40ab-8955-dfdf00157dab@github.com>

On Wed, 11 May 2022 02:43:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
>> 
>> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
>> 
>> I also cleaned up related code in the JDK and HotSpot.
>> 
>> Testing:
>> - Passed tiers 1 and 2
>> - Tiers 3, 4, 5 are in progress
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From iklam at openjdk.java.net  Wed May 11 19:29:57 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 19:29:57 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <fJVbOoDRaDA37EScdewg0G4nCyTzYZ2M4ZXWY_ubpoQ=.1be2132e-0af9-4a36-a9ee-33cc182f745d@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
 <fJVbOoDRaDA37EScdewg0G4nCyTzYZ2M4ZXWY_ubpoQ=.1be2132e-0af9-4a36-a9ee-33cc182f745d@github.com>
Message-ID: <LvpF1pmJ9MSZD7OYitX5Q_jy2uJSNG1cUZWY3KywhyU=.8080bd6b-2b9d-4992-81cf-39d8ed158cf9@github.com>

On Tue, 10 May 2022 20:03:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
>> 
>> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
>> 
>> I also cleaned up related code in the JDK and HotSpot.
>> 
>> Testing:
>> - Passed tiers 1 ~ 5
>
> I skimmed through the changes and I think they look okay. In the distant past there were tools outside of the JDK that used the jvmstat API directly. It's possible that VisualVM still does but it would only compile/run if --add-exports is used to export the sun.jvmstat.* packages. So it might be that dropping the parameter from a method in RemoteHost is noticed and I think that is okay because this package is not exported and is not meant to be used by code outside of the JDK.

Thanks to @AlanBateman and @cl4es for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From iklam at openjdk.java.net  Wed May 11 19:29:59 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 19:29:59 GMT
Subject: Integrated: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
Message-ID: <c5o6SCVcv3i5y1sOxqKYcrktFjB-Wwxr4Fzj8xwIULs=.3f841139-5230-4357-b88c-568e93e453fe@github.com>

On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
> 
> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
> 
> I also cleaned up related code in the JDK and HotSpot.
> 
> Testing:
> - Passed tiers 1 ~ 5

This pull request has now been integrated.

Changeset: fcf49f42
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fcf49f42cef4ac3e50b3b480aecf6fa38cf5be00
Stats:     205 lines in 15 files changed: 3 ins; 153 del; 49 mod

8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

Reviewed-by: redestad, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From amenkov at openjdk.java.net  Wed May 11 19:57:46 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 11 May 2022 19:57:46 GMT
Subject: RFR: 8283001: windows-x86-cmp-baseline fails in some jvmti native
 libs
In-Reply-To: <ufswzVwXh-JK9Ahz-rE8ovv-gPRV71Sk-m25Wuth7Eg=.c3f03de0-f30c-4ff9-ae35-d2f2b51ecda9@github.com>
References: <ufswzVwXh-JK9Ahz-rE8ovv-gPRV71Sk-m25Wuth7Eg=.c3f03de0-f30c-4ff9-ae35-d2f2b51ecda9@github.com>
Message-ID: <M1vJSZCmF_IJRX9t5PQT41okat64WMA-RGSTq-aPAwA=.367ad95f-d6b4-4185-83e0-6e73974c7a84@github.com>

On Tue, 10 May 2022 20:23:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8283001: windows-x86-cmp-baseline fails in some jvmti native libs

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8641

From lmesnik at openjdk.java.net  Thu May 12 02:33:43 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 12 May 2022 02:33:43 GMT
Subject: Integrated: 8283001: windows-x86-cmp-baseline fails in some jvmti
 native libs
In-Reply-To: <ufswzVwXh-JK9Ahz-rE8ovv-gPRV71Sk-m25Wuth7Eg=.c3f03de0-f30c-4ff9-ae35-d2f2b51ecda9@github.com>
References: <ufswzVwXh-JK9Ahz-rE8ovv-gPRV71Sk-m25Wuth7Eg=.c3f03de0-f30c-4ff9-ae35-d2f2b51ecda9@github.com>
Message-ID: <O0BcxDwtBU1p70JrV2hAQM3q9z52RYTWMElezztFk_A=.115b7ffd-4a07-485e-8e3a-873ac6a7e34c@github.com>

On Tue, 10 May 2022 20:23:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8283001: windows-x86-cmp-baseline fails in some jvmti native libs

This pull request has now been integrated.

Changeset: 82d25700
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/82d257006d6337920bbc78a33cf61c3cb809ce4b
Stats:     85 lines in 41 files changed: 41 ins; 2 del; 42 mod

8283001: windows-x86-cmp-baseline fails in some jvmti native libs

Reviewed-by: sspitsyn, amenkov

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

PR: https://git.openjdk.java.net/jdk/pull/8641

From iklam at openjdk.java.net  Thu May 12 06:16:45 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 12 May 2022 06:16:45 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
In-Reply-To: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
Message-ID: <Tb2H9w2gDKJ7c4-dlu08OxlxhOvXac4KI_ZPU0bakT8=.1f13223a-8a2c-42a4-bae9-d5f78ed81c10@github.com>

On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
> 
> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
> 
> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
> 
> Testing:
> - [x] Added unit tests
> - [x] GHA
> - [x] Container tests on cgroups v1 Linux. Continue to pass

I just started to look at the code so just one comment for now.

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 65:

> 63:                             path = mountPoint + cgroupSubstr;
> 64:                         }
> 65:                     } else {

Looks like `path` is still not set if the condition at line 61 `if (cgroupPath.length() > root.length()) {` is false.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From duke at openjdk.java.net  Thu May 12 06:51:20 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Thu, 12 May 2022 06:51:20 GMT
Subject: RFR: 8281268: Resolve duplication of test ClassTransformer class
Message-ID: <0LDP8tblKUqLt0fcYtmlJ2Mu8hRCBh7rvge6Muo7dtg=.04497b51-993a-4f3b-984f-65ece6addcfd@github.com>

ClassTransformer.java is duplicated because ClassTransformer.java was copied from test/jdk/com/sun/jdi/lib/jdb to test/lib/jdk/test/lib/util at [JDK-8240908](https://bugs.openjdk.java.net/browse/JDK-8240908). test/lib/jdk/test/lib/util/ClassTransformer.java should be deleted and test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java should be used. This is because ClassTransformer is used for testing jdi, and it is not appropriate to exist in test/lib/jdk/test/lib/util.
Would you please review this fix?

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

Commit messages:
 - 8281268: Resolve duplication of test ClassTransformer class

Changes: https://git.openjdk.java.net/jdk/pull/8672/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8672&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281268
  Stats: 165 lines in 2 files changed: 0 ins; 163 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8672.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8672/head:pull/8672

PR: https://git.openjdk.java.net/jdk/pull/8672

From duke at openjdk.java.net  Thu May 12 07:32:56 2022
From: duke at openjdk.java.net (duke)
Date: Thu, 12 May 2022 07:32:56 GMT
Subject: Withdrawn: 8283147: Include NonJavaThread stacktrace during thread
 dump
In-Reply-To: <OoiXCWx0LCA1R8VjyZfIp-ZUYSl3ky0kkrAGZZfZ6Ew=.d8458654-2e48-4af8-af64-a990bf70681e@github.com>
References: <OoiXCWx0LCA1R8VjyZfIp-ZUYSl3ky0kkrAGZZfZ6Ew=.d8458654-2e48-4af8-af64-a990bf70681e@github.com>
Message-ID: <JIY-0uwkm4dRtTZtPD0AdNesKlIEc0n9nIWYZkMI7Zs=.f2be211d-5e31-425c-9657-4dd573f69f3d@github.com>

On Wed, 16 Mar 2022 02:40:15 GMT, Yi Yang <yyang at openjdk.org> wrote:

> When we use jcmd <pid> Thread.dump/jstack <pid>, we could dump all Java thread stack trace, but unfortunately we are not able to print NonJavaThread stack trace such as VMThread/GCWorker, etc. For these threads, we know nothing about what are they doing/are they blocked in pthread condition from jstack output. An alternative is to use pstack, it internally attaches destination process and uses `thread apply all bt`, which introduces more overhead and much more dangerous.
> 
> ====== JStack Ouput(Currrent)
> 
> ...
> "ApplicationImpl pooled thread 441" #1478 prio=4 os_prio=31 cpu=11.71ms elapsed=60.30s tid=0x00007f8d32171000 nid=0x22f23 waiting on condition  [0x0000700010d5d000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
> 	at jdk.internal.misc.Unsafe.park(java.base at 11.0.11/Native Method)
> 	- parking to wait for  <0x00000007af851760> (a java.util.concurrent.SynchronousQueue$TransferStack)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11.0.11/LockSupport.java:234)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11.0.11/SynchronousQueue.java:462)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11.0.11/SynchronousQueue.java:361)
> 	at java.util.concurrent.SynchronousQueue.poll(java.base at 11.0.11/SynchronousQueue.java:937)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11.0.11/ThreadPoolExecutor.java:1053)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11.0.11/ThreadPoolExecutor.java:1114)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11.0.11/ThreadPoolExecutor.java:628)
> 	at java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(java.base at 11.0.11/Executors.java:668)
> 	at java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(java.base at 11.0.11/Executors.java:665)
> 	at java.security.AccessController.doPrivileged(java.base at 11.0.11/Native Method)
> 	at java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(java.base at 11.0.11/Executors.java:665)
> 	at java.lang.Thread.run(java.base at 11.0.11/Thread.java:829)
> 
> "VM Thread" os_prio=31 cpu=31205.83ms elapsed=154131.15s tid=0x00007f8d49046000 nid=0x4703 runnable
> 
> "GC Thread#0" os_prio=31 cpu=3811.96ms elapsed=154131.18s tid=0x00007f8d49809800 nid=0x3603 runnable
> 
> "GC Thread#1" os_prio=31 cpu=3749.09ms elapsed=154130.24s tid=0x00007f8d4a9b3000 nid=0x6103 runnable
> 
> "GC Thread#2" os_prio=31 cpu=3745.73ms elapsed=154129.74s tid=0x00007f8d48249000 nid=0x12f27 runnable
> 
> "GC Thread#3" os_prio=31 cpu=3692.77ms elapsed=154129.74s tid=0x00007f8d48b93000 nid=0xe50b runnable
> 
> "GC Thread#4" os_prio=31 cpu=3728.57ms elapsed=154129.74s tid=0x00007f8d47b0b000 nid=0xe603 runnable
> 
> "GC Thread#5" os_prio=31 cpu=3726.08ms elapsed=154129.74s tid=0x00007f8d47afc800 nid=0xe803 runnable
> 
> "GC Thread#6" os_prio=31 cpu=3660.35ms elapsed=154129.02s tid=0x00007f8d48de5800 nid=0x15d2f runnable
> 
> "GC Thread#7" os_prio=31 cpu=3676.68ms elapsed=154129.02s tid=0x00007f8d48dc4800 nid=0x16103 runnable
> 
> "GC Thread#8" os_prio=31 cpu=3676.15ms elapsed=154128.31s tid=0x00007f8d4849d800 nid=0x1f503 runnable
> 
> "GC Thread#9" os_prio=31 cpu=3570.95ms elapsed=154128.31s tid=0x00007f8d494ab000 nid=0x1f303 runnable
> 
> "CMS Main Thread" os_prio=31 cpu=6715.33ms elapsed=154131.18s tid=0x00007f8d4780f800 nid=0x4b03 runnable
> 
> "CMS Thread#0" os_prio=31 cpu=2429.86ms elapsed=154131.18s tid=0x00007f8d4900e000 nid=0x3703 runnable
> 
> "CMS Thread#1" os_prio=31 cpu=2422.35ms elapsed=154129.72s tid=0x00007f8d4d044000 nid=0x11a03 runnable
> 
> "CMS Thread#2" os_prio=31 cpu=2418.81ms elapsed=154129.72s tid=0x00007f8d48b93800 nid=0xea03 runnable
> 
> "VM Periodic Task Thread" os_prio=31 cpu=10658.80ms elapsed=154130.41s tid=0x00007f8d49035000 nid=0xa003 waiting on condition
> 
> JNI global refs: 660, weak refs: 1217
> 
> 
> Most of above information makes no sense for further debugging. I think we can extend this functionality, e.g. add a new flag such as DumpAllThreadStackTrace, to print non java thread stack trace:
> 
> ====== JStack Ouput(Modified)
> 
> 2022-03-16 10:46:55
> Full thread dump OpenJDK 64-Bit Server VM (19-internal-adhoc.qingfengyy.jdktip mixed mode, sharing):
> 
> Threads class SMR info:
> _java_thread_list=0x00007f15040015f0, length=22, elements={
> 0x00007f159c0255b0, 0x00007f159c1babc0, 0x00007f159c1bc180, 0x00007f159c1c21d0,
> 0x00007f159c1c36a0, 0x00007f159c1c4bb0, 0x00007f159c1c6730, 0x00007f159c1c7db0,
> 0x00007f159c1c9330, 0x00007f159c1fc300, 0x00007f159c211a60, 0x00007f159c213b60,
> 0x00007f159c302960, 0x00007f14cc0319d0, 0x00007f14cc0375c0, 0x00007f159c307e80,
> 0x00007f159c30db30, 0x00007f159c3e6db0, 0x00007f159c647300, 0x00007f159c64b600,
> 0x00007f159c678910, 0x00007f1504000be0
> }
> 
> "main" #1 prio=5 os_prio=0 cpu=766.48ms elapsed=23.73s tid=0x00007f159c0255b0 nid=115919 in Object.wait()  [0x00007f15a3e58000]
>    java.lang.Thread.State: TIMED_WAITING (on object monitor)
> 	at java.lang.Object.wait(java.base at 19-internal/Native Method)
> 	- waiting on <no object reference available>
> 	at jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 19-internal/NonBlockingInputStreamImpl.java:139)
> 	- locked <0x00000000a2000368> (a jdk.internal.jshell.tool.ConsoleIOContext$1)
> 	at jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 19-internal/NonBlockingInputStream.java:62)
> 	at jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 19-internal/NonBlocking.java:168)
> 	at jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 19-internal/NonBlockingReader.java:57)
> 	at jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 19-internal/BindingReader.java:160)
> 	at jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 19-internal/BindingReader.java:110)
> 	at jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 19-internal/BindingReader.java:61)
> 	at jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 19-internal/LineReaderImpl.java:923)
> 	at jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 19-internal/LineReaderImpl.java:956)
> 	at jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 19-internal/ConsoleIOContext.java:173)
> 	at jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 19-internal/LineReaderImpl.java:651)
> 	at jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 19-internal/LineReaderImpl.java:468)
> 	at jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 19-internal/ConsoleIOContext.java:249)
> 	at jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 19-internal/JShellTool.java:1281)
> 	at jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 19-internal/JShellTool.java:1215)
> 	at jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 19-internal/JShellTool.java:1001)
> 	at jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 19-internal/JShellToolBuilder.java:261)
> 	at jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 19-internal/JShellToolProvider.java:120)
> 
> "Reference Handler" #2 daemon prio=10 os_prio=0 cpu=1.04ms elapsed=23.72s tid=0x00007f159c1babc0 nid=115926 waiting on condition  [0x00007f1529302000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.ref.Reference.waitForReferencePendingList(java.base at 19-internal/Native Method)
> 	at java.lang.ref.Reference.processPendingReferences(java.base at 19-internal/Reference.java:253)
> 	at java.lang.ref.Reference$ReferenceHandler.run(java.base at 19-internal/Reference.java:215)
> 
> "Finalizer" #3 daemon prio=8 os_prio=0 cpu=0.35ms elapsed=23.72s tid=0x00007f159c1bc180 nid=115927 in Object.wait()  [0x00007f1529201000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(java.base at 19-internal/Native Method)
> 	- waiting on <0x00000000a00002e8> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(java.base at 19-internal/ReferenceQueue.java:155)
> 	- locked <0x00000000a00002e8> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(java.base at 19-internal/ReferenceQueue.java:176)
> 	at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 19-internal/Finalizer.java:183)
> 
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=0.24ms elapsed=23.71s tid=0x00007f159c1c21d0 nid=115928 waiting on condition  [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> 
> "Service Thread" #5 daemon prio=9 os_prio=0 cpu=0.20ms elapsed=23.71s tid=0x00007f159c1c36a0 nid=115929 runnable  [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> 
> "Monitor Deflation Thread" #6 daemon prio=9 os_prio=0 cpu=0.24ms elapsed=23.71s tid=0x00007f159c1c4bb0 nid=115930 runnable  [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> 
> "C2 CompilerThread0" #7 daemon prio=9 os_prio=0 cpu=527.71ms elapsed=23.71s tid=0x00007f159c1c6730 nid=115931 waiting on condition  [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>    No compile task
> 
> "C1 CompilerThread0" #19 daemon prio=9 os_prio=0 cpu=216.87ms elapsed=23.71s tid=0x00007f159c1c7db0 nid=115932 waiting on condition  [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
>    No compile task
> 
> "Sweeper thread" #25 daemon prio=9 os_prio=0 cpu=0.04ms elapsed=23.71s tid=0x00007f159c1c9330 nid=115933 runnable  [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> 
> "Notification Thread" #26 daemon prio=9 os_prio=0 cpu=0.05ms elapsed=23.70s tid=0x00007f159c1fc300 nid=115936 runnable  [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> 
> "Common-Cleaner" #27 daemon prio=8 os_prio=0 cpu=0.99ms elapsed=23.68s tid=0x00007f159c211a60 nid=115938 in Object.wait()  [0x00007f15282d2000]
>    java.lang.Thread.State: TIMED_WAITING (on object monitor)
> 	at java.lang.Object.wait(java.base at 19-internal/Native Method)
> 	- waiting on <no object reference available>
> 	at java.lang.ref.ReferenceQueue.remove(java.base at 19-internal/ReferenceQueue.java:155)
> 	- locked <0x00000000a0000628> (a java.lang.ref.ReferenceQueue$Lock)
> 	at jdk.internal.ref.CleanerImpl.run(java.base at 19-internal/CleanerImpl.java:140)
> 	at java.lang.Thread.run(java.base at 19-internal/Thread.java:828)
> 	at jdk.internal.misc.InnocuousThread.run(java.base at 19-internal/InnocuousThread.java:162)
> 
> "Timer-0" #28 daemon prio=5 os_prio=0 cpu=0.10ms elapsed=23.68s tid=0x00007f159c213b60 nid=115939 in Object.wait()  [0x00007f15281d1000]
>    java.lang.Thread.State: TIMED_WAITING (on object monitor)
> 	at java.lang.Object.wait(java.base at 19-internal/Native Method)
> 	- waiting on <0x00000000a00007e8> (a java.util.TaskQueue)
> 	at java.util.TimerThread.mainLoop(java.base at 19-internal/Timer.java:563)
> 	- locked <0x00000000a00007e8> (a java.util.TaskQueue)
> 	at java.util.TimerThread.run(java.base at 19-internal/Timer.java:516)
> 
> "process reaper" #30 daemon prio=10 os_prio=0 cpu=0.17ms elapsed=23.53s tid=0x00007f159c302960 nid=115944 runnable  [0x00007f15a3c9e000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.ProcessHandleImpl.waitForProcessExit0(java.base at 19-internal/Native Method)
> 	at java.lang.ProcessHandleImpl$1.run(java.base at 19-internal/ProcessHandleImpl.java:147)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 19-internal/ThreadPoolExecutor.java:1136)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 19-internal/ThreadPoolExecutor.java:635)
> 	at java.lang.Thread.run(java.base at 19-internal/Thread.java:828)
> 
> "JDI Internal Event Handler" #34 daemon prio=5 os_prio=0 cpu=14.16ms elapsed=23.49s tid=0x00007f14cc0319d0 nid=115971 in Object.wait()  [0x00007f15096b7000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(java.base at 19-internal/Native Method)
> 	- waiting on <no object reference available>
> 	at java.lang.Object.wait(java.base at 19-internal/Object.java:338)
> 	at com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 19-internal/EventQueueImpl.java:190)
> 	- locked <0x00000000a0000e80> (a com.sun.tools.jdi.EventQueueImpl)
> 	at com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 19-internal/EventQueueImpl.java:125)
> 	at com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 19-internal/InternalEventHandler.java:61)
> 	at java.lang.Thread.run(java.base at 19-internal/Thread.java:828)
> 
> "JDI Target VM Interface" #33 daemon prio=5 os_prio=0 cpu=16.02ms elapsed=23.49s tid=0x00007f14cc0375c0 nid=115972 runnable  [0x00007f15095b6000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.SocketDispatcher.read0(java.base at 19-internal/Native Method)
> 	at sun.nio.ch.SocketDispatcher.read(java.base at 19-internal/SocketDispatcher.java:47)
> 	at sun.nio.ch.NioSocketImpl.tryRead(java.base at 19-internal/NioSocketImpl.java:258)
> 	at sun.nio.ch.NioSocketImpl.implRead(java.base at 19-internal/NioSocketImpl.java:309)
> 	at sun.nio.ch.NioSocketImpl.read(java.base at 19-internal/NioSocketImpl.java:347)
> 	at sun.nio.ch.NioSocketImpl$1.read(java.base at 19-internal/NioSocketImpl.java:800)
> 	at java.net.Socket$SocketInputStream.read(java.base at 19-internal/Socket.java:966)
> 	at java.net.Socket$SocketInputStream.read(java.base at 19-internal/Socket.java:961)
> 	at com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 19-internal/SocketConnection.java:82)
> 	- locked <0x00000000a00012e0> (a java.lang.Object)
> 	at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 19-internal/TargetVM.java:123)
> 	at java.lang.Thread.run(java.base at 19-internal/Thread.java:828)
> 
> "event-handler" #35 daemon prio=5 os_prio=0 cpu=8.29ms elapsed=23.48s tid=0x00007f159c307e80 nid=115973 in Object.wait()  [0x00007f15098b9000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(java.base at 19-internal/Native Method)
> 	- waiting on <no object reference available>
> 	at java.lang.Object.wait(java.base at 19-internal/Object.java:338)
> 	at com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 19-internal/EventQueueImpl.java:190)
> 	- locked <0x00000000a0001e98> (a com.sun.tools.jdi.EventQueueImpl)
> 	at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 19-internal/EventQueueImpl.java:97)
> 	at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 19-internal/EventQueueImpl.java:83)
> 	at jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 19-internal/JdiEventHandler.java:79)
> 	at java.lang.Thread.run(java.base at 19-internal/Thread.java:828)
> 
> "output reader" #36 daemon prio=5 os_prio=0 cpu=0.30ms elapsed=23.44s tid=0x00007f159c30db30 nid=115990 runnable  [0x00007f15097b8000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.SocketDispatcher.read0(java.base at 19-internal/Native Method)
> 	at sun.nio.ch.SocketDispatcher.read(java.base at 19-internal/SocketDispatcher.java:47)
> 	at sun.nio.ch.NioSocketImpl.tryRead(java.base at 19-internal/NioSocketImpl.java:258)
> 	at sun.nio.ch.NioSocketImpl.implRead(java.base at 19-internal/NioSocketImpl.java:309)
> 	at sun.nio.ch.NioSocketImpl.read(java.base at 19-internal/NioSocketImpl.java:347)
> 	at sun.nio.ch.NioSocketImpl$1.read(java.base at 19-internal/NioSocketImpl.java:800)
> 	at java.net.Socket$SocketInputStream.read(java.base at 19-internal/Socket.java:966)
> 	at java.net.Socket$SocketInputStream.read(java.base at 19-internal/Socket.java:961)
> 	at java.io.FilterInputStream.read(java.base at 19-internal/FilterInputStream.java:79)
> 	at jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 19-internal/DemultiplexInput.java:60)
> 
> "Thread-1" #38 daemon prio=5 os_prio=0 cpu=222.19ms elapsed=23.37s tid=0x00007f159c3e6db0 nid=115995 waiting on condition  [0x00007f15094b5000]
>    java.lang.Thread.State: WAITING (parking)
> 	at jdk.internal.misc.Unsafe.park(java.base at 19-internal/Native Method)
> 	- parking to wait for  <0x00000000a007a880> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(java.base at 19-internal/LockSupport.java:341)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 19-internal/AbstractQueuedSynchronizer.java:506)
> 	at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base at 19-internal/ForkJoinPool.java:3464)
> 	at java.util.concurrent.ForkJoinPool.managedBlock(java.base at 19-internal/ForkJoinPool.java:3435)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 19-internal/AbstractQueuedSynchronizer.java:1623)
> 	at java.util.concurrent.LinkedBlockingQueue.take(java.base at 19-internal/LinkedBlockingQueue.java:435)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 19-internal/ThreadPoolExecutor.java:1062)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 19-internal/ThreadPoolExecutor.java:1122)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 19-internal/ThreadPoolExecutor.java:635)
> 	at java.lang.Thread.run(java.base at 19-internal/Thread.java:828)
> 
> "process reaper" #40 daemon prio=10 os_prio=0 cpu=1.83ms elapsed=22.94s tid=0x00007f159c647300 nid=116044 waiting on condition  [0x00007f15280d0000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
> 	at jdk.internal.misc.Unsafe.park(java.base at 19-internal/Native Method)
> 	- parking to wait for  <0x00000000a0079fb0> (a java.util.concurrent.SynchronousQueue$TransferStack)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 19-internal/LockSupport.java:252)
> 	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 19-internal/SynchronousQueue.java:401)
> 	at java.util.concurrent.SynchronousQueue.poll(java.base at 19-internal/SynchronousQueue.java:903)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 19-internal/ThreadPoolExecutor.java:1061)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 19-internal/ThreadPoolExecutor.java:1122)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 19-internal/ThreadPoolExecutor.java:635)
> 	at java.lang.Thread.run(java.base at 19-internal/Thread.java:828)
> 
> "Thread-3" #41 daemon prio=5 os_prio=0 cpu=1.39ms elapsed=22.94s tid=0x00007f159c64b600 nid=116045 runnable  [0x00007f14734ed000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.io.FileInputStream.read0(java.base at 19-internal/Native Method)
> 	at java.io.FileInputStream.read(java.base at 19-internal/FileInputStream.java:228)
> 	at jdk.internal.org.jline.terminal.impl.AbstractPty$PtyInputStream.read(jdk.internal.le at 19-internal/AbstractPty.java:73)
> 	at jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 19-internal/NonBlockingInputStream.java:62)
> 	at jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 19-internal/StopDetectingInputStream.java:74)
> 	at jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$355/0x0000000800dd68d0.run(jdk.jshell at 19-internal/Unknown Source)
> 	at java.lang.Thread.run(java.base at 19-internal/Thread.java:828)
> 
> "null non blocking reader thread" #43 daemon prio=5 os_prio=0 cpu=0.15ms elapsed=22.78s tid=0x00007f159c678910 nid=116063 in Object.wait()  [0x00007f1472ee6000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(java.base at 19-internal/Native Method)
> 	- waiting on <no object reference available>
> 	at java.lang.Object.wait(java.base at 19-internal/Object.java:338)
> 	at jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 19-internal/StopDetectingInputStream.java:111)
> 	- locked <0x00000000a2000908> (a jdk.internal.jshell.tool.StopDetectingInputStream)
> 	at jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 19-internal/NonBlockingInputStreamImpl.java:216)
> 	at jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$530/0x0000000800dfde40.run(jdk.internal.le at 19-internal/Unknown Source)
> 	at java.lang.Thread.run(java.base at 19-internal/Thread.java:828)
> 
> "Attach Listener" #44 daemon prio=9 os_prio=0 cpu=0.17ms elapsed=0.10s tid=0x00007f1504000be0 nid=116383 waiting on condition  [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> 
> "VM Thread" os_prio=0 cpu=8.31ms elapsed=23.72s tid=0x00007f159c1b78f0 nid=115925 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xf21ec5]  VM_PrintThreads::doit()+0x25
> V  [libjvm.so+0xf225aa]  VM_Operation::evaluate()+0xea
> V  [libjvm.so+0xf23f18]  VMThread::evaluate_operation(VM_Operation*)+0xb8
> V  [libjvm.so+0xf245c7]  VMThread::inner_execute(VM_Operation*)+0x3a7
> V  [libjvm.so+0xf24877]  VMThread::run()+0xb7
> V  [libjvm.so+0xe99770]  Thread::call_run()+0xc0
> V  [libjvm.so+0xc37a08]  thread_native_entry(Thread*)+0xd8
> 
> "GC Thread#0" os_prio=0 cpu=39.19ms elapsed=23.73s tid=0x00007f159c066a10 nid=115920 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "GC Thread#1" os_prio=0 cpu=9.75ms elapsed=23.16s tid=0x00007f15180140e0 nid=116014 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "GC Thread#2" os_prio=0 cpu=0.48ms elapsed=23.15s tid=0x00007f151801b730 nid=116015 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "GC Thread#3" os_prio=0 cpu=11.09ms elapsed=23.15s tid=0x00007f151801c160 nid=116016 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "GC Thread#4" os_prio=0 cpu=24.95ms elapsed=23.15s tid=0x00007f151801ccc0 nid=116017 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "GC Thread#5" os_prio=0 cpu=0.58ms elapsed=23.15s tid=0x00007f151801d820 nid=116018 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "GC Thread#6" os_prio=0 cpu=35.58ms elapsed=23.15s tid=0x00007f151801e380 nid=116019 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "GC Thread#7" os_prio=0 cpu=13.88ms elapsed=22.98s tid=0x00007f151801b050 nid=116042 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "GC Thread#8" os_prio=0 cpu=12.97ms elapsed=22.92s tid=0x00007f1518021950 nid=116047 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Main Marker" os_prio=0 cpu=0.84ms elapsed=23.73s tid=0x00007f159c076ed0 nid=115921 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xba33]  pthread_cond_wait+0xc3
> V  [libjvm.so+0xbf1589]  Monitor::wait_without_safepoint_check(long)+0x39
> V  [libjvm.so+0x725fda]  G1ConcurrentMarkThread::wait_for_next_cycle()+0x3a
> V  [libjvm.so+0x7270bb]  G1ConcurrentMarkThread::run_service()+0xdb
> V  [libjvm.so+0x60be0b]  ConcurrentGCThread::run()+0x1b
> V  [libjvm.so+0xe99770]  Thread::call_run()+0xc0
> V  [libjvm.so+0xc37a08]  thread_native_entry(Thread*)+0xd8
> 
> "G1 Conc#0" os_prio=0 cpu=6.39ms elapsed=23.73s tid=0x00007f159c077f50 nid=115922 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#1" os_prio=0 cpu=1.74ms elapsed=23.05s tid=0x00007f152c000960 nid=116022 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#2" os_prio=0 cpu=1.23ms elapsed=23.05s tid=0x00007f152c001490 nid=116023 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#3" os_prio=0 cpu=2.04ms elapsed=23.05s tid=0x00007f152c001ff0 nid=116024 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#4" os_prio=0 cpu=1.28ms elapsed=23.05s tid=0x00007f152c002b50 nid=116025 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#5" os_prio=0 cpu=1.60ms elapsed=23.05s tid=0x00007f152c0036b0 nid=116026 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#6" os_prio=0 cpu=1.61ms elapsed=23.05s tid=0x00007f152c004210 nid=116027 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#7" os_prio=0 cpu=2.00ms elapsed=23.05s tid=0x00007f152c005160 nid=116028 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#8" os_prio=0 cpu=1.58ms elapsed=23.05s tid=0x00007f152c0060b0 nid=116029 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#9" os_prio=0 cpu=1.26ms elapsed=23.05s tid=0x00007f152c007000 nid=116030 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#10" os_prio=0 cpu=1.61ms elapsed=23.05s tid=0x00007f152c007f50 nid=116031 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#11" os_prio=0 cpu=1.52ms elapsed=23.05s tid=0x00007f152c008ea0 nid=116032 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#12" os_prio=0 cpu=1.17ms elapsed=23.05s tid=0x00007f152c009df0 nid=116033 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#13" os_prio=0 cpu=1.88ms elapsed=23.05s tid=0x00007f152c00ad40 nid=116034 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#14" os_prio=0 cpu=1.31ms elapsed=23.05s tid=0x00007f152c00bc90 nid=116035 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Conc#15" os_prio=0 cpu=1.52ms elapsed=23.05s tid=0x00007f152c00cbe0 nid=116036 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Refine#0" os_prio=0 cpu=0.03ms elapsed=23.73s tid=0x00007f159c1881d0 nid=115923 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xdb39]  do_futex_wait.constprop.1+0x29
> 
> "G1 Service" os_prio=0 cpu=0.72ms elapsed=23.73s tid=0x00007f159c189290 nid=115924 runnable  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xbde2]  pthread_cond_timedwait+0x132
> V  [libjvm.so+0xbf1589]  Monitor::wait_without_safepoint_check(long)+0x39
> V  [libjvm.so+0x77d208]  G1ServiceThread::wait_for_task()+0xf8
> V  [libjvm.so+0x77d600]  G1ServiceThread::run_service()+0x20
> V  [libjvm.so+0x60be0b]  ConcurrentGCThread::run()+0x1b
> V  [libjvm.so+0xe99770]  Thread::call_run()+0xc0
> V  [libjvm.so+0xc37a08]  thread_native_entry(Thread*)+0xd8
> 
> "VM Periodic Task Thread" os_prio=0 cpu=4.05ms elapsed=23.71s tid=0x00007f159c1fddf0 nid=115937 waiting on condition  
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0xbde2]  pthread_cond_timedwait+0x132
> V  [libjvm.so+0xbf1589]  Monitor::wait_without_safepoint_check(long)+0x39
> V  [libjvm.so+0xc07015]  WatcherThread::sleep() const+0xa5
> V  [libjvm.so+0xc070e5]  WatcherThread::run()+0x35
> V  [libjvm.so+0xe99770]  Thread::call_run()+0xc0
> V  [libjvm.so+0xc37a08]  thread_native_entry(Thread*)+0xd8
> 
> JNI global refs: 28, weak refs: 0

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/7833

From sgehwolf at openjdk.java.net  Thu May 12 10:07:31 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 10:07:31 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
In-Reply-To: <Tb2H9w2gDKJ7c4-dlu08OxlxhOvXac4KI_ZPU0bakT8=.1f13223a-8a2c-42a4-bae9-d5f78ed81c10@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <Tb2H9w2gDKJ7c4-dlu08OxlxhOvXac4KI_ZPU0bakT8=.1f13223a-8a2c-42a4-bae9-d5f78ed81c10@github.com>
Message-ID: <AuSTxEhK-QJ31UQvQX2lApJy8iwOqhtnwscBoh9Qd4k=.b6e8aadc-e28d-4f16-a63c-e874c5055aa3@github.com>

On Thu, 12 May 2022 06:11:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 65:
> 
>> 63:                             path = mountPoint + cgroupSubstr;
>> 64:                         }
>> 65:                     } else {
> 
> Looks like `path` is still not set if the condition at line 61 `if (cgroupPath.length() > root.length()) {` is false.

Yes. There are more cases where the cgroup path might be null. If you know of cases that should be handled and aren't, please do let me know. Incidentally, that's why I've added the catch for NPE in `CgroupV1Subsystem.initSubSystem()`, because it's not clear what should be used as `path` in those corner cases. It certainly shouldn't throw a NPE :-). It then also more closely matches what hotspot does. Having said that, if `cgroupPath.length < root.length()` it's implied that `cgroupPath.startsWith(root)` is false. Then the only case where it would still be null is when the paths match in lenght, but aren't the same.

I'm not convinced the logic when then cgroup patch starts with the root path, then it should do what it does today. I.e. given `mountpath=/sys/fs/cgroup/memory`, `root=/foo/bar` and `cgroupPath=/foo/bar/baz` then `path=/sys/fs/cgroup/memory/baz`. I've personally not seen such a setup and the code predates me. Considering that the equivalent hotspot code had a bug in this logic since day 1, it doesn't seem very widely used...

The most common cases I know to date are:

1. `root=/`, `cgroupPath=/some`, `mount=/sys/fs/cgroup/controller` => `path=/sys/fs/cgroup/controller/some` (host systems)
2. `root=/foo/bar/baz`, `cgroupPath=/foo/bar/baz`, `mount=/sys/fs/cgroup/controller` => `path=/sys/fs/cgroup/controller` (most container engines)

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Thu May 12 11:36:46 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 11:36:46 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
In-Reply-To: <Tb2H9w2gDKJ7c4-dlu08OxlxhOvXac4KI_ZPU0bakT8=.1f13223a-8a2c-42a4-bae9-d5f78ed81c10@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <Tb2H9w2gDKJ7c4-dlu08OxlxhOvXac4KI_ZPU0bakT8=.1f13223a-8a2c-42a4-bae9-d5f78ed81c10@github.com>
Message-ID: <WILIeWUVwxUpcuxVnZRdm6iqCWgxn1qX9NRJrjhNQK4=.80206e0f-ad75-4091-a625-e8eaf8563995@github.com>

On Thu, 12 May 2022 06:13:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I just started to look at the code so just one comment for now.

Sure, thanks for the review!

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From stuefe at openjdk.java.net  Thu May 12 14:05:57 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 12 May 2022 14:05:57 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
In-Reply-To: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
Message-ID: <PT5BLg7JAwHZRRhw3c1HV53IHWBiuf6NFUAOMYYQTLI=.f91bbf3c-569b-49d8-85f1-62a0f8c62589@github.com>

On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
> 
> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
> 
> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
> 
> Testing:
> - [x] Added unit tests
> - [x] GHA
> - [x] Container tests on cgroups v1 Linux. Continue to pass

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 113:

> 111:           }
> 112:           buf[MAXPATHLEN-1] = '\0';
> 113:           _path = os::strdup(buf);

I think this code can be simplified a lot with stringStream and without strtok, so no need for fixed buffers (which may fail with longer path names) and no need for writable string copies on the stack.

Something like this:

stringStream ss;
ss.print_raw(_mount_point);
const char* p1 = _root;
const char* p2 = cgroup_path;
int last_matching_dash_pos = -1;
for (int i = 0; *p1 == *p2 && *p1 != 0; i ++) {
	if (*p1 == '/') {
		last_matching_dash_pos = i;
	}
        p1++; p2++;
}
ss.print_raw(_root, last_matching_dash_pos);
// Now use ss.base() to access the assembled string

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Thu May 12 16:03:01 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 16:03:01 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
In-Reply-To: <PT5BLg7JAwHZRRhw3c1HV53IHWBiuf6NFUAOMYYQTLI=.f91bbf3c-569b-49d8-85f1-62a0f8c62589@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <PT5BLg7JAwHZRRhw3c1HV53IHWBiuf6NFUAOMYYQTLI=.f91bbf3c-569b-49d8-85f1-62a0f8c62589@github.com>
Message-ID: <NR24l0clt_UoJ2At2RSbAtuOUCFnR3bFvS3rArnZTSo=.0fa3b638-7956-461c-9d2d-5441b639b3d4@github.com>

On Thu, 12 May 2022 14:00:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 113:
> 
>> 111:           }
>> 112:           buf[MAXPATHLEN-1] = '\0';
>> 113:           _path = os::strdup(buf);
> 
> I think this code can be simplified a lot with stringStream and without strtok, so no need for fixed buffers (which may fail with longer path names) and no need for writable string copies on the stack.
> 
> Something like this:
> 
> stringStream ss;
> ss.print_raw(_mount_point);
> const char* p1 = _root;
> const char* p2 = cgroup_path;
> int last_matching_dash_pos = -1;
> for (int i = 0; *p1 == *p2 && *p1 != 0; i ++) {
> 	if (*p1 == '/') {
> 		last_matching_dash_pos = i;
> 	}
>         p1++; p2++;
> }
> ss.print_raw(_root, last_matching_dash_pos);
> // Now use ss.base() to access the assembled string

Nice, thanks! I'll update it.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Thu May 12 18:09:40 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 18:09:40 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
Message-ID: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>

> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
> 
> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
> 
> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
> 
> Testing:
> - [x] Added unit tests
> - [x] GHA
> - [x] Container tests on cgroups v1 Linux. Continue to pass

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Use stringStream to simplify controller path assembly

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8629/files
  - new: https://git.openjdk.java.net/jdk/pull/8629/files/bc873b3f..66241aa5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=00-01

  Stats: 32 lines in 1 file changed: 0 ins; 21 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8629.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8629/head:pull/8629

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Thu May 12 18:09:41 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 18:09:41 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <NR24l0clt_UoJ2At2RSbAtuOUCFnR3bFvS3rArnZTSo=.0fa3b638-7956-461c-9d2d-5441b639b3d4@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <PT5BLg7JAwHZRRhw3c1HV53IHWBiuf6NFUAOMYYQTLI=.f91bbf3c-569b-49d8-85f1-62a0f8c62589@github.com>
 <NR24l0clt_UoJ2At2RSbAtuOUCFnR3bFvS3rArnZTSo=.0fa3b638-7956-461c-9d2d-5441b639b3d4@github.com>
Message-ID: <LEj5namOIjF-CUA3NPXu_N2eX_-uIhQoKS8nOLfswO0=.fd38089b-bab5-43c2-af80-47dfdbaebc0d@github.com>

On Thu, 12 May 2022 15:58:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 113:
>> 
>>> 111:           }
>>> 112:           buf[MAXPATHLEN-1] = '\0';
>>> 113:           _path = os::strdup(buf);
>> 
>> I think this code can be simplified a lot with stringStream and without strtok, so no need for fixed buffers (which may fail with longer path names) and no need for writable string copies on the stack.
>> 
>> Something like this:
>> 
>> stringStream ss;
>> ss.print_raw(_mount_point);
>> const char* p1 = _root;
>> const char* p2 = cgroup_path;
>> int last_matching_dash_pos = -1;
>> for (int i = 0; *p1 == *p2 && *p1 != 0; i ++) {
>> 	if (*p1 == '/') {
>> 		last_matching_dash_pos = i;
>> 	}
>>         p1++; p2++;
>> }
>> ss.print_raw(_root, last_matching_dash_pos);
>> // Now use ss.base() to access the assembled string
>
> Nice, thanks! I'll update it.

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From amenkov at openjdk.java.net  Thu May 12 23:17:39 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 12 May 2022 23:17:39 GMT
Subject: RFR: 8281268: Resolve duplication of test ClassTransformer class
In-Reply-To: <0LDP8tblKUqLt0fcYtmlJ2Mu8hRCBh7rvge6Muo7dtg=.04497b51-993a-4f3b-984f-65ece6addcfd@github.com>
References: <0LDP8tblKUqLt0fcYtmlJ2Mu8hRCBh7rvge6Muo7dtg=.04497b51-993a-4f3b-984f-65ece6addcfd@github.com>
Message-ID: <vYeGPVkA1pCh01UWh5wGHqiNsr652VWUCxEoKf0gdjU=.577257bd-b215-4266-bcf4-27b5c611d657@github.com>

On Thu, 12 May 2022 06:43:29 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> ClassTransformer.java is duplicated because ClassTransformer.java was copied from test/jdk/com/sun/jdi/lib/jdb to test/lib/jdk/test/lib/util at [JDK-8240908](https://bugs.openjdk.java.net/browse/JDK-8240908). test/lib/jdk/test/lib/util/ClassTransformer.java should be deleted and test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java should be used. This is because ClassTransformer is used for testing jdi, and it is not appropriate to exist in test/lib/jdk/test/lib/util.
> Would you please review this fix?

There are 2 point here.
1. You started to work on a fix for issue assigned to another engineer. This is a way to duplicate effort and waste time. I have a fix ready locally, but haven't submitted a PR (had to resolve dependency first).
2. Looks like you misunderstood the issue. There are tests which use ClassTransformer outside of test/jdk/com/sun/jdi (and there are test which use ClassTransformer in other project, and that was the reason the file was copied by JDK-8240908). Actually your fix changes test from lang/instrument, so the fix conflicts with the PR description.

So I think it's better to withdraw the PR - I'll create another one soon.

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

PR: https://git.openjdk.java.net/jdk/pull/8672

From duke at openjdk.java.net  Fri May 13 07:00:55 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Fri, 13 May 2022 07:00:55 GMT
Subject: RFR: 8281268: Resolve duplication of test ClassTransformer class
In-Reply-To: <0LDP8tblKUqLt0fcYtmlJ2Mu8hRCBh7rvge6Muo7dtg=.04497b51-993a-4f3b-984f-65ece6addcfd@github.com>
References: <0LDP8tblKUqLt0fcYtmlJ2Mu8hRCBh7rvge6Muo7dtg=.04497b51-993a-4f3b-984f-65ece6addcfd@github.com>
Message-ID: <GFxXhuZEy4ULVmh3V2wOlVHMzAVOTkER5RMG2aAApg0=.61773372-e764-4f87-a8e9-156008df5b8c@github.com>

On Thu, 12 May 2022 06:43:29 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> ClassTransformer.java is duplicated because ClassTransformer.java was copied from test/jdk/com/sun/jdi/lib/jdb to test/lib/jdk/test/lib/util at [JDK-8240908](https://bugs.openjdk.java.net/browse/JDK-8240908). test/lib/jdk/test/lib/util/ClassTransformer.java should be deleted and test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java should be used. This is because ClassTransformer is used for testing jdi, and it is not appropriate to exist in test/lib/jdk/test/lib/util.
> Would you please review this fix?

All right.. I closed this pull request.

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

PR: https://git.openjdk.java.net/jdk/pull/8672

From duke at openjdk.java.net  Fri May 13 07:00:56 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Fri, 13 May 2022 07:00:56 GMT
Subject: Withdrawn: 8281268: Resolve duplication of test ClassTransformer class
In-Reply-To: <0LDP8tblKUqLt0fcYtmlJ2Mu8hRCBh7rvge6Muo7dtg=.04497b51-993a-4f3b-984f-65ece6addcfd@github.com>
References: <0LDP8tblKUqLt0fcYtmlJ2Mu8hRCBh7rvge6Muo7dtg=.04497b51-993a-4f3b-984f-65ece6addcfd@github.com>
Message-ID: <c_aysPN7XvhRHkyDw9GezH-MfLolKLzB-UL0ksBzrow=.5fac6771-f2ab-4161-9df5-f62b24f00ecb@github.com>

On Thu, 12 May 2022 06:43:29 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> ClassTransformer.java is duplicated because ClassTransformer.java was copied from test/jdk/com/sun/jdi/lib/jdb to test/lib/jdk/test/lib/util at [JDK-8240908](https://bugs.openjdk.java.net/browse/JDK-8240908). test/lib/jdk/test/lib/util/ClassTransformer.java should be deleted and test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java should be used. This is because ClassTransformer is used for testing jdi, and it is not appropriate to exist in test/lib/jdk/test/lib/util.
> Would you please review this fix?

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8672

From asotona at openjdk.java.net  Fri May 13 08:32:29 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Fri, 13 May 2022 08:32:29 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v6]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <LWPvsMChniyfkaHPvxdnn1tvOwQkW9MSCwiDoJ_Fm78=.5ca8e192-b796-43d4-a621-0ac58232eae9@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

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

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=05
  Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From stuefe at openjdk.java.net  Fri May 13 10:21:48 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 13 May 2022 10:21:48 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
Message-ID: <Oa0E9OEZpABTtFpdieFA2Sh4Tsc4M6QbGM21LXTehNk=.13759647-60f2-4beb-a698-c84477cfcc76@github.com>

On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use stringStream to simplify controller path assembly

Thanks for taking my suggestion! Much simpler now :-)

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From ihse at openjdk.java.net  Fri May 13 15:14:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 15:14:43 GMT
Subject: RFR: 8285366: Fix typos in serviceability [v2]
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <de2J9hbH6Geo9BTK6iIPUAZGlDY6rV_RKI5-3GAir1U=.95c6f093-6bc8-4335-935e-7f2965325a57@github.com>

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert "invocable"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8334/files
  - new: https://git.openjdk.java.net/jdk/pull/8334/files/4b26668d..ad36a59a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8334

From ihse at openjdk.java.net  Fri May 13 15:18:26 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 15:18:26 GMT
Subject: RFR: 8285366: Fix typos in serviceability [v3]
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <spv7AmHQlRMq1ecLah808rHAow8zcvCViF_El1OX_ho=.8361392e-4647-44d9-8219-6724f232d2aa@github.com>

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8334/files
  - new: https://git.openjdk.java.net/jdk/pull/8334/files/ad36a59a..4490ef75

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=01-02

  Stats: 117 lines in 117 files changed: 0 ins; 0 del; 117 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8334.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8334/head:pull/8334

PR: https://git.openjdk.java.net/jdk/pull/8334

From ihse at openjdk.java.net  Fri May 13 15:20:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 15:20:38 GMT
Subject: Integrated: 8285366: Fix typos in serviceability
In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com>
Message-ID: <31om9CILXc-UyN6Rbq8TQ3rgRgKopMrAlzF0o2hp84c=.2c91e2cd-08e2-400f-b320-19444106d5ad@github.com>

On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos.
> 
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

This pull request has now been integrated.

Changeset: 76caeed4
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/76caeed498d868c7923461fb481349c0a2cbd99d
Stats:     303 lines in 136 files changed: 0 ins; 0 del; 303 mod

8285366: Fix typos in serviceability

Reviewed-by: kevinw, sspitsyn

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

PR: https://git.openjdk.java.net/jdk/pull/8334

From amenkov at openjdk.java.net  Fri May 13 22:58:05 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 13 May 2022 22:58:05 GMT
Subject: RFR: 8281268: Resolve duplication of test ClassTransformer class
Message-ID: <iUFC3U4i8UE6I_Bld7MyzYsBr1dJ_LgRb3RDvRS2Xl0=.735e3167-c0cb-4c23-8899-183f8939a382@github.com>

The fix deletes ClassTransformer class from jdi, switches all the test to jdk.test.lib copy.

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

Commit messages:
 - deleted ClassTransformer in jdi lib

Changes: https://git.openjdk.java.net/jdk/pull/8710/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8710&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281268
  Stats: 169 lines in 4 files changed: 1 ins; 163 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8710.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8710/head:pull/8710

PR: https://git.openjdk.java.net/jdk/pull/8710

From jbachorik at openjdk.java.net  Mon May 16 08:27:36 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Mon, 16 May 2022 08:27:36 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v7]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <-Qyxt1vJeKwHeORs4OHDaSwa2OrMCCWgQD5tO9nVvfI=.6a4a2180-9c53-4164-868b-36b05827c919@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Avoid check overhead when possible

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/949609c8..5b1debc3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=05-06

  Stats: 16 lines in 1 file changed: 8 ins; 6 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Mon May 16 08:49:40 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Mon, 16 May 2022 08:49:40 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v8]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <suCJ8JLZCv7H9-2PjxMtBFxBuyoXD--_27BqQhVgfbQ=.f277e265-ea4b-430b-8b89-0f857d554cc2@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - Use RAII object to manage thread in_asgct status
 - Avoid check overhead when possible

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/5b1debc3..3db28ccf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=06-07

  Stats: 23 lines in 3 files changed: 20 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549

PR: https://git.openjdk.java.net/jdk/pull/8549

From kevinw at openjdk.java.net  Mon May 16 08:54:48 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 16 May 2022 08:54:48 GMT
Subject: RFR: 8281268: Resolve duplication of test ClassTransformer class
In-Reply-To: <iUFC3U4i8UE6I_Bld7MyzYsBr1dJ_LgRb3RDvRS2Xl0=.735e3167-c0cb-4c23-8899-183f8939a382@github.com>
References: <iUFC3U4i8UE6I_Bld7MyzYsBr1dJ_LgRb3RDvRS2Xl0=.735e3167-c0cb-4c23-8899-183f8939a382@github.com>
Message-ID: <VeDWXNPTffTtSn-O5Ge2AFC1CaRo_Fa41QkMBHcQQqU=.a81531c6-15e9-45ed-a2b0-fdfea3f78cf5@github.com>

On Fri, 13 May 2022 22:50:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix deletes ClassTransformer class from jdi, switches all the test to jdk.test.lib copy.

Looks good.  Those are the only imports I can see for this, and the ClassTransformer.java text is the same in both places.

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

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8710

From jbachorik at openjdk.java.net  Mon May 16 09:51:43 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Mon, 16 May 2022 09:51:43 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v8]
In-Reply-To: <suCJ8JLZCv7H9-2PjxMtBFxBuyoXD--_27BqQhVgfbQ=.f277e265-ea4b-430b-8b89-0f857d554cc2@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <suCJ8JLZCv7H9-2PjxMtBFxBuyoXD--_27BqQhVgfbQ=.f277e265-ea4b-430b-8b89-0f857d554cc2@github.com>
Message-ID: <PnhS0i_xYDms44_9MwkYVj57uC0yxfp0Z_1Kfu4Qg8s=.bef56378-cfa6-42a0-a5d0-79bbea3aa359@github.com>

On Mon, 16 May 2022 08:49:40 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Use RAII object to manage thread in_asgct status
>  - Avoid check overhead when possible

Ok, I moved the expensive check only after it is sure we are dealing with a zombie method.

Thanks for all the suggestions! This change now looks much more self-contained than I hoped for.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Mon May 16 09:51:45 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Mon, 16 May 2022 09:51:45 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6]
In-Reply-To: <6ikleowciR73wkChDKRAhEgUEuHH1ZtFXze7VjptS3Q=.29ab42a4-4926-420c-8ce8-8ed2db7ec8db@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <sY6-KDTAAlH-Q0VYKiFalVplyImwCCfVxL1sn7j_rNw=.c9be73d1-59be-4267-891c-58cc807dcf16@github.com>
 <6ikleowciR73wkChDKRAhEgUEuHH1ZtFXze7VjptS3Q=.29ab42a4-4926-420c-8ce8-8ed2db7ec8db@github.com>
Message-ID: <rzcHuQS60Y23BxG8WZSPWBcqTZUwNmT8E_ONIqsVkMc=.0275ef13-e9d4-43f1-82d8-4414a2b6d52b@github.com>

On Sat, 7 May 2022 04:59:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Jaroslav Bachorik has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Move 'in_asgct' flag to JavaThread
>
> src/hotspot/share/prims/forte.cpp line 594:
> 
>> 592:   }
>> 593: 
>> 594:   thread->set_in_asgct(true);
> 
> Suggestion: Use a small RAII Mark object instead. That way you prevent future errors if someone should add a return in the mids of AGCT.

Done

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From asotona at openjdk.java.net  Mon May 16 14:45:25 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 16 May 2022 14:45:25 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v7]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <B9n9ovVUUAPav2KdXUFCOizjfBhzhONYzbossdB5IoQ=.dcca8271-3116-4026-a51a-0afa592cb3ad@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

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

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06
  Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Mon May 16 14:58:33 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 16 May 2022 14:58:33 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v8]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <6fMaRe1U4N-Uz4oe8QKOqIwy-bqkQRVR75XJJpLSXgY=.c8072af3-f0e1-430e-9ab2-33db617c5d77@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  8244681: Add a warning for possibly lossy conversion in compound assignments
  re-enabled warnings for java.base, java.rmi and java.smartcardio

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/a72644e9..74f9f4b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06-07

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From jbachorik at openjdk.java.net  Mon May 16 15:14:25 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Mon, 16 May 2022 15:14:25 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Restore the original find_blob behavior regarding dead blobs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/3db28ccf..546dc819

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From dholmes at openjdk.java.net  Tue May 17 05:41:54 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 17 May 2022 05:41:54 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
Message-ID: <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>

On Mon, 16 May 2022 15:14:25 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore the original find_blob behavior regarding dead blobs

src/hotspot/share/prims/forte.hpp line 53:

> 51:   ASGCTMark() : ASGCTMark(JavaThread::current()) {}
> 52:   ~ASGCTMark() {
> 53:     JavaThread::current()->set_in_asgct(false);

You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`.

Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO.

src/hotspot/share/runtime/thread.hpp line 1650:

> 1648:   static void vm_exit_on_osthread_failure(JavaThread* thread);
> 1649: 
> 1650: 

Don't need two blank lines. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From iklam at openjdk.java.net  Tue May 17 05:58:45 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 17 May 2022 05:58:45 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
Message-ID: <wCV6hj4zbb5rrZXFcGAWcNUHKxATBR9fGX9JO30ql9k=.005bbfdf-4fcd-4362-8c5e-ba3968f08010@github.com>

On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use stringStream to simplify controller path assembly

test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63:

> 61:     ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path());
> 62:   }
> 63: }

I found it hard to relate the different paths. Could you create a new struct like this?


struct TestCase {
    char* mount_path;
    char* root_paths;
    char* cgroup_path;
    char* expected_cg_paths;
} = {
  {  "/sys/fs/cgroup/memory",     // mount
       "/",                       // root,
       ....

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From iklam at openjdk.java.net  Tue May 17 06:21:50 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 17 May 2022 06:21:50 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
Message-ID: <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>

On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use stringStream to simplify controller path assembly

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:

> 90:           }
> 91:           ss.print_raw(_root, last_matching_slash_pos);
> 92:           _path = os::strdup(ss.base());

Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From stuefe at openjdk.java.net  Tue May 17 07:17:49 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 17 May 2022 07:17:49 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
Message-ID: <jsmEFefV1TES-LeReR8zTwkPT9XovK_V6Gyl1n1NwyY=.d9d7077c-318a-4703-b646-82f7c69f117c@github.com>

On Tue, 17 May 2022 06:18:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use stringStream to simplify controller path assembly
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:
> 
>> 90:           }
>> 91:           ss.print_raw(_root, last_matching_slash_pos);
>> 92:           _path = os::strdup(ss.base());
> 
> Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand.

Maybe factor out the search like this

// Return length of common starting substring. E.g. "cat" for ("cattle", "catnip");
static int find_common_starting_substring(const char* s1, const char* s2) {
...
}

That way its clearer and we can find and move this to utilities if we ever need this in other places.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From jbachorik at openjdk.java.net  Tue May 17 07:52:31 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Tue, 17 May 2022 07:52:31 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v10]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <_XPbmmj0IKyltlA6zfsgfXw0zOg3FGAwK_4_5jQMvEo=.af18c47a-8202-49b5-9118-0d1cc510c807@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with two additional commits since the last revision:

 - Remove extra new line
 - Fix ASGCTMark safety issues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/546dc819..356462a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=08-09

  Stats: 19 lines in 3 files changed: 8 ins; 6 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549

PR: https://git.openjdk.java.net/jdk/pull/8549

From sgehwolf at openjdk.java.net  Tue May 17 08:15:40 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 17 May 2022 08:15:40 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <jsmEFefV1TES-LeReR8zTwkPT9XovK_V6Gyl1n1NwyY=.d9d7077c-318a-4703-b646-82f7c69f117c@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
 <jsmEFefV1TES-LeReR8zTwkPT9XovK_V6Gyl1n1NwyY=.d9d7077c-318a-4703-b646-82f7c69f117c@github.com>
Message-ID: <JH9YUX0j7ylapxhxWDk9p5NYdMKAHYAzq-cfzBQfzLE=.fe47a403-c4cd-494e-9098-6fe78cb2bd22@github.com>

On Tue, 17 May 2022 07:14:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:
>> 
>>> 90:           }
>>> 91:           ss.print_raw(_root, last_matching_slash_pos);
>>> 92:           _path = os::strdup(ss.base());
>> 
>> Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand.
>
> Maybe factor out the search like this
> 
> // Return length of common starting substring. E.g. "cat" for ("cattle", "catnip");
> static int find_common_starting_substring(const char* s1, const char* s2) {
> ...
> }
> 
> That way its clearer and we can find and move this to utilities if we ever need this in other places.

OK.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Tue May 17 08:15:41 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 17 May 2022 08:15:41 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <wCV6hj4zbb5rrZXFcGAWcNUHKxATBR9fGX9JO30ql9k=.005bbfdf-4fcd-4362-8c5e-ba3968f08010@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <wCV6hj4zbb5rrZXFcGAWcNUHKxATBR9fGX9JO30ql9k=.005bbfdf-4fcd-4362-8c5e-ba3968f08010@github.com>
Message-ID: <WBoNsbDS2rWIBcmFh6Khgg4Q_3Nj6QlDNoaU5hCEzTI=.68f8f86a-8b35-463f-8225-ed136614362f@github.com>

On Tue, 17 May 2022 05:55:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use stringStream to simplify controller path assembly
>
> test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63:
> 
>> 61:     ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path());
>> 62:   }
>> 63: }
> 
> I found it hard to relate the different paths. Could you create a new struct like this?
> 
> 
> struct TestCase {
>     char* mount_path;
>     char* root_paths;
>     char* cgroup_path;
>     char* expected_cg_paths;
> } = {
>   {  "/sys/fs/cgroup/memory",     // mount
>        "/",                       // root,
>        ....

Yes, makes sense. Will do.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From jbachorik at openjdk.java.net  Tue May 17 08:16:49 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Tue, 17 May 2022 08:16:49 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
Message-ID: <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>

On Tue, 17 May 2022 05:38:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore the original find_blob behavior regarding dead blobs
>
> src/hotspot/share/prims/forte.hpp line 53:
> 
>> 51:   ASGCTMark() : ASGCTMark(JavaThread::current()) {}
>> 52:   ~ASGCTMark() {
>> 53:     JavaThread::current()->set_in_asgct(false);
> 
> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`.
> 
> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO.

Ok, I fixed the `ASGCTMark` to be safe to use from a signal handler.

I have no strong opinion about whether we should keep it or not - it makes the code in `forte.cpp` slightly more resilient in case of further modifications for the price of more complexity introduced by the mark class ??

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From stuefe at openjdk.java.net  Tue May 17 09:10:49 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 17 May 2022 09:10:49 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
Message-ID: <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>

On Tue, 17 May 2022 08:13:11 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/hotspot/share/prims/forte.hpp line 53:
>> 
>>> 51:   ASGCTMark() : ASGCTMark(JavaThread::current()) {}
>>> 52:   ~ASGCTMark() {
>>> 53:     JavaThread::current()->set_in_asgct(false);
>> 
>> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`.
>> 
>> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO.
>
> Ok, I fixed the `ASGCTMark` to be safe to use from a signal handler.
> 
> I have no strong opinion about whether we should keep it or not - it makes the code in `forte.cpp` slightly more resilient in case of further modifications for the price of more complexity introduced by the mark class ??

Hi David,

> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`.
> 
> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO.

No problem, that's why we talk :)

To make an argument for this: if you compare the first iterations of this patch to the current one, the current one is a lot simpler. I really dislike funneling arguments through many layers down to a utility function, only to fine control one specific behavioral aspect of that tiny function, and that aspect is only relevant for one outlier use case. I dislike this more than the RAII object.

Look at it this way. We have a thread-specific state (we are in AGCT and deep down somewhere we want to do something different depending on that state). We need to pass that information down. The only difference is where we keep the "we are in thread-specific state" info - on the stack as an argument chain, or anchored to TLS.

Putting it into arguments is one way, but I find this rather ugly. Now every caller of this function has to care. With the RAII, we have the information as a mark exactly where it matters - in the entrance frame of AGCT - and no outside code needs to care.

Cheers, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From dholmes at openjdk.java.net  Tue May 17 12:27:43 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 17 May 2022 12:27:43 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
 <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
Message-ID: <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>

On Tue, 17 May 2022 09:07:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Ok, I fixed the `ASGCTMark` to be safe to use from a signal handler.
>> 
>> I have no strong opinion about whether we should keep it or not - it makes the code in `forte.cpp` slightly more resilient in case of further modifications for the price of more complexity introduced by the mark class ??
>
> Hi David,
> 
>> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`.
>> 
>> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO.
> 
> No problem, that's why we talk :)
> 
> To make an argument for this: if you compare the first iterations of this patch to the current one, the current one is a lot simpler. I really dislike funneling arguments through many layers down to a utility function, only to fine control one specific behavioral aspect of that tiny function, and that aspect is only relevant for one outlier use case. I dislike this more than the RAII object.
> 
> Look at it this way. We have a thread-specific state (we are in AGCT and deep down somewhere we want to do something different depending on that state). We need to pass that information down. The only difference is where we keep the "we are in thread-specific state" info - on the stack as an argument chain, or anchored to TLS.
> 
> Putting it into arguments is one way, but I find this rather ugly. Now every caller of this function has to care. With the RAII, we have the information as a mark exactly where it matters - in the entrance frame of AGCT - and no outside code needs to care.
> 
> Cheers, Thomas

But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace:


thread->set_in_asgct(true);
<stuff>
thread->set_in_asgct(false);

with


ASGCTMark mark(thread);
<stuff>

but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`.

And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `<stuff>` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Tue May 17 12:45:52 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Tue, 17 May 2022 12:45:52 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v11]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <nbCbFkyv7VIN9XUVinwRTlt74UGP4VFgwJKSaPWN9-I=.d282dd4d-fdaf-4200-9f62-106b2c034a0d@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Remove ASGCTMark

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/356462a8..bdd758fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=09-10

  Stats: 25 lines in 2 files changed: 3 ins; 21 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Tue May 17 12:45:54 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Tue, 17 May 2022 12:45:54 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
 <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
 <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
Message-ID: <04ZPdzZZEw_lJvtvxDZikSEVLbieDOo_ZtW85P9VEL4=.48564ed6-3065-4951-a7f8-d3aa7465da9c@github.com>

On Tue, 17 May 2022 12:23:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi David,
>> 
>>> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`.
>>> 
>>> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO.
>> 
>> No problem, that's why we talk :)
>> 
>> To make an argument for this: if you compare the first iterations of this patch to the current one, the current one is a lot simpler. I really dislike funneling arguments through many layers down to a utility function, only to fine control one specific behavioral aspect of that tiny function, and that aspect is only relevant for one outlier use case. I dislike this more than the RAII object.
>> 
>> Look at it this way. We have a thread-specific state (we are in AGCT and deep down somewhere we want to do something different depending on that state). We need to pass that information down. The only difference is where we keep the "we are in thread-specific state" info - on the stack as an argument chain, or anchored to TLS.
>> 
>> Putting it into arguments is one way, but I find this rather ugly. Now every caller of this function has to care. With the RAII, we have the information as a mark exactly where it matters - in the entrance frame of AGCT - and no outside code needs to care.
>> 
>> Cheers, Thomas
>
> But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace:
> 
> 
> thread->set_in_asgct(true);
> <stuff>
> thread->set_in_asgct(false);
> 
> with
> 
> 
> ASGCTMark mark(thread);
> <stuff>
> 
> but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`.
> 
> And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `<stuff>` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful.

Fair enough.

I removed the RAII and added a comment making explicit the requirement to reset the 'in_asgct' flag on method return. If there ever appear more return points in that method the RAII can be reconsidered.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From stuefe at openjdk.java.net  Tue May 17 12:55:58 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 17 May 2022 12:55:58 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
 <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
 <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
Message-ID: <GTxAdKTO224y2fpAE2apfkTyQ2JUFb5V1hj8k5b2WeU=.3ad98bcf-755c-4107-9e27-a7bfa231d304@github.com>

On Tue, 17 May 2022 12:23:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi David,
>> 
>>> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`.
>>> 
>>> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO.
>> 
>> No problem, that's why we talk :)
>> 
>> To make an argument for this: if you compare the first iterations of this patch to the current one, the current one is a lot simpler. I really dislike funneling arguments through many layers down to a utility function, only to fine control one specific behavioral aspect of that tiny function, and that aspect is only relevant for one outlier use case. I dislike this more than the RAII object.
>> 
>> Look at it this way. We have a thread-specific state (we are in AGCT and deep down somewhere we want to do something different depending on that state). We need to pass that information down. The only difference is where we keep the "we are in thread-specific state" info - on the stack as an argument chain, or anchored to TLS.
>> 
>> Putting it into arguments is one way, but I find this rather ugly. Now every caller of this function has to care. With the RAII, we have the information as a mark exactly where it matters - in the entrance frame of AGCT - and no outside code needs to care.
>> 
>> Cheers, Thomas
>
> But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace:
> 
> 
> thread->set_in_asgct(true);
> <stuff>
> thread->set_in_asgct(false);
> 
> with
> 
> 
> ASGCTMark mark(thread);
> <stuff>
> 
> but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`.
> 
> And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `<stuff>` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful.

@dholmes-ora Oh, you are only objecting to the RAII mark, not to the fact that we store the state in Thread? Ok, sure. In my view, a mark prevents the "on" state from escaping the frame, e.g. if stray return calls sneak in with future changes. But I don't have strong emotions here.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From duke at openjdk.java.net  Tue May 17 12:56:00 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 17 May 2022 12:56:00 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <GTxAdKTO224y2fpAE2apfkTyQ2JUFb5V1hj8k5b2WeU=.3ad98bcf-755c-4107-9e27-a7bfa231d304@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
 <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
 <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
 <GTxAdKTO224y2fpAE2apfkTyQ2JUFb5V1hj8k5b2WeU=.3ad98bcf-755c-4107-9e27-a7bfa231d304@github.com>
Message-ID: <VorZ7S6pUSg_dYczlsbklkVDCI2ugzt1ljt4PNdWY_8=.092dc301-2117-4573-aa29-b6481e8b2398@github.com>

On Tue, 17 May 2022 12:50:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace:
>> 
>> 
>> thread->set_in_asgct(true);
>> <stuff>
>> thread->set_in_asgct(false);
>> 
>> with
>> 
>> 
>> ASGCTMark mark(thread);
>> <stuff>
>> 
>> but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`.
>> 
>> And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `<stuff>` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful.
>
> @dholmes-ora Oh, you are only objecting to the RAII mark, not to the fact that we store the state in Thread? Ok, sure. In my view, a mark prevents the "on" state from escaping the frame, e.g. if stray return calls sneak in with future changes. But I don't have strong emotions here.

It would be interesting to see if it this ASGCT flag is useful in JFR, i.e. if JFR suffers potentially from the same problem. There would then be two additional places for setting this flag.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From duke at openjdk.java.net  Tue May 17 13:04:55 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 17 May 2022 13:04:55 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v11]
In-Reply-To: <nbCbFkyv7VIN9XUVinwRTlt74UGP4VFgwJKSaPWN9-I=.d282dd4d-fdaf-4200-9f62-106b2c034a0d@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <nbCbFkyv7VIN9XUVinwRTlt74UGP4VFgwJKSaPWN9-I=.d282dd4d-fdaf-4200-9f62-106b2c034a0d@github.com>
Message-ID: <zlNR_teH56qYIa45BRbwRzs3bwa2z77IjwWpt7wrlZA=.accd301a-edef-49f7-b312-b439327d2819@github.com>

On Tue, 17 May 2022 12:45:52 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove ASGCTMark

src/hotspot/share/prims/forte.cpp line 594:

> 592:   }
> 593: 
> 594:   // !important! make sure all return points will reset the IN_ASGCT flag to 'false'

Please change it to something like "// !important! make sure all to call set_in_asgct(false) before every return" as this is clearer in the context of the forte.cpp and omits mentioning the encapsulated state.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From aturbanov at openjdk.java.net  Tue May 17 13:21:48 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 17 May 2022 13:21:48 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <bdyMScRIzJTzmKnpU9Bdu7Qe7gv9r1te5Yw6yVYsk4o=.ab88908e-33aa-4efe-8d80-3ad8cda92483@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Any more reviewers, please?)

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From jbachorik at openjdk.java.net  Tue May 17 13:53:36 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Tue, 17 May 2022 13:53:36 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <WqLUUXUPXypq7DQnB3nKqjfb1bDsfdHDTzuCG6kwc8I=.690fdac3-df3a-4ab0-83b1-83d19b62bb0f@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Change comment wording

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/bdd758fb..ce5924d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=10-11

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Tue May 17 13:53:36 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Tue, 17 May 2022 13:53:36 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v11]
In-Reply-To: <zlNR_teH56qYIa45BRbwRzs3bwa2z77IjwWpt7wrlZA=.accd301a-edef-49f7-b312-b439327d2819@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <nbCbFkyv7VIN9XUVinwRTlt74UGP4VFgwJKSaPWN9-I=.d282dd4d-fdaf-4200-9f62-106b2c034a0d@github.com>
 <zlNR_teH56qYIa45BRbwRzs3bwa2z77IjwWpt7wrlZA=.accd301a-edef-49f7-b312-b439327d2819@github.com>
Message-ID: <5-T9t-DGHtnBKJdhr1oq2nNPTuWi0jwa0ZrTwmtlqKE=.1296aa86-fef9-4811-80e0-3b03f6210ea4@github.com>

On Tue, 17 May 2022 13:01:36 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove ASGCTMark
>
> src/hotspot/share/prims/forte.cpp line 594:
> 
>> 592:   }
>> 593: 
>> 594:   // !important! make sure all return points will reset the IN_ASGCT flag to 'false'
> 
> Please change it to something like "// !important! make sure all to call set_in_asgct(false) before every return" as this is clearer in the context of the forte.cpp and omits mentioning the encapsulated state.

?? 
I have modified the comment wording

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From duke at openjdk.java.net  Tue May 17 14:20:58 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 17 May 2022 14:20:58 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v11]
In-Reply-To: <5-T9t-DGHtnBKJdhr1oq2nNPTuWi0jwa0ZrTwmtlqKE=.1296aa86-fef9-4811-80e0-3b03f6210ea4@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <nbCbFkyv7VIN9XUVinwRTlt74UGP4VFgwJKSaPWN9-I=.d282dd4d-fdaf-4200-9f62-106b2c034a0d@github.com>
 <zlNR_teH56qYIa45BRbwRzs3bwa2z77IjwWpt7wrlZA=.accd301a-edef-49f7-b312-b439327d2819@github.com>
 <5-T9t-DGHtnBKJdhr1oq2nNPTuWi0jwa0ZrTwmtlqKE=.1296aa86-fef9-4811-80e0-3b03f6210ea4@github.com>
Message-ID: <jSNlqfdE9NqHFaCE3bTONeHWLhcG9H0yocf0xWk_psc=.4254c930-53b8-4a53-a5be-8ff39927b11c@github.com>

On Tue, 17 May 2022 13:49:25 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/hotspot/share/prims/forte.cpp line 594:
>> 
>>> 592:   }
>>> 593: 
>>> 594:   // !important! make sure all return points will reset the IN_ASGCT flag to 'false'
>> 
>> Please change it to something like "// !important! make sure all to call set_in_asgct(false) before every return" as this is clearer in the context of the forte.cpp and omits mentioning the encapsulated state.
>
> ?? 
> I have modified the comment wording

There is an "all" to much in the new version, I forgot to remove it in my suggestion

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Tue May 17 14:43:00 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Tue, 17 May 2022 14:43:00 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <VorZ7S6pUSg_dYczlsbklkVDCI2ugzt1ljt4PNdWY_8=.092dc301-2117-4573-aa29-b6481e8b2398@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
 <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
 <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
 <GTxAdKTO224y2fpAE2apfkTyQ2JUFb5V1hj8k5b2WeU=.3ad98bcf-755c-4107-9e27-a7bfa231d304@github.com>
 <VorZ7S6pUSg_dYczlsbklkVDCI2ugzt1ljt4PNdWY_8=.092dc301-2117-4573-aa29-b6481e8b2398@github.com>
Message-ID: <JE0WK4Oyun5-CgFZ9yO-_bHBt8gk-AU6B2FNyzZRBDo=.1d8b03a3-db3e-444c-9e57-ca49aa21a236@github.com>

On Tue, 17 May 2022 12:52:30 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> @dholmes-ora Oh, you are only objecting to the RAII mark, not to the fact that we store the state in Thread? Ok, sure. In my view, a mark prevents the "on" state from escaping the frame, e.g. if stray return calls sneak in with future changes. But I don't have strong emotions here.
>
> It would be interesting to see if it this ASGCT flag is useful in JFR, i.e. if JFR suffers potentially from the same problem. There would then be two additional places for setting this flag.

AFAIK, currently JFR is 'wrapping' the code in a crash-handler.
We can take a look at reusing this approach there in some follow-up PR but for now I would really prefer getting this one merged without attaching any more bells&whistles.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From duke at openjdk.java.net  Tue May 17 14:58:53 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 17 May 2022 14:58:53 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
 <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
 <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
Message-ID: <MyAx02aFVGEGzMmSZg9FwAobGYQsWr-7QGbCggdJ8MA=.e778fa76-1791-4c47-809e-d3c6dd615082@github.com>

On Tue, 17 May 2022 12:23:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi David,
>> 
>>> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`.
>>> 
>>> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO.
>> 
>> No problem, that's why we talk :)
>> 
>> To make an argument for this: if you compare the first iterations of this patch to the current one, the current one is a lot simpler. I really dislike funneling arguments through many layers down to a utility function, only to fine control one specific behavioral aspect of that tiny function, and that aspect is only relevant for one outlier use case. I dislike this more than the RAII object.
>> 
>> Look at it this way. We have a thread-specific state (we are in AGCT and deep down somewhere we want to do something different depending on that state). We need to pass that information down. The only difference is where we keep the "we are in thread-specific state" info - on the stack as an argument chain, or anchored to TLS.
>> 
>> Putting it into arguments is one way, but I find this rather ugly. Now every caller of this function has to care. With the RAII, we have the information as a mark exactly where it matters - in the entrance frame of AGCT - and no outside code needs to care.
>> 
>> Cheers, Thomas
>
> But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace:
> 
> 
> thread->set_in_asgct(true);
> <stuff>
> thread->set_in_asgct(false);
> 
> with
> 
> 
> ASGCTMark mark(thread);
> <stuff>
> 
> but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`.
> 
> And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `<stuff>` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful.

But the crash-handler does not prevent that `guarantee` aborts the VM, as we discussed already in my related PR. My comment was more a suggestion and related to "And this is the only place we will ever use ASGCTMark" by @dholmes-ora . I agree with you that changing JFR should be done in another PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From stuefe at openjdk.java.net  Tue May 17 14:58:54 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 17 May 2022 14:58:54 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <MyAx02aFVGEGzMmSZg9FwAobGYQsWr-7QGbCggdJ8MA=.e778fa76-1791-4c47-809e-d3c6dd615082@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
 <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
 <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
 <MyAx02aFVGEGzMmSZg9FwAobGYQsWr-7QGbCggdJ8MA=.e778fa76-1791-4c47-809e-d3c6dd615082@github.com>
Message-ID: <Xumjqf08pINK7-6FaaBY4u1uSQNssTmAGaCPEjzXvnc=.074fdfd7-b6fa-419c-96c7-d39ff85ec6d3@github.com>

On Tue, 17 May 2022 14:54:23 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace:
>> 
>> 
>> thread->set_in_asgct(true);
>> <stuff>
>> thread->set_in_asgct(false);
>> 
>> with
>> 
>> 
>> ASGCTMark mark(thread);
>> <stuff>
>> 
>> but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`.
>> 
>> And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `<stuff>` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful.
>
> But the crash-handler does not prevent that `guarantee` aborts the VM, as we discussed already in my related PR. My comment was more a suggestion and related to "And this is the only place we will ever use ASGCTMark" by @dholmes-ora . I agree with you that changing JFR should be done in another PR.

> AFAIK, currently JFR is 'wrapping' the code in a crash-handler. We can take a look at reusing this approach there in some follow-up PR but for now I would really prefer getting this one merged without attaching any more bells&whistles.

@jbachorik No, please don't do that. That approach is very unsafe and should be used with extreme care. I would actually prefer for it to get removed completely, not to be reused.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From duke at openjdk.java.net  Tue May 17 15:26:58 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 17 May 2022 15:26:58 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <Xumjqf08pINK7-6FaaBY4u1uSQNssTmAGaCPEjzXvnc=.074fdfd7-b6fa-419c-96c7-d39ff85ec6d3@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
 <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
 <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
 <MyAx02aFVGEGzMmSZg9FwAobGYQsWr-7QGbCggdJ8MA=.e778fa76-1791-4c47-809e-d3c6dd615082@github.com>
 <Xumjqf08pINK7-6FaaBY4u1uSQNssTmAGaCPEjzXvnc=.074fdfd7-b6fa-419c-96c7-d39ff85ec6d3@github.com>
Message-ID: <JvYMiiMMqXrD-3DmD--_SYCUOoi47bcKSkX3Xb58UT4=.441fba50-5c17-4f29-937d-75f224bea2a6@github.com>

On Tue, 17 May 2022 14:55:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> But the crash-handler does not prevent that `guarantee` aborts the VM, as we discussed already in my related PR. My comment was more a suggestion and related to "And this is the only place we will ever use ASGCTMark" by @dholmes-ora . I agree with you that changing JFR should be done in another PR.
>
>> AFAIK, currently JFR is 'wrapping' the code in a crash-handler. We can take a look at reusing this approach there in some follow-up PR but for now I would really prefer getting this one merged without attaching any more bells&whistles.
> 
> @jbachorik No, please don't do that. That approach is very unsafe and should be used with extreme care. I would actually prefer for it to get removed completely, not to be reused.

I thought that "this approach" referred to the approach of this PR (possibly renaming the flag), as CrashProtection is orthogonal to the issue that this PR solves.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Tue May 17 15:51:11 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Tue, 17 May 2022 15:51:11 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <JvYMiiMMqXrD-3DmD--_SYCUOoi47bcKSkX3Xb58UT4=.441fba50-5c17-4f29-937d-75f224bea2a6@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
 <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
 <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
 <MyAx02aFVGEGzMmSZg9FwAobGYQsWr-7QGbCggdJ8MA=.e778fa76-1791-4c47-809e-d3c6dd615082@github.com>
 <Xumjqf08pINK7-6FaaBY4u1uSQNssTmAGaCPEjzXvnc=.074fdfd7-b6fa-419c-96c7-d39ff85ec6d3@github.com>
 <JvYMiiMMqXrD-3DmD--_SYCUOoi47bcKSkX3Xb58UT4=.441fba50-5c17-4f29-937d-75f224bea2a6@github.com>
Message-ID: <_uTaFAbOYQ7YMhOYF93FWwR41KdviVvFFXKKsTYS3eI=.55ee82a6-c6b0-42f1-b8bd-fd8294788dd8@github.com>

On Tue, 17 May 2022 15:23:04 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> thought that "this approach" referred to the approach of this PR (possibly renaming the flag)

^ this

But still, I would prefer to defer any further improvements into a separate PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From cjplummer at openjdk.java.net  Tue May 17 22:14:48 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 17 May 2022 22:14:48 GMT
Subject: RFR: 8281268: Resolve duplication of test ClassTransformer class
In-Reply-To: <iUFC3U4i8UE6I_Bld7MyzYsBr1dJ_LgRb3RDvRS2Xl0=.735e3167-c0cb-4c23-8899-183f8939a382@github.com>
References: <iUFC3U4i8UE6I_Bld7MyzYsBr1dJ_LgRb3RDvRS2Xl0=.735e3167-c0cb-4c23-8899-183f8939a382@github.com>
Message-ID: <QJglAwk76nrgOh3Yi6tf3hiFCAi_fUvbyKMhYPTy0V8=.6e25b891-0fe2-46c5-8993-38d9291f6b58@github.com>

On Fri, 13 May 2022 22:50:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix deletes ClassTransformer class from jdi, switches all the test to jdk.test.lib copy.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8710

From cjplummer at openjdk.java.net  Tue May 17 23:20:46 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 17 May 2022 23:20:46 GMT
Subject: RFR: 8279358:
 vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java
 fails with usage tracker
In-Reply-To: <uu8mRgNuhwkn7dHQYFMxIrYDXVIDH-4E3cnzlyEtRjU=.fcfb44f5-d922-4bb2-8f7a-bfefaf5e722a@github.com>
References: <uu8mRgNuhwkn7dHQYFMxIrYDXVIDH-4E3cnzlyEtRjU=.fcfb44f5-d922-4bb2-8f7a-bfefaf5e722a@github.com>
Message-ID: <_Myo7w65JxLKUh3Kb61pArxs_zGoQO4178561Yc332Q=.b138b8d2-dff9-4f04-a039-1c5b5a992d8a@github.com>

On Mon, 9 May 2022 21:26:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> isThreadExpected function checks only some known JFR/Graal threads.
> This approach requires to keep this function up to date (add other internal threads like usage tracker, loom, etc).
> 
> To avoid this updated all tests which use it, now the tests filter out all unknown threads.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8614

From dholmes at openjdk.java.net  Wed May 18 01:50:03 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 18 May 2022 01:50:03 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12]
In-Reply-To: <WqLUUXUPXypq7DQnB3nKqjfb1bDsfdHDTzuCG6kwc8I=.690fdac3-df3a-4ab0-83b1-83d19b62bb0f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <WqLUUXUPXypq7DQnB3nKqjfb1bDsfdHDTzuCG6kwc8I=.690fdac3-df3a-4ab0-83b1-83d19b62bb0f@github.com>
Message-ID: <Nntumdita3bx8cenoo9ECAXJKV55Q-kXNsCJ1u0eAoY=.5d86412c-a929-4eb1-a9bc-bc2cbaebc08c@github.com>

On Tue, 17 May 2022 13:53:36 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comment wording

One minor unneeded change to revert but otherwise this is good to go. Lets ship these and leave other issues for other PRs.

Thanks.

src/hotspot/share/prims/forte.hpp line 29:

> 27: 
> 28: #include "memory/allocation.hpp"
> 29: 

No longer needed.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8549

From dholmes at openjdk.java.net  Wed May 18 01:50:05 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 18 May 2022 01:50:05 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9]
In-Reply-To: <_uTaFAbOYQ7YMhOYF93FWwR41KdviVvFFXKKsTYS3eI=.55ee82a6-c6b0-42f1-b8bd-fd8294788dd8@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <zDyFZfcs3hw0ztkogIcB6pu6opR4T4wSNP3NMtlKMWU=.440e5dfc-795d-493b-b0e3-3db2ea18cd03@github.com>
 <UWvvtpF59OdtmWnDLk8AuHo-RFmZ6LmTzwW239dQ3A0=.dc7ff222-fafd-4fb8-8854-16a8d3430470@github.com>
 <PTz96ny4BESWoKlCboKrnHtuBqOm_wksyEwAEzWw13s=.3e7ffdcc-f4fc-4e7c-8e33-897ec7b99e31@github.com>
 <ir-SvP0BkXovY6C8tB3y52gJxQFIP4J1VF0Xfl-QDto=.c4f9f877-8cbd-4bf8-973e-8bb23d1915fb@github.com>
 <jSO9eAZ5lXZ5legWaxzocAAs_Xt3VEK3ulfSzgyAbHw=.3e68b92b-60fe-42b8-a502-3d4bf3df764f@github.com>
 <MyAx02aFVGEGzMmSZg9FwAobGYQsWr-7QGbCggdJ8MA=.e778fa76-1791-4c47-809e-d3c6dd615082@github.com>
 <Xumjqf08pINK7-6FaaBY4u1uSQNssTmAGaCPEjzXvnc=.074fdfd7-b6fa-419c-96c7-d39ff85ec6d3@github.com>
 <JvYMiiMMqXrD-3DmD--_SYCUOoi47bcKSkX3Xb58UT4=.441fba50-5c17-4f29-937d-75f224bea2a6@github.com>
 <_uTaFAbOYQ7YMhOYF93FWwR41KdviVvFFXKKsTYS3eI=.55ee82a6-c6b0-42f1-b8bd-fd8294788dd8@github.com>
Message-ID: <BWswEZLiX-GBtcLEI4gZ21PvPyDqsXgEgJajHN_kcaA=.2a02093d-fbc3-4f2d-a23c-95fea0ee4a3f@github.com>

On Tue, 17 May 2022 15:48:47 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> I thought that "this approach" referred to the approach of this PR (possibly renaming the flag), as CrashProtection is orthogonal to the issue that this PR solves.
>
>> thought that "this approach" referred to the approach of this PR (possibly renaming the flag)
> 
> ^ this
> 
> But still, I would prefer to defer any further improvements into a separate PR.

> It would be interesting to see if it this ASGCT flag is useful in JFR
@parttimenerd , if you mean whether JFR might also benefit from a flag that indicates whether a thread is executing in some "sensitive" location, then perhaps. But there is only one ASGCT and AFAIK JFR does not use it. But that is a discussion for another place.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From stuefe at openjdk.java.net  Wed May 18 05:34:55 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 18 May 2022 05:34:55 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12]
In-Reply-To: <WqLUUXUPXypq7DQnB3nKqjfb1bDsfdHDTzuCG6kwc8I=.690fdac3-df3a-4ab0-83b1-83d19b62bb0f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <WqLUUXUPXypq7DQnB3nKqjfb1bDsfdHDTzuCG6kwc8I=.690fdac3-df3a-4ab0-83b1-83d19b62bb0f@github.com>
Message-ID: <FlDSJcANs4BPSYc_3KmWirR6jLxspLy6aYczv-fHcgo=.c84ae49b-5f3f-4192-966f-bd4df3df8897@github.com>

On Tue, 17 May 2022 13:53:36 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comment wording

src/hotspot/share/code/codeCache.cpp line 662:

> 660:   bool is_zombie = result != NULL && result->is_zombie();
> 661:   bool is_result_safe = !is_zombie || result->is_locked_by_vm() || VMError::is_error_reported();
> 662:   guarantee(is_result_safe || is_in_asgct(), "unsafe access to zombie method");

Why is this a guarantee? Does it still need to be one? We usually avoid paying for assert setup in release VMs, its rather uncommon to use guarantee.

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From stuefe at openjdk.java.net  Wed May 18 05:58:59 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 18 May 2022 05:58:59 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12]
In-Reply-To: <WqLUUXUPXypq7DQnB3nKqjfb1bDsfdHDTzuCG6kwc8I=.690fdac3-df3a-4ab0-83b1-83d19b62bb0f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <WqLUUXUPXypq7DQnB3nKqjfb1bDsfdHDTzuCG6kwc8I=.690fdac3-df3a-4ab0-83b1-83d19b62bb0f@github.com>
Message-ID: <ZBPIHBrTt7HB3zG_b4cVv33-mqt-gwD7TZkSr8Bm_Xc=.7031e337-7583-4556-aebb-1383a97b1d08@github.com>

On Tue, 17 May 2022 13:53:36 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
>> 
>> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
>> 
>> <hr>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
>> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
>> 
>> <br><br>
>> 
>> _Note: This is a followup PR for #8061_
>
> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comment wording

Looks good to me now.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Wed May 18 06:43:43 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 18 May 2022 06:43:43 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v13]
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <komB2xcQVYuV3yVUJNy4OaVZidqoONe_s_etgvXNOUs=.c10a293a-a72b-4ee6-90e2-d15d426cee4b@github.com>

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Remove unneeded import

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8549/files
  - new: https://git.openjdk.java.net/jdk/pull/8549/files/ce5924d7..f9e42fd8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=11-12

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Wed May 18 06:45:41 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 18 May 2022 06:45:41 GMT
Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12]
In-Reply-To: <FlDSJcANs4BPSYc_3KmWirR6jLxspLy6aYczv-fHcgo=.c84ae49b-5f3f-4192-966f-bd4df3df8897@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
 <WqLUUXUPXypq7DQnB3nKqjfb1bDsfdHDTzuCG6kwc8I=.690fdac3-df3a-4ab0-83b1-83d19b62bb0f@github.com>
 <FlDSJcANs4BPSYc_3KmWirR6jLxspLy6aYczv-fHcgo=.c84ae49b-5f3f-4192-966f-bd4df3df8897@github.com>
Message-ID: <O_KhbysU3__t0mkUVtiYtJ1uzoSgQAXKDZThcEk46xo=.4d044c0c-1a21-4539-88cb-834fb080108b@github.com>

On Wed, 18 May 2022 05:30:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change comment wording
>
> src/hotspot/share/code/codeCache.cpp line 662:
> 
>> 660:   bool is_zombie = result != NULL && result->is_zombie();
>> 661:   bool is_result_safe = !is_zombie || result->is_locked_by_vm() || VMError::is_error_reported();
>> 662:   guarantee(is_result_safe || is_in_asgct(), "unsafe access to zombie method");
> 
> Why is this a guarantee? Does it still need to be one? We usually avoid paying for assert setup in release VMs, its rather uncommon to use guarantee.

Not the original author so it is just my best guess - the consequences of accidentally touching dead code blob (where the data structures could have been freed or reused) were considered bad enough to justify the 'guarantee'.
Unfortunately, if the code blob is not locked even this guarantee can pass but we can still return a zombie a moment later. But that is another story that will need to be ironed out for ASGCT(2?)

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From jbachorik at openjdk.java.net  Wed May 18 06:49:00 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 18 May 2022 06:49:00 GMT
Subject: Integrated: 8283849: AsyncGetCallTrace may crash JVM on guarantee
In-Reply-To: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
References: <Ur8uSHncWpiFFeppf50Kj9DuC-gAJpn7mDdLhoDwbZw=.def8bb27-9a76-4912-8ec9-081c3a08f94f@github.com>
Message-ID: <x2uUmxVuhn1d6zsaTcY-wZsL8KU01YItFCZMNrPJLhY=.1fb16a66-0bdd-4281-80fc-2c95871cc387@github.com>

On Thu, 5 May 2022 11:28:14 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. 
> 
> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
> 
> <hr>
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically.
> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.
> 
> <br><br>
> 
> _Note: This is a followup PR for #8061_

This pull request has now been integrated.

Changeset: 93c88690
Author:    Jaroslav Bachorik <jbachorik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/93c88690a1c2cbc7ba7fc70ddef9bf5928e4de03
Stats:     21 lines in 4 files changed: 19 ins; 0 del; 2 mod

8283849: AsyncGetCallTrace may crash JVM on guarantee

Reviewed-by: dholmes, stuefe

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

PR: https://git.openjdk.java.net/jdk/pull/8549

From aivanov at openjdk.java.net  Wed May 18 13:34:24 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 13:34:24 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
Message-ID: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

Also, I fixed a couple of spelling mistakes.

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

Commit messages:
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...c7e73658

Changes: https://git.openjdk.java.net/jdk/pull/8768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284191
  Stats: 202 lines in 162 files changed: 0 ins; 11 del; 191 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From lancea at openjdk.java.net  Wed May 18 14:42:53 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:42:53 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <DOokHH_SxPtXjdpCSV9F_RmnHaNC6WnO3ChzhQNGxF8=.3fbb1072-bae7-4dc9-a424-4e9dd0cecc33@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Wed May 18 14:53:28 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 14:53:28 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
Message-ID: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

It's the last issue in the series, and it still touches different areas of the code.

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

Commit messages:
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'an? an?' in source code
 - 8284209: Replace remaining usages of 'a the' in source code
 - 8284209: Replace remaining usages of 'an the' in source code
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...8290c07e

Changes: https://git.openjdk.java.net/jdk/pull/8771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284209
  Stats: 51 lines in 41 files changed: 0 ins; 2 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From lancea at openjdk.java.net  Wed May 18 14:59:56 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:59:56 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <H0aIQ5SRJgWgvc_Hp8Y6ClzE86lEOzNYOKiV56ueWU0=.9bf1a830-fb68-4f70-a254-3b5d182739ae@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8771

From wetmore at openjdk.java.net  Wed May 18 15:15:56 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 18 May 2022 15:15:56 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <AIjhEfuQaJLjZPeDl94HgUet9eMCoEwolZpNvKGGHGs=.bb1c32b4-65d8-40f2-84c3-38dc7db54894@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Looked at 

- java.base/.../sun/security
- jdk.crypto.*
- test/*/com/sun/crypto/provider
- test/*/java/lang/SecurityManager
- test/*/java/security
- test/*/krb5
- test/*/jarsigner

and those look fine.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From wetmore at openjdk.java.net  Wed May 18 15:19:55 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 18 May 2022 15:19:55 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <BlEMdHGx8wwWoDnuSLakASovW6f-yse6TPC3pbF6bcE=.8caab0de-e0bf-457d-883e-ae779ccff635@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Looked at 

-java.security.jgss.

LGTM

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From dfuchs at openjdk.java.net  Wed May 18 16:07:52 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 18 May 2022 16:07:52 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <hqiM9eFHWbK89Zfb-ZaJGalvghiDsyvw09l6hQI8YxA=.6cb984f1-c988-4f52-bd07-406a5362fe70@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Logging/JNDI OK

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From naoto at openjdk.java.net  Wed May 18 16:18:58 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 18 May 2022 16:18:58 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <4eXpe5pmBsvw8u6fJlzd9BWsnY74LiyjTqQhQ88uxoc=.6182985a-f751-4d55-b9d0-bc605d7636da@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

LGTM for i18n changes.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From iris at openjdk.java.net  Wed May 18 16:59:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 16:59:50 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <pRvaphDcC8dB1bZPh6x4OhyZ8BHSfCn9ZCdBzq9Dnco=.1ca1edd4-0004-43b9-815c-3b20ffb5368f@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From iris at openjdk.java.net  Wed May 18 17:04:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 17:04:50 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <KFAmufl8fur2ZWbG3C6rN_8h7oficN_4ViuHJ7hfvg4=.3ee598c2-3fd1-4344-bd94-89459431f74b@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8771

From sgehwolf at openjdk.java.net  Wed May 18 18:14:52 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 May 2022 18:14:52 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
Message-ID: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>

> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
> 
> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
> 
> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
> 
> Testing:
> - [x] Added unit tests
> - [x] GHA
> - [x] Container tests on cgroups v1 Linux. Continue to pass

Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor hotspot gtest
 - Separate into function. Fix comment.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8629/files
  - new: https://git.openjdk.java.net/jdk/pull/8629/files/66241aa5..4b8e92fa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=01-02

  Stats: 93 lines in 3 files changed: 56 ins; 25 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8629.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8629/head:pull/8629

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Wed May 18 18:14:55 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 May 2022 18:14:55 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
Message-ID: <MJKt4LfScjBzsqrbVdVpeBRqai7vP1uq0pvZqnYVp7Q=.1882c0a0-770e-4048-8a29-a1fb98c14bf4@github.com>

On Tue, 17 May 2022 06:18:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use stringStream to simplify controller path assembly
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:
> 
>> 90:           }
>> 91:           ss.print_raw(_root, last_matching_slash_pos);
>> 92:           _path = os::strdup(ss.base());
> 
> Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand.

@iklam yes I meant `Find the longest common prefix`. Fixed the comment.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Wed May 18 18:14:57 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 May 2022 18:14:57 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <MJKt4LfScjBzsqrbVdVpeBRqai7vP1uq0pvZqnYVp7Q=.1882c0a0-770e-4048-8a29-a1fb98c14bf4@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
 <MJKt4LfScjBzsqrbVdVpeBRqai7vP1uq0pvZqnYVp7Q=.1882c0a0-770e-4048-8a29-a1fb98c14bf4@github.com>
Message-ID: <MufMBz_4YPBASS5M7ZqphZBcRSJL1VrNQnsqEAIn30Y=.c5e1a8ce-8e78-4526-8283-9b4ef82c6dfa@github.com>

On Wed, 18 May 2022 18:09:54 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:
>> 
>>> 90:           }
>>> 91:           ss.print_raw(_root, last_matching_slash_pos);
>>> 92:           _path = os::strdup(ss.base());
>> 
>> Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand.
>
> @iklam yes I meant `Find the longest common prefix`. Fixed the comment.

I'm not convinced the extra function makes the code more readable, but here it is. I can revert back if this is too much.

>> test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63:
>> 
>>> 61:     ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path());
>>> 62:   }
>>> 63: }
>> 
>> I found it hard to relate the different paths. Could you create a new struct like this?
>> 
>> 
>> struct TestCase {
>>     char* mount_path;
>>     char* root_paths;
>>     char* cgroup_path;
>>     char* expected_cg_paths;
>> } = {
>>   {  "/sys/fs/cgroup/memory",     // mount
>>        "/",                       // root,
>>        ....
>
> Yes, makes sense. Will do.

Done now.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From amenkov at openjdk.java.net  Wed May 18 20:54:41 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 18 May 2022 20:54:41 GMT
Subject: Integrated: 8281268: Resolve duplication of test ClassTransformer
 class
In-Reply-To: <iUFC3U4i8UE6I_Bld7MyzYsBr1dJ_LgRb3RDvRS2Xl0=.735e3167-c0cb-4c23-8899-183f8939a382@github.com>
References: <iUFC3U4i8UE6I_Bld7MyzYsBr1dJ_LgRb3RDvRS2Xl0=.735e3167-c0cb-4c23-8899-183f8939a382@github.com>
Message-ID: <4RIjoAVzRiItPr11McUiAQfrNnLTVcXTlK9l2RRTXTM=.951105fb-1c68-4542-ba5f-09df828b67b2@github.com>

On Fri, 13 May 2022 22:50:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix deletes ClassTransformer class from jdi, switches all the test to jdk.test.lib copy.

This pull request has now been integrated.

Changeset: a6177092
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a617709235588420ad16624e44625de5e3f4625f
Stats:     169 lines in 4 files changed: 1 ins; 163 del; 5 mod

8281268: Resolve duplication of test ClassTransformer class

Reviewed-by: kevinw, cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/8710

From jjg at openjdk.java.net  Wed May 18 22:06:44 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 18 May 2022 22:06:44 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <aEkG0OZ86yGP3oWxO4p1nrLGfm0uEdI0SOvg4EczMaY=.c368691e-af13-46dc-8e60-b664f8094e00@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

javac and javadoc changes look OK

test/langtools/tools/javac/modules/T8168854/module-info.java line 4:

> 2:  * @test
> 3:  * @bug 8168854
> 4:  * @summary javac erroneously reject a service interface inner class in a provides clause

FYI, this duplication was in the JBS issue summary; now fixed there.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From cjplummer at openjdk.java.net  Thu May 19 00:17:16 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 19 May 2022 00:17:16 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom related
 jdb and debug agent options
Message-ID: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>

As part of the loom integration, jdb added -trackvthreads and the debug agent added "enumeratevthreads". The help text for these options should call out that they are Preview Features.

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

Commit messages:
 - Add mention of "Preview Feature" for new vthread related debugging options.

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From amenkov at openjdk.java.net  Thu May 19 00:54:52 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 19 May 2022 00:54:52 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options
In-Reply-To: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
Message-ID: <qfJ8XL6r-6Qs1kIfPUuFjDDkhgC2zIlBtJZFlh90gMk=.1dceb663-2309-44c9-abc8-03b1282437be@github.com>

On Thu, 19 May 2022 00:10:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> As part of the loom integration, jdb added -trackvthreads and the debug agent added "enumeratevthreads". The help text for these options should call out that they are Preview Features.

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From lmesnik at openjdk.java.net  Thu May 19 01:55:34 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 19 May 2022 01:55:34 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options
In-Reply-To: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
Message-ID: <xkXjX9TRj3_04kr9R9ktUL_aGTxJZ2DKT-klLdU2GOI=.c95dd6ab-68e8-42a5-817f-2bf2405ad65b@github.com>

On Thu, 19 May 2022 00:10:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> As part of the loom integration, jdb added -trackvthreads and the debug agent added "enumeratevthreads". The help text for these options should call out that they are Preview Features.

Marked as reviewed by lmesnik (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From iklam at openjdk.java.net  Thu May 19 06:21:58 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 19 May 2022 06:21:58 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
Message-ID: <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>

On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor hotspot gtest
>  - Separate into function. Fix comment.

Changes requested by iklam (Reviewer).

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 60:

> 58:         strncpy(buf, _mount_point, MAXPATHLEN);
> 59:         buf[MAXPATHLEN-1] = '\0';
> 60:         _path = os::strdup(buf);

Comment on the old code: why this cannot be simply


_path = os::strdup(_mount_point);


Also, all the strncat calls in this function seem problematic, and should be converted to stringStream for consistency.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 63:

> 61:       } else {
> 62:         char *p = strstr(cgroup_path, _root);
> 63:         if (p != NULL && p == cgroup_path) {

What happens if cgroup_path is "/foo/bar" and _root is "/fo"?

Maybe this block should be combined with the new `else` block you're adding? However, the behavior seems opposite between these two blocks of code:

The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path


  TestCase substring_match = {
    "/sys/fs/cgroup/memory",                           // mount_path
    "/user.slice/user-1000.slice",                     // root_path
    "/user.slice/user-1000.slice/user at 1001.service",   // cgroup_path
    "/sys/fs/cgroup/memory/user at 1001.service"          // expected_path
  };


The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path


 TestCase prefix_matched_cg = {
    "/sys/fs/cgroup/memory",                           // mount_path
    "/user.slice/user-1000.slice/session-50.scope",    // root_path
    "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
    "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path
  };


I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 86:

> 84:           const char* cgroup_p = cgroup_path;
> 85:           int last_slash = find_last_slash_pos(root_p, cgroup_p);
> 86:           assert(last_slash >= 0, "not an absolute path?");

Are root_p and cgroup_p directly read from the /proc/xxx files. If so, do we validate the input to make sure they are absolute paths?

It seems like our code cannot handle trailing '/' in the input. If so, we should clear all trailing '/' from the input string. Then, in functions that process them, we should assert that they don't end with slash. See my comment in find_last_slash_pos().

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 102:

> 100:   for (int i = 0; *s1 == *s2 && *s1 != 0; i++) {
> 101:     if (*s1 == '/') {
> 102:       last_matching_slash_pos = i;

I found the behavior a little hard to understand. Is it intentional?


"/cat/cow", "/cat/dog"    -> "/cat/"
"/cat/",    "/cat/dog"    -> "/cat/"
"/cat",     "/cat/dog"    -> "/"


The name `find_last_slash_pos` doesn't properly describe the behavior. I thought about `find_common_path_prefix`, but that doesn't match the current behavior (for the 3rd case, the common path prefix is `"/cat"`).

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From stuefe at openjdk.java.net  Thu May 19 07:05:50 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 19 May 2022 07:05:50 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <MufMBz_4YPBASS5M7ZqphZBcRSJL1VrNQnsqEAIn30Y=.c5e1a8ce-8e78-4526-8283-9b4ef82c6dfa@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
 <MJKt4LfScjBzsqrbVdVpeBRqai7vP1uq0pvZqnYVp7Q=.1882c0a0-770e-4048-8a29-a1fb98c14bf4@github.com>
 <MufMBz_4YPBASS5M7ZqphZBcRSJL1VrNQnsqEAIn30Y=.c5e1a8ce-8e78-4526-8283-9b4ef82c6dfa@github.com>
Message-ID: <bFP17N-GapgIOJykZ_pkLEvCGrKwTnj9yBo9fHAQ_xg=.c817dbf2-21d0-4d92-adc1-f159e3726d43@github.com>

On Wed, 18 May 2022 18:10:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> @iklam yes I meant `Find the longest common prefix`. Fixed the comment.
>
> I'm not convinced the extra function makes the code more readable, but here it is. I can revert back if this is too much.

@jerboaa Feel free to go back to your original variant. This was only a proposal.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Thu May 19 08:21:48 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 19 May 2022 08:21:48 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <bFP17N-GapgIOJykZ_pkLEvCGrKwTnj9yBo9fHAQ_xg=.c817dbf2-21d0-4d92-adc1-f159e3726d43@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
 <MJKt4LfScjBzsqrbVdVpeBRqai7vP1uq0pvZqnYVp7Q=.1882c0a0-770e-4048-8a29-a1fb98c14bf4@github.com>
 <MufMBz_4YPBASS5M7ZqphZBcRSJL1VrNQnsqEAIn30Y=.c5e1a8ce-8e78-4526-8283-9b4ef82c6dfa@github.com>
 <bFP17N-GapgIOJykZ_pkLEvCGrKwTnj9yBo9fHAQ_xg=.c817dbf2-21d0-4d92-adc1-f159e3726d43@github.com>
Message-ID: <tFgYOehlmvqyy43MLE2MrMvQjQmi50OFBSRVu3AJOPA=.d5c88a7a-9404-4911-8476-23fbb5a0d1bc@github.com>

On Thu, 19 May 2022 07:02:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I'm not convinced the extra function makes the code more readable, but here it is. I can revert back if this is too much.
>
> @jerboaa Feel free to go back to your original variant. This was only a proposal.

understood.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From kevinw at openjdk.java.net  Thu May 19 08:43:45 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:43:45 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <c0o1YvhNkDe026TrcGqKdFaH6G93AfyQCHvBLzGNf8s=.007721e9-d02c-4319-a562-c3296fed6bbf@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.sctp/share/classes/com/sun/nio/sctp/ShutdownNotification.java line 28:

> 26: 
> 27: /**
> 28:  * Notification emitted when a peers shutdowns the association.

Maybe: "...when a peer shuts down an association."
(could be "shuts down the association" if there is only ever one, but using "an" looks safe)

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 08:50:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:50:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:

> 346: 
> 347:     /**
> 348:      * Returns the single non-abstract {@link Method} visible from

I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:02:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:02:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <gSIQ2U9H0PmGgCBlsc4SocQff7AauSX3jiC10z26SJQ=.af26181b-5c61-4ecc-b836-5e5cff2cc901@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/opto/graphKit.cpp line 3626:

> 3624: // The optional arguments are for specialized use by intrinsics:
> 3625: //  - If 'extra_slow_test' if not null is an extra condition for the slow-path.
> 3626: //  - If 'return_size_val', report the total object size to the caller.

"reports the total"

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:09:50 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:09:50 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <A3yxKJkrz3h716ciAsbQHtiWg_y5gMtqLrMoDSxFTWE=.6e31ca1c-505c-4794-b1f0-622dc811388c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/interpreter/bytecodeUtils.cpp line 186:

> 184:   static const int _max_cause_detail = 5;
> 185: 
> 186:   // Merges the stack the given bci with the given stack. If there

"...the stack at the given bci..."

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From sgehwolf at openjdk.java.net  Thu May 19 09:10:49 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 19 May 2022 09:10:49 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
Message-ID: <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>

On Thu, 19 May 2022 05:53:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor hotspot gtest
>>  - Separate into function. Fix comment.
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 60:
> 
>> 58:         strncpy(buf, _mount_point, MAXPATHLEN);
>> 59:         buf[MAXPATHLEN-1] = '\0';
>> 60:         _path = os::strdup(buf);
> 
> Comment on the old code: why this cannot be simply
> 
> 
> _path = os::strdup(_mount_point);
> 
> 
> Also, all the strncat calls in this function seem problematic, and should be converted to stringStream for consistency.

Agreed. I've filed https://bugs.openjdk.java.net/browse/JDK-8287007 to track this. I'd like to limit the changes of this patch to a minimum. It seems orthogonal.

> What happens if cgroup_path is "/foo/bar" and _root is "/fo"?

With a mount path of `/bar` this ends up being `/bar/o/bar`. Pretty strange, but then again it's a bit of a contrived example as those paths come from `/proc` parsing. Anyway, this is code that got added with [JDK-8146115](https://bugs.openjdk.java.net/browse/JDK-8146115). It's not something I've written and to be honest, I'm not sure this branch is needed, but I didn't want to change the existing behaviour with this patch. I have no more insight than you in terms of why that approach has been taken.

> Maybe this block should be combined with the new `else` block you're adding?

Maybe, but I'm not sure if it would break something.

> However, the behavior seems opposite between these two blocks of code:
> 
> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path
> 
> ```
>   TestCase substring_match = {
>     "/sys/fs/cgroup/memory",                           // mount_path
>     "/user.slice/user-1000.slice",                     // root_path
>     "/user.slice/user-1000.slice/user at 1001.service",   // cgroup_path
>     "/sys/fs/cgroup/memory/user at 1001.service"          // expected_path
>   };
> ```

Yes. Though, I cannot comment on why that has been chosen. It's been there since day one :-/

> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path
> 
> ```
>  TestCase prefix_matched_cg = {
>     "/sys/fs/cgroup/memory",                           // mount_path
>     "/user.slice/user-1000.slice/session-50.scope",    // root_path
>     "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>     "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path
>   };
> ```
> 
> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function.

The reason why I've gone down the path of adding the head of cgroup_path is because of this document (in conjunction to what the user was observing on an affected system):
https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/

The user was observing paths as listed in the test:

"/user.slice/user-1000.slice/session-50.scope",    // root_path
"/user.slice/user-1000.slice/session-3.scope",     // cgroup_path

This very much looks like systemd managed. Given that and knowing that systemd adds processes into `scopes` or `services` and groups them via `slices` and also knowing that cgroups are hierarchical (i.e. limits of `/foo/bar` also apply to `/foo/bar/baz`), it seems likely that if there are any limits, then it'll be on `/user.slice/user-1000.slice` within the mounted controller. Unfortunately, I'm not able to reproduce this myself.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From kevinw at openjdk.java.net  Thu May 19 09:27:55 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:27:55 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <02e6mwqZ3ihNyJb4lBK-5WeIGMfiLMj3I8LpJPv4i8o=.3c56077b-54f0-4c4e-b031-5a000b9ea887@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/cds/filemap.cpp line 1914:

> 1912: 
> 1913:     // the current value of the pointers to be patched must be within this
> 1914:     // range (i.e., must be between the requested base address, and the of the current archive).

"the of the" ? 
Maybe "..and the address of the current archive",  or maybe it was a typo for "and that of the current archive".

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From sgehwolf at openjdk.java.net  Thu May 19 09:33:41 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 19 May 2022 09:33:41 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
Message-ID: <Lrot_Fnbdjdv045WS9jwgVZyBZgAB3Ndu1mjmiUVx1I=.8e30c076-badd-4b19-894d-0d7e558fdc61@github.com>

On Thu, 19 May 2022 06:00:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor hotspot gtest
>>  - Separate into function. Fix comment.
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 86:
> 
>> 84:           const char* cgroup_p = cgroup_path;
>> 85:           int last_slash = find_last_slash_pos(root_p, cgroup_p);
>> 86:           assert(last_slash >= 0, "not an absolute path?");
> 
> Are root_p and cgroup_p directly read from the /proc/xxx files. If so, do we validate the input to make sure they are absolute paths?
> 
> It seems like our code cannot handle trailing '/' in the input. If so, we should clear all trailing '/' from the input string. Then, in functions that process them, we should assert that they don't end with slash. See my comment in find_last_slash_pos().

Yes, those values come from `/proc/self/mountinfo` and `/proc/self/cgroup`. There is no validation being done. Then again, we only end up in this branch if the root path is not a substring of the cgroup path. In that case trailing slashes don't matter, since there would not be a character by character match earlier.

I'll add handling of trailing slashes and appropriate asserts where it makes sense.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From kevinw at openjdk.java.net  Thu May 19 09:35:42 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:35:42 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 84:

> 82: 
> 83:     /**
> 84:      * Create a Zip file that will result in an Zip64 Extra (EXT) header

"result in a Zip64..."

test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:

> 30: /*
> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
> 32:  * formatted individual sections in addition the main attributes tested

"in addition to the..."

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:41:57 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:41:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

test/jdk/java/net/InterfaceAddress/Equals.java line 81:

> 79:     /**
> 80:      * Returns an InterfaceAddress instance with its fields set the values
> 81:      * specificed.

probably a typo for "set to the values specified."

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

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From sgehwolf at openjdk.java.net  Thu May 19 09:49:07 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 19 May 2022 09:49:07 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
Message-ID: <7HeR1izA4CAi-Q989J7bEf5vyjguRveviD8rNOouYkY=.63efa7b6-d2c4-4a17-8659-02c62b63f250@github.com>

On Thu, 19 May 2022 05:58:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor hotspot gtest
>>  - Separate into function. Fix comment.
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 102:
> 
>> 100:   for (int i = 0; *s1 == *s2 && *s1 != 0; i++) {
>> 101:     if (*s1 == '/') {
>> 102:       last_matching_slash_pos = i;
> 
> I found the behavior a little hard to understand. Is it intentional?
> 
> 
> "/cat/cow", "/cat/dog"    -> "/cat/"
> "/cat/",    "/cat/dog"    -> "/cat/"
> "/cat",     "/cat/dog"    -> "/"
> 
> 
> The name `find_last_slash_pos` doesn't properly describe the behavior. I thought about `find_common_path_prefix`, but that doesn't match the current behavior (for the 3rd case, the common path prefix is `"/cat"`).

It's supposed to find the common path prefix as you say. I'll fix it. Open to suggestions to make it easier to understand.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From alanb at openjdk.java.net  Thu May 19 11:21:09 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 19 May 2022 11:21:09 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format
Message-ID: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>

This is a test-only change to add some test infrastructure and improve the testing of thread dumps in JSON format. The new tests added by JEP 425 for this thread dump format search the JSON text for strings but don't parse it completely.  These tests can be improved with a test class that parses the thread dump. The tests for JEP 428 like make use of the test infrastructure too.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/8784/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8784&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287008
  Stats: 332 lines in 3 files changed: 305 ins; 9 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8784.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8784/head:pull/8784

PR: https://git.openjdk.java.net/jdk/pull/8784

From alanb at openjdk.java.net  Thu May 19 13:13:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 19 May 2022 13:13:48 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options
In-Reply-To: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
Message-ID: <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>

On Thu, 19 May 2022 00:10:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> As part of the loom integration, jdb added -trackvthreads and the debug agent added "enumeratevthreads". The help text for these options should call out that they are Preview Features.

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c line 880:

> 878:  "onuncaught=y|n                   debug on any uncaught?            n\n"
> 879:  "timeout=<timeout value>          for listen/attach in milliseconds n\n"
> 880:  "enumeratevthreads=y|n            (Preview Feature) thread lists include all vthreads\n"

I think the description needs to say "virtual threads" rather than "vthreads". Also I think "(Preview" needs to go after "virtual threads" to make it clearer that it's virtual threads that are preview,.

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From xuelei at openjdk.java.net  Thu May 19 14:58:48 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:48 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <AEcXIgzPrzjMIYqVKaZBv2j_3w8nrjL-kejrZ0nvBGE=.cb7c63c7-8f32-4cfa-b7d5-e2bb84750add@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

The security/crypto parts look good to me.

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

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From xuelei at openjdk.java.net  Thu May 19 14:58:49 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
Message-ID: <lPlIgFLf96r_Xr7YJIr2w2uODPCG9bRPhAnl2tuAo50=.82a145da-9923-4c5b-a72d-14ba982bf303@github.com>

On Thu, 19 May 2022 09:31:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> Also, I fixed a couple of spelling mistakes.
>
> test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:
> 
>> 30: /*
>> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
>> 32:  * formatted individual sections in addition the main attributes tested
> 
> "in addition to the..."

+1.

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From cjplummer at openjdk.java.net  Thu May 19 15:30:06 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 19 May 2022 15:30:06 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format
In-Reply-To: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
Message-ID: <ltNlRdoxIui4pWIXnQyEOTPViIEaqPe91FKqtDYkAWw=.39347747-1aef-4ccd-bb46-22c012501910@github.com>

On Thu, 19 May 2022 09:38:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only change to add some test infrastructure and improve the testing of thread dumps in JSON format. The new tests added by JEP 425 for this thread dump format search the JSON text for strings but don't parse it completely.  These tests can be improved with a test class that parses the thread dump. The tests for JEP 428 like make use of the test infrastructure too.

It would be useful if ThreadDump.java contained a comment with a description of the JSON file syntax. It could either be in the form of a simple dump or as a simple syntactic description.

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From cjplummer at openjdk.java.net  Thu May 19 15:32:58 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 19 May 2022 15:32:58 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options
In-Reply-To: <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
 <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>
Message-ID: <XccKZlWUIQS6BolQEAwRHs6_P_dlCNHvyPHKTrQDfXA=.b84273c7-fb3d-4aaf-8d21-be1b4657b6a7@github.com>

On Thu, 19 May 2022 13:10:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> As part of the loom integration, jdb added -trackvthreads and the debug agent added "enumeratevthreads". The help text for these options should call out that they are Preview Features.
>
> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c line 880:
> 
>> 878:  "onuncaught=y|n                   debug on any uncaught?            n\n"
>> 879:  "timeout=<timeout value>          for listen/attach in milliseconds n\n"
>> 880:  "enumeratevthreads=y|n            (Preview Feature) thread lists include all vthreads\n"
> 
> I think the description needs to say "virtual threads" rather than "vthreads". Also I think "(Preview" needs to go after "virtual threads" to make it clearer that it's virtual threads that are preview,.

I was really trying to emphasize that the flag is preview, and therefore may change or go away.  If I change as  you suggest, the reader could imply that as long as virtual threads support is in place, then the flag will be also (and in its current form).

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From alanb at openjdk.java.net  Thu May 19 15:36:53 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 19 May 2022 15:36:53 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format
In-Reply-To: <ltNlRdoxIui4pWIXnQyEOTPViIEaqPe91FKqtDYkAWw=.39347747-1aef-4ccd-bb46-22c012501910@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <ltNlRdoxIui4pWIXnQyEOTPViIEaqPe91FKqtDYkAWw=.39347747-1aef-4ccd-bb46-22c012501910@github.com>
Message-ID: <52JmxaqbyDdqC2BvHA25jxZmneHagLQeWkQnCJeuMsE=.3a62de41-566c-431a-ba83-834ab2c1ef23@github.com>

On Thu, 19 May 2022 15:28:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> It would be useful if ThreadDump.java contained a comment with a description of the JSON file syntax. It could either be in the form of a simple dump or as a simple syntactic description.

Still TBD on where the JSON "schema" will be specified, it might HotSpotDiagnosMXBean.dumpThreads so it will needed by tools that parse the JSON text. So when we do that then I think we can reference it from the test class.

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From cjplummer at openjdk.java.net  Thu May 19 16:28:42 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 19 May 2022 16:28:42 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format
In-Reply-To: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
Message-ID: <GCSnAGNKDYVeFVHOBKRFX7HlF4yyqdgkFxewD_BjfJs=.a580def9-5f9f-41d9-8be1-2e2ffae3d446@github.com>

On Thu, 19 May 2022 09:38:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only change to add some test infrastructure and improve the testing of thread dumps in JSON format. The new tests added by JEP 425 for this thread dump format search the JSON text for strings but don't parse it completely.  These tests can be improved with a test class that parses the thread dump. The tests for JEP 428 like make use of the test infrastructure too.

Ok, but I was mostly hoping to have it to make reviewing this PR easier.

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From alanb at openjdk.java.net  Thu May 19 16:52:41 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 19 May 2022 16:52:41 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format
In-Reply-To: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
Message-ID: <ERI_tkqZANEMUGw92HL7_lCH3lYszri74Q5RnYyIIrw=.6e60890c-2ef7-4922-bbe2-f57e58e4feac@github.com>

On Thu, 19 May 2022 09:38:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only change to add some test infrastructure and improve the testing of thread dumps in JSON format. The new tests added by JEP 425 for this thread dump format search the JSON text for strings but don't parse it completely.  These tests can be improved with a test class that parses the thread dump. The tests for JEP 428 like make use of the test infrastructure too.

If we use JSON schema then it will something like this, does that help?


{
  "properties": {
    "threadDump": {
      "type": "object",
      "properties": {
        "processId": {
          "type": "integer"
        },
        "time": {
          "type": "string"
        },
        "runtimeVersion": {
          "type": "string"
        },
        "threadContainers": {
          "type": "array",
          "items": [
            {
              "type": "object",
              "properties": {
                "tid": {
                  "type": "integer"
                },
                "name": {
                  "type": "string"
                },
                "stack": {
                  "type": "array",
                  "items": [
                    {
                      "type": "string"
                    }
                  ]
                }
              },
              "required": [
                "tid",
                "name",
                "stack"
              ]
            }
          ]
        }
      },
      "required": [
        "processId",
        "time",
        "runtimeVersion",
        "threadContainers"
      ]
    }
  },
  "required": [
    "threadDump"
  ]
}

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From aivanov at openjdk.java.net  Thu May 19 18:54:04 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:54:04 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <De1XJE92ZHSiL99Rs-yvnD30-uzxuj4sfIn432JAocM=.2d3d0f7a-8c35-4575-aa20-1ccc267021c4@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:

 - ...set to the values...
 - ...will result in a Zip64 Extra (EXT) header
 - ...in addition to the main attributes...
 - ...and the address of the current archive
 - Merges the stack at the given bci...
 - Returns a single ...
 - ...when a peer shuts down an association.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/c7e73658..0669cdc1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Thu May 19 18:59:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:59:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>
Message-ID: <bBFati7RKtrl5FcrKP4_YCSO34DZrrIX7b_Daw9f91E=.dbbf28d9-92ef-4ae1-950c-f34036d483e4@github.com>

On Thu, 19 May 2022 08:47:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:
> 
>> 346: 
>> 347:     /**
>> 348:      * Returns the single non-abstract {@link Method} visible from
> 
> I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

I've accepted it, yet I'm still unsure whether ?a? or ?the??

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Thu May 19 19:06:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 19:06:56 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>
Message-ID: <Hm4DXlPz0QuS87RjrcFEwxyh-97burW3YzckN3z0aGM=.6c816cc2-3256-4b2c-87d7-c2206b9f9a39@github.com>

On Thu, 19 May 2022 09:38:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

Thank you @kevinjwalls for your suggestions. I've incorporated them.

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From iklam at openjdk.java.net  Thu May 19 20:02:36 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 19 May 2022 20:02:36 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
 <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>
Message-ID: <bPoDNxABi63JebXkYflJ3FUR0IF8OieXLmwkwjIxmk8=.1651330e-59af-4f56-932e-08d37626dfe9@github.com>

On Thu, 19 May 2022 09:06:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 63:
>> 
>>> 61:       } else {
>>> 62:         char *p = strstr(cgroup_path, _root);
>>> 63:         if (p != NULL && p == cgroup_path) {
>> 
>> What happens if cgroup_path is "/foo/bar" and _root is "/fo"?
>> 
>> Maybe this block should be combined with the new `else` block you're adding? However, the behavior seems opposite between these two blocks of code:
>> 
>> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path
>> 
>> 
>>   TestCase substring_match = {
>>     "/sys/fs/cgroup/memory",                           // mount_path
>>     "/user.slice/user-1000.slice",                     // root_path
>>     "/user.slice/user-1000.slice/user at 1001.service",   // cgroup_path
>>     "/sys/fs/cgroup/memory/user at 1001.service"          // expected_path
>>   };
>> 
>> 
>> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path
>> 
>> 
>>  TestCase prefix_matched_cg = {
>>     "/sys/fs/cgroup/memory",                           // mount_path
>>     "/user.slice/user-1000.slice/session-50.scope",    // root_path
>>     "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>>     "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path
>>   };
>> 
>> 
>> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function.
>
>> What happens if cgroup_path is "/foo/bar" and _root is "/fo"?
> 
> With a mount path of `/bar` this ends up being `/bar/o/bar`. Pretty strange, but then again it's a bit of a contrived example as those paths come from `/proc` parsing. Anyway, this is code that got added with [JDK-8146115](https://bugs.openjdk.java.net/browse/JDK-8146115). It's not something I've written and to be honest, I'm not sure this branch is needed, but I didn't want to change the existing behaviour with this patch. I have no more insight than you in terms of why that approach has been taken.
> 
>> Maybe this block should be combined with the new `else` block you're adding?
> 
> Maybe, but I'm not sure if it would break something.
> 
>> However, the behavior seems opposite between these two blocks of code:
>> 
>> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path
>> 
>> ```
>>   TestCase substring_match = {
>>     "/sys/fs/cgroup/memory",                           // mount_path
>>     "/user.slice/user-1000.slice",                     // root_path
>>     "/user.slice/user-1000.slice/user at 1001.service",   // cgroup_path
>>     "/sys/fs/cgroup/memory/user at 1001.service"          // expected_path
>>   };
>> ```
> 
> Yes. Though, I cannot comment on why that has been chosen. It's been there since day one :-/
> 
>> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path
>> 
>> ```
>>  TestCase prefix_matched_cg = {
>>     "/sys/fs/cgroup/memory",                           // mount_path
>>     "/user.slice/user-1000.slice/session-50.scope",    // root_path
>>     "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>>     "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path
>>   };
>> ```
>> 
>> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function.
> 
> The reason why I've gone down the path of adding the head of cgroup_path is because of this document (in conjunction to what the user was observing on an affected system):
> https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> 
> The user was observing paths as listed in the test:
> 
> "/user.slice/user-1000.slice/session-50.scope",    // root_path
> "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
> 
> This very much looks like systemd managed. Given that and knowing that systemd adds processes into `scopes` or `services` and groups them via `slices` and also knowing that cgroups are hierarchical (i.e. limits of `/foo/bar` also apply to `/foo/bar/baz`), it seems likely that if there are any limits, then it'll be on `/user.slice/user-1000.slice` within the mounted controller. Unfortunately, I'm not able to reproduce this myself.

I am wondering if the problem is this:

We have systemd running on the host, and a different copy of systemd that runs inside the container.

- They both set up `/user.slice/user-1000.slice/session-??.scope` within their own file systems
- For some reason, when you're looking inside the container, `/proc/self/cgroup` might use a path in the containerized file system whereas `/proc/self/mountinfo` uses a path in the host file system. These two paths may look alike but they have absolutely no relation to each other.

I have asked the reporter for more information:

https://gist.github.com/gaol/4d96eace8290e6549635fdc0ea41d0b4?permalink_comment_id=4172593#gistcomment-4172593

Meanwhile, I think the current method of finding "which directory under /sys/fs/cgroup/memory controls my memory usage" is broken. As mentioned about, the path you get from  `/proc/self/cgroup`  and `/proc/self/mountinfo` have no relation to each other, but we use them anyway to get our answer, with many ad-hoc methods that are not documented in the code.

Maybe we should do this instead?

- Read /proc/self/cgroup
- Find the `10:memory:<path>` line
- If `/sys/fs/cgroup/memory/<path>/tasks` contains my PID, this is the path
- Otherwise, scan all `tasks` files under  `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID.

For example, here's a test with docker:


INSIDE CONTAINER
# cat /proc/self/cgroup | grep memory
10:memory:/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050
# cat /proc/self/mountinfo | grep memory
801 791 0:42 /docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime master:23 - cgroup cgroup rw,memory
# cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
cat: /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks: No such file or directory
# cat /sys/fs/cgroup/memory/tasks | grep $$
1

ON HOST
# cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
37494
# cat /proc/37494/status | grep NSpid
NSpid:	37494	1

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From iklam at openjdk.java.net  Thu May 19 20:21:47 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 19 May 2022 20:21:47 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <bPoDNxABi63JebXkYflJ3FUR0IF8OieXLmwkwjIxmk8=.1651330e-59af-4f56-932e-08d37626dfe9@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
 <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>
 <bPoDNxABi63JebXkYflJ3FUR0IF8OieXLmwkwjIxmk8=.1651330e-59af-4f56-932e-08d37626dfe9@github.com>
Message-ID: <fRitJVBN5BS8dbJ0VvMDkFZ65xpDJvhd5KlCKk5DhMI=.ca576f15-5b74-48d3-b46a-1432780ad016@github.com>

On Thu, 19 May 2022 19:59:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> What happens if cgroup_path is "/foo/bar" and _root is "/fo"?
>> 
>> With a mount path of `/bar` this ends up being `/bar/o/bar`. Pretty strange, but then again it's a bit of a contrived example as those paths come from `/proc` parsing. Anyway, this is code that got added with [JDK-8146115](https://bugs.openjdk.java.net/browse/JDK-8146115). It's not something I've written and to be honest, I'm not sure this branch is needed, but I didn't want to change the existing behaviour with this patch. I have no more insight than you in terms of why that approach has been taken.
>> 
>>> Maybe this block should be combined with the new `else` block you're adding?
>> 
>> Maybe, but I'm not sure if it would break something.
>> 
>>> However, the behavior seems opposite between these two blocks of code:
>>> 
>>> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path
>>> 
>>> ```
>>>   TestCase substring_match = {
>>>     "/sys/fs/cgroup/memory",                           // mount_path
>>>     "/user.slice/user-1000.slice",                     // root_path
>>>     "/user.slice/user-1000.slice/user at 1001.service",   // cgroup_path
>>>     "/sys/fs/cgroup/memory/user at 1001.service"          // expected_path
>>>   };
>>> ```
>> 
>> Yes. Though, I cannot comment on why that has been chosen. It's been there since day one :-/
>> 
>>> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path
>>> 
>>> ```
>>>  TestCase prefix_matched_cg = {
>>>     "/sys/fs/cgroup/memory",                           // mount_path
>>>     "/user.slice/user-1000.slice/session-50.scope",    // root_path
>>>     "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>>>     "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path
>>>   };
>>> ```
>>> 
>>> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function.
>> 
>> The reason why I've gone down the path of adding the head of cgroup_path is because of this document (in conjunction to what the user was observing on an affected system):
>> https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
>> 
>> The user was observing paths as listed in the test:
>> 
>> "/user.slice/user-1000.slice/session-50.scope",    // root_path
>> "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>> 
>> This very much looks like systemd managed. Given that and knowing that systemd adds processes into `scopes` or `services` and groups them via `slices` and also knowing that cgroups are hierarchical (i.e. limits of `/foo/bar` also apply to `/foo/bar/baz`), it seems likely that if there are any limits, then it'll be on `/user.slice/user-1000.slice` within the mounted controller. Unfortunately, I'm not able to reproduce this myself.
>
> I am wondering if the problem is this:
> 
> We have systemd running on the host, and a different copy of systemd that runs inside the container.
> 
> - They both set up `/user.slice/user-1000.slice/session-??.scope` within their own file systems
> - For some reason, when you're looking inside the container, `/proc/self/cgroup` might use a path in the containerized file system whereas `/proc/self/mountinfo` uses a path in the host file system. These two paths may look alike but they have absolutely no relation to each other.
> 
> I have asked the reporter for more information:
> 
> https://gist.github.com/gaol/4d96eace8290e6549635fdc0ea41d0b4?permalink_comment_id=4172593#gistcomment-4172593
> 
> Meanwhile, I think the current method of finding "which directory under /sys/fs/cgroup/memory controls my memory usage" is broken. As mentioned about, the path you get from  `/proc/self/cgroup`  and `/proc/self/mountinfo` have no relation to each other, but we use them anyway to get our answer, with many ad-hoc methods that are not documented in the code.
> 
> Maybe we should do this instead?
> 
> - Read /proc/self/cgroup
> - Find the `10:memory:<path>` line
> - If `/sys/fs/cgroup/memory/<path>/tasks` contains my PID, this is the path
> - Otherwise, scan all `tasks` files under  `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID.
> 
> For example, here's a test with docker:
> 
> 
> INSIDE CONTAINER
> # cat /proc/self/cgroup | grep memory
> 10:memory:/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050
> # cat /proc/self/mountinfo | grep memory
> 801 791 0:42 /docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime master:23 - cgroup cgroup rw,memory
> # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
> cat: /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks: No such file or directory
> # cat /sys/fs/cgroup/memory/tasks | grep $$
> 1
> 
> ON HOST
> # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
> 37494
> # cat /proc/37494/status | grep NSpid
> NSpid:	37494	1

Also, I think the current PR could produce the wrong answer, if systemd is indeed running inside the container, and we have:


"/user.slice/user-1000.slice/session-50.scope",    // root_path
"/user.slice/user-1000.slice/session-3.scope",     // cgroup_path


The PR gives /sys/fs/cgroup/memory/user.slice/user-1000.slice/, which specifies the overall memory limit for user-1000. However, the correct answer may be /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-3.scope, which may have a smaller memory limit, and the JVM may end up allocating a larger heap than allowed.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From rriggs at openjdk.java.net  Thu May 19 20:59:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 May 2022 20:59:01 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <jbBaODyPtTd8-tuH-COiI2ThXfoKUWG-KPHV-il4ohQ=.0fc3bc38-0236-4244-8094-1dab9a2ba505@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From aturbanov at openjdk.java.net  Thu May 19 21:23:45 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 19 May 2022 21:23:45 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <vSSWEeLopB9OfgPnj3bMmrcDoWqUaXU1Vx4Ob-Sr2e4=.00db113f-cfe6-41a7-b227-fbd8bb96819f@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Thank you for review!

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From aturbanov at openjdk.java.net  Thu May 19 21:46:09 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 19 May 2022 21:46:09 GMT
Subject: Integrated: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable
In-Reply-To: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
Message-ID: <m5Mlh_GXpRbgYU6ZFCOd4XxqZaSy9yYVTOz5Mnnr69I=.4c5baad6-401b-41b0-af78-60b6a3e417a8@github.com>

On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Method `Class.isAssignableFrom` is often used in form of:
> 
>     if (clazz.isAssignableFrom(obj.getClass())) {
> Such condition could be simplified to more shorter and performarnt code
> 
>     if (clazz.isInstance(obj)) {
>     
> Replacement is equivalent if it's known that `obj != null`.
> In JDK codebase there are many such places.
> 
> I tried to measure performance via JMH
> 
>     Class<?> integerClass = Integer.class;
>     Class<?> numberClass = Number.class;
> 
>     Object integerObject = 45666;
>     Object doubleObject = 8777d;
> 
>     @Benchmark
>     public boolean integerInteger_isInstance() {
>         return integerClass.isInstance(integerObject);
>     }
> 
>     @Benchmark
>     public boolean integerInteger_isAssignableFrom() {
>         return integerClass.isAssignableFrom(integerObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean integerDouble_isInstance() {
>         return integerClass.isInstance(doubleObject);
>     }
> 
>     @Benchmark
>     public boolean integerDouble_isAssignableFrom() {
>         return integerClass.isAssignableFrom(doubleObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean numberDouble_isInstance() {
>         return numberClass.isInstance(doubleObject);
>     }
> 
>     @Benchmark
>     public boolean numberDouble_isAssignableFrom() {
>         return numberClass.isAssignableFrom(doubleObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean numberInteger_isInstance() {
>         return numberClass.isInstance(integerObject);
>     }
> 
>     @Benchmark
>     public boolean numberInteger_isAssignableFrom() {
>         return numberClass.isAssignableFrom(integerObject.getClass());
>     }
> 
>     @Benchmark
>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>         bh.consume(numberClass.isInstance(integerObject));
>         bh.consume(numberClass.isInstance(doubleObject));
>     }
> 
>     @Benchmark
>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>     }
> 
> `isInstance` is a bit faster than `isAssignableFrom`
> 
> Benchmark                              Mode  Cnt  Score   Error  Units
> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op

This pull request has now been integrated.

Changeset: de74e0e2
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/de74e0e25a195084745891419f0c4a8ad286560c
Stats:     25 lines in 10 files changed: 0 ins; 3 del; 22 mod

8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable

Reviewed-by: prr, rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From cjplummer at openjdk.java.net  Fri May 20 04:18:41 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 20 May 2022 04:18:41 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options [v2]
In-Reply-To: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
Message-ID: <yD34WHS-Fd3gDIkgVNlVrArzd18w_XRFfq_UNQYJ8Ag=.9a4f0ea1-c8a3-43c9-be2b-a1b29a52a250@github.com>

> As part of the loom integration, jdb added -trackvthreads and the debug agent added "enumeratevthreads". The help text for these options should call out that they are Preview Features.

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

  use "virtual threads" instead of "vthreads"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8780/files
  - new: https://git.openjdk.java.net/jdk/pull/8780/files/98dab265..23667503

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8780&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8780&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From cjplummer at openjdk.java.net  Fri May 20 04:25:47 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 20 May 2022 04:25:47 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format
In-Reply-To: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
Message-ID: <_T1FzHB4M7NL9wJ4BECTxJtcigfB1KTzv3VTYLAd4Dc=.4a0bc7f2-ac23-46b9-bdd8-958aad1fdd4c@github.com>

On Thu, 19 May 2022 09:38:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only change to add some test infrastructure and improve the testing of thread dumps in JSON format. The new tests added by JEP 425 for this thread dump format search the JSON text for strings but don't parse it completely.  These tests can be improved with a test class that parses the thread dump. The tests for JEP 428 like make use of the test infrastructure too.

I think  a short example dump would actually be easier to read alongside the code.

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From ihse at openjdk.java.net  Fri May 20 08:42:44 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 20 May 2022 08:42:44 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <RmHbfRXO30BBvfEUmUW7R2l6YV8gOypiJVRi-E1Z40E=.2275399d-8168-4fd2-8f39-2a6be94db1db@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Build changes look good. Thanks for the cleanup!

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From alanb at openjdk.java.net  Fri May 20 11:32:14 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 May 2022 11:32:14 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v2]
In-Reply-To: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
Message-ID: <NHwFlkDqB0MzAgZfhAlaYu7KsEvu9C4Jkb8iYDKFdVY=.4e94396f-f644-4724-bb52-424524f1ca47@github.com>

> This is a test-only change to add some test infrastructure and improve the testing of thread dumps in JSON format. The new tests added by JEP 425 for this thread dump format search the JSON text for strings but don't parse it completely.  These tests can be improved with a test class that parses the thread dump. The tests for JEP 428 like make use of the test infrastructure too.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Add example thread dump and usage to class description

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8784/files
  - new: https://git.openjdk.java.net/jdk/pull/8784/files/c0a12746..15c2fd7b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8784&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8784&range=00-01

  Stats: 69 lines in 1 file changed: 68 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8784.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8784/head:pull/8784

PR: https://git.openjdk.java.net/jdk/pull/8784

From alanb at openjdk.java.net  Fri May 20 11:34:22 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 May 2022 11:34:22 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format
In-Reply-To: <_T1FzHB4M7NL9wJ4BECTxJtcigfB1KTzv3VTYLAd4Dc=.4a0bc7f2-ac23-46b9-bdd8-958aad1fdd4c@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <_T1FzHB4M7NL9wJ4BECTxJtcigfB1KTzv3VTYLAd4Dc=.4a0bc7f2-ac23-46b9-bdd8-958aad1fdd4c@github.com>
Message-ID: <SQVaKpl3RCLu_jRbnbqciv4hylU1aW7uDF-0Ahchkd0=.99fb8507-7a82-410e-a5ad-45c5d5c0a245@github.com>

On Fri, 20 May 2022 04:22:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I think a short example dump would actually be easier to read alongside the code.

That's a good idea. I've updated the class description to include an example and also a code example of how it can be used in tests. The thread dump example collapses several objects to avoid it getting too unwieldily. 

I've started [PR8807](https://github.com/openjdk/jdk/pull/8807) to document the format.

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From dfuchs at openjdk.java.net  Fri May 20 13:37:00 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 20 May 2022 13:37:00 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v2]
In-Reply-To: <NHwFlkDqB0MzAgZfhAlaYu7KsEvu9C4Jkb8iYDKFdVY=.4e94396f-f644-4724-bb52-424524f1ca47@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <NHwFlkDqB0MzAgZfhAlaYu7KsEvu9C4Jkb8iYDKFdVY=.4e94396f-f644-4724-bb52-424524f1ca47@github.com>
Message-ID: <D9SwXFZtAkDISPLN7cviVVNjd2eOv_3Ik1gov8AXb2I=.d01251d5-4d34-4f4a-9198-bc42018e4159@github.com>

On Fri, 20 May 2022 11:32:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is a test-only change to add some test infrastructure and improve the testing of thread dumps in JSON format. The new tests added by JEP 425 for this thread dump format search the JSON text for strings but don't parse it completely.  These tests can be improved with a test class that parses the thread dump. The tests for JEP 428 like make use of the test infrastructure too.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example thread dump and usage to class description

test/lib/jdk/test/lib/threaddump/ThreadDump.java line 82:

> 80:  *         "parent": "<root>",
> 81:  *         "owner": null,
> 82:  *         "threads:": [...],

probably the extra colon after `threads` is a typo here

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From ngasson at openjdk.java.net  Fri May 20 15:58:38 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 20 May 2022 15:58:38 GMT
Subject: RFR: 8286711: AArch64: serviceability agent tests fail with PAC
 enabled
Message-ID: <HrusXjkc89qs4KckW40XWqMBFc1XlfmPt6aNhPxn3Vk=.dbd3dadb-27c9-46fc-a065-0c13fdea2bfc@github.com>

When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU, the upper bits of the saved link register contain a "pointer authentication code" which must be checked and removed by a special instruction before a function returns.  The serviceability agent is unaware of this and so sees garbled PC values when walking the stack. This patch just masks out the PAC bits from the sender PC after reading it from the stack frame.

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

Commit messages:
 - 8286711: AArch64: serviceability agent tests fail with PAC enabled

Changes: https://git.openjdk.java.net/jdk/pull/8814/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8814&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286711
  Stats: 43 lines in 5 files changed: 35 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8814.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8814/head:pull/8814

PR: https://git.openjdk.java.net/jdk/pull/8814

From alanb at openjdk.java.net  Fri May 20 16:41:36 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 May 2022 16:41:36 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v3]
In-Reply-To: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
Message-ID: <fQ1ZcUIhOWqFycYMy-kM5tlZ8h7E5HfFu4cRNTdz2co=.4285e6be-eecb-4ab6-971e-3804c618ccd3@github.com>

> This is a test-only change to add some test infrastructure and improve the testing of thread dumps in JSON format. The new tests added by JEP 425 for this thread dump format search the JSON text for strings but don't parse it completely.  These tests can be improved with a test class that parses the thread dump. The tests for JEP 428 like make use of the test infrastructure too.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Remove spurious colon

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8784/files
  - new: https://git.openjdk.java.net/jdk/pull/8784/files/15c2fd7b..4f9590f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8784&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8784&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From lmesnik at openjdk.java.net  Fri May 20 20:09:59 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 20 May 2022 20:09:59 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
 [v2]
In-Reply-To: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
Message-ID: <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>

> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
> 
> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  2nd v

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8589/files
  - new: https://git.openjdk.java.net/jdk/pull/8589/files/3e0c6ee6..726e7dcc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8589&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8589&range=00-01

  Stats: 14 lines in 3 files changed: 5 ins; 5 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8589.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8589/head:pull/8589

PR: https://git.openjdk.java.net/jdk/pull/8589

From lmesnik at openjdk.java.net  Fri May 20 20:14:59 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 20 May 2022 20:14:59 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
 [v2]
In-Reply-To: <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
 <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
Message-ID: <WxjuzmrUtyezRIVm_ZUEgzORFj5kVNY-y0R7QopAY_w=.4da679ce-eeca-478f-9ef4-d5175c173b63@github.com>

On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
>> 
>> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd v

After discussion with @sspitsyn and more testing, I realized that it is not enough to disable EA with some capabilities. The IterateHeap requires a capability which is enabled by default. Moreover, code might be compiled before the agent requests any caps. So the new proposed fix is to apply EscapeBarriers for platform threads only. For virtual threads, the behavior is the same as before JDK-8227745. This should be fixed by https://bugs.openjdk.java.net/browse/JDK-8264699

The fix has been pushed into loom repo already and it is a backport:
https://github.com/openjdk/loom/commit/6520b71a62baf64d214ff94c9291bfc513dfbe51

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From kvn at openjdk.java.net  Fri May 20 20:20:56 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 20 May 2022 20:20:56 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
 [v2]
In-Reply-To: <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
 <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
Message-ID: <YMijxIpPhRiO7yLmeyKh-zFH1Ff_qnmM5lNAVvxpHBM=.d1375dee-4646-4b7b-a9fc-0d79f8a1d57f@github.com>

On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
>> 
>> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd v

Update is good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8589

From kemperw at amazon.com  Fri May 20 21:46:31 2022
From: kemperw at amazon.com (Kemper, William)
Date: Fri, 20 May 2022 21:46:31 +0000
Subject: Concurrent heap monitoring
Message-ID: <1653083191904.40109@amazon.com>

Taking a heap dump is a stop the world event. Garbage collection events can provide heap utilization information only after a cycle completes. We've found that detailed heap occupancy data (such as heap inspections provide) are too expensive to use for production monitoring.  Similarly, we find that heap statistics generated from collection cycles may come too late and may not provide enough detail (young collections do not reflect the state of the old generation). We have developed a prototype feature to provide detailed heap metrics concurrently, without barriers. It therefore provides only an estimate as changes to the object graph may cause it to miss objects. We would like to hear the thoughts of serviceability experts on such a thing. It is only at the proof of concept phase, but it is able to run popular benchmarks (specjbb, dacapo) with minimal overhead and the estimates are sufficiently accurate for our use cases (monitoring heap and object growth rates).


Thank you for reading,

William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20220520/c328f9cf/attachment.htm>

From lmesnik at openjdk.java.net  Fri May 20 22:34:12 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 20 May 2022 22:34:12 GMT
Subject: RFR: 8287103:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp
Message-ID: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>

Sync improved in test

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

Commit messages:
 - 8287103: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp

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

PR: https://git.openjdk.java.net/jdk/pull/8821

From sspitsyn at openjdk.java.net  Sat May 21 02:39:40 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 21 May 2022 02:39:40 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
 [v2]
In-Reply-To: <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
 <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
Message-ID: <caJTZ8ULvFhutONfp9DFce4FV5Y9MEHHh94honkCGKU=.3c865121-5ce2-4761-85ca-068eae336679@github.com>

On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
>> 
>> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd v

Hi Leonid,
Thank you a lot for taking care about this!
Looks good to me (according to our private agreement).
My understanding is that this changeset fixes a test regression.
Could you, please, list this test being fixed in the bug report?
Also, you said there was a related bug/rfe filed to fully disable EA when continuations and related JVMTI capabilities are enabled. Could you, please, link this bug/rfe to current bug?
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8589

From lmesnik at openjdk.java.net  Sat May 21 04:03:57 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sat, 21 May 2022 04:03:57 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
 [v2]
In-Reply-To: <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
 <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
Message-ID: <XI9Ec1THWQdOBmEwOax82DA0A_MKdf5O6u0wF_NGiho=.8b76e148-09fa-43f0-b0b2-f62c7c2f5aff@github.com>

On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
>> 
>> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd v

This change fixes regression of platform threads behavior with --enabled-preview enabled. However, the info for virtual threads might be incorrect if EA is enabled.
The issue [JDK-8264699](https://bugs.openjdk.java.net/browse/JDK-8264699) Re-examine deopt of frames to allow EA be enabled with JVMTI agents should cover it.

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From lmesnik at openjdk.java.net  Sat May 21 04:08:34 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sat, 21 May 2022 04:08:34 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
 [v2]
In-Reply-To: <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
 <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
Message-ID: <7x6MdIPrpfZWybpyJ1rm6A5CTmlog2dB9IUvZbVUl1U=.5cc393e9-9456-4c0e-a01b-f086ebd1cd70@github.com>

On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
>> 
>> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd v

Affected tests are:
serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java
com/sun/jdi/EATests.java#id0

The pass in jdk/jdk because --enable-preview is not enabled but failed before fix in fibers branch where --enable-preview is enabled by default.

The should pass with --enabled-preview after fix. The are removed from problemlist in fibers branch in the fix:
https://github.com/openjdk/loom/commit/6520b71a62baf64d214ff94c9291bfc513dfbe51

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From alanb at openjdk.java.net  Sat May 21 05:24:46 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 21 May 2022 05:24:46 GMT
Subject: RFR: 8287103:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp
In-Reply-To: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>
References: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>
Message-ID: <3V6RXjRfvA0z1F4OV4RXwMUGgsqqxPVT_Jx84KpcfoM=.522f2a32-2bb1-47f8-8597-a697e465ffe4@github.com>

On Fri, 20 May 2022 22:27:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Sync improved in test

Can you add `@bug 8284161 8287103` to the test description?

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

PR: https://git.openjdk.java.net/jdk/pull/8821

From alanb at openjdk.java.net  Sat May 21 05:29:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 21 May 2022 05:29:48 GMT
Subject: RFR: 8287103:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp
In-Reply-To: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>
References: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>
Message-ID: <ufMoeuq6O0LAgwj3KqOH5zrELrBDYMhNWZHycbBz4o4=.b335b211-d22f-404e-b86c-c3aabb5ae191@github.com>

On Fri, 20 May 2022 22:27:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Sync improved in test

test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 43:

> 41:     private static final Object LOCK2 = new Object();
> 42: 
> 43:     private static volatile boolean lock2Obtained = false;

The term used in the APIs is "lock held"  so might be better to rename this to lock2Held. Can you drop the explicit init to false and also put a blank line after the declaration as it looks strange to have it run into the comment on the main method.

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

PR: https://git.openjdk.java.net/jdk/pull/8821

From volker.simonis at gmail.com  Sat May 21 07:49:36 2022
From: volker.simonis at gmail.com (Volker Simonis)
Date: Sat, 21 May 2022 09:49:36 +0200
Subject: Concurrent heap monitoring
In-Reply-To: <1653083191904.40109@amazon.com>
References: <1653083191904.40109@amazon.com>
Message-ID: <CA+3eh10=hF7HpnED9nTsRZ+_UiVCnEJvm65qT5wFBa03DgpoKg@mail.gmail.com>

This sounds very interesting. Does this feature work with every GC or  does
the implementation depend on specific GCs (and if the latter, which GCs
does your prototype currently support).

Kemper, William <kemperw at amazon.com> schrieb am Fr., 20. Mai 2022, 23:46:

> Taking a heap dump is a stop the world event. Garbage collection events
> can provide heap utilization information only after a cycle completes.
> We've found that detailed heap occupancy data (such as heap inspections
> provide) are too expensive to use for production monitoring.  Similarly, we
> find that heap statistics generated from collection cycles may come too
> late and may not provide enough detail (young collections do not reflect
> the state of the old generation). We have developed a *prototype* feature
> to provide detailed heap metrics *concurrently**, without barriers.* It
> therefore provides only an estimate as changes to the object graph may
> cause it to miss objects. We would like to hear the thoughts of
> serviceability experts on such a thing. It is only at the proof of concept
> phase, but it is able to run popular benchmarks (specjbb, dacapo) with
> minimal overhead and the estimates are sufficiently accurate for our use
> cases (monitoring heap and object growth rates).
>
>
> Thank you for reading,
>
> William
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20220521/ed994b7a/attachment.htm>

From rrich at openjdk.java.net  Sat May 21 12:17:56 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sat, 21 May 2022 12:17:56 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
 [v2]
In-Reply-To: <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
 <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
Message-ID: <PG39H-_43j5dphQn6uGz9LSpNATgicbNEeAJ_NnS3EI=.d7201c7b-abd9-4d91-b951-e228af510a3a@github.com>

On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
>> 
>> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd v

Hi Leonid,
if EscapeAnalysis is not disabled, then local objects cannot be read per JVMTI if they are scalarized in compiled frames on the heap, right? This would be a problem I'd think.
Thanks, Richard.

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From lmesnik at openjdk.java.net  Sat May 21 16:12:50 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sat, 21 May 2022 16:12:50 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
 [v2]
In-Reply-To: <PG39H-_43j5dphQn6uGz9LSpNATgicbNEeAJ_NnS3EI=.d7201c7b-abd9-4d91-b951-e228af510a3a@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
 <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
 <PG39H-_43j5dphQn6uGz9LSpNATgicbNEeAJ_NnS3EI=.d7201c7b-abd9-4d91-b951-e228af510a3a@github.com>
Message-ID: <tWh_6z-9Ftg-XFAjv5HO_Y_M1ew4qiOXl2EFx5WKVHk=.9131f41a-bd8d-46c5-af86-9f0aa608ab8c@github.com>

On Sat, 21 May 2022 12:14:11 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Hi Leonid, if EscapeAnalysis is not disabled, then local objects cannot be read per JVMTI if they are scalarized in compiled frames on the heap, right? This would be a problem I'd think. Thanks, Richard.

Yes, the fix restores correct behavior for platform threads if --enable-preview is on.  The [JDK-8285739](https://bugs.openjdk.java.net/browse/JDK-8285739) should fix this for virtual threads. 

And as test serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java demonstrates there are might be methods which compiled with EA before JVMTI agent require capabilities.

I incorrectly tested my previous fix, it really doesn't pass  serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java test with --enable-preview.

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From lmesnik at openjdk.java.net  Sat May 21 16:34:32 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sat, 21 May 2022 16:34:32 GMT
Subject: RFR: 8287103:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp
 [v2]
In-Reply-To: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>
References: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>
Message-ID: <xH8nLfHZdP3HMQImv2N3HN-EH5wCZZ6hI3JbnW8FTTY=.41b75b9b-6364-401a-ba50-bfbdc73532ac@github.com>

> Sync improved in test

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8821/files
  - new: https://git.openjdk.java.net/jdk/pull/8821/files/b3f870b5..681a2d97

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8821&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8821&range=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8821.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8821/head:pull/8821

PR: https://git.openjdk.java.net/jdk/pull/8821

From alanb at openjdk.java.net  Sat May 21 17:09:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 21 May 2022 17:09:43 GMT
Subject: RFR: 8287103:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp
 [v2]
In-Reply-To: <xH8nLfHZdP3HMQImv2N3HN-EH5wCZZ6hI3JbnW8FTTY=.41b75b9b-6364-401a-ba50-bfbdc73532ac@github.com>
References: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>
 <xH8nLfHZdP3HMQImv2N3HN-EH5wCZZ6hI3JbnW8FTTY=.41b75b9b-6364-401a-ba50-bfbdc73532ac@github.com>
Message-ID: <HoLDU30_wXnZY2QBs4_uj8mMjR3hq2yVCWszCRYhGNA=.aa0ca977-71d7-4b82-a141-4bbfae9f79a5@github.com>

On Sat, 21 May 2022 16:34:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Sync improved in test
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8821

From dholmes at openjdk.java.net  Mon May 23 02:17:48 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 23 May 2022 02:17:48 GMT
Subject: RFR: 8286711: AArch64: serviceability agent tests fail with PAC
 enabled
In-Reply-To: <HrusXjkc89qs4KckW40XWqMBFc1XlfmPt6aNhPxn3Vk=.dbd3dadb-27c9-46fc-a065-0c13fdea2bfc@github.com>
References: <HrusXjkc89qs4KckW40XWqMBFc1XlfmPt6aNhPxn3Vk=.dbd3dadb-27c9-46fc-a065-0c13fdea2bfc@github.com>
Message-ID: <1ztZlywZcqdvzY9foCeL_jsW9V59Rono5AeGiCoNH3g=.4d00dada-c27c-48ce-a95c-7647472e47bc@github.com>

On Fri, 20 May 2022 15:52:04 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU, the upper bits of the saved link register contain a "pointer authentication code" which must be checked and removed by a special instruction before a function returns.  The serviceability agent is unaware of this and so sees garbled PC values when walking the stack. This patch just masks out the PAC bits from the sender PC after reading it from the stack frame.

That all seems reasonable to me.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8814

From dholmes at openjdk.java.net  Mon May 23 02:55:39 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 23 May 2022 02:55:39 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options [v2]
In-Reply-To: <XccKZlWUIQS6BolQEAwRHs6_P_dlCNHvyPHKTrQDfXA=.b84273c7-fb3d-4aaf-8d21-be1b4657b6a7@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
 <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>
 <XccKZlWUIQS6BolQEAwRHs6_P_dlCNHvyPHKTrQDfXA=.b84273c7-fb3d-4aaf-8d21-be1b4657b6a7@github.com>
Message-ID: <hFYsIjH1sDsXzyG0GEQ7YIsVB3opUPeeWXPvS6AOtwI=.e4ab1a8b-a5a3-469b-ba23-14565343ea2a@github.com>

On Thu, 19 May 2022 15:29:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c line 880:
>> 
>>> 878:  "onuncaught=y|n                   debug on any uncaught?            n\n"
>>> 879:  "timeout=<timeout value>          for listen/attach in milliseconds n\n"
>>> 880:  "enumeratevthreads=y|n            (Preview Feature) thread lists include all vthreads\n"
>> 
>> I think the description needs to say "virtual threads" rather than "vthreads". Also I think "(Preview" needs to go after "virtual threads" to make it clearer that it's virtual threads that are preview,.
>
> I was really trying to emphasize that the flag is preview, and therefore may change or go away.  If I change as  you suggest, the reader could imply that as long as virtual threads support is in place, then the flag will be also (and in its current form).

I agree with @plummercj , this is documenting that the flag is itself a "preview feature" and thus subject to change.

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From cjplummer at openjdk.java.net  Mon May 23 06:17:48 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 23 May 2022 06:17:48 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v3]
In-Reply-To: <fQ1ZcUIhOWqFycYMy-kM5tlZ8h7E5HfFu4cRNTdz2co=.4285e6be-eecb-4ab6-971e-3804c618ccd3@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <fQ1ZcUIhOWqFycYMy-kM5tlZ8h7E5HfFu4cRNTdz2co=.4285e6be-eecb-4ab6-971e-3804c618ccd3@github.com>
Message-ID: <Ci5LX-DNFDnQ1jrIKlJiHnTyU93TFcZrJ1i0O0nIZa0=.b17553a2-934a-472b-a9b0-c516979ceb65@github.com>

On Fri, 20 May 2022 16:41:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is a test-only change to add some test infrastructure and improve the testing of thread dumps in JSON format. The new tests added by JEP 425 for this thread dump format search the JSON text for strings but don't parse it completely.  These tests can be improved with a test class that parses the thread dump. The tests for JEP 428 like make use of the test infrastructure too.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove spurious colon

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 115:

> 113: 
> 114:                 // find the thread container that corresponds to the executor
> 115:                 String name = Objects.toIdentityString(executor);

I don't understand the need for `toIdentityString()` rather than just `toString()`

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 121:

> 119:                 container.findThread(vthread.threadId()).orElseThrow();
> 120: 
> 121:                 // if the current thread is a platform thread then will be in root container

"..._it_ will be in _the_ root container"

test/lib/jdk/test/lib/threaddump/ThreadDump.java line 179:

> 177:                 return this;
> 178:             if (name().startsWith(name + "/"))
> 179:                 return this;

It's not clear to me why this is here. What does it mean if the name of the container starts with `<name>/`?

test/lib/jdk/test/lib/threaddump/ThreadDump.java line 299:

> 297: 
> 298:             // add to map if not already encountered
> 299:             var container = map.computeIfAbsent(name, k -> new ThreadContainer(name));

Why might the container already be in `map`?

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From yyang at openjdk.java.net  Mon May 23 07:37:16 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 23 May 2022 07:37:16 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
Message-ID: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>

It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.

Currently, NonHeapUsage = CodeCache + Metaspace + CompressedClassSpace

==> CodeHeap 'non-nmethods' 1532544 (Used)
==> CodeHeap 'profiled nmethods' 0
==> CodeHeap 'non-profiled nmethods' 13952
==> Metaspace 506696
==> Compressed Class Space 43312
init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K)

In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be NonHeapUsage = CodeCache + Metaspace.

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

Commit messages:
 - 8287135 Calculation of jmm_GetMemoryUsage is wrong

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From alanb at openjdk.java.net  Mon May 23 07:56:50 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 07:56:50 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v3]
In-Reply-To: <Ci5LX-DNFDnQ1jrIKlJiHnTyU93TFcZrJ1i0O0nIZa0=.b17553a2-934a-472b-a9b0-c516979ceb65@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <fQ1ZcUIhOWqFycYMy-kM5tlZ8h7E5HfFu4cRNTdz2co=.4285e6be-eecb-4ab6-971e-3804c618ccd3@github.com>
 <Ci5LX-DNFDnQ1jrIKlJiHnTyU93TFcZrJ1i0O0nIZa0=.b17553a2-934a-472b-a9b0-c516979ceb65@github.com>
Message-ID: <ajs5TrUg9GqZonJ63Pb3QneADBuExasK6E38c5apUvU=.7ac04cda-bd93-4b04-83e4-4e9e6096950c@github.com>

On Mon, 23 May 2022 06:09:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove spurious colon
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 115:
> 
>> 113: 
>> 114:                 // find the thread container that corresponds to the executor
>> 115:                 String name = Objects.toIdentityString(executor);
> 
> I don't understand the need for `toIdentityString()` rather than just `toString()`

The implementation lends on the string returned by Object::toString when not overridden. In this case, either will do so I can change it to toString.

> test/lib/jdk/test/lib/threaddump/ThreadDump.java line 179:
> 
>> 177:                 return this;
>> 178:             if (name().startsWith(name + "/"))
>> 179:                 return this;
> 
> It's not clear to me why this is here. What does it mean if the name of the container starts with `<name>/`?

With the exception of the root container, the names have the form "name1/name2" where name1 is the "external name" and name2 identifies the internal thread grouping.  The external name is the object identity for thread pools and thread-per-executors created by user code. In time we may expose ways to provide a name.

> test/lib/jdk/test/lib/threaddump/ThreadDump.java line 299:
> 
>> 297: 
>> 298:             // add to map if not already encountered
>> 299:             var container = map.computeIfAbsent(name, k -> new ThreadContainer(name));
> 
> Why might the container already be in `map`?

They aren't topologically sorted so it's possible to encounter a thread container before its parent.

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From alanb at openjdk.java.net  Mon May 23 08:30:51 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 08:30:51 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v4]
In-Reply-To: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
Message-ID: <CFh2wNJBGZkkCoXKB_ytRD4PdbiKq2CvCeaabLzWJAE=.0c355a58-8a6e-4add-966e-9d84a6a94970@github.com>

> This change is mostly test infrastructure and improvements to the testing of thread dumps in JSON format. It also tweaks the thread dump format so that the process identifier and thread identifiers are a type string rather than number.
> 
> The tests for thread dumps added by JEP 425 are changed to use the test infrastructure library. The tests for JEP 428 will also make use of this test infrastructure.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Use string rater than number for process/thread identifiers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8784/files
  - new: https://git.openjdk.java.net/jdk/pull/8784/files/4f9590f3..353fc53d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8784&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8784&range=02-03

  Stats: 58 lines in 4 files changed: 26 ins; 2 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8784.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8784/head:pull/8784

PR: https://git.openjdk.java.net/jdk/pull/8784

From alanb at openjdk.java.net  Mon May 23 08:36:50 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 08:36:50 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v4]
In-Reply-To: <CFh2wNJBGZkkCoXKB_ytRD4PdbiKq2CvCeaabLzWJAE=.0c355a58-8a6e-4add-966e-9d84a6a94970@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <CFh2wNJBGZkkCoXKB_ytRD4PdbiKq2CvCeaabLzWJAE=.0c355a58-8a6e-4add-966e-9d84a6a94970@github.com>
Message-ID: <22pgay8-JpDLqx_o9mYcqF0KQPEa3JA90vkpPGRBT-o=.7032cea3-afe4-4899-b82a-cfe203d8def8@github.com>

On Mon, 23 May 2022 08:30:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change is mostly test infrastructure and improvements to the testing of thread dumps in JSON format. It also tweaks the thread dump format so that the process identifier and thread identifiers are a type string rather than number.
>> 
>> The tests for thread dumps added by JEP 425 are changed to use the test infrastructure library. The tests for JEP 428 will also make use of this test infrastructure.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use string rater than number for process/thread identifiers

I've updated the patch to generating the process and thread identifiers as string rather than number (as JSON numbers that are integers don't have the required range). The test infra and DumpThreads.java test are expanded a bit and now test the processId, time and runtimeVersion fields.

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From sgehwolf at openjdk.java.net  Mon May 23 09:27:45 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 23 May 2022 09:27:45 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <fRitJVBN5BS8dbJ0VvMDkFZ65xpDJvhd5KlCKk5DhMI=.ca576f15-5b74-48d3-b46a-1432780ad016@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
 <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>
 <bPoDNxABi63JebXkYflJ3FUR0IF8OieXLmwkwjIxmk8=.1651330e-59af-4f56-932e-08d37626dfe9@github.com>
 <fRitJVBN5BS8dbJ0VvMDkFZ65xpDJvhd5KlCKk5DhMI=.ca576f15-5b74-48d3-b46a-1432780ad016@github.com>
Message-ID: <KPDr-0LR7sXWsSUW5w_0Qbuh-MXaddpNBO6s5Lsd8_U=.80b1eb53-c1f9-4e8a-8ac7-7f8b092008cc@github.com>

On Thu, 19 May 2022 20:18:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I am wondering if the problem is this:
>> 
>> We have systemd running on the host, and a different copy of systemd that runs inside the container.
>> 
>> - They both set up `/user.slice/user-1000.slice/session-??.scope` within their own file systems
>> - For some reason, when you're looking inside the container, `/proc/self/cgroup` might use a path in the containerized file system whereas `/proc/self/mountinfo` uses a path in the host file system. These two paths may look alike but they have absolutely no relation to each other.
>> 
>> I have asked the reporter for more information:
>> 
>> https://gist.github.com/gaol/4d96eace8290e6549635fdc0ea41d0b4?permalink_comment_id=4172593#gistcomment-4172593
>> 
>> Meanwhile, I think the current method of finding "which directory under /sys/fs/cgroup/memory controls my memory usage" is broken. As mentioned about, the path you get from  `/proc/self/cgroup`  and `/proc/self/mountinfo` have no relation to each other, but we use them anyway to get our answer, with many ad-hoc methods that are not documented in the code.
>> 
>> Maybe we should do this instead?
>> 
>> - Read /proc/self/cgroup
>> - Find the `10:memory:<path>` line
>> - If `/sys/fs/cgroup/memory/<path>/tasks` contains my PID, this is the path
>> - Otherwise, scan all `tasks` files under  `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID.
>> 
>> For example, here's a test with docker:
>> 
>> 
>> INSIDE CONTAINER
>> # cat /proc/self/cgroup | grep memory
>> 10:memory:/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050
>> # cat /proc/self/mountinfo | grep memory
>> 801 791 0:42 /docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime master:23 - cgroup cgroup rw,memory
>> # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
>> cat: /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks: No such file or directory
>> # cat /sys/fs/cgroup/memory/tasks | grep $$
>> 1
>> 
>> ON HOST
>> # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
>> 37494
>> # cat /proc/37494/status | grep NSpid
>> NSpid:	37494	1
>
> Also, I think the current PR could produce the wrong answer, if systemd is indeed running inside the container, and we have:
> 
> 
> "/user.slice/user-1000.slice/session-50.scope",    // root_path
> "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
> 
> 
> The PR gives /sys/fs/cgroup/memory/user.slice/user-1000.slice/, which specifies the overall memory limit for user-1000. However, the correct answer may be /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-3.scope, which may have a smaller memory limit, and the JVM may end up allocating a larger heap than allowed.

Yes, if we can decide which one the right file is. This is largely undocumented territory. The correct fix is a) find the correct path to the namespace hierarchy the process is a part of. b) starting at the leaf node, walk up the hierarchy and find the **lowest** limits. Doing this would be very expensive!

Aside: Current container detection in the JVM/JDK is notoriously imprecise. It's largely based on common setups (containers like docker). The heuristics assume that memory limits are reported inside the container at the leaf node. If, however, that's not the case, the detected limits will be wrong (it will detect it as unlimited, even though it's - for example - memory constrained at the parent). This can for example be reproduced on a cgroups v2 system with a systemd slice using memory limits. We've worked-around this in OpenJDK for cgroups v1 by https://bugs.openjdk.java.net/browse/JDK-8217338

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From dholmes at openjdk.java.net  Mon May 23 10:01:42 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 23 May 2022 10:01:42 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
Message-ID: <sViIdbdRBHRLlHAVfOcHdtj9iHjQ2uJPM0ZoVDB09Wg=.1ed1c78a-9d5d-4ca9-808b-e9d86879c393@github.com>

On Mon, 23 May 2022 07:28:41 GMT, Yi Yang <yyang at openjdk.org> wrote:

> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
> 
> Currently, NonHeapUsage = CodeCache + Metaspace + CompressedClassSpace
> 
> ==> CodeHeap 'non-nmethods' 1532544 (Used)
> ==> CodeHeap 'profiled nmethods' 0
> ==> CodeHeap 'non-profiled nmethods' 13952
> ==> Metaspace 506696
> ==> Compressed Class Space 43312
> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K)
> 
> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be NonHeapUsage = CodeCache + Metaspace.

Sorry but I can't agree with this change as presented. By definition the total non-heap memory is the sum of all pools which identify as non-heap as per the specification:

"The non-heap memory consists of one or more memory pools. The used and committed size of the returned memory usage is the sum of those values of all non-heap memory pools ..."

so the existing code that sums the non-heap pools is correct. If you think `CompressedClassSpace` should not be counted then you need to argue for it  to not be "non-heap".

Cheers,
David

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8831

From rrich at openjdk.java.net  Mon May 23 10:24:03 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 23 May 2022 10:24:03 GMT
Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled
 [v2]
In-Reply-To: <tWh_6z-9Ftg-XFAjv5HO_Y_M1ew4qiOXl2EFx5WKVHk=.9131f41a-bd8d-46c5-af86-9f0aa608ab8c@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
 <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
 <PG39H-_43j5dphQn6uGz9LSpNATgicbNEeAJ_NnS3EI=.d7201c7b-abd9-4d91-b951-e228af510a3a@github.com>
 <tWh_6z-9Ftg-XFAjv5HO_Y_M1ew4qiOXl2EFx5WKVHk=.9131f41a-bd8d-46c5-af86-9f0aa608ab8c@github.com>
Message-ID: <J4V8tSx91FWL5Uqr_WRvf6kwmqjE5WjDP41-N_Cv0v8=.c19186b2-284b-4f54-8a9c-f9648e0ff9ba@github.com>

On Sat, 21 May 2022 16:09:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> > Hi Leonid, if EscapeAnalysis is not disabled, then local objects cannot be read per JVMTI if they are scalarized in compiled frames on the heap, right? This would be a problem I'd think. Thanks, Richard.
> 
> Yes, the fix restores correct behavior for platform threads if --enable-preview is on. The [JDK-8285739](https://bugs.openjdk.java.net/browse/JDK-8285739) should fix this for virtual threads.

Could it be that you mean [JDK-8264699](https://bugs.openjdk.java.net/browse/JDK-8264699)?

I'm ok with this version of your fix. I'd suggest to change title/synopsis of the bug report to better match it though.

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From asotona at openjdk.java.net  Mon May 23 10:40:40 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 10:40:40 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v9]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <W_1U5L9wg5OtyL_Ar1-3297-G3AA7DQKexeRB1qm6D8=.cf6451b5-559d-4d20-b3d6-b294f5b1cf06@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c9065915...455720ef

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

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08
  Stats: 441 lines in 18 files changed: 438 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Mon May 23 11:02:32 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 11:02:32 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v10]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <BjXRwHICfpOB1Ol2lbijomFjPYp0eaUL2Y2NRkHYuRQ=.346a7ec5-96ed-48a3-9c36-af1aea010a8e@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/455720ef..4978c2a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08-09

  Stats: 5 lines in 3 files changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From yyang at openjdk.java.net  Mon May 23 11:14:54 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 23 May 2022 11:14:54 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <sViIdbdRBHRLlHAVfOcHdtj9iHjQ2uJPM0ZoVDB09Wg=.1ed1c78a-9d5d-4ca9-808b-e9d86879c393@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <sViIdbdRBHRLlHAVfOcHdtj9iHjQ2uJPM0ZoVDB09Wg=.1ed1c78a-9d5d-4ca9-808b-e9d86879c393@github.com>
Message-ID: <AawAujs_RMoiUsxzxn6glkjnTTGjnnXf2gn52cFepsI=.c6e3568f-7172-4321-83f1-269018a231ce@github.com>

On Mon, 23 May 2022 09:58:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but I can't agree with this change as presented. By definition the total non-heap memory is the sum of all pools which identify as non-heap as per the specification:
> 
> "The non-heap memory consists of one or more memory pools. The used and committed size of the returned memory usage is the sum of those values of all non-heap memory pools ..."
> 
> so the existing code that sums the non-heap pools is correct. If you think `CompressedClassSpace` should not be counted then you need to argue for it to not be "non-heap".
> 
> Cheers, David

Hi David,

As far as APIs go, nobody wants to count ClassTypeSpace twice(`NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`) when using getNonHeapMemoryUsage. The documentation should be there to explain the API more clearly, rather than guiding how to implement the API. Digging into commit history, I found only CodeHeap was presented as NonHeap pool [originally](https://github.com/kelthuzadx/jdk/blob/ca3a1be3fe174f6e406a0f5f61a77d3d8d4ec4d7/hotspot/src/share/vm/services/memoryPool.cpp)

But yes, there is a slightly conflict between API doc and internal implementation. I think there are some possible changes:
1. Tweak API documentation and adopt patch. Clearly document on what NonHeap really is. e.g. it consists of CodeCache + Metaspace.
2. Remove CompressedClassSpacePool. As there is no explicit use for it.

Or some other candidates? Looking forward to your suggesstions.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From kevinw at openjdk.java.net  Mon May 23 11:46:43 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 23 May 2022 11:46:43 GMT
Subject: RFR: 8287103:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp
 [v2]
In-Reply-To: <xH8nLfHZdP3HMQImv2N3HN-EH5wCZZ6hI3JbnW8FTTY=.41b75b9b-6364-401a-ba50-bfbdc73532ac@github.com>
References: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>
 <xH8nLfHZdP3HMQImv2N3HN-EH5wCZZ6hI3JbnW8FTTY=.41b75b9b-6364-401a-ba50-bfbdc73532ac@github.com>
Message-ID: <L68iIesdTuvFuQGGfg2DsG9AfxOhFfuqkn1N3l-4h0k=.aa2b4966-22f1-4f25-ae84-c0ac58a897f2@github.com>

On Sat, 21 May 2022 16:34:32 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Sync improved in test
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Looks good!

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

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8821

From lmesnik at openjdk.java.net  Mon May 23 14:46:37 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 23 May 2022 14:46:37 GMT
Subject: RFR: 8285739: disable EscapeBarrier deopt for virtual threads [v2]
In-Reply-To: <J4V8tSx91FWL5Uqr_WRvf6kwmqjE5WjDP41-N_Cv0v8=.c19186b2-284b-4f54-8a9c-f9648e0ff9ba@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
 <LeiYYAPsun1cra0oNhkWfVQLxyuYl4ZnP4uCReoe85I=.ef179e30-aed9-431f-a31d-f0c441cc380e@github.com>
 <PG39H-_43j5dphQn6uGz9LSpNATgicbNEeAJ_NnS3EI=.d7201c7b-abd9-4d91-b951-e228af510a3a@github.com>
 <tWh_6z-9Ftg-XFAjv5HO_Y_M1ew4qiOXl2EFx5WKVHk=.9131f41a-bd8d-46c5-af86-9f0aa608ab8c@github.com>
 <J4V8tSx91FWL5Uqr_WRvf6kwmqjE5WjDP41-N_Cv0v8=.c19186b2-284b-4f54-8a9c-f9648e0ff9ba@github.com>
Message-ID: <hDlv9t76ljzjXtWoxbYzjsrSps-mhS6seEU94iUMiuQ=.31cc6c8e-c157-4940-980a-e93cd5426d2e@github.com>

On Mon, 23 May 2022 10:20:39 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Could it be that you mean [JDK-8264699](https://bugs.openjdk.java.net/browse/JDK-8264699)?
> 
Yes, you are right.
> I'm ok with this version of your fix. I'd suggest to change title/synopsis of the bug report to better match it though.

Thank you. I've renamed the summary

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From lmesnik at openjdk.java.net  Mon May 23 14:52:58 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 23 May 2022 14:52:58 GMT
Subject: Integrated: 8287103:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp
In-Reply-To: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>
References: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>
Message-ID: <TOfkuH2EQnb9Pi-AV4wrTMpQZQ8YjiD7rbLXe_hj7J4=.d515286f-80e6-4122-bc8a-254736c14847@github.com>

On Fri, 20 May 2022 22:27:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Sync improved in test

This pull request has now been integrated.

Changeset: 110d9064
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/110d906432761482acd2899be1314e075bc21bec
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8287103: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp

Reviewed-by: alanb, kevinw

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

PR: https://git.openjdk.java.net/jdk/pull/8821

From lmesnik at openjdk.java.net  Mon May 23 14:55:43 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 23 May 2022 14:55:43 GMT
Subject: Integrated: 8285739: disable EscapeBarrier deopt for virtual threads
In-Reply-To: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
References: <lOBW6vuGfhbXnfCEe60ALOFDURGD4rCyzgNnUFu60Xg=.87dc53f2-2390-4c4b-a100-836ff67a86b7@github.com>
Message-ID: <3VVI_adm7AMY5DpfsJMpt2pQvI8VxO6Roh6oSAphmMc=.36ec6726-8923-4b8e-b753-cc67b0896986@github.com>

On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview.
> 
> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled.

This pull request has now been integrated.

Changeset: 940e94f1
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/940e94f194e2abab8006e67dbb82cab5f16e3a17
Stats:     6 lines in 2 files changed: 5 ins; 0 del; 1 mod

8285739: disable EscapeBarrier deopt for virtual threads

Reviewed-by: kvn, rrich, sspitsyn

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

PR: https://git.openjdk.java.net/jdk/pull/8589

From cjplummer at openjdk.java.net  Mon May 23 16:47:55 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 23 May 2022 16:47:55 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v4]
In-Reply-To: <CFh2wNJBGZkkCoXKB_ytRD4PdbiKq2CvCeaabLzWJAE=.0c355a58-8a6e-4add-966e-9d84a6a94970@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <CFh2wNJBGZkkCoXKB_ytRD4PdbiKq2CvCeaabLzWJAE=.0c355a58-8a6e-4add-966e-9d84a6a94970@github.com>
Message-ID: <3Ky3GASdcXW3uBvgZwkQYA51p83Nuoi1Uv92z7_LVcw=.d6ac2ac8-439e-4999-b74c-15779cd61e2e@github.com>

On Mon, 23 May 2022 08:30:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change is mostly test infrastructure and improvements to the testing of thread dumps in JSON format. It also tweaks the thread dump format so that the process identifier and thread identifiers are a type string rather than number.
>> 
>> The tests for thread dumps added by JEP 425 are changed to use the test infrastructure library. The tests for JEP 428 will also make use of this test infrastructure.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use string rater than number for process/thread identifiers

test/lib/jdk/test/lib/threaddump/ThreadDump.java line 85:

> 83:  *         "threads": [...],
> 84:  *         "threadCount": "1"
> 85:  *       }

Why is there no longer a ',' here?

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From alanb at openjdk.java.net  Mon May 23 16:58:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 16:58:43 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v4]
In-Reply-To: <3Ky3GASdcXW3uBvgZwkQYA51p83Nuoi1Uv92z7_LVcw=.d6ac2ac8-439e-4999-b74c-15779cd61e2e@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <CFh2wNJBGZkkCoXKB_ytRD4PdbiKq2CvCeaabLzWJAE=.0c355a58-8a6e-4add-966e-9d84a6a94970@github.com>
 <3Ky3GASdcXW3uBvgZwkQYA51p83Nuoi1Uv92z7_LVcw=.d6ac2ac8-439e-4999-b74c-15779cd61e2e@github.com>
Message-ID: <PxVaX94kicCd7dLlts3ZCLSvTRWrntxZ_I-m-la-NgQ=.165b0ab3-5702-4400-b943-64d6e1ea4faf@github.com>

On Mon, 23 May 2022 16:44:12 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use string rater than number for process/thread identifiers
>
> test/lib/jdk/test/lib/threaddump/ThreadDump.java line 85:
> 
>> 83:  *         "threads": [...],
>> 84:  *         "threadCount": "1"
>> 85:  *       }
> 
> Why is there no longer a ',' here?

I had to collapse several objects and reduce the number of items in the arrays in order to get it down to an example that fits into the class description. To yes, all items except the last should have a trailing comma.

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From cjplummer at openjdk.java.net  Mon May 23 16:58:44 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 23 May 2022 16:58:44 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v3]
In-Reply-To: <ajs5TrUg9GqZonJ63Pb3QneADBuExasK6E38c5apUvU=.7ac04cda-bd93-4b04-83e4-4e9e6096950c@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <fQ1ZcUIhOWqFycYMy-kM5tlZ8h7E5HfFu4cRNTdz2co=.4285e6be-eecb-4ab6-971e-3804c618ccd3@github.com>
 <Ci5LX-DNFDnQ1jrIKlJiHnTyU93TFcZrJ1i0O0nIZa0=.b17553a2-934a-472b-a9b0-c516979ceb65@github.com>
 <ajs5TrUg9GqZonJ63Pb3QneADBuExasK6E38c5apUvU=.7ac04cda-bd93-4b04-83e4-4e9e6096950c@github.com>
Message-ID: <AEE73Ewd_79076geIgbp-KNYFFWnJoGmCbkoBY2KbJc=.19dbce4f-7afc-44c3-9c41-fa3ed12c584a@github.com>

On Mon, 23 May 2022 07:53:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/lib/jdk/test/lib/threaddump/ThreadDump.java line 179:
>> 
>>> 177:                 return this;
>>> 178:             if (name().startsWith(name + "/"))
>>> 179:                 return this;
>> 
>> It's not clear to me why this is here. What does it mean if the name of the container starts with `<name>/`?
>
> With the exception of the root container, the names have the form "name1/name2" where name1 is the "external name" and name2 identifies the internal thread grouping.  The external name is the object identity for thread pools and thread-per-executors created by user code. In time we may expose ways to provide a name.

Ok. That wasn't in the original example dump, but appears to be there now.

>> test/lib/jdk/test/lib/threaddump/ThreadDump.java line 299:
>> 
>>> 297: 
>>> 298:             // add to map if not already encountered
>>> 299:             var container = map.computeIfAbsent(name, k -> new ThreadContainer(name));
>> 
>> Why might the container already be in `map`?
>
> They aren't topologically sorted so it's possible to encounter a thread container before its parent.

ok

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From cjplummer at openjdk.java.net  Mon May 23 17:03:04 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 23 May 2022 17:03:04 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v3]
In-Reply-To: <ajs5TrUg9GqZonJ63Pb3QneADBuExasK6E38c5apUvU=.7ac04cda-bd93-4b04-83e4-4e9e6096950c@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <fQ1ZcUIhOWqFycYMy-kM5tlZ8h7E5HfFu4cRNTdz2co=.4285e6be-eecb-4ab6-971e-3804c618ccd3@github.com>
 <Ci5LX-DNFDnQ1jrIKlJiHnTyU93TFcZrJ1i0O0nIZa0=.b17553a2-934a-472b-a9b0-c516979ceb65@github.com>
 <ajs5TrUg9GqZonJ63Pb3QneADBuExasK6E38c5apUvU=.7ac04cda-bd93-4b04-83e4-4e9e6096950c@github.com>
Message-ID: <yIZj4FGjyZBcMcmnX5TF_HfDRoGfG-Fu67MfkklB-T0=.c64d99da-f832-45d3-a461-4c52ab0c967f@github.com>

On Mon, 23 May 2022 07:52:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java line 115:
>> 
>>> 113: 
>>> 114:                 // find the thread container that corresponds to the executor
>>> 115:                 String name = Objects.toIdentityString(executor);
>> 
>> I don't understand the need for `toIdentityString()` rather than just `toString()`
>
> The implementation lends on the string returned by Object::toString when not overridden. In this case, either will do so I can change it to toString.

Yeah, the fact that it's known not to be overridden makes it confusing that toIdentityString() is used. But if you feel this helps better document what the dumping implementation uses, it might be better to use toIdentityString(). It makes for accurate example code in that case. Either is ok (or maybe just a useful comment)

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From chris.plummer at oracle.com  Mon May 23 17:07:40 2022
From: chris.plummer at oracle.com (Chris Plummer)
Date: Mon, 23 May 2022 10:07:40 -0700
Subject: Concurrent heap monitoring
In-Reply-To: <CA+3eh10=hF7HpnED9nTsRZ+_UiVCnEJvm65qT5wFBa03DgpoKg@mail.gmail.com>
References: <1653083191904.40109@amazon.com>
 <CA+3eh10=hF7HpnED9nTsRZ+_UiVCnEJvm65qT5wFBa03DgpoKg@mail.gmail.com>
Message-ID: <d69b43ed-1c51-05cb-c48c-837fb381ebab@oracle.com>

Adding hotspot-gc-dev.

On 5/21/22 12:49 AM, Volker Simonis wrote:
> This sounds very interesting. Does this feature work with every GC or? 
> does the implementation depend on specific GCs (and if the latter, 
> which GCs does your prototype currently support).
>
> Kemper, William <kemperw at amazon.com> schrieb am Fr., 20. Mai 2022, 23:46:
>
>     Taking a heap dump is a stop the world event. Garbage collection
>     events can provide heap utilization information only after a cycle
>     completes. We've found that detailed heap occupancy data (such as
>     heap inspections provide) are too expensive to use for production
>     monitoring.? Similarly, we find that heap statistics generated
>     from collection cycles?may come too late and may not provide
>     enough detail (young collections do not reflect the state of the
>     old generation). We have developed a /prototype/ feature to
>     provide detailed heap metrics /concurrently//, without barriers./
>     It therefore provides only an estimate as changes to the object
>     graph may cause it to miss objects. We would like to hear the
>     thoughts of serviceability experts on such a thing. It is only at
>     the proof of concept phase, but it is able to run popular
>     benchmarks (specjbb, dacapo) with minimal overhead and the
>     estimates are sufficiently accurate for our use cases (monitoring
>     heap and object?growth rates).
>
>
>     Thank you for reading,
>
>     William
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20220523/11c06d23/attachment-0001.htm>

From alanb at openjdk.java.net  Mon May 23 18:37:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 18:37:49 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options [v2]
In-Reply-To: <hFYsIjH1sDsXzyG0GEQ7YIsVB3opUPeeWXPvS6AOtwI=.e4ab1a8b-a5a3-469b-ba23-14565343ea2a@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
 <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>
 <XccKZlWUIQS6BolQEAwRHs6_P_dlCNHvyPHKTrQDfXA=.b84273c7-fb3d-4aaf-8d21-be1b4657b6a7@github.com>
 <hFYsIjH1sDsXzyG0GEQ7YIsVB3opUPeeWXPvS6AOtwI=.e4ab1a8b-a5a3-469b-ba23-14565343ea2a@github.com>
Message-ID: <5ZvGivHbAqBQ1Swni92NKMFCePP6b_BiwSLuk2O7SL4=.e1783148-7eae-43d6-91c8-becba8446285@github.com>

On Mon, 23 May 2022 02:52:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I was really trying to emphasize that the flag is preview, and therefore may change or go away.  If I change as  you suggest, the reader could imply that as long as virtual threads support is in place, then the flag will be also (and in its current form).
>
> I agree with @plummercj , this is documenting that the flag is itself a "preview feature" and thus subject to change.

I don't think it is correct to say that this command line option is a preview feature. Maybe it can be clarified on a second line, something like:


-trackvthreads    track virtual threads as they are created
                             Virtual threads are a preview API.

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From sgehwolf at openjdk.java.net  Mon May 23 19:13:58 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 23 May 2022 19:13:58 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <KPDr-0LR7sXWsSUW5w_0Qbuh-MXaddpNBO6s5Lsd8_U=.80b1eb53-c1f9-4e8a-8ac7-7f8b092008cc@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
 <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>
 <bPoDNxABi63JebXkYflJ3FUR0IF8OieXLmwkwjIxmk8=.1651330e-59af-4f56-932e-08d37626dfe9@github.com>
 <fRitJVBN5BS8dbJ0VvMDkFZ65xpDJvhd5KlCKk5DhMI=.ca576f15-5b74-48d3-b46a-1432780ad016@github.com>
 <KPDr-0LR7sXWsSUW5w_0Qbuh-MXaddpNBO6s5Lsd8_U=.80b1eb53-c1f9-4e8a-8ac7-7f8b092008cc@github.com>
Message-ID: <3kqALUtVpso2x-3Pv41cTPRvjpXI7_88yFPfj-xmRNg=.143ff56d-ad5a-4ffb-8649-03f9447a9248@github.com>

On Mon, 23 May 2022 09:24:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Also, I think the current PR could produce the wrong answer, if systemd is indeed running inside the container, and we have:
>> 
>> 
>> "/user.slice/user-1000.slice/session-50.scope",    // root_path
>> "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>> 
>> 
>> The PR gives /sys/fs/cgroup/memory/user.slice/user-1000.slice/, which specifies the overall memory limit for user-1000. However, the correct answer may be /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-3.scope, which may have a smaller memory limit, and the JVM may end up allocating a larger heap than allowed.
>
> Yes, if we can decide which one the right file is. This is largely undocumented territory. The correct fix is a) find the correct path to the namespace hierarchy the process is a part of. b) starting at the leaf node, walk up the hierarchy and find the **lowest** limits. Doing this would be very expensive!
> 
> Aside: Current container detection in the JVM/JDK is notoriously imprecise. It's largely based on common setups (containers like docker). The heuristics assume that memory limits are reported inside the container at the leaf node. If, however, that's not the case, the detected limits will be wrong (it will detect it as unlimited, even though it's - for example - memory constrained at the parent). This can for example be reproduced on a cgroups v2 system with a systemd slice using memory limits. We've worked-around this in OpenJDK for cgroups v1 by https://bugs.openjdk.java.net/browse/JDK-8217338

> Maybe we should do this instead?
> 
>     * Read /proc/self/cgroup
> 
>     * Find the `10:memory:<path>` line
> 
>     * If `/sys/fs/cgroup/memory/<path>/tasks` contains my PID, this is the path
> 
>     * Otherwise, scan all `tasks` files under  `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID.

Something like that seems most promising, but it would have to be `cgroup.procs` not `tasks` as `tasks` is the task id (i.e. Linux's thread), not the process. We could keep the two common cases as short circuiting. I.e. host and docker cases in the test.

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

PR: https://git.openjdk.java.net/jdk/pull/8629

From alanb at openjdk.java.net  Mon May 23 19:33:31 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 19:33:31 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v5]
In-Reply-To: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
Message-ID: <dPineBJF9ADAcfA6gc_-CRLxIuzMpAoEn3I8PptXb9g=.fa0c346a-b2f4-4de7-b2f0-e5eb8cc77430@github.com>

> This change is mostly test infrastructure and improvements to the testing of thread dumps in JSON format. It also tweaks the thread dump format so that the process identifier and thread identifiers are a type string rather than number.
> 
> The tests for thread dumps added by JEP 425 are changed to use the test infrastructure library. The tests for JEP 428 will also make use of this test infrastructure.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8784/files
  - new: https://git.openjdk.java.net/jdk/pull/8784/files/353fc53d..7e0c1513

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8784&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8784&range=03-04

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8784.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8784/head:pull/8784

PR: https://git.openjdk.java.net/jdk/pull/8784

From aivanov at openjdk.java.net  Mon May 23 20:06:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 May 2022 20:06:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v3]
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <3E93xe0v68L9AHsT3c5D58_5OdaSDEGtdg5ih7TTkfk=.45bed80f-be56-49e8-9dfb-a7fa70b9ea23@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright to 2022

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01-02

  Stats: 102 lines in 102 files changed: 0 ins; 0 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Mon May 23 20:46:23 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 May 2022 20:46:23 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
 [v2]
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <6pmdug3Hpy1LPgcb-OIdMP6XuOWpWYngOju7mFPdDV4=.a68d1c15-58a3-4ffa-b94d-a1a14666f9eb@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge master
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'an? an?' in source code
 - 8284209: Replace remaining usages of 'a the' in source code
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/5b7d066c...fab0a4bb

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

Changes: https://git.openjdk.java.net/jdk/pull/8771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01
  Stats: 50 lines in 40 files changed: 0 ins; 2 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From cjplummer at openjdk.java.net  Mon May 23 22:21:56 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 23 May 2022 22:21:56 GMT
Subject: RFR: 8287008: Improve tests for thread dumps in JSON format [v5]
In-Reply-To: <dPineBJF9ADAcfA6gc_-CRLxIuzMpAoEn3I8PptXb9g=.fa0c346a-b2f4-4de7-b2f0-e5eb8cc77430@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
 <dPineBJF9ADAcfA6gc_-CRLxIuzMpAoEn3I8PptXb9g=.fa0c346a-b2f4-4de7-b2f0-e5eb8cc77430@github.com>
Message-ID: <xeUSuamWyD-fobHUVYByzdaZRA6tYdUhkL4WDko2_Aw=.c35244f4-c7c0-4c75-9a17-b2722746ae7e@github.com>

On Mon, 23 May 2022 19:33:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change is mostly test infrastructure and improvements to the testing of thread dumps in JSON format. It also tweaks the thread dump format so that the process identifier and thread identifiers are a type string rather than number.
>> 
>> The tests for thread dumps added by JEP 425 are changed to use the test infrastructure library. The tests for JEP 428 will also make use of this test infrastructure.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From sspitsyn at openjdk.java.net  Tue May 24 05:52:25 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 05:52:25 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect
Message-ID: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>

It was a typo when the original CLEARING_MASK was initially introduced:


 // Mask to clear normal event bits.
  const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
  // Avoid cleaning extension event bits.
  jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();

``` 

The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
`  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`

Let me provide some background to understand how this mask is used.

Normal JVMTI event types are numbered from 50 to 88. There are two constants:

  JVMTI_MIN_EVENT_TYPE_VAL = 50
  JVMTI_MAX_EVENT_TYPE_VAL = 88

The extension event types are numbered from 47 to 49. There are also two constants:

  EXT_MIN_EVENT_TYPE_VAL = 47
  EXT_MAX_EVENT_TYPE_VAL = 49


There are also two additional constants:

  TOTAL_MIN_EVENT_TYPE_VAL = 47
  TOTAL_MAX_EVENT_TYPE_VAL = 88


The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.

Testing:
I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

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

Commit messages:
 - 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From alanb at openjdk.java.net  Tue May 24 06:24:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 06:24:47 GMT
Subject: Integrated: 8287008: Improve tests for thread dumps in JSON format
In-Reply-To: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
References: <bd5AmTY9Q1dKcHGm6mqIDW_-FdQ2rkh6xD57CWRsuhI=.8950c2d2-5462-4121-8808-5bdb4d8cb601@github.com>
Message-ID: <4FsOV9XWZUEE6e3O2KdDWnfeZ_40Am294fip2fmc1Cg=.d48746de-be13-48d4-9dd8-0408498bc3e5@github.com>

On Thu, 19 May 2022 09:38:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change is mostly test infrastructure and improvements to the testing of thread dumps in JSON format. It also tweaks the thread dump format so that the process identifier and thread identifiers are a type string rather than number.
> 
> The tests for thread dumps added by JEP 425 are changed to use the test infrastructure library. The tests for JEP 428 will also make use of this test infrastructure.

This pull request has now been integrated.

Changeset: 15f15830
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/15f15830f00895c046c08b55dfeb1618700a2c10
Stats:     431 lines in 4 files changed: 399 ins; 10 del; 22 mod

8287008: Improve tests for thread dumps in JSON format

Reviewed-by: cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/8784

From jbachorik at openjdk.java.net  Tue May 24 07:22:56 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Tue, 24 May 2022 07:22:56 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <U_rq9nqqE9kcKNQXtrMI4aF1wAkrji-t0TRegp7LXnU=.7b53900f-c4de-45e5-b5ba-1c5765c63837@github.com>

On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

Good catch! LGTM!

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

Marked as reviewed by jbachorik (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8860

From aivanov at openjdk.java.net  Tue May 24 09:52:29 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 09:52:29 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
 [v3]
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <yDxT1sZCfM9b18MbUqSFDeyieqOfB5aBWMLKNxZEeYg=.8278ad27-ca58-4bf7-a236-d79604a6bff9@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright to 2022

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8771/files
  - new: https://git.openjdk.java.net/jdk/pull/8771/files/fab0a4bb..4d529f79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01-02

  Stats: 24 lines in 24 files changed: 0 ins; 0 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From lancea at openjdk.java.net  Tue May 24 09:58:42 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 24 May 2022 09:58:42 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
 [v3]
In-Reply-To: <yDxT1sZCfM9b18MbUqSFDeyieqOfB5aBWMLKNxZEeYg=.8278ad27-ca58-4bf7-a236-d79604a6bff9@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
 <yDxT1sZCfM9b18MbUqSFDeyieqOfB5aBWMLKNxZEeYg=.8278ad27-ca58-4bf7-a236-d79604a6bff9@github.com>
Message-ID: <orVtBes_pss1zNktMdUeKjQeZmAHhREnRo2NXmb4Ip0=.deb262e2-aa59-4235-9308-4232698603d2@github.com>

On Tue, 24 May 2022 09:52:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> It's the last issue in the series, and it still touches different areas of the code.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright to 2022

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8771

From aivanov at openjdk.java.net  Tue May 24 11:28:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 11:28:50 GMT
Subject: Integrated: 8284191: Replace usages of 'a the' in hotspot and
 java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ZIBUrN38HimpUwfEYc-LwYC3gXjfDXNaD55bHE9PU2M=.87e99c4b-c1a3-47d4-9323-421efb88ed06@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

This pull request has now been integrated.

Changeset: e0d361ce
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e0d361cea91d3dd1450aece73f660b4abb7ce5fa
Stats:     303 lines in 162 files changed: 0 ins; 11 del; 292 mod

8284191: Replace usages of 'a the' in hotspot and java.base

Reviewed-by: lancea, wetmore, naoto, iris, kevinw, xuelei

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

PR: https://git.openjdk.java.net/jdk/pull/8768

From sspitsyn at openjdk.java.net  Tue May 24 17:01:54 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 17:01:54 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <jBrpMzMFnJWYtuOb4BPc5z5xUu_FCLVnE88uDAuNWWw=.8cb5b0d4-9741-4d77-8662-f881e5b38264@github.com>

On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

Thank you for review, Jaroslav!

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From ihse at openjdk.java.net  Tue May 24 17:18:46 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 24 May 2022 17:18:46 GMT
Subject: RFR: 8287254: Clean up Xcode sysroot logic
Message-ID: <1FTVA5oSUiWmtyRzeWHuGVoobQEHL74I7mUpqKG8yfE=.4c11c8cc-f952-4932-a571-dfd60e15f58f@github.com>

The logic in BASIC_SETUP_DEVKIT for setting a correct sysroot for Xcode is hard to follow. This should be straightened out. We also expose variables that are no longer used. So there's a bit of related cleanup. 

The new code is more or less functionally equivalent to the old. There were some corner cases which the old code did not handle well; this has now been improved. I've also added yet another method of trying to get the SDK root before falling back to the system library, by using `xcrun --show-sdk-path`.

In an ideal world, the sysroot flags to `mig` should be set in configure, e.g. as `MIG_FLAGS` or `MIG_SYSROOT_FLAGS`. I can't be bothered to do that for a single call to `mig`, though.

As always, changes like this that depend on the environment is tricky to test. I've tried running it on a couple of different macs, with and without a devkit.

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

Commit messages:
 - Make Xcode SDK locating more robust
 - * Clean up BASIC_SETUP_XCODE_SYSROOT
 - Don't export SDKROOT
 - Move sdk setup to BASIC_SETUP_XCODE_SYSROOT

Changes: https://git.openjdk.java.net/jdk/pull/8872/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8872&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287254
  Stats: 200 lines in 4 files changed: 91 ins; 98 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8872/head:pull/8872

PR: https://git.openjdk.java.net/jdk/pull/8872

From cjplummer at openjdk.java.net  Tue May 24 19:25:56 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 24 May 2022 19:25:56 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <fkrziqGvub6UZc2IfiM8mfb0DifYvaia2k4bug2WW64=.c074fb15-ecaa-41b9-8f40-5110a06430eb@github.com>

On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

Is there a reason no tests are failing as a result of this? It's unclear how this bug is exposed to JVMTI clients.

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From cjplummer at openjdk.java.net  Tue May 24 19:39:49 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 24 May 2022 19:39:49 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options [v2]
In-Reply-To: <5ZvGivHbAqBQ1Swni92NKMFCePP6b_BiwSLuk2O7SL4=.e1783148-7eae-43d6-91c8-becba8446285@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
 <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>
 <XccKZlWUIQS6BolQEAwRHs6_P_dlCNHvyPHKTrQDfXA=.b84273c7-fb3d-4aaf-8d21-be1b4657b6a7@github.com>
 <hFYsIjH1sDsXzyG0GEQ7YIsVB3opUPeeWXPvS6AOtwI=.e4ab1a8b-a5a3-469b-ba23-14565343ea2a@github.com>
 <5ZvGivHbAqBQ1Swni92NKMFCePP6b_BiwSLuk2O7SL4=.e1783148-7eae-43d6-91c8-becba8446285@github.com>
Message-ID: <Aizyv-1jRWysfCZJWCuj7doc9tijClUtg9XYv_8ZYgQ=.9ffc19ba-aba6-4749-afcc-b559c43e78ef@github.com>

On Mon, 23 May 2022 18:34:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I agree with @plummercj , this is documenting that the flag is itself a "preview feature" and thus subject to change.
>
> I don't think it is correct to say that this command line option is a preview feature. Maybe it can be clarified on a second line:
> 
> 
> -trackvthreads    track virtual threads as they are created
>                              Virtual threads are a preview feature of the Java platform.

Does that imply that `-trackvthreads` can be changed or removed?

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From cjplummer at openjdk.java.net  Tue May 24 19:44:50 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 24 May 2022 19:44:50 GMT
Subject: RFR: 8286711: AArch64: serviceability agent tests fail with PAC
 enabled
In-Reply-To: <HrusXjkc89qs4KckW40XWqMBFc1XlfmPt6aNhPxn3Vk=.dbd3dadb-27c9-46fc-a065-0c13fdea2bfc@github.com>
References: <HrusXjkc89qs4KckW40XWqMBFc1XlfmPt6aNhPxn3Vk=.dbd3dadb-27c9-46fc-a065-0c13fdea2bfc@github.com>
Message-ID: <ydWTcIvIUpoMmi5dXDHM7H8Zb9HBMPYc6_klTz0VISs=.4b3cfa6a-8b8c-4432-b0b8-da775ad65f1a@github.com>

On Fri, 20 May 2022 15:52:04 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU, the upper bits of the saved link register contain a "pointer authentication code" which must be checked and removed by a special instruction before a function returns.  The serviceability agent is unaware of this and so sees garbled PC values when walking the stack. This patch just masks out the PAC bits from the sender PC after reading it from the stack frame.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8814

From erikj at openjdk.java.net  Tue May 24 19:49:54 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 24 May 2022 19:49:54 GMT
Subject: RFR: 8287254: Clean up Xcode sysroot logic
In-Reply-To: <1FTVA5oSUiWmtyRzeWHuGVoobQEHL74I7mUpqKG8yfE=.4c11c8cc-f952-4932-a571-dfd60e15f58f@github.com>
References: <1FTVA5oSUiWmtyRzeWHuGVoobQEHL74I7mUpqKG8yfE=.4c11c8cc-f952-4932-a571-dfd60e15f58f@github.com>
Message-ID: <Ox8q_lONn8aYEVOpas04QQtyrtHdnGiNs5V3EFk4Elc=.c8263aca-32ca-4153-b949-99f8d7661b8b@github.com>

On Tue, 24 May 2022 17:09:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The logic in BASIC_SETUP_DEVKIT for setting a correct sysroot for Xcode is hard to follow. This should be straightened out. We also expose variables that are no longer used. So there's a bit of related cleanup. 
> 
> The new code is more or less functionally equivalent to the old. There were some corner cases which the old code did not handle well; this has now been improved. I've also added yet another method of trying to get the SDK root before falling back to the system library, by using `xcrun --show-sdk-path`.
> 
> In an ideal world, the sysroot flags to `mig` should be set in configure, e.g. as `MIG_FLAGS` or `MIG_SYSROOT_FLAGS`. I can't be bothered to do that for a single call to `mig`, though.
> 
> As always, changes like this that depend on the environment is tricky to test. I've tried running it on a couple of different macs, with and without a devkit.

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8872

From lmesnik at openjdk.java.net  Tue May 24 20:00:26 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 24 May 2022 20:00:26 GMT
Subject: RFR: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103
Message-ID: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>

Need to use proper synchronization.

The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So it should not confuse existing checks.

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

Commit messages:
 - 8287200

Changes: https://git.openjdk.java.net/jdk/pull/8874/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8874&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287200
  Stats: 9 lines in 1 file changed: 4 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8874.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8874/head:pull/8874

PR: https://git.openjdk.java.net/jdk/pull/8874

From aivanov at openjdk.java.net  Tue May 24 20:12:09 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 20:12:09 GMT
Subject: Integrated: 8284209: Replace remaining usages of 'a the' in source
 code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <JXgQy5enWm0flv2yyi6KK36WsHpPuZHj8uhkz_P13H0=.b9d1bc0a-ad41-416a-ab60-22c8271b9413@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

This pull request has now been integrated.

Changeset: 9b7e42c0
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9b7e42c0f078db778dda1011d85cd92e3e4eb979
Stats:     74 lines in 40 files changed: 0 ins; 2 del; 72 mod

8284209: Replace remaining usages of 'a the' in source code

Reviewed-by: lancea, wetmore, dfuchs, iris, jjg, ihse

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

PR: https://git.openjdk.java.net/jdk/pull/8771

From kevinw at openjdk.java.net  Tue May 24 20:35:57 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 24 May 2022 20:35:57 GMT
Subject: RFR: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103
In-Reply-To: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
References: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
Message-ID: <DUWJy1c0Aygp4xQJcSz7VPRyGaGbZ3D3xutUwshxzb4=.1f8f9fe1-e11c-4cf4-ab13-b3fed804a06b@github.com>

On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Need to use proper synchronization.
> 
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So it should not confuse existing checks.

Yes I think that's nice - the two competing Threads own their first lock and wait until the other thread has owned its first lock, before continuing. 8-)

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

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8874

From sspitsyn at openjdk.java.net  Tue May 24 20:43:02 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 20:43:02 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <UMvUGZcz3kaJETRtCYtN733t9S_TrCG9NJfdtdsTpnQ=.141e0cb8-5b90-458f-b260-ef67ff627f82@github.com>

On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

The extension events are not much used in the tests. There was only one extension event inn pre-jdk19 which is ClassUnload. This event was implemented to prove the event extension mechanism is working but it is is not really used anywhere except in our testing.
Two new extension events were introduced to support testing of virtual threads:
- VirtualThreadMount
- VirtualThreadUnmount

This particular issue depends on the order the extension events and normal JVMTI events are enabled.

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From cjplummer at openjdk.java.net  Tue May 24 20:46:58 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 24 May 2022 20:46:58 GMT
Subject: RFR: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103
In-Reply-To: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
References: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
Message-ID: <WJKp13v3QpvLpEpRxqzMziFTfOpI4mmWYqNF99KSsYQ=.6c00022b-b26c-4176-b0c5-07649e1e6da0@github.com>

On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Need to use proper synchronization.
> 
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So it should not confuse existing checks.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8874

From cjplummer at openjdk.java.net  Tue May 24 20:48:58 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 24 May 2022 20:48:58 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <RW1cEeQyRGA8SpJ9chEu1Muo-Jcs8csjbY7HKoLOQKM=.94301202-edbb-4117-991e-61c7ff1adde5@github.com>

On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

What would it take to write a test that fails due to this bug?

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Tue May 24 20:59:55 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 20:59:55 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <Yge94wT3kHRHPclKiKSTelRw3mxcliEOtl25YQNESKc=.ab5b3522-84a8-4aae-bc96-d08493667d07@github.com>

On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

One (I do not remember what was the exact test) of the new serviceability/jvmti/vthread tests was failing initially. It was a motivation to add this `CLEARING_MASK`. I'm puzzled why it did not fail because of this typo. Will try to find out. I doubt that it was problem-listed because I normally run all the serviceability/jvmti/vthread tests in the repo-loom.

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From lmesnik at openjdk.java.net  Tue May 24 21:37:56 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 24 May 2022 21:37:56 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <ZpdnlQ68DA6NeOQ1wrpq5F18paMdFFNlRja4Sr20ohc=.ced057c0-db5f-4b50-a02b-4fa3fda1e1e3@github.com>

On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

Marked as reviewed by lmesnik (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Tue May 24 21:47:54 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 21:47:54 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v2]
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

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

  add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8860/files
  - new: https://git.openjdk.java.net/jdk/pull/8860/files/d77b8dcb..6361d85b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=00-01

  Stats: 35 lines in 2 files changed: 31 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8860.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8860/head:pull/8860

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Tue May 24 21:52:57 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 21:52:57 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect
In-Reply-To: <RW1cEeQyRGA8SpJ9chEu1Muo-Jcs8csjbY7HKoLOQKM=.94301202-edbb-4117-991e-61c7ff1adde5@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <RW1cEeQyRGA8SpJ9chEu1Muo-Jcs8csjbY7HKoLOQKM=.94301202-edbb-4117-991e-61c7ff1adde5@github.com>
Message-ID: <C4oQ2YY8FX6-jECxRIsBwO2MfcuPoMWvRnO9aFh28Bc=.7b5274e1-51b1-4235-ba28-188d4b20683f@github.com>

On Tue, 24 May 2022 20:45:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It was a typo when the original CLEARING_MASK was initially introduced:
>> 
>> 
>>  // Mask to clear normal event bits.
>>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>>   // Avoid cleaning extension event bits.
>>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
>> 
>> ``` 
>> 
>> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
>> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
>> 
>> Let me provide some background to understand how this mask is used.
>> 
>> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
>> 
>>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>>   JVMTI_MAX_EVENT_TYPE_VAL = 88
>> 
>> The extension event types are numbered from 47 to 49. There are also two constants:
>> 
>>   EXT_MIN_EVENT_TYPE_VAL = 47
>>   EXT_MAX_EVENT_TYPE_VAL = 49
>> 
>> 
>> There are also two additional constants:
>> 
>>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>>   TOTAL_MAX_EVENT_TYPE_VAL = 88
>> 
>> 
>> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
>> 
>> Testing:
>> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.
>
> What would it take to write a test that fails due to this bug?

@plummercj
I've updated the serviceability/jvmti/vthreadVThreadTest to provide test coverage for this issue.
The updated test is failed without this fix and is passed with it.

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Tue May 24 21:53:00 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 21:53:00 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v2]
In-Reply-To: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
Message-ID: <M3WWTGhtsEQxAmW3BWFbuNK8VA72CwcqR0-_qdZPegU=.9e77705c-3e2a-447f-bf5a-5112954f87bf@github.com>

On Tue, 24 May 2022 21:47:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was a typo when the original CLEARING_MASK was initially introduced:
>> 
>> 
>>  // Mask to clear normal event bits.
>>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>>   // Avoid cleaning extension event bits.
>>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
>> 
>> ``` 
>> 
>> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
>> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
>> 
>> Let me provide some background to understand how this mask is used.
>> 
>> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
>> 
>>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>>   JVMTI_MAX_EVENT_TYPE_VAL = 88
>> 
>> The extension event types are numbered from 47 to 49. There are also two constants:
>> 
>>   EXT_MIN_EVENT_TYPE_VAL = 47
>>   EXT_MAX_EVENT_TYPE_VAL = 49
>> 
>> 
>> There are also two additional constants:
>> 
>>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>>   TOTAL_MAX_EVENT_TYPE_VAL = 88
>> 
>> 
>> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
>> 
>> Testing:
>> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount

Leonid, thank you for review!

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From cjplummer at openjdk.java.net  Tue May 24 22:04:03 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 24 May 2022 22:04:03 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v2]
In-Reply-To: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
Message-ID: <vBcjJVoq4qdlwoWByxK5gsHvEuyjayWxiSh6Ptc7lZE=.4fad053d-718a-42c3-a775-4200b594b820@github.com>

On Tue, 24 May 2022 21:47:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was a typo when the original CLEARING_MASK was initially introduced:
>> 
>> 
>>  // Mask to clear normal event bits.
>>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>>   // Avoid cleaning extension event bits.
>>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
>> 
>> ``` 
>> 
>> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
>> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
>> 
>> Let me provide some background to understand how this mask is used.
>> 
>> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
>> 
>>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>>   JVMTI_MAX_EVENT_TYPE_VAL = 88
>> 
>> The extension event types are numbered from 47 to 49. There are also two constants:
>> 
>>   EXT_MIN_EVENT_TYPE_VAL = 47
>>   EXT_MAX_EVENT_TYPE_VAL = 49
>> 
>> 
>> There are also two additional constants:
>> 
>>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>>   TOTAL_MAX_EVENT_TYPE_VAL = 88
>> 
>> 
>> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
>> 
>> Testing:
>> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount

test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/libVThreadTest.cpp line 625:

> 623:   }
> 624: 
> 625:   err = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VIRTUAL_THREAD_END, NULL);

Why does the ordering matter for these 4 SetEventNotificationMode() calls?

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From amenkov at openjdk.java.net  Tue May 24 22:26:01 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 24 May 2022 22:26:01 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v2]
In-Reply-To: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
Message-ID: <TSrJv3YUFHQXKE0ifxOaT1Rz6jzjf1YSft8jmyhvRjs=.e0c4bb06-216d-4ddf-8920-c481212cfa07@github.com>

On Tue, 24 May 2022 21:47:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was a typo when the original CLEARING_MASK was initially introduced:
>> 
>> 
>>  // Mask to clear normal event bits.
>>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>>   // Avoid cleaning extension event bits.
>>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
>> 
>> ``` 
>> 
>> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
>> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
>> 
>> Let me provide some background to understand how this mask is used.
>> 
>> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
>> 
>>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>>   JVMTI_MAX_EVENT_TYPE_VAL = 88
>> 
>> The extension event types are numbered from 47 to 49. There are also two constants:
>> 
>>   EXT_MIN_EVENT_TYPE_VAL = 47
>>   EXT_MAX_EVENT_TYPE_VAL = 49
>> 
>> 
>> There are also two additional constants:
>> 
>>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>>   TOTAL_MAX_EVENT_TYPE_VAL = 88
>> 
>> 
>> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
>> 
>> Testing:
>> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount

src/hotspot/share/prims/jvmtiEventController.cpp line 775:

> 773:   env->set_event_callbacks(callbacks, size_of_callbacks);
> 774:   // Mask to clear normal event bits.
> 775:   const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;

I don't follow how this works..
Should it be "<<" instead of ">>" ?

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From amenkov at openjdk.java.net  Tue May 24 22:34:54 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 24 May 2022 22:34:54 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v2]
In-Reply-To: <TSrJv3YUFHQXKE0ifxOaT1Rz6jzjf1YSft8jmyhvRjs=.e0c4bb06-216d-4ddf-8920-c481212cfa07@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
 <TSrJv3YUFHQXKE0ifxOaT1Rz6jzjf1YSft8jmyhvRjs=.e0c4bb06-216d-4ddf-8920-c481212cfa07@github.com>
Message-ID: <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com>

On Tue, 24 May 2022 22:23:59 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount
>
> src/hotspot/share/prims/jvmtiEventController.cpp line 775:
> 
>> 773:   env->set_event_callbacks(callbacks, size_of_callbacks);
>> 774:   // Mask to clear normal event bits.
>> 775:   const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
> 
> I don't follow how this works..
> Should it be "<<" instead of ">>" ?

Maybe it would be clearer to turn off the bits when there are no events:

  jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits();
  for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) {
      jvmtiEvent evt_t = (jvmtiEvent)ei;
      if (!env->has_callback(evt_t)) {
          // clear the bit if there is no callback
          enabled_bits &= ~JvmtiEventEnabled::bit_for(evt_t);
      }
  }

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Tue May 24 23:00:56 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 23:00:56 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v2]
In-Reply-To: <vBcjJVoq4qdlwoWByxK5gsHvEuyjayWxiSh6Ptc7lZE=.4fad053d-718a-42c3-a775-4200b594b820@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
 <vBcjJVoq4qdlwoWByxK5gsHvEuyjayWxiSh6Ptc7lZE=.4fad053d-718a-42c3-a775-4200b594b820@github.com>
Message-ID: <fqQPjhGl5ldiyzKLl5dz5jVTJNn8w68SL8DgBDOfGtQ=.5ddc91e8-4df3-499f-a84a-8971d229b3ac@github.com>

On Tue, 24 May 2022 22:00:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/libVThreadTest.cpp line 625:
> 
>> 623:   }
>> 624: 
>> 625:   err = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VIRTUAL_THREAD_END, NULL);
> 
> Why does the ordering matter for these 4 SetEventNotificationMode() calls?

You are right. This order does not matter.
What matters is the order of calls to SetExtensionEventCallback and SetEventCallbacks.
It is important to call SetExtensionEventCallback first in order to reproduce the issue.

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Tue May 24 23:05:41 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 23:05:41 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v3]
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <gjwl5-QcDx_VMFnpCwG92RxzXbaG-veemF5Mi06aYJc=.c68c3ef9-54c1-4e01-821f-ce77fb8a5906@github.com>

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

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

  roll back changes that are not needed to reproduce JVMTI problem with CLEARING_MASK

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8860/files
  - new: https://git.openjdk.java.net/jdk/pull/8860/files/6361d85b..f4ec32ef

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Tue May 24 23:34:53 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 23:34:53 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v2]
In-Reply-To: <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
 <TSrJv3YUFHQXKE0ifxOaT1Rz6jzjf1YSft8jmyhvRjs=.e0c4bb06-216d-4ddf-8920-c481212cfa07@github.com>
 <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com>
Message-ID: <eY6jowgocN1a2TpbZnxdjGy5og6auY_k0wVZebMltrE=.e20fd140-c28a-4d1c-aec4-de3d93d84ac6@github.com>

On Tue, 24 May 2022 22:31:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEventController.cpp line 775:
>> 
>>> 773:   env->set_event_callbacks(callbacks, size_of_callbacks);
>>> 774:   // Mask to clear normal event bits.
>>> 775:   const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>> 
>> I don't follow how this works..
>> Should it be "<<" instead of ">>" ?
>
> Maybe it would be clearer to turn off the bits when there are no events:
> 
>   jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits();
>   for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) {
>       jvmtiEvent evt_t = (jvmtiEvent)ei;
>       if (!env->has_callback(evt_t)) {
>           // clear the bit if there is no callback
>           enabled_bits &= ~JvmtiEventEnabled::bit_for(evt_t);
>       }
>   }

Thanks, Alex! You are right - fixed.
I was stupid enough to confuse the direction. Minimal tracing helps in such cases.

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Tue May 24 23:39:56 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 23:39:56 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v4]
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <4cfAXWCngz4N3LTF-rDkfhmPAU8DH9m9_fV2KY6nC9k=.79e1fc47-764d-4306-b3eb-5a09359759a9@github.com>

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

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

  replaced right shift with left shift in CLEARING_MASK setting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8860/files
  - new: https://git.openjdk.java.net/jdk/pull/8860/files/f4ec32ef..0c80ef4a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Tue May 24 23:52:01 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 May 2022 23:52:01 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v2]
In-Reply-To: <eY6jowgocN1a2TpbZnxdjGy5og6auY_k0wVZebMltrE=.e20fd140-c28a-4d1c-aec4-de3d93d84ac6@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
 <TSrJv3YUFHQXKE0ifxOaT1Rz6jzjf1YSft8jmyhvRjs=.e0c4bb06-216d-4ddf-8920-c481212cfa07@github.com>
 <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com>
 <eY6jowgocN1a2TpbZnxdjGy5og6auY_k0wVZebMltrE=.e20fd140-c28a-4d1c-aec4-de3d93d84ac6@github.com>
Message-ID: <qqej3NCRshcSQ67TGEAX48abINyhiNw8pm7he22pUxY=.13231834-dd71-453b-acf7-82aeab31def4@github.com>

On Tue, 24 May 2022 23:31:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Maybe it would be clearer to turn off the bits when there are no events:
>> 
>>   jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits();
>>   for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) {
>>       jvmtiEvent evt_t = (jvmtiEvent)ei;
>>       if (!env->has_callback(evt_t)) {
>>           // clear the bit if there is no callback
>>           enabled_bits &= ~JvmtiEventEnabled::bit_for(evt_t);
>>       }
>>   }
>
> Thanks, Alex! You are right - fixed.
> I was stupid enough to confuse the direction. Minimal tracing helps in such cases.

Clearing event bits to make it more readable looks like a good idea.
What about the following? :

jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits();
for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) {
  jvmtiEvent evt_t = (jvmtiEvent)ei;
  if (env->has_callback(evt_t)) {
     // set the bit if there is a callback
     enabled_bits |= JvmtiEventEnabled::bit_for(evt_t);
  } else {
    // clear the bit if there is no callback
    enabled_bits &= ~JvmtiEventEnabled::bit_for(evt_t);
  }
}

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Wed May 25 00:20:48 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 25 May 2022 00:20:48 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v5]
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <x5UmEDEXIYMCU11KZRSu0juysDndT4PN6jiINtqSkDw=.207c91a2-a251-47e1-8ea0-339e33b864ed@github.com>

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

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

  get rid of CLEARING_MASK in JVMTI set_event_callbacks

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8860/files
  - new: https://git.openjdk.java.net/jdk/pull/8860/files/0c80ef4a..9a899ddd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=03-04

  Stats: 9 lines in 1 file changed: 4 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8860.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8860/head:pull/8860

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Wed May 25 00:24:52 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 25 May 2022 00:24:52 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v2]
In-Reply-To: <qqej3NCRshcSQ67TGEAX48abINyhiNw8pm7he22pUxY=.13231834-dd71-453b-acf7-82aeab31def4@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
 <TSrJv3YUFHQXKE0ifxOaT1Rz6jzjf1YSft8jmyhvRjs=.e0c4bb06-216d-4ddf-8920-c481212cfa07@github.com>
 <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com>
 <eY6jowgocN1a2TpbZnxdjGy5og6auY_k0wVZebMltrE=.e20fd140-c28a-4d1c-aec4-de3d93d84ac6@github.com>
 <qqej3NCRshcSQ67TGEAX48abINyhiNw8pm7he22pUxY=.13231834-dd71-453b-acf7-82aeab31def4@github.com>
Message-ID: <c8nk6kZH3tKa7gO7eSrYBxKic40MT_3IT9fZJ2qfdvk=.474b363e-1e0d-4646-a2b5-4ee6547977c0@github.com>

On Tue, 24 May 2022 23:49:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thanks, Alex! You are right - fixed.
>> I was stupid enough to confuse the direction. Minimal tracing helps in such cases.
>
> Clearing event bits to make it more readable looks like a good idea.
> What about the following? :
> 
>   jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits();
>   for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) {
>     jvmtiEvent evt_t = (jvmtiEvent)ei;
>     jlong bit_for = JvmtiEventEnabled::bit_for(evt_t);
>     if (env->has_callback(evt_t)) {
>       enabled_bits |= bit_for;
>     } else {
>       enabled_bits &= ~bit_for;
>     }
>   }

Alex, I've removed the CLEARING_MASK and implemented your suggestion which makes the code more clear.

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From amenkov at openjdk.java.net  Wed May 25 00:44:56 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 25 May 2022 00:44:56 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v5]
In-Reply-To: <x5UmEDEXIYMCU11KZRSu0juysDndT4PN6jiINtqSkDw=.207c91a2-a251-47e1-8ea0-339e33b864ed@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <x5UmEDEXIYMCU11KZRSu0juysDndT4PN6jiINtqSkDw=.207c91a2-a251-47e1-8ea0-339e33b864ed@github.com>
Message-ID: <PHOJaOPGg0VhO2TnkaEzYFXL7hsB8Okoa8F8EO5Jiw8=.0c8bb1ae-420e-4767-a3d9-71edf67d3a2f@github.com>

On Wed, 25 May 2022 00:20:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was a typo when the original CLEARING_MASK was initially introduced:
>> 
>> 
>>  // Mask to clear normal event bits.
>>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>>   // Avoid cleaning extension event bits.
>>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
>> 
>> ``` 
>> 
>> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
>> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
>> 
>> Let me provide some background to understand how this mask is used.
>> 
>> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
>> 
>>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>>   JVMTI_MAX_EVENT_TYPE_VAL = 88
>> 
>> The extension event types are numbered from 47 to 49. There are also two constants:
>> 
>>   EXT_MIN_EVENT_TYPE_VAL = 47
>>   EXT_MAX_EVENT_TYPE_VAL = 49
>> 
>> 
>> There are also two additional constants:
>> 
>>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>>   TOTAL_MAX_EVENT_TYPE_VAL = 88
>> 
>> 
>> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
>> 
>> Testing:
>> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of CLEARING_MASK in JVMTI set_event_callbacks

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From amenkov at openjdk.java.net  Wed May 25 00:44:58 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 25 May 2022 00:44:58 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v2]
In-Reply-To: <c8nk6kZH3tKa7gO7eSrYBxKic40MT_3IT9fZJ2qfdvk=.474b363e-1e0d-4646-a2b5-4ee6547977c0@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com>
 <TSrJv3YUFHQXKE0ifxOaT1Rz6jzjf1YSft8jmyhvRjs=.e0c4bb06-216d-4ddf-8920-c481212cfa07@github.com>
 <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com>
 <eY6jowgocN1a2TpbZnxdjGy5og6auY_k0wVZebMltrE=.e20fd140-c28a-4d1c-aec4-de3d93d84ac6@github.com>
 <qqej3NCRshcSQ67TGEAX48abINyhiNw8pm7he22pUxY=.13231834-dd71-453b-acf7-82aeab31def4@github.com>
 <c8nk6kZH3tKa7gO7eSrYBxKic40MT_3IT9fZJ2qfdvk=.474b363e-1e0d-4646-a2b5-4ee6547977c0@github.com>
Message-ID: <pp-t_SvFWD4Yf0SYMVXhtVRrcFkS_PVR9-PP6xW8vWc=.efb65a06-20bd-4a85-985f-a69dbfe6e84e@github.com>

On Wed, 25 May 2022 00:21:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Clearing event bits to make it more readable looks like a good idea.
>> What about the following? :
>> 
>>   jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits();
>>   for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) {
>>     jvmtiEvent evt_t = (jvmtiEvent)ei;
>>     jlong bit_for = JvmtiEventEnabled::bit_for(evt_t);
>>     if (env->has_callback(evt_t)) {
>>       enabled_bits |= bit_for;
>>     } else {
>>       enabled_bits &= ~bit_for;
>>     }
>>   }
>
> Alex, I've removed the CLEARING_MASK and implemented your suggestion which makes the code more clear.

Thank you. It looks much clearer to me now.

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Wed May 25 00:50:56 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 25 May 2022 00:50:56 GMT
Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect [v5]
In-Reply-To: <x5UmEDEXIYMCU11KZRSu0juysDndT4PN6jiINtqSkDw=.207c91a2-a251-47e1-8ea0-339e33b864ed@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
 <x5UmEDEXIYMCU11KZRSu0juysDndT4PN6jiINtqSkDw=.207c91a2-a251-47e1-8ea0-339e33b864ed@github.com>
Message-ID: <t7s3zhFb2eeIozaETKxjgu5ObJfhTF7BZfo-u_ECGJM=.ba23cd6f-e7cd-45a8-b494-1d7a292dc459@github.com>

On Wed, 25 May 2022 00:20:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was a typo when the original CLEARING_MASK was initially introduced:
>> 
>> 
>>  // Mask to clear normal event bits.
>>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>>   // Avoid cleaning extension event bits.
>>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
>> 
>> ``` 
>> 
>> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
>> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
>> 
>> Let me provide some background to understand how this mask is used.
>> 
>> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
>> 
>>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>>   JVMTI_MAX_EVENT_TYPE_VAL = 88
>> 
>> The extension event types are numbered from 47 to 49. There are also two constants:
>> 
>>   EXT_MIN_EVENT_TYPE_VAL = 47
>>   EXT_MAX_EVENT_TYPE_VAL = 49
>> 
>> 
>> There are also two additional constants:
>> 
>>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>>   TOTAL_MAX_EVENT_TYPE_VAL = 88
>> 
>> 
>> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
>> 
>> Testing:
>> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of CLEARING_MASK in JVMTI set_event_callbacks

Thank you for review and good comments, Alex!

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From alanb at openjdk.java.net  Wed May 25 06:22:58 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 25 May 2022 06:22:58 GMT
Subject: RFR: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103
In-Reply-To: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
References: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
Message-ID: <1xoxU3PEAdM3YtAGBMDD_jcdsbVMFALY9uON6IyRuiA=.533ee366-0528-4b5e-a2ef-2d0f297b735a@github.com>

On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Need to use proper synchronization.
> 
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So it should not confuse existing checks.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8874

From alanb at openjdk.java.net  Wed May 25 06:27:01 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 25 May 2022 06:27:01 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options [v2]
In-Reply-To: <Aizyv-1jRWysfCZJWCuj7doc9tijClUtg9XYv_8ZYgQ=.9ffc19ba-aba6-4749-afcc-b559c43e78ef@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
 <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>
 <XccKZlWUIQS6BolQEAwRHs6_P_dlCNHvyPHKTrQDfXA=.b84273c7-fb3d-4aaf-8d21-be1b4657b6a7@github.com>
 <hFYsIjH1sDsXzyG0GEQ7YIsVB3opUPeeWXPvS6AOtwI=.e4ab1a8b-a5a3-469b-ba23-14565343ea2a@github.com>
 <5ZvGivHbAqBQ1Swni92NKMFCePP6b_BiwSLuk2O7SL4=.e1783148-7eae-43d6-91c8-becba8446285@github.com>
 <Aizyv-1jRWysfCZJWCuj7doc9tijClUtg9XYv_8ZYgQ=.9ffc19ba-aba6-4749-afcc-b559c43e78ef@github.com>
Message-ID: <kRcMF98qgCMHXif_plcVfmkpwcoyjJYrYfah_YqA62o=.7d87c886-8899-4360-b020-de6f959a817c@github.com>

On Tue, 24 May 2022 19:36:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I don't think it is correct to say that this command line option is a preview feature. Maybe it can be clarified on a second line:
>> 
>> 
>> -trackvthreads    track virtual threads as they are created
>>                              Virtual threads are a preview feature of the Java platform.
>
> Does that imply that `-trackvthreads` can be changed or removed?

If virtual threads become permanent then the usage message would minimally be updated to drop the sentence that virtual threads are a preview feature. At that point the debugger APIs may have been built out further and it might be that there is no need for the -trackvthreads option but that's too far out to know at this point.

If virtual threads were to be removed then the -trackvthreads command line option would be removed too.

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From sspitsyn at openjdk.java.net  Wed May 25 06:27:10 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 25 May 2022 06:27:10 GMT
Subject: Integrated: 8286490: JvmtiEventControllerPrivate::set_event_callbacks
 CLEARING_MASK computation is incorrect
In-Reply-To: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
References: <DWOS6LocHood-kv0hev4GPswj8DRXjkr4g8ffbPewT8=.54aae018-6a27-4546-b5e4-a09c315b4feb@github.com>
Message-ID: <qSTrLYi2IuyMohmqDYtPjkjIwICHLOJr2AvoDG9H8oo=.b9e2f924-93a7-4818-871a-bbf141292445@github.com>

On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> It was a typo when the original CLEARING_MASK was initially introduced:
> 
> 
>  // Mask to clear normal event bits.
>   const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>   // Avoid cleaning extension event bits.
>   jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits();
> 
> ``` 
> 
> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below:
> `  const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;`
> 
> Let me provide some background to understand how this mask is used.
> 
> Normal JVMTI event types are numbered from 50 to 88. There are two constants:
> 
>   JVMTI_MIN_EVENT_TYPE_VAL = 50
>   JVMTI_MAX_EVENT_TYPE_VAL = 88
> 
> The extension event types are numbered from 47 to 49. There are also two constants:
> 
>   EXT_MIN_EVENT_TYPE_VAL = 47
>   EXT_MAX_EVENT_TYPE_VAL = 49
> 
> 
> There are also two additional constants:
> 
>   TOTAL_MIN_EVENT_TYPE_VAL = 47
>   TOTAL_MAX_EVENT_TYPE_VAL = 88
> 
> 
> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged.
> 
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage.

This pull request has now been integrated.

Changeset: a0cccb54
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a0cccb54791d954bf08da5aac9b9794e370617c8
Stats:     40 lines in 3 files changed: 35 ins; 4 del; 1 mod

8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect

Reviewed-by: jbachorik, lmesnik, amenkov

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

PR: https://git.openjdk.java.net/jdk/pull/8860

From sspitsyn at openjdk.java.net  Wed May 25 07:31:11 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 25 May 2022 07:31:11 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
Message-ID: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>

A part of this issue was contributed with the following changeset:

commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
Date: Mon Nov 8 14:45:04 2021 +0000

    8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
    Reviewed-by: coleenp, sspitsyn, dholmes, rehn

The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:

bool JavaThread::java_suspend() {
- ThreadsListHandle tlh;
- if (!tlh.includes(this)) {
- log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
- return false;
- }
+ guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
 + "missing ThreadsListHandle in calling context.");
  return this->handshake_state()->suspend();
}

This new assert misses a check for target thread as being current `JavaThread`.

Also, the JVMTI SuspendThread is protected with TLH:

JvmtiEnv::SuspendThread(jthread thread) {
  JavaThread* current = JavaThread::current();
  ThreadsListHandle tlh(current);              <= TLS defined here!!!

   oop thread_oop = NULL;
   {
     JvmtiVTMSTransitionDisabler disabler(true); 


However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:


@@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
 jvmtiError
 JvmtiEnv::SuspendThread(jthread thread) {
   JavaThread* current = JavaThread::current();
-  ThreadsListHandle tlh(current);

   jvmtiError err;
   JavaThread* java_thread = NULL;
   oop thread_oop = NULL;
   {
     JvmtiVTMSTransitionDisabler disabler(true);
+    ThreadsListHandle tlh(current);

     err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
     if (err != JVMTI_ERROR_NONE) {



This problem exist in all JVMTI Suspend functions:
 `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

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

Commit messages:
 - 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context

Changes: https://git.openjdk.java.net/jdk/pull/8878/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8878&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286960
  Stats: 17 lines in 2 files changed: 8 ins; 7 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8878.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8878/head:pull/8878

PR: https://git.openjdk.java.net/jdk/pull/8878

From ihse at openjdk.java.net  Wed May 25 08:09:00 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 25 May 2022 08:09:00 GMT
Subject: Integrated: 8287254: Clean up Xcode sysroot logic
In-Reply-To: <1FTVA5oSUiWmtyRzeWHuGVoobQEHL74I7mUpqKG8yfE=.4c11c8cc-f952-4932-a571-dfd60e15f58f@github.com>
References: <1FTVA5oSUiWmtyRzeWHuGVoobQEHL74I7mUpqKG8yfE=.4c11c8cc-f952-4932-a571-dfd60e15f58f@github.com>
Message-ID: <p67Ecmipfqtc96YZvcIeKOv3ELWEeWBgKegbZE59EPY=.c82398f8-47c1-4b2f-8761-100d0689c639@github.com>

On Tue, 24 May 2022 17:09:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The logic in BASIC_SETUP_DEVKIT for setting a correct sysroot for Xcode is hard to follow. This should be straightened out. We also expose variables that are no longer used. So there's a bit of related cleanup. 
> 
> The new code is more or less functionally equivalent to the old. There were some corner cases which the old code did not handle well; this has now been improved. I've also added yet another method of trying to get the SDK root before falling back to the system library, by using `xcrun --show-sdk-path`.
> 
> In an ideal world, the sysroot flags to `mig` should be set in configure, e.g. as `MIG_FLAGS` or `MIG_SYSROOT_FLAGS`. I can't be bothered to do that for a single call to `mig`, though.
> 
> As always, changes like this that depend on the environment is tricky to test. I've tried running it on a couple of different macs, with and without a devkit.

This pull request has now been integrated.

Changeset: d889319a
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d889319a86101e944aefd4ad7f300505abbe5b30
Stats:     200 lines in 4 files changed: 91 ins; 98 del; 11 mod

8287254: Clean up Xcode sysroot logic

Reviewed-by: erikj

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

PR: https://git.openjdk.java.net/jdk/pull/8872

From dholmes at openjdk.java.net  Wed May 25 11:50:43 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 25 May 2022 11:50:43 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <-MO7BkySm4ODXdSellmykES0wwX9h4Ka143TajbNXHY=.6cb3e8e1-15f6-4e2a-970b-cc3ead63f560@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

These changes look good to me - as per our discussion in JBS issue.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8878

From dholmes at openjdk.java.net  Wed May 25 11:55:50 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 25 May 2022 11:55:50 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <s6a5h8oGcuSqm9lZN2kfpZVNL3SjE-C-iajMvA1vrKs=.02a21ddc-f6cd-42ba-b86e-10f4d09ac435@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

One query though - don't we have a self-suspension test that would have triggered the guarantee failure? If we don't then we should (obviously the resume will be a bit racy).

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From cjplummer at openjdk.java.net  Wed May 25 16:14:55 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 25 May 2022 16:14:55 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options [v2]
In-Reply-To: <kRcMF98qgCMHXif_plcVfmkpwcoyjJYrYfah_YqA62o=.7d87c886-8899-4360-b020-de6f959a817c@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
 <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>
 <XccKZlWUIQS6BolQEAwRHs6_P_dlCNHvyPHKTrQDfXA=.b84273c7-fb3d-4aaf-8d21-be1b4657b6a7@github.com>
 <hFYsIjH1sDsXzyG0GEQ7YIsVB3opUPeeWXPvS6AOtwI=.e4ab1a8b-a5a3-469b-ba23-14565343ea2a@github.com>
 <5ZvGivHbAqBQ1Swni92NKMFCePP6b_BiwSLuk2O7SL4=.e1783148-7eae-43d6-91c8-becba8446285@github.com>
 <Aizyv-1jRWysfCZJWCuj7doc9tijClUtg9XYv_8ZYgQ=.9ffc19ba-aba6-4749-afcc-b559c43e78ef@github.com>
 <kRcMF98qgCMHXif_plcVfmkpwcoyjJYrYfah_YqA62o=.7d87c886-8899-4360-b020-de6f959a817c@github.com>
Message-ID: <Lz6gpMbkQwOPFHWeMcDtEmQULNu_q9l1ytA421NftL0=.8df7f8f3-359a-40b2-8764-5343a24064ef@github.com>

On Wed, 25 May 2022 06:23:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If virtual threads become permanent then the usage message would minimally be updated to drop the sentence that virtual threads are a preview feature.

But that's precisely the commitment to this flag that I want to avoid.  I want something that is the equivalent of `EXPERIMENTAL` for `-XX` flags.

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From sspitsyn at openjdk.java.net  Wed May 25 16:34:58 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 25 May 2022 16:34:58 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <U42PgT9uGONt5OA0YZ169gR3qLXp3xzCd_jfhD8iuvo=.c3cf36e9-7873-4ab5-9fb1-4ca88de54e92@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

The test `serviceability/jvmti/vthread/SelfSuspendDisablerTest` is triggering this guarantee.
But it needs this update in the `SuspendThread` in order to do it.


#  Internal Error (/scratch/sspitsyn/loom5/open/src/hotspot/share/runtime/thread.cpp:1781), pid=31157, tid=31182
#  guarantee(Thread::is_JavaThread_protected_by_TLH( this)) failed: missing ThreadsListHandle in calling context.
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-05-19-0744187.sspitsyn...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-05-19-0744187.sspitsyn..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1a41724]  JavaThread::java_suspend()+0xa4
. . . . .
---------------  S U M M A R Y ------------

Command Line: -Dtest.vm.opts=-XX:+CreateCoredumpOnCrash --enable-preview -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -XX:-VerifyContinuations -XX:+CheckUnhandledOops -Xcheck:jni -Dmain.wrapper=Virtual -Dtest.tool.vm.opts=-J-XX:+CreateCoredumpOnCrash -J--enable-preview -J-Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -J-XX:-VerifyContinuations -J-XX:+CheckUnhandledOops -J-Xcheck:jni -J-Dmain.wrapper=Virtual -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/jdk -Dcompile.jdk=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/jdk -Dtest.timeout.factor=1.0 -Dtest.nativepath=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/test/hotspot/jtreg/native -Dtest.root=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg -Dtest.name=serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java -Dtest.file=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerT
 est/SelfSuspendDisablerTest.java -Dtest.src=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest -Dtest.src.path=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest:/scratch/sspitsyn/loom5/open/test/lib -Dtest.classes=/scratch/sspitsyn/tst/loom5/JTwork/classes/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.d -Dtest.class.path=/scratch/sspitsyn/tst/loom5/JTwork/classes/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.d:/scratch/sspitsyn/tst/loom5/JTwork/classes/test/lib -XX:+CreateCoredumpOnCrash --enable-preview -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -XX:-VerifyContinuations -XX:+CheckUnhandledOops -Xcheck:jni -Dmain.wrapper=Virtual -Djava.library.path=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/test/hotspot/jtreg/native --enable-preview -agentlib:SelfSuspendDisablerTest com.sun.javatest.regtest.agent.Ma
 inWrapper /scratch/sspitsyn/tst/loom5/JTwork/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.d/main.1.jta

Host: hotspot-oraclelinux-01, Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz, 32 cores, 235G, Oracle Linux Server release 7.8
Time: Wed May 25 16:23:30 2022 GMT elapsed time: 0.322123 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread (0x00007f3440022920):  JavaThread "Thread-1" [_thread_in_vm, id=31182, stack(0x00007f348afee000,0x00007f348b0ef000)]

Stack: [0x00007f348afee000,0x00007f348b0ef000],  sp=0x00007f348b0ed620,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1a41724]  JavaThread::java_suspend()+0xa4
V  [libjvm.so+0x1315989]  JvmtiEnvBase::suspend_thread(oop, JavaThread*, bool, int*)+0x379
V  [libjvm.so+0x12fba6a]  JvmtiEnv::SuspendThread(_jobject*)+0x1ba
V  [libjvm.so+0x12a42df]  jvmti_SuspendThread+0x17f
C  [libSelfSuspendDisablerTest.so+0x21a8]  Java_SelfSuspendDisablerTest_selfSuspend+0x38
j  SelfSuspendDisablerTest.selfSuspend()V+0
j  SelfSuspendDisablerTest.lambda$main$0()V+0
j  SelfSuspendDisablerTest$$Lambda$1+0x0000000801001200.run()V+0
j  java.lang.Thread.run()V+13 java.base at 19-internal
v  ~StubRoutines::call_stub 0x00007f34f6db9d47
V  [libjvm.so+0xfba465]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x505
V  [libjvm.so+0xfbacf4]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x4b4
V  [libjvm.so+0xfbb167]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x77
V  [libjvm.so+0x113d20b]  thread_entry(JavaThread*, JavaThread*)+0x12b
V  [libjvm.so+0x1a40b7a]  JavaThread::thread_main_inner()+0x21a
V  [libjvm.so+0x1a4e430]  Thread::call_run()+0x100
V  [libjvm.so+0x16fc2b4]  thread_native_entry(Thread*)+0x104

David, thank you for review and help with analysis of this problem!

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From pchilanomate at openjdk.java.net  Wed May 25 20:44:43 2022
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 25 May 2022 20:44:43 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <ENWC1SdoUUeD3aXdaZvJM8R_kueIDy_BMeOLkd2Sd9I=.7a55481a-46da-411d-9617-3d9876b46e2c@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

LGTM.

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

Marked as reviewed by pchilanomate (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8878

From sspitsyn at openjdk.java.net  Wed May 25 21:10:40 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 25 May 2022 21:10:40 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <xNiI4Ybee2-h_wZnkOf38KECapmhAuo4Y2SUqbcWaPA=.8c1c3cf6-ec82-4070-88bf-f2642723031d@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

Thank you for quick review, Patricio!

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From duke at openjdk.java.net  Wed May 25 21:23:44 2022
From: duke at openjdk.java.net (master-code-java)
Date: Wed, 25 May 2022 21:23:44 GMT
Subject: RFR: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103
In-Reply-To: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
References: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
Message-ID: <-ZGz1LMLAaXkyHsOXCs4K_H9ANUAFDl4PtkoF6eCKJU=.55c5ca84-51fa-4603-8844-13aff98b6711@github.com>

On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Need to use proper synchronization.
> 
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So it should not confuse existing checks.

test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 98:

> 96: 
> 97:     private static void awaitBlocked(Thread thread) throws InterruptedException {
> 98:         while (thread.getState() != Thread.State.BLOCKED) {

Thread.State.BLOCKED == thread.getState(). Does it make sense?

test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 100:

> 98:         while (thread.getState() != Thread.State.BLOCKED) {
> 99:             Thread.sleep(10);
> 100:             if (thread.getState() == Thread.State.TERMINATED) {

Thread.State.TERMINATED == thread.getState(). Does it make sense?

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

PR: https://git.openjdk.java.net/jdk/pull/8874

From lmesnik at openjdk.java.net  Wed May 25 23:08:55 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 25 May 2022 23:08:55 GMT
Subject: RFR: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103
In-Reply-To: <-ZGz1LMLAaXkyHsOXCs4K_H9ANUAFDl4PtkoF6eCKJU=.55c5ca84-51fa-4603-8844-13aff98b6711@github.com>
References: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
 <-ZGz1LMLAaXkyHsOXCs4K_H9ANUAFDl4PtkoF6eCKJU=.55c5ca84-51fa-4603-8844-13aff98b6711@github.com>
Message-ID: <sT91nWBMbSVDx-Yva3s1g3AZRr27_yWYpCmfubYBDvw=.b515b7da-a47c-42df-bf3b-38d1ea4f03e6@github.com>

On Wed, 25 May 2022 21:18:24 GMT, master-code-java <duke at openjdk.java.net> wrote:

>> Need to use proper synchronization.
>> 
>> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So it should not confuse existing checks.
>
> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 98:
> 
>> 96: 
>> 97:     private static void awaitBlocked(Thread thread) throws InterruptedException {
>> 98:         while (thread.getState() != Thread.State.BLOCKED) {
> 
> Thread.State.BLOCKED == thread.getState(). Does it make sense?

Do you mean '==' or '!='? Both don't make sense to me, honestly. Could you please elaborate?

> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 100:
> 
>> 98:         while (thread.getState() != Thread.State.BLOCKED) {
>> 99:             Thread.sleep(10);
>> 100:             if (thread.getState() == Thread.State.TERMINATED) {
> 
> Thread.State.TERMINATED == thread.getState(). Does it make sense?

Not sure. What is the goal?

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

PR: https://git.openjdk.java.net/jdk/pull/8874

From amenkov at openjdk.java.net  Wed May 25 23:13:39 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 25 May 2022 23:13:39 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <FJjpXouSWM4Ewm18wfKkFzY9Doe4d0axHaktdO1ORZo=.655807d9-3f3b-4fff-b0ff-cf44e4a40cc2@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From Matthew.Carter at microsoft.com  Wed May 25 23:45:32 2022
From: Matthew.Carter at microsoft.com (Mat Carter)
Date: Wed, 25 May 2022 23:45:32 +0000
Subject: How can Java developers best understand their impact on the start-up
 of the JVM?
Message-ID: <BN8PR00MB0595D22FCDB1F429B1B069C68AD69@BN8PR00MB0595.namprd00.prod.outlook.com>

The Microsoft Java Engineering Group (JEG) have been looking at how Java developers can best understand the impact of their decisions on start-up time. Specifically, how developers can identify and mitigate the dominant activities that occur during start-up, through to their app / service reaching a steady state (warmed up). 

Upon investigation into the available tooling (i.e., jstat, jcmd, jmc, VisualVM, MXBeans), it seems that Performance Counters (PCs) and JDK Flight Recorder events (JFREs) are the main source of the available startup metrics that get surfaced. 

Whilst the tooling does provide insight to specific areas (GC, JIT Compilation etc.), there does not seem to be one view to help a developer identify the dominant activities that are impacting start-up. 

Q: Has the above been discussed before and are there any existing plans to address the outcomes that I might have missed? 

Looking at the specific PCs and JFREs there are a few ?missing? metrics, for example a timestamp at the very beginning entry point of the JVM. Also, it appears that the JFREs represent a subset of the PCs - does this indicate that either some PCs should be removed (or only enabled for JVM development) or that there remain JFREs to be added? 

Q: Is there a current position on whether PCs and JFREs will continue to co-exist (the former supporting JMX MXBeans, et al.), or is there a plan to phase out PCs in favor of JFREs? 

Q: Assuming PCs should continue to exist, do folks see the value in documenting them and making them readily accessible to the running application? Especially in the deployment scenario where running a second application or tool (to sample the PCs remotely) is not feasible. FYI - during our initial investigations we wrote some scripts to find all possible PCs. We did this because jcmd only lists instantiated PCs and the PC names are procedurally generated, making them non-trivial to search for. 

Q: Do folks see value in documenting the JFREs, especially since the application can access the JFR Event stream? (There is non-official documentation available [1]) 

Q: While Project Leyden concerns itself primarily with improving start-up times, are there any other known activities targeting profiling of Java applications (esp. start-up)? 

Answers and discussion of the above is most welcome so that our group moves forward in helping our customers, whilst staying aligned with and contributing to the OpenJDK community! 

Thanks in advance 
Mat Carter 

[1] https://bestsolution-at.github.io/jfr-doc/index.html 

From sspitsyn at openjdk.java.net  Thu May 26 00:32:35 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 26 May 2022 00:32:35 GMT
Subject: Integrated: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <ppltJeFulEPHD2DUBzSVKqE261L3NwhCz3_d-F08VcE=.7acfcfce-ef60-40c5-8af3-3f895c841a42@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

This pull request has now been integrated.

Changeset: 94811c0d
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/94811c0dc7c20b0e7cb2649fe8da5061ce3d6246
Stats:     17 lines in 2 files changed: 8 ins; 7 del; 2 mod

8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context

Reviewed-by: dholmes, pchilanomate, amenkov

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From sspitsyn at openjdk.java.net  Thu May 26 00:32:35 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 26 May 2022 00:32:35 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <_NLTWJj7sPUvNFhPYopIRG1H1UtUy6MxlNVeDanfCqo=.20b541f6-a65c-40df-b138-c9a65f7afc12@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

Thank you for review, Alex!

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From david.holmes at oracle.com  Thu May 26 02:10:06 2022
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 May 2022 12:10:06 +1000
Subject: How can Java developers best understand their impact on the
 start-up of the JVM?
In-Reply-To: <BN8PR00MB0595D22FCDB1F429B1B069C68AD69@BN8PR00MB0595.namprd00.prod.outlook.com>
References: <BN8PR00MB0595D22FCDB1F429B1B069C68AD69@BN8PR00MB0595.namprd00.prod.outlook.com>
Message-ID: <be827a1a-4559-6960-34e3-db01bbf622ab@oracle.com>

cc'ing hotspot-jfr-dev

On 26/05/2022 9:45 am, Mat Carter wrote:
> The Microsoft Java Engineering Group (JEG) have been looking at how Java developers can best understand the impact of their decisions on start-up time. Specifically, how developers can identify and mitigate the dominant activities that occur during start-up, through to their app / service reaching a steady state (warmed up).
> 
> Upon investigation into the available tooling (i.e., jstat, jcmd, jmc, VisualVM, MXBeans), it seems that Performance Counters (PCs) and JDK Flight Recorder events (JFREs) are the main source of the available startup metrics that get surfaced.
> 
> Whilst the tooling does provide insight to specific areas (GC, JIT Compilation etc.), there does not seem to be one view to help a developer identify the dominant activities that are impacting start-up.
> 
> Q: Has the above been discussed before and are there any existing plans to address the outcomes that I might have missed?
> 
> Looking at the specific PCs and JFREs there are a few ?missing? metrics, for example a timestamp at the very beginning entry point of the JVM. Also, it appears that the JFREs represent a subset of the PCs - does this indicate that either some PCs should be removed (or only enabled for JVM development) or that there remain JFREs to be added?
> 
> Q: Is there a current position on whether PCs and JFREs will continue to co-exist (the former supporting JMX MXBeans, et al.), or is there a plan to phase out PCs in favor of JFREs?
> 
> Q: Assuming PCs should continue to exist, do folks see the value in documenting them and making them readily accessible to the running application? Especially in the deployment scenario where running a second application or tool (to sample the PCs remotely) is not feasible. FYI - during our initial investigations we wrote some scripts to find all possible PCs. We did this because jcmd only lists instantiated PCs and the PC names are procedurally generated, making them non-trivial to search for.
> 
> Q: Do folks see value in documenting the JFREs, especially since the application can access the JFR Event stream? (There is non-official documentation available [1])
> 
> Q: While Project Leyden concerns itself primarily with improving start-up times, are there any other known activities targeting profiling of Java applications (esp. start-up)?
> 
> Answers and discussion of the above is most welcome so that our group moves forward in helping our customers, whilst staying aligned with and contributing to the OpenJDK community!
> 
> Thanks in advance
> Mat Carter
> 
> [1] https://bestsolution-at.github.io/jfr-doc/index.html

From dholmes at openjdk.java.net  Thu May 26 02:36:43 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 May 2022 02:36:43 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <CL0Gh3lFg2JkWIMwW1fXrNu4BwA0Q7BVvlET7t5dQM0=.82fe1955-952a-4c00-a907-c3c8f1caf4bd@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

I was expecting there to be an existing non-vthread-related test for self-suspension. That seems to be a hole in our test coverage.

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From dholmes at openjdk.java.net  Thu May 26 02:38:34 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 May 2022 02:38:34 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options [v2]
In-Reply-To: <Lz6gpMbkQwOPFHWeMcDtEmQULNu_q9l1ytA421NftL0=.8df7f8f3-359a-40b2-8764-5343a24064ef@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
 <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>
 <XccKZlWUIQS6BolQEAwRHs6_P_dlCNHvyPHKTrQDfXA=.b84273c7-fb3d-4aaf-8d21-be1b4657b6a7@github.com>
 <hFYsIjH1sDsXzyG0GEQ7YIsVB3opUPeeWXPvS6AOtwI=.e4ab1a8b-a5a3-469b-ba23-14565343ea2a@github.com>
 <5ZvGivHbAqBQ1Swni92NKMFCePP6b_BiwSLuk2O7SL4=.e1783148-7eae-43d6-91c8-becba8446285@github.com>
 <Aizyv-1jRWysfCZJWCuj7doc9tijClUtg9XYv_8ZYgQ=.9ffc19ba-aba6-4749-afcc-b559c43e78ef@github.com>
 <kRcMF98qgCMHXif_plcVfmkpwcoyjJYrYfah_YqA62o=.7d87c886-8899-4360-b020-de6f959a817c@github.com>
 <Lz6gpMbkQwOPFHWeMcDtEmQULNu_q9l1ytA421NftL0=.8df7f8f3-359a-40b2-8764-5343a24064ef@github.com>
Message-ID: <RFfS9BZy4J87FVtMwl7Y9EaD0T0wnkPknTp7FY738Os=.a642c3b2-b501-43bf-9142-4dc5badc9935@github.com>

On Wed, 25 May 2022 16:11:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> If virtual threads become permanent then the usage message would minimally be updated to drop the sentence that virtual threads are a preview feature. At that point the debugger APIs may have been built out further and it might be that there is no need for the -trackvthreads option but that's too far out to know at this point.
>> 
>> If virtual threads were to be removed then the -trackvthreads command line option would be removed too.
>
>> If virtual threads become permanent then the usage message would minimally be updated to drop the sentence that virtual threads are a preview feature.
> 
> But that's precisely the commitment to this flag that I want to avoid.  I want something that is the equivalent of `EXPERIMENTAL` for `-XX` flags.

Again I have to say I agree with Chris. The flag itself is a "preview" flag and relates to a "preview feature". If the feature goes obviously the flag does too, but the flag could go even if the feature stays.

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From cjplummer at openjdk.java.net  Thu May 26 03:50:36 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 26 May 2022 03:50:36 GMT
Subject: RFR: 8286983: Add mention of "Preview Feature" for new loom
 related jdb and debug agent options [v2]
In-Reply-To: <RFfS9BZy4J87FVtMwl7Y9EaD0T0wnkPknTp7FY738Os=.a642c3b2-b501-43bf-9142-4dc5badc9935@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
 <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>
 <XccKZlWUIQS6BolQEAwRHs6_P_dlCNHvyPHKTrQDfXA=.b84273c7-fb3d-4aaf-8d21-be1b4657b6a7@github.com>
 <hFYsIjH1sDsXzyG0GEQ7YIsVB3opUPeeWXPvS6AOtwI=.e4ab1a8b-a5a3-469b-ba23-14565343ea2a@github.com>
 <5ZvGivHbAqBQ1Swni92NKMFCePP6b_BiwSLuk2O7SL4=.e1783148-7eae-43d6-91c8-becba8446285@github.com>
 <Aizyv-1jRWysfCZJWCuj7doc9tijClUtg9XYv_8ZYgQ=.9ffc19ba-aba6-4749-afcc-b559c43e78ef@github.com>
 <kRcMF98qgCMHXif_plcVfmkpwcoyjJYrYfah_YqA62o=.7d87c886-8899-4360-b020-de6f959a817c@github.com>
 <Lz6gpMbkQwOPFHWeMcDtEmQULNu_q9l1ytA421NftL0=.8df7f8f3-359a-40b2-8764-5343a24064ef@github.com>
 <RFfS9BZy4J87FVtMwl7Y9EaD0T0wnkPknTp7FY738Os=.a642c3b2-b501-43bf-9142-4dc5badc9935@github.com>
Message-ID: <ArfIf-hctkyhLpHyPbaf8oG6FTH6JFbqO-G-5xjLgHs=.d532879e-7177-4ddd-90ea-d7019a2a342f@github.com>

On Thu, 26 May 2022 02:35:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> If virtual threads become permanent then the usage message would minimally be updated to drop the sentence that virtual threads are a preview feature.
>> 
>> But that's precisely the commitment to this flag that I want to avoid.  I want something that is the equivalent of `EXPERIMENTAL` for `-XX` flags.
>
> Again I have to say I agree with Chris. The flag itself is a "preview" flag and relates to a "preview feature". If the feature goes obviously the flag does too, but the flag could go even if the feature stays.

Please see the discussion with Alex in [JDK-8286983](https://bugs.openjdk.java.net/browse/JDK-8286983)

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From iklam at openjdk.java.net  Thu May 26 05:11:35 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 26 May 2022 05:11:35 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
Message-ID: <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>

On Mon, 23 May 2022 07:28:41 GMT, Yi Yang <yyang at openjdk.org> wrote:

> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
> 
> Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
> 
> ==> CodeHeap 'non-nmethods' 1532544 (Used)
> ==> CodeHeap 'profiled nmethods' 0
> ==> CodeHeap 'non-profiled nmethods' 13952
> ==> Metaspace 506696
> ==> Compressed Class Space 43312
> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K)
> 
> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`.

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

> 751:     for (int i = 0; i < MemoryService::num_memory_pools(); i++) {
> 752:       MemoryPool* pool = MemoryService::get_memory_pool(i);
> 753:       if (pool->is_codeheap() || pool->is_metaspace()) {

Our only special case is that all the memory reported by `CompressedKlassSpacePool` are already reported by `MetaspacePool`, so shouldn't we do this:


if (pool->is_non_heap() && !pool->is_compressed_klass_space()) {
  // skip CompressedKlassSpacePool since its memory is already reported by
  // MetaspacePool

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From alanb at openjdk.java.net  Thu May 26 05:44:28 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 26 May 2022 05:44:28 GMT
Subject: RFR: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103
In-Reply-To: <sT91nWBMbSVDx-Yva3s1g3AZRr27_yWYpCmfubYBDvw=.b515b7da-a47c-42df-bf3b-38d1ea4f03e6@github.com>
References: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
 <-ZGz1LMLAaXkyHsOXCs4K_H9ANUAFDl4PtkoF6eCKJU=.55c5ca84-51fa-4603-8844-13aff98b6711@github.com>
 <sT91nWBMbSVDx-Yva3s1g3AZRr27_yWYpCmfubYBDvw=.b515b7da-a47c-42df-bf3b-38d1ea4f03e6@github.com>
Message-ID: <UqRlPLNa71KR8-FXMgxJGNnRDMiFYA2kS57B82SrTEg=.9b4f2754-839f-4e24-8d31-cd2b730ee86b@github.com>

On Wed, 25 May 2022 23:04:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 100:
>> 
>>> 98:         while (thread.getState() != Thread.State.BLOCKED) {
>>> 99:             Thread.sleep(10);
>>> 100:             if (thread.getState() == Thread.State.TERMINATED) {
>> 
>> Thread.State.TERMINATED == thread.getState(). Does it make sense?
>
> Not sure. What is the goal?

I assume this test is catch the catch where the thread terminates without blocking. Using isAlive might be cleaner for people to understand.

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

PR: https://git.openjdk.java.net/jdk/pull/8874

From yyang at openjdk.java.net  Thu May 26 06:02:42 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 26 May 2022 06:02:42 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>
Message-ID: <ah32eBkCAmE_qcaWAjWQ06ZphSqdrP2od_zCkCbrMCw=.826f91e3-dbe1-41bb-b2bf-7c67758ddda7@github.com>

On Thu, 26 May 2022 05:08:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>> 
>> Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>> 
>> ==> CodeHeap 'non-nmethods' 1532544 (Used)
>> ==> CodeHeap 'profiled nmethods' 0
>> ==> CodeHeap 'non-profiled nmethods' 13952
>> ==> Metaspace 506696
>> ==> Compressed Class Space 43312
>> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K)
>> 
>> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`.
>
> src/hotspot/share/services/management.cpp line 753:
> 
>> 751:     for (int i = 0; i < MemoryService::num_memory_pools(); i++) {
>> 752:       MemoryPool* pool = MemoryService::get_memory_pool(i);
>> 753:       if (pool->is_codeheap() || pool->is_metaspace()) {
> 
> Our only special case is that all the memory reported by `CompressedKlassSpacePool` are already reported by `MetaspacePool`, so shouldn't we do this:
> 
> 
> if (pool->is_non_heap() && !pool->is_compressed_klass_space()) {
>   // skip CompressedKlassSpacePool since its memory is already reported by
>   // MetaspacePool

This is also acceptable, but if we add more memory pools, we might add more special pools to exclude their space from nonheap. Instead, we can specify exactly which pools we need to accumulate, which is what this change did.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From sspitsyn at openjdk.java.net  Thu May 26 07:01:35 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 26 May 2022 07:01:35 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <et2kFXvaFyoSLTz6s0_HaQ-U8FBZqFKvwpSF276veWA=.45bbf19b-693c-418d-ae70-96e99ea30b62@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

This nsk.jvmti test is also failing with the guarantee for current platform thread:
 `test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002`
 

 #  Internal Error (/scratch/sspitsyn/loom5/open/src/hotspot/share/runtime/thread.cpp:1781), pid=7458, tid=7506
#  guarantee(Thread::is_JavaThread_protected_by_TLH( this)) failed: missing ThreadsListHandle in calling context.
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-05-19-0744187.sspitsyn...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-05-19-0744187.sspitsyn..., mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1a41814]  JavaThread::java_suspend()+0xa4
. . . . . . . . . . . . . . . .
---------------  T H R E A D  ---------------

Current thread (0x000014b91001d0f0):  JavaThread "Thread-1" [_thread_in_vm, id=7506, stack(0x000014b92bafa000,0x000014b92bbfb000)]

Stack: [0x000014b92bafa000,0x000014b92bbfb000],  sp=0x000014b92bbf8ef0,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1a41814]  JavaThread::java_suspend()+0xa4
V  [libjvm.so+0x1315a79]  JvmtiEnvBase::suspend_thread(oop, JavaThread*, bool, int*)+0x379
V  [libjvm.so+0x12fb9ca]  JvmtiEnv::SuspendThread(_jobject*)+0x1ba
V  [libjvm.so+0x12a42df]  jvmti_SuspendThread+0x17f
C  [libhs202t002.so+0xc0a7]  callbackMethodExit.part.0+0x107
V  [libjvm.so+0x1336887]  JvmtiExport::post_method_exit_inner(JavaThread*, methodHandle&, JvmtiThreadState*, bool, frame, jvalue&) [clone .part.0]+0x307
V  [libjvm.so+0x133ac71]  JvmtiExport::notice_unwind_due_to_exception(JavaThread*, Method*, unsigned char*, oop, bool)+0x531
V  [libjvm.so+0xfad21a]  InterpreterRuntime::exception_handler_for_exception(JavaThread*, oopDesc*)+0xb9a
j  nsk.jvmti.scenarios.hotswap.HS202.hs202t002.MyThread.display()V+19
j  nsk.jvmti.scenarios.hotswap.HS202.hs202t002.MyThread.playWithThis()V+1
j  nsk.jvmti.scenarios.hotswap.HS202.hs202t002.MyThread.run()V+1
v  ~StubRoutines::call_stub 0x000014b98fa09d47
V  [libjvm.so+0xfba465]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x505
V  [libjvm.so+0xfbacf4]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x4b4
V  [libjvm.so+0xfbb167]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x77
V  [libjvm.so+0x113d20b]  thread_entry(JavaThread*, JavaThread*)+0x12b
V  [libjvm.so+0x1a40c6a]  JavaThread::thread_main_inner()+0x21a
V  [libjvm.so+0x1a4e520]  Thread::call_run()+0x100
V  [libjvm.so+0x16fc3a4]  thread_native_entry(Thread*)+0x104

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From dholmes at openjdk.java.net  Thu May 26 07:38:43 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 May 2022 07:38:43 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <ah32eBkCAmE_qcaWAjWQ06ZphSqdrP2od_zCkCbrMCw=.826f91e3-dbe1-41bb-b2bf-7c67758ddda7@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>
 <ah32eBkCAmE_qcaWAjWQ06ZphSqdrP2od_zCkCbrMCw=.826f91e3-dbe1-41bb-b2bf-7c67758ddda7@github.com>
Message-ID: <c9qUdzr7umZ0atYWXDJ3dao4QYqLIvrWuy_eFBQX1kU=.d8836c3d-6aa3-484c-8eac-9b4bbb166537@github.com>

On Thu, 26 May 2022 05:59:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> src/hotspot/share/services/management.cpp line 753:
>> 
>>> 751:     for (int i = 0; i < MemoryService::num_memory_pools(); i++) {
>>> 752:       MemoryPool* pool = MemoryService::get_memory_pool(i);
>>> 753:       if (pool->is_codeheap() || pool->is_metaspace()) {
>> 
>> Our only special case is that all the memory reported by `CompressedKlassSpacePool` are already reported by `MetaspacePool`, so shouldn't we do this:
>> 
>> 
>> if (pool->is_non_heap() && !pool->is_compressed_klass_space()) {
>>   // skip CompressedKlassSpacePool since its memory is already reported by
>>   // MetaspacePool
>
> This is also acceptable, but if we add more memory pools, we might add more special pools to exclude their space from nonheap. Instead, we can specify exactly which pools we need to accumulate, which is what this change did.

I think the problem is the definition of the pools. We seem to have nested pools but it is far from clear that this API/mechanism was designed/intended to support nested pools.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From dholmes at openjdk.java.net  Thu May 26 07:45:28 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 May 2022 07:45:28 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <FsOqqIUMGDj2aJvNRwuH-R2aFrsJNokiVMA6H262oDw=.ea251121-6966-409c-9529-5ab92cbb232f@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

Ah I see. Hmmm it might be argued (when Dan gets back) that the TLH was in fact intended/expected to cover the current thread - even though the current thread never needs such protection.

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From yyang at openjdk.java.net  Thu May 26 11:34:48 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 26 May 2022 11:34:48 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <c9qUdzr7umZ0atYWXDJ3dao4QYqLIvrWuy_eFBQX1kU=.d8836c3d-6aa3-484c-8eac-9b4bbb166537@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>
 <ah32eBkCAmE_qcaWAjWQ06ZphSqdrP2od_zCkCbrMCw=.826f91e3-dbe1-41bb-b2bf-7c67758ddda7@github.com>
 <c9qUdzr7umZ0atYWXDJ3dao4QYqLIvrWuy_eFBQX1kU=.d8836c3d-6aa3-484c-8eac-9b4bbb166537@github.com>
Message-ID: <HvEEPP4CkmBPN2xNr4cchJVzZhxFi5U1HwAydsiZKy4=.1a3b0465-cfd8-47db-8ce0-6d48097e9305@github.com>

On Thu, 26 May 2022 07:34:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is also acceptable, but if we add more memory pools, we might add more special pools to exclude their space from nonheap. Instead, we can specify exactly which pools we need to accumulate, which is what this change did.
>
> I think the problem is the definition of the pools. We seem to have nested pools but it is far from clear that this API/mechanism was designed/intended to support nested pools.

In any case, it's unreasonable for getNonHeapMemoryUsage to repeatedly count a piece of memory, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage.

>From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area:

     * Returns the current memory usage of the heap that
     * is used for object allocation.  The heap consists
     * of one or more memory pools.


I propose to revise the Java doc to describe the definition of non-heap area more precisely:

    /**
     * Returns the current memory usage of non-heap memory that
     * contains code cache and metaspace.
     * The non-heap memory consists of one or more memory pools.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From dholmes at openjdk.java.net  Thu May 26 12:51:36 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 May 2022 12:51:36 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <HvEEPP4CkmBPN2xNr4cchJVzZhxFi5U1HwAydsiZKy4=.1a3b0465-cfd8-47db-8ce0-6d48097e9305@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>
 <ah32eBkCAmE_qcaWAjWQ06ZphSqdrP2od_zCkCbrMCw=.826f91e3-dbe1-41bb-b2bf-7c67758ddda7@github.com>
 <c9qUdzr7umZ0atYWXDJ3dao4QYqLIvrWuy_eFBQX1kU=.d8836c3d-6aa3-484c-8eac-9b4bbb166537@github.com>
 <HvEEPP4CkmBPN2xNr4cchJVzZhxFi5U1HwAydsiZKy4=.1a3b0465-cfd8-47db-8ce0-6d48097e9305@github.com>
Message-ID: <Bo5UR_0GT68SQj3CfZFOkM8knjrlxWItI8mifU05O0s=.5d7e8e3b-a7b7-4bdf-a36e-18f329dabd02@github.com>

On Thu, 26 May 2022 11:32:46 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> I think the problem is the definition of the pools. We seem to have nested pools but it is far from clear that this API/mechanism was designed/intended to support nested pools.
>
> In any case, it's unreasonable for getNonHeapMemoryUsage to count a piece of memory repeatedly, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage, which should be far beyond what developers expect. In a real scenario, some monitor platforms draw a line chart by collecting getHeapMemoryUsage and getNonHeapMemoryUsage. It's confusing for end-users of the monitor platform to understand why getHeapMemoryUsage is desired while getNonHeapMemoryUsage is bigger than expectation.
> 
> From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area:
> 
>      * Returns the current memory usage of the heap that
>      * is used for object allocation.  The heap consists
>      * of one or more memory pools.
> 
> 
> I propose to revise the Java doc to describe the definition of non-heap area more precisely:
> 
>     /**
>      * Returns the current memory usage of non-heap memory that
>      * contains code cache and metaspace.
>      * The non-heap memory consists of one or more memory pools.

No, things like code-cache and metaspace do not get baked into the specification. "non-heap" is deliberately vague and open-ended.

I can agree the calculation may be wrong but we need to determine exactly why it is wrong. To me the pool definitions seem wrong - they shouldn't be nested, so then you couldn't double-count. But we really need the experts on this code to chime in.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From stuefe at openjdk.java.net  Thu May 26 13:15:42 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 26 May 2022 13:15:42 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <Bo5UR_0GT68SQj3CfZFOkM8knjrlxWItI8mifU05O0s=.5d7e8e3b-a7b7-4bdf-a36e-18f329dabd02@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>
 <ah32eBkCAmE_qcaWAjWQ06ZphSqdrP2od_zCkCbrMCw=.826f91e3-dbe1-41bb-b2bf-7c67758ddda7@github.com>
 <c9qUdzr7umZ0atYWXDJ3dao4QYqLIvrWuy_eFBQX1kU=.d8836c3d-6aa3-484c-8eac-9b4bbb166537@github.com>
 <HvEEPP4CkmBPN2xNr4cchJVzZhxFi5U1HwAydsiZKy4=.1a3b0465-cfd8-47db-8ce0-6d48097e9305@github.com>
 <Bo5UR_0GT68SQj3CfZFOkM8knjrlxWItI8mifU05O0s=.5d7e8e3b-a7b7-4bdf-a36e-18f329dabd02@github.com>
Message-ID: <p95npMVUkg0lDgiMF_Cw0OyjgkzuRIo6sC_Raq1L3Yw=.89ddd6ed-f050-4d77-9de5-acab275b2955@github.com>

On Thu, 26 May 2022 12:47:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In any case, it's unreasonable for getNonHeapMemoryUsage to count a piece of memory repeatedly, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage, which should be far beyond what developers expect. In a real scenario, some monitor platforms draw a line chart by collecting getHeapMemoryUsage and getNonHeapMemoryUsage. It's confusing for end-users of the monitor platform to understand why getHeapMemoryUsage is desired while getNonHeapMemoryUsage is bigger than expectation.
>> 
>> From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area:
>> 
>>      * Returns the current memory usage of the heap that
>>      * is used for object allocation.  The heap consists
>>      * of one or more memory pools.
>> 
>> 
>> I propose to revise the Java doc to describe the definition of non-heap area more precisely:
>> 
>>     /**
>>      * Returns the current memory usage of non-heap memory that
>>      * contains code cache and metaspace.
>>      * The non-heap memory consists of one or more memory pools.
>
> No, things like code-cache and metaspace do not get baked into the specification. "non-heap" is deliberately vague and open-ended.
> 
> I can agree the calculation may be wrong but we need to determine exactly why it is wrong. To me the pool definitions seem wrong - they shouldn't be nested, so then you couldn't double-count. But we really need the experts on this code to chime in.

Sorry for chiming in in a not very helpful way, but I am not sure what even the point is of this API. 

I'm seriously interested in who uses it, and for what. Calculating real memory usage is notoriously difficult. This one seems to be just an arbitrary selection of stuff. It leaves out C-heap usage (VM, outer JDK, and third party libs), native mappings, sometimes massive system library overhead, text segments, thread stacks... that it counts class space twice is probably its smallest problem...

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From stuefe at openjdk.java.net  Thu May 26 13:51:41 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 26 May 2022 13:51:41 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <HvEEPP4CkmBPN2xNr4cchJVzZhxFi5U1HwAydsiZKy4=.1a3b0465-cfd8-47db-8ce0-6d48097e9305@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>
 <ah32eBkCAmE_qcaWAjWQ06ZphSqdrP2od_zCkCbrMCw=.826f91e3-dbe1-41bb-b2bf-7c67758ddda7@github.com>
 <c9qUdzr7umZ0atYWXDJ3dao4QYqLIvrWuy_eFBQX1kU=.d8836c3d-6aa3-484c-8eac-9b4bbb166537@github.com>
 <HvEEPP4CkmBPN2xNr4cchJVzZhxFi5U1HwAydsiZKy4=.1a3b0465-cfd8-47db-8ce0-6d48097e9305@github.com>
Message-ID: <fk5TFECD3xVh9kuE5XXN-1KXf9d9IVAVTgJ7x7gcas4=.bcc82bf3-ee12-4595-a2c7-9f712319a337@github.com>

On Thu, 26 May 2022 11:32:46 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> I think the problem is the definition of the pools. We seem to have nested pools but it is far from clear that this API/mechanism was designed/intended to support nested pools.
>
> In any case, it's unreasonable for getNonHeapMemoryUsage to count a piece of memory repeatedly, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage, which should be far beyond what developers expect. In a real scenario, some monitor platforms draw a line chart by collecting getHeapMemoryUsage and getNonHeapMemoryUsage. It's confusing for end-users of the monitor platform to understand why getHeapMemoryUsage is desired while getNonHeapMemoryUsage is bigger than expectation.
> 
> From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area:
> 
>      * Returns the current memory usage of the heap that
>      * is used for object allocation.  The heap consists
>      * of one or more memory pools.
> 
> 
> I propose to revise the Java doc to describe the definition of non-heap area more precisely:
> 
>     /**
>      * Returns the current memory usage of non-heap memory that
>      * contains code cache and metaspace.
>      * The non-heap memory consists of one or more memory pools.

Beside my general points, I think this patch makes sense. I agree with @kelthuzadx that counting Classspace twice is wrong, whatever the intention of this API originally was.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From cjplummer at openjdk.java.net  Thu May 26 16:53:33 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 26 May 2022 16:53:33 GMT
Subject: RFR: 8286983: rename jdb -trackvthreads and debug agent
 enumeratevthreads options and clarify "Preview Feature" nature of these
 options [v3]
In-Reply-To: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
Message-ID: <SRh1uyuDDgqFHa0DbHwRqW_aiZQBm9ZQf1loW4NZNww=.05300914-5748-4621-8fec-14ee04910dec@github.com>

> As part of the loom integration, jdb added `-trackvthreads` and the debug agent added `enumeratevthreads`. These options are being renamed to `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads` should not have been used). Also, the help text for these options now calls out that virtual threads are a Preview Feature.
> 
> After the update to help text, wlil look as follows:
> 
> jdb doc (search for "trackallthreads"): http://cr.openjdk.java.net/~cjplummer/8286983/jdb.html
> debug agent doc (seach for "includevirtualthreads"): http://cr.openjdk.java.net/~cjplummer/8286983/conninv.html
> 
> 
> $ jdb -listconnectors
> ...
>   Connector: com.sun.jdi.CommandLineLaunch  Transport: dt_socket
>     description: Launches target using Sun Java VM command line and attaches to it
> ...
>     Argument: includevirtualthreads Default value: n
>     description: List of all threads includes virtual threads as well as platform threads. Virtual threads are a preview feature of the Java platform.
> 
> 
> 
> $ jdb -help
> Usage: jdb <options> <class> <arguments>
> 
> where options include:
> ...
>     -dbgtrace [flags] print info for debugging jdb
>     -trackallthreads  Track all threads, including virtual threads.
>                       Virtual threads are a preview feature of the Java platform.
>     -tclient          run the application in the HotSpot(TM) Client Compiler
> ...
> 
> 
> 
> $ man -M ./build/linux-x64-debug/images/jdk/man/ jdb
> ...
>        -tclient
>               Runs the application in the Java HotSpot VM client.
> 
>        -trackallthreads
>               Track  all  threads  as  they  are  created,  including  Virtual
>               Threads.   See  Working  With  Virtual  Threads  below.  Virtual
>               threads are a preview feature of the Java platform.
> 
>        -tserver
>               Runs the application in the Java HotSpot VM server.
> ...
> WORKING WITH VIRTUAL THREADS
>        Virtual threads are a preview feature of the  Java  platform.   Preview
>        features  may  be removed in a future release, or upgraded to permanent
>        features of the Java platform.
> 
>        Often virtual theads are created in such large  numbers  and  frequency
> ...
> 
> 
> 
> $ java -agentlib:jdwp=help
>                Java Debugger JDWP Agent Library
>                --------------------------------
> 
>   (See the "VM Invocation Options" section of the JPDA
>    "Connection and Invocation Details" document for more information.)
> 
> jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]
> 
> Option Name and Value            Description                       Default
> ---------------------            -----------                       -------
> ...
> timeout=<timeout value>          for listen/attach in milliseconds n
> includevirtualthreads=y|n        List of all threads includes virtual threads as well as platform threads.
>                                  Virtual threads are a preview feature of the Java platform.
>                                                                    n
> mutf8=y|n                        output modified utf-8             n
> ...

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

  Rename loom debugger related flags and clarify in their help text that virtual threads are a preview feature.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8780/files
  - new: https://git.openjdk.java.net/jdk/pull/8780/files/23667503..6807075d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8780&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8780&range=01-02

  Stats: 39 lines in 13 files changed: 8 ins; 0 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8780.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8780/head:pull/8780

PR: https://git.openjdk.java.net/jdk/pull/8780

From cjplummer at openjdk.java.net  Thu May 26 16:53:33 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 26 May 2022 16:53:33 GMT
Subject: RFR: 8286983: rename jdb -trackvthreads and debug agent
 enumeratevthreads options and clarify "Preview Feature" nature of these
 options [v3]
In-Reply-To: <ArfIf-hctkyhLpHyPbaf8oG6FTH6JFbqO-G-5xjLgHs=.d532879e-7177-4ddd-90ea-d7019a2a342f@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
 <rjv3MNLFyCCAOaTpR5TOhuGVG364Be6HTBGMkjiOxgs=.1543d10a-6e7a-445d-8892-645c1bde8dac@github.com>
 <XccKZlWUIQS6BolQEAwRHs6_P_dlCNHvyPHKTrQDfXA=.b84273c7-fb3d-4aaf-8d21-be1b4657b6a7@github.com>
 <hFYsIjH1sDsXzyG0GEQ7YIsVB3opUPeeWXPvS6AOtwI=.e4ab1a8b-a5a3-469b-ba23-14565343ea2a@github.com>
 <5ZvGivHbAqBQ1Swni92NKMFCePP6b_BiwSLuk2O7SL4=.e1783148-7eae-43d6-91c8-becba8446285@github.com>
 <Aizyv-1jRWysfCZJWCuj7doc9tijClUtg9XYv_8ZYgQ=.9ffc19ba-aba6-4749-afcc-b559c43e78ef@github.com>
 <kRcMF98qgCMHXif_plcVfmkpwcoyjJYrYfah_YqA62o=.7d87c886-8899-4360-b020-de6f959a817c@github.com>
 <Lz6gpMbkQwOPFHWeMcDtEmQULNu_q9l1ytA421NftL0=.8df7f8f3-359a-40b2-8764-5343a24064ef@github.com>
 <RFfS9BZy4J87FVtMwl7Y9EaD0T0wnkPknTp7FY738Os=.a642c3b2-b501-43bf-9142-4dc5badc9935@github.com>
 <ArfIf-hctkyhLpHyPbaf8oG6FTH6JFbqO-G-5xjLgHs=.d532879e-7177-4ddd-90ea-d7019a2a342f@github.com>
Message-ID: <4ApfhxE5imWkGFe4PhjVE5xEkg3Tj1l1ApmkWHjkzxA=.be9c35fb-3896-4048-8ecb-10102b0f14a0@github.com>

On Thu, 26 May 2022 03:47:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Again I have to say I agree with Chris. The flag itself is a "preview" flag and relates to a "preview feature". If the feature goes obviously the flag does too, but the flag could go even if the feature stays.
>
> Please see the discussion with Alex in [JDK-8286983](https://bugs.openjdk.java.net/browse/JDK-8286983)

This PR has been updated to reflect the discussion in [JDK-8286983](https://bugs.openjdk.java.net/browse/JDK-8286983). Please re-review.

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From cjplummer at openjdk.java.net  Thu May 26 17:09:25 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 26 May 2022 17:09:25 GMT
Subject: RFR: 8286983: rename jdb -trackvthreads and debug agent
 enumeratevthreads options and clarify "Preview Feature" nature of these
 options [v4]
In-Reply-To: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
Message-ID: <SiX2uOSL0J8opRRFfaHUfgaZKV4Rn0fe7GKR8bWrLE8=.d4d515f4-e6f4-4c06-bab4-1bafcde74a52@github.com>

> As part of the loom integration, jdb added `-trackvthreads` and the debug agent added `enumeratevthreads`. These options are being renamed to `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads` should not have been used). Also, the help text for these options now calls out that virtual threads are a Preview Feature.
> 
> After the update to help text, wlil look as follows:
> 
> jdb doc (search for "trackallthreads"): http://cr.openjdk.java.net/~cjplummer/8286983/jdb.html
> debug agent doc (seach for "includevirtualthreads"): http://cr.openjdk.java.net/~cjplummer/8286983/conninv.html
> 
> 
> $ jdb -listconnectors
> ...
>   Connector: com.sun.jdi.CommandLineLaunch  Transport: dt_socket
>     description: Launches target using Sun Java VM command line and attaches to it
> ...
>     Argument: includevirtualthreads Default value: n
>     description: List of all threads includes virtual threads as well as platform threads. Virtual threads are a preview feature of the Java platform.
> 
> 
> 
> $ jdb -help
> Usage: jdb <options> <class> <arguments>
> 
> where options include:
> ...
>     -dbgtrace [flags] print info for debugging jdb
>     -trackallthreads  Track all threads, including virtual threads.
>                       Virtual threads are a preview feature of the Java platform.
>     -tclient          run the application in the HotSpot(TM) Client Compiler
> ...
> 
> 
> 
> $ man -M ./build/linux-x64-debug/images/jdk/man/ jdb
> ...
>        -tclient
>               Runs the application in the Java HotSpot VM client.
> 
>        -trackallthreads
>               Track  all  threads  as  they  are  created,  including  Virtual
>               Threads.   See  Working  With  Virtual  Threads  below.  Virtual
>               threads are a preview feature of the Java platform.
> 
>        -tserver
>               Runs the application in the Java HotSpot VM server.
> ...
> WORKING WITH VIRTUAL THREADS
>        Virtual threads are a preview feature of the  Java  platform.   Preview
>        features  may  be removed in a future release, or upgraded to permanent
>        features of the Java platform.
> 
>        Often virtual theads are created in such large  numbers  and  frequency
> ...
> 
> 
> 
> $ java -agentlib:jdwp=help
>                Java Debugger JDWP Agent Library
>                --------------------------------
> 
>   (See the "VM Invocation Options" section of the JPDA
>    "Connection and Invocation Details" document for more information.)
> 
> jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]
> 
> Option Name and Value            Description                       Default
> ---------------------            -----------                       -------
> ...
> timeout=<timeout value>          for listen/attach in milliseconds n
> includevirtualthreads=y|n        List of all threads includes virtual threads as well as platform threads.
>                                  Virtual threads are a preview feature of the Java platform.
>                                                                    n
> mutf8=y|n                        output modified utf-8             n
> ...

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

  Fix minor typo in comment.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8780/files
  - new: https://git.openjdk.java.net/jdk/pull/8780/files/6807075d..2a6f2e49

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8780&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8780&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From itakiguchi at openjdk.java.net  Thu May 26 17:33:14 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Thu, 26 May 2022 17:33:14 GMT
Subject: RFR: 8287362: FieldAccessWatch testcase failed on AIX platform
Message-ID: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>

On AIX platform, `test/hotspot/jtreg/serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java` testcase failed by single testcase execution.

Failure message is:

Error occurred during initialization of VM
agent library failed to init: FieldAccessWatch
Failed to set capabilities, error: 98

It seems following initialization code affects this issue

jvmtiCapabilities caps = {0};

So additionally `memset()` is required just for AIX platform

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

Commit messages:
 - 8287362: FieldAccessWatch testcase failed on AIX platform

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

PR: https://git.openjdk.java.net/jdk/pull/8904

From mchung at openjdk.java.net  Thu May 26 18:12:52 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 26 May 2022 18:12:52 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
Message-ID: <EGU8rSPMWJviKFzVfWp3lpPYiIq5bY3edkPWBpj9dKw=.49856662-e7e3-401e-a470-d00931a0a023@github.com>

On Mon, 23 May 2022 07:28:41 GMT, Yi Yang <yyang at openjdk.org> wrote:

> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
> 
> Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
> 
> ==> CodeHeap 'non-nmethods' 1532544 (Used)
> ==> CodeHeap 'profiled nmethods' 0
> ==> CodeHeap 'non-profiled nmethods' 13952
> ==> Metaspace 506696
> ==> Compressed Class Space 43312
> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K)
> 
> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`.

Memory pool API does not support "nested" memory pools (or sub-memory pools).  JDK 18 memory pools are the following:

HEAP      G1 Eden Space
HEAP      G1 Old Gen
HEAP      G1 Survivor Space
NON_HEAP  CodeHeap 'non-nmethods'
NON_HEAP  Metaspace
NON_HEAP  CodeHeap 'profiled nmethods'
NON_HEAP  Compressed Class Space
NON_HEAP  CodeHeap 'non-profiled nmethods'


If `Metaspace` memory pool contains the compressed class space, then I agree with David that the current non-heap memory pools need to be examined. The meta space should be separated into multiple non-heap memory pools without overlap.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From dholmes at openjdk.java.net  Thu May 26 22:20:41 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 May 2022 22:20:41 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <fk5TFECD3xVh9kuE5XXN-1KXf9d9IVAVTgJ7x7gcas4=.bcc82bf3-ee12-4595-a2c7-9f712319a337@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>
 <ah32eBkCAmE_qcaWAjWQ06ZphSqdrP2od_zCkCbrMCw=.826f91e3-dbe1-41bb-b2bf-7c67758ddda7@github.com>
 <c9qUdzr7umZ0atYWXDJ3dao4QYqLIvrWuy_eFBQX1kU=.d8836c3d-6aa3-484c-8eac-9b4bbb166537@github.com>
 <HvEEPP4CkmBPN2xNr4cchJVzZhxFi5U1HwAydsiZKy4=.1a3b0465-cfd8-47db-8ce0-6d48097e9305@github.com>
 <fk5TFECD3xVh9kuE5XXN-1KXf9d9IVAVTgJ7x7gcas4=.bcc82bf3-ee12-4595-a2c7-9f712319a337@github.com>
Message-ID: <Lp1eV4d_g__ysOrJkqrjw6n8Qq0jIGISIMb41ltPEZA=.d9187dd2-998a-4490-9077-3a6e0cac2ffa@github.com>

On Thu, 26 May 2022 13:47:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> In any case, it's unreasonable for getNonHeapMemoryUsage to count a piece of memory repeatedly, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage, which should be far beyond what developers expect. In a real scenario, some monitor platforms draw a line chart by collecting getHeapMemoryUsage and getNonHeapMemoryUsage. It's confusing for end-users of the monitor platform to understand why getHeapMemoryUsage is desired while getNonHeapMemoryUsage is bigger than expectation.
>> 
>> From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area:
>> 
>>      * Returns the current memory usage of the heap that
>>      * is used for object allocation.  The heap consists
>>      * of one or more memory pools.
>> 
>> 
>> I propose to revise the Java doc to describe the definition of non-heap area more precisely:
>> 
>>     /**
>>      * Returns the current memory usage of non-heap memory that
>>      * contains code cache and metaspace.
>>      * The non-heap memory consists of one or more memory pools.
>
> Beside my general points, I think this patch makes sense. I agree with @kelthuzadx that counting Classspace twice is wrong, whatever the intention of this API originally was.

Yes counting it twice is wrong but this is the wrong fix. The pools are not defined correctly.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From lmesnik at openjdk.java.net  Thu May 26 22:27:15 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 26 May 2022 22:27:15 GMT
Subject: RFR: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103 [v2]
In-Reply-To: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
References: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
Message-ID: <YD36HsAD4w8tWaKvrkAdyAOniyW4xB2uJldLozzGJ78=.f1376e7c-ebf0-4962-b9a7-d7fb878433cd@github.com>

> Need to use proper synchronization.
> 
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So it should not confuse existing checks.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8874/files
  - new: https://git.openjdk.java.net/jdk/pull/8874/files/3402eb82..c79aa582

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8874&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8874&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8874

From yyang at openjdk.java.net  Fri May 27 02:15:40 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 27 May 2022 02:15:40 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <Lp1eV4d_g__ysOrJkqrjw6n8Qq0jIGISIMb41ltPEZA=.d9187dd2-998a-4490-9077-3a6e0cac2ffa@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>
 <ah32eBkCAmE_qcaWAjWQ06ZphSqdrP2od_zCkCbrMCw=.826f91e3-dbe1-41bb-b2bf-7c67758ddda7@github.com>
 <c9qUdzr7umZ0atYWXDJ3dao4QYqLIvrWuy_eFBQX1kU=.d8836c3d-6aa3-484c-8eac-9b4bbb166537@github.com>
 <HvEEPP4CkmBPN2xNr4cchJVzZhxFi5U1HwAydsiZKy4=.1a3b0465-cfd8-47db-8ce0-6d48097e9305@github.com>
 <fk5TFECD3xVh9kuE5XXN-1KXf9d9IVAVTgJ7x7gcas4=.bcc82bf3-ee12-4595-a2c7-9f712319a337@github.com>
 <Lp1eV4d_g__ysOrJkqrjw6n8Qq0jIGISIMb41ltPEZA=.d9187dd2-998a-4490-9077-3a6e0cac2ffa@github.com>
Message-ID: <s9v3Fsg7ISGBrKd643WERncXR2VSVviosYhynpgpyrQ=.568d4f8d-70fc-41e6-9fa7-366b33d5afbe@github.com>

On Thu, 26 May 2022 22:17:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Beside my general points, I think this patch makes sense. I agree with @kelthuzadx that counting Classspace twice is wrong, whatever the intention of this API originally was.
>
> Yes counting it twice is wrong but this is the wrong fix. The pools are not defined correctly.

> Sorry for chiming in in a not very helpful way, but I am not sure what even the point is of this API.
> 
> I'm seriously interested in who uses it, and for what. Calculating real memory usage is notoriously difficult. This one seems to be just an arbitrary selection of stuff. It leaves out C-heap usage (VM, outer JDK, and third party libs), native mappings, sometimes massive system library overhead, text segments, thread stacks... that it counts class space twice is probably its smallest problem...

AFAIK, some DevOps platforms monitor JVM memory occupation by MemoryMXBean:

![image](https://user-images.githubusercontent.com/5010047/170614454-84e7fe3e-71bb-4277-8c03-db0f461d6ccf.png)

Users are confused about why `HeapMemory+NonHeapMemory` is not equal to resident memory(top->res). It's still not clear what NonHeap means from `Java Doc`, I tried to understand the definition of NonHeap in source code, then found this bug...

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From dholmes at openjdk.java.net  Fri May 27 05:04:28 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 27 May 2022 05:04:28 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <s9v3Fsg7ISGBrKd643WERncXR2VSVviosYhynpgpyrQ=.568d4f8d-70fc-41e6-9fa7-366b33d5afbe@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <BBMLFFuFyADjA-L-jHBQWn6khncrT6KqLMCcHxJZcmw=.a5d3aca1-112a-4231-98c8-4e8257b862ec@github.com>
 <ah32eBkCAmE_qcaWAjWQ06ZphSqdrP2od_zCkCbrMCw=.826f91e3-dbe1-41bb-b2bf-7c67758ddda7@github.com>
 <c9qUdzr7umZ0atYWXDJ3dao4QYqLIvrWuy_eFBQX1kU=.d8836c3d-6aa3-484c-8eac-9b4bbb166537@github.com>
 <HvEEPP4CkmBPN2xNr4cchJVzZhxFi5U1HwAydsiZKy4=.1a3b0465-cfd8-47db-8ce0-6d48097e9305@github.com>
 <fk5TFECD3xVh9kuE5XXN-1KXf9d9IVAVTgJ7x7gcas4=.bcc82bf3-ee12-4595-a2c7-9f712319a337@github.com>
 <Lp1eV4d_g__ysOrJkqrjw6n8Qq0jIGISIMb41ltPEZA=.d9187dd2-998a-4490-9077-3a6e0cac2ffa@github.com>
 <s9v3Fsg7ISGBrKd643WERncXR2VSVviosYhynpgpyrQ=.568d4f8d-70fc-41e6-9fa7-366b33d5afbe@github.com>
Message-ID: <uevT3q5Z1rIWXtURsuXw0WZmgL6ROcx9YJjZejhtRd0=.439d7e7f-398d-4ece-a705-d8a1b42fbb63@github.com>

On Fri, 27 May 2022 02:12:32 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Yes counting it twice is wrong but this is the wrong fix. The pools are not defined correctly.
>
>> Sorry for chiming in in a not very helpful way, but I am not sure what even the point is of this API.
>> 
>> I'm seriously interested in who uses it, and for what. Calculating real memory usage is notoriously difficult. This one seems to be just an arbitrary selection of stuff. It leaves out C-heap usage (VM, outer JDK, and third party libs), native mappings, sometimes massive system library overhead, text segments, thread stacks... that it counts class space twice is probably its smallest problem...
> 
> AFAIK, some DevOps platforms monitor JVM memory occupation by MemoryMXBean:
> 
> ![image](https://user-images.githubusercontent.com/5010047/170614454-84e7fe3e-71bb-4277-8c03-db0f461d6ccf.png)
> 
> Users are confused about why `HeapMemory+NonHeapMemory` is not equal to resident memory(top->res). It's still not clear what NonHeap means from `Java Doc`, I tried to understand the definition of NonHeap in source code, then found this bug...

"non-heap" is any memory not part of the Java heap. But it is up to an implementation to decide what kinds of non-heap memory are represented by memory pools. The JavaDoc can only give possible examples not numerate an actual required set.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From alanb at openjdk.java.net  Fri May 27 05:23:34 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 27 May 2022 05:23:34 GMT
Subject: RFR: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103 [v2]
In-Reply-To: <YD36HsAD4w8tWaKvrkAdyAOniyW4xB2uJldLozzGJ78=.f1376e7c-ebf0-4962-b9a7-d7fb878433cd@github.com>
References: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
 <YD36HsAD4w8tWaKvrkAdyAOniyW4xB2uJldLozzGJ78=.f1376e7c-ebf0-4962-b9a7-d7fb878433cd@github.com>
Message-ID: <K5gduq0eSv3q6Z0ch9-dVICRf10eKk1HYbakTTDtoFw=.c94abb89-f537-466d-9375-b1bdb510e5d2@github.com>

On Thu, 26 May 2022 22:27:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Need to use proper synchronization.
>> 
>> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So it should not confuse existing checks.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8874

From lmesnik at openjdk.java.net  Fri May 27 05:33:40 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 27 May 2022 05:33:40 GMT
Subject: Integrated: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103
In-Reply-To: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
References: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>
Message-ID: <Y9bHzzL8mGzLNrjP6S7jADSussXecfDOuojN4VN-9sQ=.3b75f37f-20fd-4d56-8e49-701606dbc74a@github.com>

On Tue, 24 May 2022 19:52:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Need to use proper synchronization.
> 
> The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So it should not confuse existing checks.

This pull request has now been integrated.

Changeset: 176bb23d
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/176bb23de18d9ab448e77e85a9c965a7c02f2c50
Stats:     9 lines in 1 file changed: 4 ins; 2 del; 3 mod

8287200: Test java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after JDK-8287103

Reviewed-by: kevinw, cjplummer, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8874

From dholmes at openjdk.java.net  Fri May 27 05:34:33 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 27 May 2022 05:34:33 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
Message-ID: <W89m8Pk1PGvgIMOh4e-o4v-PfGoOVuAkmywGuVNasy0=.e1bfeb55-4a9a-4e3f-994b-48344dd2f6ab@github.com>

On Mon, 23 May 2022 07:28:41 GMT, Yi Yang <yyang at openjdk.org> wrote:

> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
> 
> Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
> 
> ==> CodeHeap 'non-nmethods' 1532544 (Used)
> ==> CodeHeap 'profiled nmethods' 0
> ==> CodeHeap 'non-profiled nmethods' 13952
> ==> Metaspace 506696
> ==> Compressed Class Space 43312
> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K)
> 
> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`.

The basic problem is that we have two non-heap pools:
- `MetaspacePool`
  - consists of `ClassType` and `NonClassType` parts
- `CompressedKlassSpacePool`

but the `CompressedKlassSpacePool` is actually the "ClassType" part of the `MetaspacePool`!

I think the right fix is to just convert the `MetaspacePool` into `NonClassMetaspacePool` and only report the non-class values.

AFAICS this will only be visible via the MXBean.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From dholmes at openjdk.java.net  Fri May 27 06:19:43 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 27 May 2022 06:19:43 GMT
Subject: RFR: 8287362: FieldAccessWatch testcase failed on AIX platform
In-Reply-To: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
References: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
Message-ID: <NoTaUM_pI3h7jGNPIv5S1kJzXqA7FRD0wiTjK0zSJPw=.cda72541-9346-4cdd-b69a-f8abde0f6541@github.com>

On Thu, 26 May 2022 17:26:25 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX platform, `test/hotspot/jtreg/serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java` testcase failed by single testcase execution.
> 
> Failure message is:
> 
> Error occurred during initialization of VM
> agent library failed to init: FieldAccessWatch
> Failed to set capabilities, error: 98
> 
> It seems following initialization code affects this issue
> 
> jvmtiCapabilities caps = {0};
> 
> So additionally `memset()` is required just for AIX platform

Given 99.9% of the tests don't try to initialize "caps" but instead do the memset, I would suggest it is perfectly fine to delete the initializer and remove the comments related to AIX/xlclang.

You may also need to check
hotspot/jtreg/runtime/jni/FastGetField/libFastGetField.c 
hotspot/jtreg/compiler/jsr292/cr8026328/libTest8026328.c
which have a similar usage for the callbacks structure.

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

PR: https://git.openjdk.java.net/jdk/pull/8904

From iklam at openjdk.java.net  Fri May 27 06:25:31 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 27 May 2022 06:25:31 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <W89m8Pk1PGvgIMOh4e-o4v-PfGoOVuAkmywGuVNasy0=.e1bfeb55-4a9a-4e3f-994b-48344dd2f6ab@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <W89m8Pk1PGvgIMOh4e-o4v-PfGoOVuAkmywGuVNasy0=.e1bfeb55-4a9a-4e3f-994b-48344dd2f6ab@github.com>
Message-ID: <YSILLpb-j71EVUYggJ8PftPFidqbPqq80PdSgLWkYnA=.9871849b-c911-4cfa-a99b-866b011658dc@github.com>

On Fri, 27 May 2022 05:31:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The basic problem is that we have two non-heap pools:
> 
> * `MetaspacePool`
>   
>   * consists of `ClassType` and `NonClassType` parts
> * `CompressedKlassSpacePool`
> 
> but the `CompressedKlassSpacePool` is actually the "ClassType" part of the `MetaspacePool`!
> 
> I think the right fix is to just convert the `MetaspacePool` into `NonClassMetaspacePool` and only report the non-class values.
> 
> AFAICS this will only be visible via the MXBean.

When CDS is enabled, the CompressedKlassSpacePool actually contains more than Klass objects. It can contain other metadata such as Method, ConstantPool, etc. So calling these pools "class" and "non-class" is not 100% correct.

Is there any reason for separating the CompressedKlassSpacePool from other metadata? I know in the past it was possible to run out of spaces in CompressedKlassSpace, so there might be a reason to monitor it separately?

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From yyang at openjdk.java.net  Fri May 27 06:29:39 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 27 May 2022 06:29:39 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <YSILLpb-j71EVUYggJ8PftPFidqbPqq80PdSgLWkYnA=.9871849b-c911-4cfa-a99b-866b011658dc@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <W89m8Pk1PGvgIMOh4e-o4v-PfGoOVuAkmywGuVNasy0=.e1bfeb55-4a9a-4e3f-994b-48344dd2f6ab@github.com>
 <YSILLpb-j71EVUYggJ8PftPFidqbPqq80PdSgLWkYnA=.9871849b-c911-4cfa-a99b-866b011658dc@github.com>
Message-ID: <c8kzyx4nxtHB874iDQMl_xeRjFv0KshCemYz2eU8zTw=.e4604f52-fb97-4fda-a76e-5630082eb5c7@github.com>

On Fri, 27 May 2022 06:22:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I think the right fix is to just convert the MetaspacePool into NonClassMetaspacePool and only report the non-class values.

Yes, it's okay for me. But I have another concern.

The compressed class pool is not directly used by other VM components. However, memory pools are exposed via java management APIs. At JDK level, users could obtain memory pools and choose a specified pool by name. If adapting the first solution, I guess it's somewhat strange for users to understand what is `Non Class Space`:

  private static MemoryPoolMXBean getMemoryPool(String name) {
        List<MemoryPoolMXBean> pools = ManagementFactory.getMemoryPoolMXBeans();
        for (MemoryPoolMXBean pool : pools) {
            if (pool.getName().equals(name)) {
                return pool;
            }
        }

        throw new RuntimeException("Expected to find a memory pool with name " + name);
    }
  public static void foo() {
     MemoryPoolMXBean a = getMemoryPool("Compressed Class Space");
     MemoryPoolMXBean a = getMemoryPool("Non Class Space");
  }

If we remove `CompressedClassSpace`, we can only `getMemoryPool("Metaspace")`. Although metaspace is not baked in the specification, IMHO it's easier for developers to understand what is `metaspace` compared to the concepts of `Non Class Space` and `Compressed Class Space`.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From stuefe at openjdk.java.net  Fri May 27 07:27:49 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 27 May 2022 07:27:49 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <YSILLpb-j71EVUYggJ8PftPFidqbPqq80PdSgLWkYnA=.9871849b-c911-4cfa-a99b-866b011658dc@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <W89m8Pk1PGvgIMOh4e-o4v-PfGoOVuAkmywGuVNasy0=.e1bfeb55-4a9a-4e3f-994b-48344dd2f6ab@github.com>
 <YSILLpb-j71EVUYggJ8PftPFidqbPqq80PdSgLWkYnA=.9871849b-c911-4cfa-a99b-866b011658dc@github.com>
Message-ID: <VTVzffMvuUqTE7aABIJQVCMJg-rdHcOF3bt6YLp-R8o=.18fa3d0d-f3fe-4930-aeaf-470c1c1b3bb5@github.com>

On Fri, 27 May 2022 06:22:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > The basic problem is that we have two non-heap pools:
> > 
> > * `MetaspacePool`
> >   
> >   * consists of `ClassType` and `NonClassType` parts
> > * `CompressedKlassSpacePool`
> > 
> > but the `CompressedKlassSpacePool` is actually the "ClassType" part of the `MetaspacePool`!
> > I think the right fix is to just convert the `MetaspacePool` into `NonClassMetaspacePool` and only report the non-class values.
> > AFAICS this will only be visible via the MXBean.
> 
> When CDS is enabled, the CompressedKlassSpacePool actually contains more than Klass objects. It can contain other metadata such as Method, ConstantPool, etc. So calling these pools "class" and "non-class" is not 100% correct.
> 
> Is there any reason for separating the CompressedKlassSpacePool from other metadata? I know in the past it was possible to run out of spaces in CompressedKlassSpace, so there might be a reason to monitor it separately?

Yes, you can run out of Class space separately from Metaspace.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From stuefe at openjdk.java.net  Fri May 27 07:27:51 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 27 May 2022 07:27:51 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <c8kzyx4nxtHB874iDQMl_xeRjFv0KshCemYz2eU8zTw=.e4604f52-fb97-4fda-a76e-5630082eb5c7@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <W89m8Pk1PGvgIMOh4e-o4v-PfGoOVuAkmywGuVNasy0=.e1bfeb55-4a9a-4e3f-994b-48344dd2f6ab@github.com>
 <YSILLpb-j71EVUYggJ8PftPFidqbPqq80PdSgLWkYnA=.9871849b-c911-4cfa-a99b-866b011658dc@github.com>
 <c8kzyx4nxtHB874iDQMl_xeRjFv0KshCemYz2eU8zTw=.e4604f52-fb97-4fda-a76e-5630082eb5c7@github.com>
Message-ID: <j4oNFVEdP-qQGTNG3rECzD6Vlmq6ez-dEYaAv31JrZY=.76641593-de66-4db8-b5d7-8d0e9bd86e1a@github.com>

On Fri, 27 May 2022 06:25:45 GMT, Yi Yang <yyang at openjdk.org> wrote:

> 
> If we remove `CompressedClassSpace`, we can only `getMemoryPool("Metaspace")`. Although metaspace is not baked in the specification, IMHO it's easier for developers to understand what is `metaspace` compared to the concepts of `Non Class Space` and `Compressed Class Space`.

I personally think that would be totally fine.

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From mdoerr at openjdk.java.net  Fri May 27 09:45:37 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 27 May 2022 09:45:37 GMT
Subject: RFR: 8287362: FieldAccessWatch testcase failed on AIX platform
In-Reply-To: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
References: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
Message-ID: <2Ey3CxtmkphJ3uS1ET5kzpfpo5FLfcDeaSf_xWkdwJE=.422f8607-51a7-4303-9124-e8e843fa033f@github.com>

On Thu, 26 May 2022 17:26:25 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX platform, `test/hotspot/jtreg/serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java` testcase failed by single testcase execution.
> 
> Failure message is:
> 
> Error occurred during initialization of VM
> agent library failed to init: FieldAccessWatch
> Failed to set capabilities, error: 98
> 
> It seems following initialization code affects this issue
> 
> jvmtiCapabilities caps = {0};
> 
> So additionally `memset()` is required just for AIX platform

I agree with David.
In addition, I suggest reporting this issue to the xlclang folks.

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

PR: https://git.openjdk.java.net/jdk/pull/8904

From sspitsyn at openjdk.java.net  Fri May 27 12:25:53 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 27 May 2022 12:25:53 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <GQkfMFjVzI41McoUU3PY7QKCP_XqEsaGQlehxZRtang=.53f42372-96d4-4a3c-88dc-f789ade041b9@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

Requiring protection of current thread with TLH makes it ugly for cases of self suspend as a nested extra TLH is required to protect current thread. The issue with self suspends is that having a jvmtiVTMSTransitionDisabler in its context is not allowed as it would cause deadlocks.
Not requiring TLH for protection of current thread makes TLH congruent with jvmtiVTMSTransitionDisabler.

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From itakiguchi at openjdk.java.net  Fri May 27 18:29:26 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 27 May 2022 18:29:26 GMT
Subject: RFR: 8287362: FieldAccessWatch testcase failed on AIX platform
 [v2]
In-Reply-To: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
References: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
Message-ID: <qFN3Bj72aAK_q3fWjImVeaR93gN6iIfNx0ubDCqsWnI=.91c041d2-019d-430d-ab61-10df39681ba0@github.com>

> On AIX platform, `test/hotspot/jtreg/serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java` testcase failed by single testcase execution.
> 
> Failure message is:
> 
> Error occurred during initialization of VM
> agent library failed to init: FieldAccessWatch
> Failed to set capabilities, error: 98
> 
> It seems following initialization code affects this issue
> 
> jvmtiCapabilities caps = {0};
> 
> So additionally `memset()` is required just for AIX platform

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8287362: FieldAccessWatch testcase failed on AIX platform

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8904/files
  - new: https://git.openjdk.java.net/jdk/pull/8904/files/53c1ff71..ff955e1e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8904&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8904&range=00-01

  Stats: 18 lines in 4 files changed: 4 ins; 5 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8904.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8904/head:pull/8904

PR: https://git.openjdk.java.net/jdk/pull/8904

From itakiguchi at openjdk.java.net  Fri May 27 19:04:49 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 27 May 2022 19:04:49 GMT
Subject: RFR: 8287362: FieldAccessWatch testcase failed on AIX platform
 [v2]
In-Reply-To: <NoTaUM_pI3h7jGNPIv5S1kJzXqA7FRD0wiTjK0zSJPw=.cda72541-9346-4cdd-b69a-f8abde0f6541@github.com>
References: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
 <NoTaUM_pI3h7jGNPIv5S1kJzXqA7FRD0wiTjK0zSJPw=.cda72541-9346-4cdd-b69a-f8abde0f6541@github.com>
Message-ID: <2se6OWL6c8qRpW2h-TTlGZfiUz3QTf6-ojWkCYK6zZU=.0a4333ec-8c5a-41dd-9e79-d3484241fe6a@github.com>

On Fri, 27 May 2022 06:15:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8287362: FieldAccessWatch testcase failed on AIX platform
>
> Given 99.9% of the tests don't try to initialize "caps" but instead do the memset, I would suggest it is perfectly fine to delete the initializer and remove the comments related to AIX/xlclang.
> 
> You may also need to check
> hotspot/jtreg/runtime/jni/FastGetField/libFastGetField.c 
> hotspot/jtreg/compiler/jsr292/cr8026328/libTest8026328.c
> which have a similar usage for the callbacks structure.

Hello @dholmes-ora and @TheRealMDoerr .
I appreciate your suggestions.
I checked other files which were use `jvmtiEventCallbacks` structure initializer.
`jvmtiEventCallbacks` structure was initialized properly with AIX's xlclang compiler.
It seems only `jvmtiCapabilities` structure initializer does not work as expected with xlclang.
I tried to create small testcase for this issue.
According to `jvmti.h`, `jvmtiCapabilities` structure likes:

typedef struct {
    unsigned int can_tag_objects : 1;
    unsigned int can_generate_field_modification_events : 1;
    unsigned int can_generate_field_access_events : 1;
    unsigned int can_get_bytecodes : 1;
......
    unsigned int can_generate_sampled_object_alloc_events : 1;
    unsigned int can_support_virtual_threads : 1;
    unsigned int : 3;
    unsigned int : 16;
    unsigned int : 16;
    unsigned int : 16;
    unsigned int : 16;
    unsigned int : 16;
} jvmtiCapabilities;

This structure can handle bits and it has padding data without variable name.
It seems xlclang initializes only variable name is available by initializer.
So last part is not initialized.
If I put dummy variable name into above structure, all bytes are initialized properly.
I checked other source files which used `jvmtiCapabilities` structure, they used `memset()` instead of initializer.
I removed `jvmtiCapabilities` and `jvmtiEventCallbacks` initializer and add `memset()`

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

PR: https://git.openjdk.java.net/jdk/pull/8904

From cjplummer at openjdk.java.net  Fri May 27 19:45:49 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 27 May 2022 19:45:49 GMT
Subject: RFR: 8287362: FieldAccessWatch testcase failed on AIX platform
 [v2]
In-Reply-To: <qFN3Bj72aAK_q3fWjImVeaR93gN6iIfNx0ubDCqsWnI=.91c041d2-019d-430d-ab61-10df39681ba0@github.com>
References: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
 <qFN3Bj72aAK_q3fWjImVeaR93gN6iIfNx0ubDCqsWnI=.91c041d2-019d-430d-ab61-10df39681ba0@github.com>
Message-ID: <9tYRPZpbx5wBo5vhw-69Oi97FPJtONS2VmqsJNtHMms=.979775fe-437f-4b61-9c0b-7d805a9bdfd8@github.com>

On Fri, 27 May 2022 18:29:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On AIX platform, `test/hotspot/jtreg/serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java` testcase failed by single testcase execution.
>> 
>> Failure message is:
>> 
>> Error occurred during initialization of VM
>> agent library failed to init: FieldAccessWatch
>> Failed to set capabilities, error: 98
>> 
>> It seems following initialization code affects this issue
>> 
>> jvmtiCapabilities caps = {0};
>> 
>> So additionally `memset()` is required just for AIX platform
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287362: FieldAccessWatch testcase failed on AIX platform

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8904

From amenkov at openjdk.java.net  Fri May 27 21:24:45 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 27 May 2022 21:24:45 GMT
Subject: RFR: 8279358:
 vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java
 fails with usage tracker
In-Reply-To: <uu8mRgNuhwkn7dHQYFMxIrYDXVIDH-4E3cnzlyEtRjU=.fcfb44f5-d922-4bb2-8f7a-bfefaf5e722a@github.com>
References: <uu8mRgNuhwkn7dHQYFMxIrYDXVIDH-4E3cnzlyEtRjU=.fcfb44f5-d922-4bb2-8f7a-bfefaf5e722a@github.com>
Message-ID: <Tkxq55jqLzwMAyTSSyJiNT8RDm-VpcuBdB39Oaq1UaY=.f76043b8-981e-449c-b3e6-d00989c5cdc4@github.com>

On Mon, 9 May 2022 21:26:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> isThreadExpected function checks only some known JFR/Graal threads.
> This approach requires to keep this function up to date (add other internal threads like usage tracker, loom, etc).
> 
> To avoid this updated all tests which use it, now the tests filter out all unknown threads.

Ping. Need 2nd review.

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

PR: https://git.openjdk.java.net/jdk/pull/8614

From mdoerr at openjdk.java.net  Fri May 27 21:41:51 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 27 May 2022 21:41:51 GMT
Subject: RFR: 8287362: FieldAccessWatch testcase failed on AIX platform
 [v2]
In-Reply-To: <qFN3Bj72aAK_q3fWjImVeaR93gN6iIfNx0ubDCqsWnI=.91c041d2-019d-430d-ab61-10df39681ba0@github.com>
References: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
 <qFN3Bj72aAK_q3fWjImVeaR93gN6iIfNx0ubDCqsWnI=.91c041d2-019d-430d-ab61-10df39681ba0@github.com>
Message-ID: <8o2RZcTTqR3N-0EfxF4qCopjpuOqdbUXzhUoHUTskZY=.1a577acd-d0de-4cb2-8444-6d192e3f79fa@github.com>

On Fri, 27 May 2022 18:29:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On AIX platform, `test/hotspot/jtreg/serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java` testcase failed by single testcase execution.
>> 
>> Failure message is:
>> 
>> Error occurred during initialization of VM
>> agent library failed to init: FieldAccessWatch
>> Failed to set capabilities, error: 98
>> 
>> It seems following initialization code affects this issue
>> 
>> jvmtiCapabilities caps = {0};
>> 
>> So additionally `memset()` is required just for AIX platform
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287362: FieldAccessWatch testcase failed on AIX platform

Marked as reviewed by mdoerr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8904

From iklam at openjdk.java.net  Fri May 27 21:45:42 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 27 May 2022 21:45:42 GMT
Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong
In-Reply-To: <j4oNFVEdP-qQGTNG3rECzD6Vlmq6ez-dEYaAv31JrZY=.76641593-de66-4db8-b5d7-8d0e9bd86e1a@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
 <W89m8Pk1PGvgIMOh4e-o4v-PfGoOVuAkmywGuVNasy0=.e1bfeb55-4a9a-4e3f-994b-48344dd2f6ab@github.com>
 <YSILLpb-j71EVUYggJ8PftPFidqbPqq80PdSgLWkYnA=.9871849b-c911-4cfa-a99b-866b011658dc@github.com>
 <c8kzyx4nxtHB874iDQMl_xeRjFv0KshCemYz2eU8zTw=.e4604f52-fb97-4fda-a76e-5630082eb5c7@github.com>
 <j4oNFVEdP-qQGTNG3rECzD6Vlmq6ez-dEYaAv31JrZY=.76641593-de66-4db8-b5d7-8d0e9bd86e1a@github.com>
Message-ID: <oP7AilQrqdY2_PRNwVsw4FtcrH0WlaKo4-f81V4jeyc=.a4333a66-177a-48f0-8817-5689de583b8f@github.com>

On Fri, 27 May 2022 07:22:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > If we remove `CompressedClassSpace`, we can only `getMemoryPool("Metaspace")`. Although metaspace is not baked in the specification, IMHO it's easier for developers to understand what is `metaspace` compared to the concepts of `Non Class Space` and `Compressed Class Space`.
> 
> I personally think that would be totally fine.

I also vote for removing `CompressedClassSpacePool`

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

PR: https://git.openjdk.java.net/jdk/pull/8831

From kemperw at amazon.com  Fri May 27 22:12:29 2022
From: kemperw at amazon.com (Kemper, William)
Date: Fri, 27 May 2022 22:12:29 +0000
Subject: Concurrent heap monitoring
In-Reply-To: <CA+3eh10=hF7HpnED9nTsRZ+_UiVCnEJvm65qT5wFBa03DgpoKg@mail.gmail.com>
References: <1653083191904.40109@amazon.com>,
 <CA+3eh10=hF7HpnED9nTsRZ+_UiVCnEJvm65qT5wFBa03DgpoKg@mail.gmail.com>
Message-ID: <1653689549469.91000@amazon.com>

The feature is independent from GCs, but it is aware of GC activity and it may be preempted by the GC at any time (which causes the loss of any work in progress). We have only tested it with G1, but we expect it to work with Parallel and Serial collectors. It is meant to stay out of the way of GC, but it is not yet aware of the concurrent phases of G1, Shenandoah and ZGC, so there is more work to be done here.


Thank you for the questions,

William


________________________________
From: Volker Simonis <volker.simonis at gmail.com>
Sent: Saturday, May 21, 2022 12:49 AM
To: Kemper, William
Cc: serviceability-dev
Subject: RE: [EXTERNAL]Concurrent heap monitoring


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


This sounds very interesting. Does this feature work with every GC or  does the implementation depend on specific GCs (and if the latter, which GCs does your prototype currently support).

Kemper, William <kemperw at amazon.com<mailto:kemperw at amazon.com>> schrieb am Fr., 20. Mai 2022, 23:46:

Taking a heap dump is a stop the world event. Garbage collection events can provide heap utilization information only after a cycle completes. We've found that detailed heap occupancy data (such as heap inspections provide) are too expensive to use for production monitoring.  Similarly, we find that heap statistics generated from collection cycles may come too late and may not provide enough detail (young collections do not reflect the state of the old generation). We have developed a prototype feature to provide detailed heap metrics concurrently, without barriers. It therefore provides only an estimate as changes to the object graph may cause it to miss objects. We would like to hear the thoughts of serviceability experts on such a thing. It is only at the proof of concept phase, but it is able to run popular benchmarks (specjbb, dacapo) with minimal overhead and the estimates are sufficiently accurate for our use cases (monitoring heap and object growth rates).


Thank you for reading,

William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20220527/5da84b99/attachment-0001.htm>

From itakiguchi at openjdk.java.net  Sat May 28 05:36:30 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sat, 28 May 2022 05:36:30 GMT
Subject: Integrated: 8287362: FieldAccessWatch testcase failed on AIX platform
In-Reply-To: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
References: <0Epg6oo7NjeIDZHhL8ZTLtcAfzuhtz_OKf221Ek8qu8=.a7ec556d-4149-4d20-bb23-2aa3d19f29bb@github.com>
Message-ID: <IK6zfuN-9KBvGUB_-EkB3KUzUfKo5HdM5wZ_7lpu3lI=.0b49a89a-b062-41dc-b9cb-43112e49cab9@github.com>

On Thu, 26 May 2022 17:26:25 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On AIX platform, `test/hotspot/jtreg/serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java` testcase failed by single testcase execution.
> 
> Failure message is:
> 
> Error occurred during initialization of VM
> agent library failed to init: FieldAccessWatch
> Failed to set capabilities, error: 98
> 
> It seems following initialization code affects this issue
> 
> jvmtiCapabilities caps = {0};
> 
> So additionally `memset()` is required just for AIX platform

This pull request has now been integrated.

Changeset: 66340372
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/66340372d595aeb4b3dfd9169a8448f363097256
Stats:     14 lines in 4 files changed: 5 ins; 0 del; 9 mod

8287362: FieldAccessWatch testcase failed on AIX platform

Reviewed-by: cjplummer, mdoerr

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

PR: https://git.openjdk.java.net/jdk/pull/8904

From ngasson at openjdk.java.net  Mon May 30 08:15:01 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 30 May 2022 08:15:01 GMT
Subject: Integrated: 8286711: AArch64: serviceability agent tests fail with PAC
 enabled
In-Reply-To: <HrusXjkc89qs4KckW40XWqMBFc1XlfmPt6aNhPxn3Vk=.dbd3dadb-27c9-46fc-a065-0c13fdea2bfc@github.com>
References: <HrusXjkc89qs4KckW40XWqMBFc1XlfmPt6aNhPxn3Vk=.dbd3dadb-27c9-46fc-a065-0c13fdea2bfc@github.com>
Message-ID: <-eeVQRlZT7jphXBlNqJPz5BY04hnfa5aefYveelwIIU=.c9c0faf5-78ee-4372-9288-e850a6b6483a@github.com>

On Fri, 20 May 2022 15:52:04 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU, the upper bits of the saved link register contain a "pointer authentication code" which must be checked and removed by a special instruction before a function returns.  The serviceability agent is unaware of this and so sees garbled PC values when walking the stack. This patch just masks out the PAC bits from the sender PC after reading it from the stack frame.

This pull request has now been integrated.

Changeset: d8331737
Author:    Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d8331737ad09fb989c492bdfe3868a7ae66e32af
Stats:     43 lines in 5 files changed: 35 ins; 2 del; 6 mod

8286711: AArch64: serviceability agent tests fail with PAC enabled

Reviewed-by: dholmes, cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/8814

From alanb at openjdk.java.net  Tue May 31 11:43:14 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 31 May 2022 11:43:14 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps to
 OS thread
Message-ID: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>

This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:

1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)

The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

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

Commit messages:
 - Continuation clinit should fail if no continuations support
 - Fix merge issue with test
 - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION
 - Update
 - Expend test coverage
 - Merge
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/8939/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287496
  Stats: 742 lines in 71 files changed: 570 ins; 53 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8939.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8939/head:pull/8939

PR: https://git.openjdk.java.net/jdk/pull/8939

From duke at openjdk.java.net  Tue May 31 11:43:15 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Tue, 31 May 2022 11:43:15 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread
In-Reply-To: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
Message-ID: <7FdpvW58T55cnXD59rW5-71p7ENg2Q7BNfW5djYTGuU=.0fda930a-6b25-4be3-b329-945b9734d6d7@github.com>

On Sun, 29 May 2022 14:46:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
> 
> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
> 
> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

Since?the?package `jdk.internal.access` is?exported[^1] to?the?`java.management`?module, this?can?use `MethodHandle`s obtained?using the?trusted?lookup.

[^1]: https://github.com/openjdk/jdk/blob/73ba7fdce838ba8a2c227a972c176311e6cc0b41/src/java.base/share/classes/module-info.java#L151-L154

src/java.management/share/classes/java/lang/management/ThreadInfo.java line 971:

> 969:             throw new InternalError(e);
> 970:         }
> 971:     }

Suggestion:

    private static boolean isVirtual(Thread thread) {
        try {
            return (boolean) IS_VIRTUAL.invokeExact(thread);
        } catch (Error | RuntimeException e) {
            throw e;
        } catch (Throwable t) {
            throw new InternalError(t);
        }
    }

    private static final MethodHandle IS_VIRTUAL;
    static {
        final JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess();
        try {
            MethodHandle m = JLIA.findVirtual(Thread.class, "isVirtual", MethodType.methodType(boolean.class));
            assert m != null;
            IS_VIRTUAL = m;
        } catch (Exception e) {
            throw new InternalError(e);
        }
    }

src/java.management/share/classes/sun/management/ThreadImpl.java line 661:

> 659: 
> 660:     private static final Method THREAD_IS_VIRTUAL = threadIsVirtual();
> 661:     private static final Field THREADINFO_VIRTUAL = threadInfoVirtual();

Suggestion:

    private static boolean isVirtual(Thread thread) {
        try {
            return (boolean) THREAD_IS_VIRTUAL.invokeExact(thread);
        } catch (Error | RuntimeException e) {
            throw e;
        } catch (Throwable t) {
            throw new InternalError(t);
        }
    }

    /**
     * Returns true if the given ThreadInfo is for a virutal thread.
     */
    private static boolean isVirtual(ThreadInfo threadInfo) {
        try {
            return (boolean) THREADINFO_VIRTUAL.invokeExact(threadInfo);
        } catch (Error | RuntimeException e) {
            throw e;
        } catch (Throwable t) {
            throw new InternalError(t);
        }
    }

    private static final JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess();

    private static MethodHandle threadIsVirtual() {
        try {
            MethodHandle m = JLIA.findVirtual(Thread.class, "isVirtual", MethodType.methodType(boolean.class));
            assert m != null;
            return m;
        } catch (Exception e) {
            throw new InternalError(e);
        }
    }

    @SuppressWarnings("removal")
    private static MethodHandle threadInfoVirtual() {
        PrivilegedExceptionAction<Field> pa = () -> ThreadInfo.class.getDeclaredField("virtual");
        try {
            return JLIA.unreflectField(AccessController.doPrivileged(pa), false);
        } catch (Exception e) {
            throw new InternalError(e);
        }
    }

    private static final MethodHandle THREAD_IS_VIRTUAL = threadIsVirtual();
    private static final MethodHandle THREADINFO_VIRTUAL = threadInfoVirtual();

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

PR: https://git.openjdk.java.net/jdk/pull/8939

From alanb at openjdk.java.net  Tue May 31 11:43:15 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 31 May 2022 11:43:15 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread
In-Reply-To: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
Message-ID: <wMOLbw8a7kxhxaTQUFTL5d5-XL5MBqDHiD1Dqm3i5sM=.a6714b0a-c1cf-4cf0-a0bf-30e3723248ac@github.com>

On Sun, 29 May 2022 14:46:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
> 
> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
> 
> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

> Since?the?package `jdk.internal.access` is?exported[1](#user-content-fn-1-97aea7d7960164849e591e42b91fb5c4) to?the?`java.management`?module, this?can?use `MethodHandle`s obtained?using the?trusted?lookup.

That export is for another reason, and probably should be re-examined so that java.base doesn't need to export this package to java.management. In any case, we expect there will be compiler support soon to allow java.management be compiled with code that makes use of preview APIs in java.base. That will at least us reference Thread::isVirtual from code.

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

PR: https://git.openjdk.java.net/jdk/pull/8939

From alanb at openjdk.java.net  Tue May 31 15:39:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 31 May 2022 15:39:39 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
Message-ID: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>

> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
> 
> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
> 
> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Allowing linking without intrinsic stub, contributed-by: rehn

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8939/files
  - new: https://git.openjdk.java.net/jdk/pull/8939/files/7989708b..126e38b6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8939

From bulasevich at openjdk.java.net  Tue May 31 16:58:42 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Tue, 31 May 2022 16:58:42 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
Message-ID: <t3_rXPchNY-df1u0SOxZUX1eqXSA6Ca4_8kz4sVumCg=.ce68380d-a517-41bc-bf02-3e4035bd668e@github.com>

On Tue, 31 May 2022 15:39:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
>> 
>> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
>> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
>> 
>> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allowing linking without intrinsic stub, contributed-by: rehn

I expected this change to fix the broken ARM32 port, but it doesn't work.

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (templateInterpreterGenerator_arm.cpp:732), pid=27345, tid=27346
#  Error: Unimplemented()
#
# JRE version:  (19.0) (build )
# Java VM: OpenJDK Server VM (19-commit6f6486e9-adhoc.re.jdk, mixed mode, g1 gc, linux-arm)
# Problematic frame:
# V  [libjvm.so+0xa14fe0]  TemplateInterpreterGenerator::generate_Continuation_doYield_entry()+0x2c

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

PR: https://git.openjdk.java.net/jdk/pull/8939

From shade at openjdk.java.net  Tue May 31 17:07:43 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 May 2022 17:07:43 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <t3_rXPchNY-df1u0SOxZUX1eqXSA6Ca4_8kz4sVumCg=.ce68380d-a517-41bc-bf02-3e4035bd668e@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
 <t3_rXPchNY-df1u0SOxZUX1eqXSA6Ca4_8kz4sVumCg=.ce68380d-a517-41bc-bf02-3e4035bd668e@github.com>
Message-ID: <jojfLI3jGW_hWmqexEbMsfzaby1mpk__Dftyx6QGulQ=.2a82ccd0-a9dd-4b1a-a28d-aed331490dec@github.com>

On Tue, 31 May 2022 16:54:41 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> I expected this change to fix the broken ARM32 port, but it doesn't work.

It would not fix ARM32, because the interpreter stubs need to be predicated on `Continuations::enabled()`. Also, as my ARM32 experiments show (https://github.com/openjdk/jdk/pull/8634/files#diff-027490ce3f4a92be9b489d9d2e54c7baaea87b7489399b198543c79f1ce1e2e3R4208-R4216) -- there is a breakage somewhere in C2 as well, which this patch would not seem to resolve as well. So, this is a stepping stone for *some* support, but it does not resolve porting situation fully.

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

PR: https://git.openjdk.java.net/jdk/pull/8939

From alanb at openjdk.java.net  Tue May 31 17:10:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 31 May 2022 17:10:45 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <jojfLI3jGW_hWmqexEbMsfzaby1mpk__Dftyx6QGulQ=.2a82ccd0-a9dd-4b1a-a28d-aed331490dec@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
 <t3_rXPchNY-df1u0SOxZUX1eqXSA6Ca4_8kz4sVumCg=.ce68380d-a517-41bc-bf02-3e4035bd668e@github.com>
 <jojfLI3jGW_hWmqexEbMsfzaby1mpk__Dftyx6QGulQ=.2a82ccd0-a9dd-4b1a-a28d-aed331490dec@github.com>
Message-ID: <CiOq7WhBN19qrIhclF6xWxS7ii8QXKaxRul0MQ-mYGg=.7e325d78-b6c1-4a12-91e6-fb971ce2c5fa@github.com>

On Tue, 31 May 2022 17:03:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I expected this change to fix the broken ARM32 port, but it doesn't work.

There is work required to get the arm32 port working again, currently tracked as JDK-828636 but there may be further issues beyond that.

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

PR: https://git.openjdk.java.net/jdk/pull/8939

From cjplummer at openjdk.java.net  Tue May 31 17:23:47 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 31 May 2022 17:23:47 GMT
Subject: RFR: 8286983: rename jdb -trackvthreads and debug agent
 enumeratevthreads options and clarify "Preview Feature" nature of these
 options [v4]
In-Reply-To: <SiX2uOSL0J8opRRFfaHUfgaZKV4Rn0fe7GKR8bWrLE8=.d4d515f4-e6f4-4c06-bab4-1bafcde74a52@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
 <SiX2uOSL0J8opRRFfaHUfgaZKV4Rn0fe7GKR8bWrLE8=.d4d515f4-e6f4-4c06-bab4-1bafcde74a52@github.com>
Message-ID: <e02kJZzLvTOAeXYeJfswqQ3ACgUOZCkpgsyY2ysz0fo=.eca9072b-2194-460a-bf3a-4b7f74b19434@github.com>

On Thu, 26 May 2022 17:09:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> As part of the loom integration, jdb added `-trackvthreads` and the debug agent added `enumeratevthreads`. These options are being renamed to `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads` should not have been used). Also, the help text for these options now calls out that virtual threads are a Preview Feature.
>> 
>> After the update to help text, wlil look as follows:
>> 
>> jdb doc (search for "trackallthreads"): http://cr.openjdk.java.net/~cjplummer/8286983/jdb.html
>> debug agent doc (seach for "includevirtualthreads"): http://cr.openjdk.java.net/~cjplummer/8286983/conninv.html
>> 
>> 
>> $ jdb -listconnectors
>> ...
>>   Connector: com.sun.jdi.CommandLineLaunch  Transport: dt_socket
>>     description: Launches target using Sun Java VM command line and attaches to it
>> ...
>>     Argument: includevirtualthreads Default value: n
>>     description: List of all threads includes virtual threads as well as platform threads. Virtual threads are a preview feature of the Java platform.
>> 
>> 
>> 
>> $ jdb -help
>> Usage: jdb <options> <class> <arguments>
>> 
>> where options include:
>> ...
>>     -dbgtrace [flags] print info for debugging jdb
>>     -trackallthreads  Track all threads, including virtual threads.
>>                       Virtual threads are a preview feature of the Java platform.
>>     -tclient          run the application in the HotSpot(TM) Client Compiler
>> ...
>> 
>> 
>> 
>> $ man -M ./build/linux-x64-debug/images/jdk/man/ jdb
>> ...
>>        -tclient
>>               Runs the application in the Java HotSpot VM client.
>> 
>>        -trackallthreads
>>               Track  all  threads  as  they  are  created,  including  Virtual
>>               Threads.   See  Working  With  Virtual  Threads  below.  Virtual
>>               threads are a preview feature of the Java platform.
>> 
>>        -tserver
>>               Runs the application in the Java HotSpot VM server.
>> ...
>> WORKING WITH VIRTUAL THREADS
>>        Virtual threads are a preview feature of the  Java  platform.   Preview
>>        features  may  be removed in a future release, or upgraded to permanent
>>        features of the Java platform.
>> 
>>        Often virtual theads are created in such large  numbers  and  frequency
>> ...
>> 
>> 
>> 
>> $ java -agentlib:jdwp=help
>>                Java Debugger JDWP Agent Library
>>                --------------------------------
>> 
>>   (See the "VM Invocation Options" section of the JPDA
>>    "Connection and Invocation Details" document for more information.)
>> 
>> jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]
>> 
>> Option Name and Value            Description                       Default
>> ---------------------            -----------                       -------
>> ...
>> timeout=<timeout value>          for listen/attach in milliseconds n
>> includevirtualthreads=y|n        List of all threads includes virtual threads as well as platform threads.
>>                                  Virtual threads are a preview feature of the Java platform.
>>                                                                    n
>> mutf8=y|n                        output modified utf-8             n
>> ...
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix minor typo in comment.

I created CSR [JDK-8287591](https://bugs.openjdk.java.net/browse/JDK-8287591)

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From rehn at openjdk.java.net  Tue May 31 17:47:46 2022
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 31 May 2022 17:47:46 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
Message-ID: <LK6sxMWt24m7zJEIp4eaUQINqXOJVgFZIS_qm3ZeH8U=.c684b70a-b64d-48a3-8e73-a560b1765b45@github.com>

On Tue, 31 May 2022 15:39:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
>> 
>> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
>> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
>> 
>> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allowing linking without intrinsic stub, contributed-by: rehn

Looks good, tested zero, thanks!

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

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8939

From cjplummer at openjdk.java.net  Tue May 31 18:14:51 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 31 May 2022 18:14:51 GMT
Subject: RFR: 8286983: rename jdb -trackvthreads and debug agent
 enumeratevthreads options and clarify "Preview Feature" nature of these
 options [v5]
In-Reply-To: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
References: <uR9SzS1xCetgxDLsPdSFgIWzXf0zglgOsZ6pJ9JFCwc=.321ca332-eef4-4080-95ef-62104235ccb7@github.com>
Message-ID: <ZrdG7pDlOPve3rjUBGCjCenYQtRzPofckRf1W0oLR-8=.1b688b64-c1a2-411e-a113-b64bb4adb110@github.com>

> As part of the loom integration, jdb added `-trackvthreads` and the debug agent added `enumeratevthreads`. These options are being renamed to `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads` should not have been used). Also, the help text for these options now calls out that virtual threads are a Preview Feature.
> 
> After the update to help text, wlil look as follows:
> 
> jdb doc (search for "trackallthreads"): http://cr.openjdk.java.net/~cjplummer/8286983/jdb.html
> debug agent doc (seach for "includevirtualthreads"): http://cr.openjdk.java.net/~cjplummer/8286983/conninv.html
> 
> 
> $ jdb -listconnectors
> ...
>   Connector: com.sun.jdi.CommandLineLaunch  Transport: dt_socket
>     description: Launches target using Sun Java VM command line and attaches to it
> ...
>     Argument: includevirtualthreads Default value: n
>     description: List of all threads includes virtual threads as well as platform threads. Virtual threads are a preview feature of the Java platform.
> 
> 
> 
> $ jdb -help
> Usage: jdb <options> <class> <arguments>
> 
> where options include:
> ...
>     -dbgtrace [flags] print info for debugging jdb
>     -trackallthreads  Track all threads, including virtual threads.
>                       Virtual threads are a preview feature of the Java platform.
>     -tclient          run the application in the HotSpot(TM) Client Compiler
> ...
> 
> 
> 
> $ man -M ./build/linux-x64-debug/images/jdk/man/ jdb
> ...
>        -tclient
>               Runs the application in the Java HotSpot VM client.
> 
>        -trackallthreads
>               Track  all  threads  as  they  are  created,  including  Virtual
>               Threads.   See  Working  With  Virtual  Threads  below.  Virtual
>               threads are a preview feature of the Java platform.
> 
>        -tserver
>               Runs the application in the Java HotSpot VM server.
> ...
> WORKING WITH VIRTUAL THREADS
>        Virtual threads are a preview feature of the  Java  platform.   Preview
>        features  may  be removed in a future release, or upgraded to permanent
>        features of the Java platform.
> 
>        Often virtual theads are created in such large  numbers  and  frequency
> ...
> 
> 
> 
> $ java -agentlib:jdwp=help
>                Java Debugger JDWP Agent Library
>                --------------------------------
> 
>   (See the "VM Invocation Options" section of the JPDA
>    "Connection and Invocation Details" document for more information.)
> 
> jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]
> 
> Option Name and Value            Description                       Default
> ---------------------            -----------                       -------
> ...
> timeout=<timeout value>          for listen/attach in milliseconds n
> includevirtualthreads=y|n        List of all threads includes virtual threads as well as platform threads.
>                                  Virtual threads are a preview feature of the Java platform.
>                                                                    n
> mutf8=y|n                        output modified utf-8             n
> ...

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

  Don't capitalize "virtual threads"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8780/files
  - new: https://git.openjdk.java.net/jdk/pull/8780/files/2a6f2e49..3a96fcac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8780&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8780&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/8780

From mchung at openjdk.java.net  Tue May 31 23:48:34 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 31 May 2022 23:48:34 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
Message-ID: <C36rgf1exkAzaEnvT8kTwv8-UDyp1_5ttKtWbJcLQGc=.136015c1-ef9d-4470-9422-02a2e46a099c@github.com>

On Tue, 31 May 2022 15:39:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
>> 
>> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
>> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
>> 
>> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allowing linking without intrinsic stub, contributed-by: rehn

Looks okay to me.

src/java.management/share/classes/sun/management/ThreadImpl.java line 586:

> 584: 
> 585:     /**
> 586:      * Returns the ThreadInfo objects from the given array that coresspond to platform

typo: coresspond -> correspond

src/java.management/share/classes/sun/management/Util.java line 92:

> 90: 
> 91:     /**
> 92:      * Returns true if the given Thread is a virutal thread.

typo: virutal -> virtual

this typo appears in other comments too.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8939