From cjplummer at openjdk.org  Fri Jul  1 00:14:51 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Jul 2022 00:14:51 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v5]
In-Reply-To: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
Message-ID: <jsRf_tX9FGKP6S7u2Dmx84hmU0PjUJPgajz2iZHrRQY=.2d3455ce-27e5-4e86-9959-6a722c3eb5fa@github.com>

> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
> 
> 
>         if (list != &otherThreads) {
>             setThreadLocalStorage(node->thread, (void*)node);
>         }

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

  Always run test both in virtual and platform thread modes

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/88/files
  - new: https://git.openjdk.org/jdk19/pull/88/files/4caca0eb..3c9b75df

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

  Stats: 28 lines in 1 file changed: 22 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk19/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/88/head:pull/88

PR: https://git.openjdk.org/jdk19/pull/88

From cjplummer at openjdk.org  Fri Jul  1 00:18:49 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Jul 2022 00:18:49 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v5]
In-Reply-To: <eJmFMxgiXF4iln37xfmDZ3aczEtTYy26ZkVQngdsJss=.f19fee21-adf8-4f58-99de-3a10cdf4fd43@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <3kr12kBJFTDi6Erb4bE3pqK_uUuKrcOcc7hvDwkzN_0=.386c4aba-86c2-449b-9def-340ab9c8bfc6@github.com>
 <ifTEDiJd7GZHAD-ff8JFU1nSsjhB2fnOBGOBACLt-LA=.e64ef0ff-54f0-4be2-ac6a-f10ced22a44d@github.com>
 <xGEgsdTMVNJ4XJZLhJHvQeB3BeZSn2NEihxTt-nx6Fk=.27cc3dfc-8a95-4367-bb39-ffece4fdc0bf@github.com>
 <Y5XaPjtw9NgKe8LjXtxXWbkPwjMCSq4dFlgdJzb0mFo=.e4840492-c35f-4db5-b3cf-141dcc731097@github.com>
 <eJmFMxgiXF4iln37xfmDZ3aczEtTYy26ZkVQngdsJss=.f19fee21-adf8-4f58-99de-3a10cdf4fd43@github.com>
Message-ID: <NScxsxH_Z5-nxcJtHrsGKTzkBwqouNQ2MlbSa9KtSDI=.eb422db8-67cf-4e60-b207-05bc2a542f96@github.com>

On Thu, 30 Jun 2022 16:27:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The @run suggestion doesn't work. There are two issues. First, it does not trigger jtreg to use TestScaffold.main(), which is what normally happens when you use TEST_VM_OPTS="-Dmain.wrapper=Virtual". So the end result is that the test is run with a platform thread.
>> 
>> The other issue is that if the test run is done with TEST_VM_OPTS="-Dmain.wrapper=Virtual", then TestScaffold.main() cannot handle any arguments added to the @run other than the main class name. You end up with CNFE for the first argument that appears after "SuspendAfterDeath".
>> 
>> The above issues aside, I still don't understand why we would want to do any virtual thread testing with com/sun/jdi tests when not using TEST_VM_OPTS="-Dmain.wrapper=Virtual". It's not how we've tested JDI support for virtual thread in the past. We've always relied on explicit virtual thread test runs using TEST_VM_OPTS="-Dmain.wrapper=Virtual". Same is true of the nsk jdi, jdb, and jdwp tests. If you really want this test handled differently because it was written to test a specific bug, then it probably does not belong in com/sun/jdi, which means it can't rely on TestScaffold.
>> 
>> One other thing is that you don't really need -Dmain.wrapper=Virtual to make this test do the testing on a virtual thread. It can just be the default mode like you used to have when you first wrote it. However, I ran into problems with that when also using  TEST_VM_OPTS="-Dmain.wrapper=Virtual" due to conflicts in argument setup between the test and TestScaffold. However, with the changes now in parseArgs() to check test.enable.preview, it might not be necessary for the test itself to add --enable-preview, so maybe that conflict will go away. But I still don't think this is the approach we should take (see my previous paragraph).
>
> The testing in OpenJDK does not run these tests with -Dmain.wrapper=Virtual so this is why this test is not testing the scenario that this bug is about.  We can make it work and have it run twice, or we can rename it to something like "SuspendVirtualThreadAfterDeath" and drop the testing with a platform thread. In time I expect there will be more tests in the jdk_jdi test group that exercise virtual threads.

I've updated the test to always run in both virtual thread and platform thread mode. The test itself does not care about the `-Dmain.wrapper=Virtual` setting and ignores it. TestScaffold does care and will run the main test thread as a virtual thread if `-Dmain.wrapper=Virtual` is used, but the test itself will spawn a virtual thread or platform thread independent of the wrapper setting.

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

PR: https://git.openjdk.org/jdk19/pull/88

From jwilhelm at openjdk.org  Fri Jul  1 00:52:48 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 1 Jul 2022 00:52:48 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <kaKg5e38rdUlc_wErqo1jlpqjTiiV933wuysiy58Rug=.ae562436-c6cf-4c43-90b9-bc082c9397a7@github.com>
References: <kaKg5e38rdUlc_wErqo1jlpqjTiiV933wuysiy58Rug=.ae562436-c6cf-4c43-90b9-bc082c9397a7@github.com>
Message-ID: <R-W2lwVsiVlgjYt1Ct6qLvBjkqJ_s3HVCvmervumZks=.d18710c6-86b8-4bfa-8a54-81d1f46e7952@github.com>

On Thu, 30 Jun 2022 23:50:57 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 918068a1
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/918068a115efee7d439084b6d743cab5193bd943
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

Merge

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

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

From cjplummer at openjdk.org  Fri Jul  1 05:29:43 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Jul 2022 05:29:43 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v6]
In-Reply-To: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
Message-ID: <D3d_ja1PalL3U6jK30pKIRunWAcmpP9Kfj6tVIXcICM=.7a78dc82-f6af-4195-bb81-30d49d2beaee@github.com>

> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
> 
> 
>         if (list != &otherThreads) {
>             setThreadLocalStorage(node->thread, (void*)node);
>         }

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

  Add new SuspendAfterDeath test to jdk_jdi_sanity test group.

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/88/files
  - new: https://git.openjdk.org/jdk19/pull/88/files/3c9b75df..96507bca

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

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

PR: https://git.openjdk.org/jdk19/pull/88

From cjplummer at openjdk.org  Fri Jul  1 06:56:46 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Jul 2022 06:56:46 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v9]
In-Reply-To: <Vm6pH_ri4FLjLSgOCHVBdUVZ8wJNL47VYcqLJMqBvsY=.66602c81-5430-40ff-963d-19db9cce2c85@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <SAVW1OgcaxEUJTzE5TkVZxvMZJFoIF0lCYIcOvmaPDY=.575d329b-0cfd-4a5d-a610-a6e3bf18e281@github.com>
 <9gGXw8F25KgjQ3a_8GqPAUJWwkxIsPdXBKZ8bTnGJL4=.7f0197c7-0176-49a1-8fd1-0434ed36714a@github.com>
 <Vm6pH_ri4FLjLSgOCHVBdUVZ8wJNL47VYcqLJMqBvsY=.66602c81-5430-40ff-963d-19db9cce2c85@github.com>
Message-ID: <yJzwv8cetjPltlkpBVFYo2b5uGCYL4-lNQz-WMAw5ng=.dce26951-f738-4fb8-8bba-aa465ec4a7d4@github.com>

On Thu, 30 Jun 2022 14:54:47 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> I just noticed the test is being added to a newly created hotspot/jtreg/serviciability/jdi directory. It should be placed in one of the existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think the latter would be better and it can leverage TestScaffold.
>> 
>> Another reason to use TestScaffold is that it will automatically add any specified VM options to the debuggee:
>> 
>> 
>>         String vmOpts = System.getProperty("test.vm.opts");
>>         System.out.println("vmOpts: '" + vmOpts + "'");
>> 
>> 
>> This way when we do our testing with various GC configurations, it should end up testing the debuggee with each GC configuration also. Same goes with other VM options that get tested like -Xcomp.
>
>> I just noticed the test is being added to a newly created hotspot/jtreg/serviciability/jdi directory. It should be placed in one of the existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think the latter would be better and it can leverage TestScaffold.
>> 
>> Another reason to use TestScaffold is that it will automatically add any specified VM options to the debuggee:
>> 
>> ```
>>         String vmOpts = System.getProperty("test.vm.opts");
>>         System.out.println("vmOpts: '" + vmOpts + "'");
>> ```
>> 
>> This way when we do our testing with various GC configurations, it should end up testing the debuggee with each GC configuration also. Same goes with other VM options that get tested like -Xcomp.
> 
> Moved new test to jdk/com/sun/jdi.

@zhengyu123 I uploaded a patch to the test. It now tests EventSets with two ClassUnloadEvents. See http://cr.openjdk.java.net/~cjplummer/8256811/. It still needs some cleaning up, but look it over first and let me know what you think.

One issue is you have a big try block around the event handling code that is catching and not rethrowing exceptions. I'm not sure why that is needed. It is preventing exceptions for some new checks I added from propagating.

The change I made was two split the class names into two groups. The first has the class name prefix you setup, and the second has the same prefixe, but with __ALT added to it. Half of the classes are created with the regular prefix and half with the ALT prefix. The ClassUnloadRequest you setup should match all the unloaded classes, but the 2nd ClassUnloadRequest I setup should only match the __ALT classes. That means the EventSet for a ClassUnloadEvent WITH the ALT name should contain two ClassUnloadEvents, one for each ClassUnloadRequest, whereas the EventSet for a ClassUnloadEvent WITHOUT the ALT name should contain one ClassUnloadEvent since it won't match the ALT ClassUnloadRequest.

I added a println of the EventSet that should help you understand this a bit better. Here's an example:


Running debugger
EventSet: event set, policy:2, count:1 = {VMStartEvent in thread main}
EventSet: event set, policy:0, count:1 = {ClassUnloadEvent}
EventSet: event set, policy:0, count:2 = {ClassUnloadEvent, ClassUnloadEvent}
EventSet: event set, policy:0, count:2 = {ClassUnloadEvent, ClassUnloadEvent}
EventSet: event set, policy:0, count:1 = {ClassUnloadEvent}
EventSet: event set, policy:0, count:2 = {ClassUnloadEvent, ClassUnloadEvent}
EventSet: event set, policy:0, count:1 = {ClassUnloadEvent}
EventSet: event set, policy:0, count:2 = {ClassUnloadEvent, ClassUnloadEvent}
EventSet: event set, policy:0, count:1 = {ClassUnloadEvent}
EventSet: event set, policy:0, count:2 = {ClassUnloadEvent, ClassUnloadEvent}
EventSet: event set, policy:0, count:1 = {ClassUnloadEvent}
EventSet: event set, policy:0, count:1 = {VMDeathEvent}


So you can see how half of the EventSets ended up with two ClassUnloadEvents, one for each ClassUnloadRequest, and the other half only one ClassUnloadEvent.

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

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

From alanb at openjdk.org  Fri Jul  1 08:54:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Jul 2022 08:54:56 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v6]
In-Reply-To: <D3d_ja1PalL3U6jK30pKIRunWAcmpP9Kfj6tVIXcICM=.7a78dc82-f6af-4195-bb81-30d49d2beaee@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <D3d_ja1PalL3U6jK30pKIRunWAcmpP9Kfj6tVIXcICM=.7a78dc82-f6af-4195-bb81-30d49d2beaee@github.com>
Message-ID: <ie9927Fs9-7dBQTk3XWamlNFnJXtsNcgVjKVmfMwh7M=.d7194c25-fcf9-408a-ab45-18d075197596@github.com>

On Fri, 1 Jul 2022 05:29:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new SuspendAfterDeath test to jdk_jdi_sanity test group.

Marked as reviewed by alanb (Reviewer).

test/jdk/com/sun/jdi/SuspendAfterDeath.java line 27:

> 25:  * @test id=platform_thread
> 26:  * @bug 8287847
> 27:  * @summary Test suspending a thread after it has terminated.

Minor comment but this could say "suspend a platform thread" (and "virtual thread" for the other summary).

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

PR: https://git.openjdk.org/jdk19/pull/88

From alanb at openjdk.org  Fri Jul  1 09:09:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Jul 2022 09:09:25 GMT
Subject: [jdk19] RFR: 8289439: Clarify relationship between
 ThreadStart/ThreadEnd and can_support_virtual_threads capability
Message-ID: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>

The description of the ThreadStart/End events in the JVM TI spec needs rewording to make it clearer when these events are sent for virtual threads and when VirtualThreadXXX events are sent instead.

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

Commit messages:
 - Tweak wording
 - Initial commit

Changes: https://git.openjdk.org/jdk19/pull/94/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=94&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289439
  Stats: 29 lines in 2 files changed: 12 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk19/pull/94.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/94/head:pull/94

PR: https://git.openjdk.org/jdk19/pull/94

From sspitsyn at openjdk.org  Fri Jul  1 09:09:26 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Jul 2022 09:09:26 GMT
Subject: [jdk19] RFR: 8289439: Clarify relationship between
 ThreadStart/ThreadEnd and can_support_virtual_threads capability
In-Reply-To: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
References: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
Message-ID: <SkB7zq_dlM-7fUe5-FGmExtCa6d_QMybOHybXl4v8Sk=.295f1f02-4e9f-4c4b-ad04-c7120be11025@github.com>

On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The description of the ThreadStart/End events in the JVM TI spec needs rewording to make it clearer when these events are sent for virtual threads and when VirtualThreadXXX events are sent instead.

src/hotspot/share/prims/jvmti.xml line 12902:

> 12900:       <code>can_support_virtual_threads</code></internallink> is not enabled.
> 12901:       This ensures that agents that enable this event, but without this
> 12902:       capability, are notified when all threads start.

It feels like this sentence can be improved. But I can't suggest anything yet.

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

PR: https://git.openjdk.org/jdk19/pull/94

From alanb at openjdk.org  Fri Jul  1 09:09:26 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Jul 2022 09:09:26 GMT
Subject: [jdk19] RFR: 8289439: Clarify relationship between
 ThreadStart/ThreadEnd and can_support_virtual_threads capability
In-Reply-To: <SkB7zq_dlM-7fUe5-FGmExtCa6d_QMybOHybXl4v8Sk=.295f1f02-4e9f-4c4b-ad04-c7120be11025@github.com>
References: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
 <SkB7zq_dlM-7fUe5-FGmExtCa6d_QMybOHybXl4v8Sk=.295f1f02-4e9f-4c4b-ad04-c7120be11025@github.com>
Message-ID: <-8C1HxbFkdEgsoqpHrwI2Itj7VGVS6kNazFdiOaQXFY=.9ce79ffc-c86d-4def-bc4c-474cfa45ca30@github.com>

On Thu, 30 Jun 2022 19:39:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The description of the ThreadStart/End events in the JVM TI spec needs rewording to make it clearer when these events are sent for virtual threads and when VirtualThreadXXX events are sent instead.
>
> src/hotspot/share/prims/jvmti.xml line 12902:
> 
>> 12900:       <code>can_support_virtual_threads</code></internallink> is not enabled.
>> 12901:       This ensures that agents that enable this event, but without this
>> 12902:       capability, are notified when all threads start.
> 
> It feels like this sentence can be improved. But I can't suggest anything yet.

I did further word smithing and I hope the proposal text is clearer now.

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

PR: https://git.openjdk.org/jdk19/pull/94

From dholmes at openjdk.org  Fri Jul  1 12:07:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 1 Jul 2022 12:07:42 GMT
Subject: [jdk19] RFR: 8289439: Clarify relationship between
 ThreadStart/ThreadEnd and can_support_virtual_threads capability
In-Reply-To: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
References: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
Message-ID: <QA3_2nGjGBzEUde0kliFRBbROhHBJSGReRlqTBnexoc=.6f0cd942-6a89-43f8-9458-f0bd2f33c895@github.com>

On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The description of the ThreadStart/End events in the JVM TI spec needs rewording to make it clearer when these events are sent for virtual threads and when VirtualThreadXXX events are sent instead.

This seems fine to me.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/94

From dholmes at openjdk.org  Fri Jul  1 12:34:43 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 1 Jul 2022 12:34:43 GMT
Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options
In-Reply-To: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
References: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
Message-ID: <feG1TKyNkpg2t7BV0WvmrEG7lLZX6vjTQWhwMEAMlV0=.2d220adc-ab26-455f-abf6-cbde6cbf19f5@github.com>

On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits.  This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

The changes seem fine, though the change to ObjectAlignmentInBytes is a bit disruptive. I don't really see a motivation for this though - the memory saving seems insignificant.

src/hotspot/share/runtime/perfMemory.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved.

2022

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

Marked as reviewed by dholmes (Reviewer).

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

From zgu at openjdk.org  Fri Jul  1 12:57:55 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 1 Jul 2022 12:57:55 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v12]
In-Reply-To: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
Message-ID: <1miMI1m2VJdL9K2Zfkmz7m3f_VuUwE0B36_8QoV1ha8=.abd05d40-03af-42a7-aa38-85866360f594@github.com>

> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
> 
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
> 
> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
> 
> It also performs `commonRef_compact()` only when there are classes unloaded.
> 
> New test failed about 20% without patch, none with patch.
> 
> **Update**
> There are significant changes from early patch. 
> 
> The new approach:
> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
> 
> The new solution breaks up into two steps:
> - Collect all dead object tags with lock
> - Transition to `_in_native` state and post object free events in one batch
> 
> This way, JDI event handler can process object free events upon arrivals without delay.
> 
> **Update 2**
> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
> 
> // This checks for posting and rehashing before operations that
> // this tagmap table.  The calls from a JavaThread only rehash, posting is
> // only done before heap walks.
> void JvmtiTagMap::check_hashmap(bool post_events) {
> 
> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
> Even the events are posted earlier in old code, but they are only processed after next GC cycle.

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Incorporated plummercj's test changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9168/files
  - new: https://git.openjdk.org/jdk/pull/9168/files/a07b3737..d265b764

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=10-11

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

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

From zgu at openjdk.org  Fri Jul  1 13:03:53 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 1 Jul 2022 13:03:53 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v9]
In-Reply-To: <Vm6pH_ri4FLjLSgOCHVBdUVZ8wJNL47VYcqLJMqBvsY=.66602c81-5430-40ff-963d-19db9cce2c85@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <SAVW1OgcaxEUJTzE5TkVZxvMZJFoIF0lCYIcOvmaPDY=.575d329b-0cfd-4a5d-a610-a6e3bf18e281@github.com>
 <9gGXw8F25KgjQ3a_8GqPAUJWwkxIsPdXBKZ8bTnGJL4=.7f0197c7-0176-49a1-8fd1-0434ed36714a@github.com>
 <Vm6pH_ri4FLjLSgOCHVBdUVZ8wJNL47VYcqLJMqBvsY=.66602c81-5430-40ff-963d-19db9cce2c85@github.com>
Message-ID: <Usz9eqssecQHXmjCZYpyiozIuY13CiL8As1rPOhygss=.00de14ae-c607-4b16-82fa-73e7e793ccac@github.com>

On Thu, 30 Jun 2022 14:54:47 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> I just noticed the test is being added to a newly created hotspot/jtreg/serviciability/jdi directory. It should be placed in one of the existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think the latter would be better and it can leverage TestScaffold.
>> 
>> Another reason to use TestScaffold is that it will automatically add any specified VM options to the debuggee:
>> 
>> 
>>         String vmOpts = System.getProperty("test.vm.opts");
>>         System.out.println("vmOpts: '" + vmOpts + "'");
>> 
>> 
>> This way when we do our testing with various GC configurations, it should end up testing the debuggee with each GC configuration also. Same goes with other VM options that get tested like -Xcomp.
>
>> I just noticed the test is being added to a newly created hotspot/jtreg/serviciability/jdi directory. It should be placed in one of the existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think the latter would be better and it can leverage TestScaffold.
>> 
>> Another reason to use TestScaffold is that it will automatically add any specified VM options to the debuggee:
>> 
>> ```
>>         String vmOpts = System.getProperty("test.vm.opts");
>>         System.out.println("vmOpts: '" + vmOpts + "'");
>> ```
>> 
>> This way when we do our testing with various GC configurations, it should end up testing the debuggee with each GC configuration also. Same goes with other VM options that get tested like -Xcomp.
> 
> Moved new test to jdk/com/sun/jdi.

> @zhengyu123 I uploaded a patch to the test. It now tests EventSets with two ClassUnloadEvents. See http://cr.openjdk.java.net/~cjplummer/8256811/. It still needs some cleaning up, but look it over first and let me know what you think.
> 
> One issue is you have a big try block around the event handling code that is catching and not rethrowing exceptions. I'm not sure why that is needed. It is preventing exceptions for some new checks I added from propagating.
> 
> The change I made was two split the class names into two groups. The first has the class name prefix you setup, and the second has the same prefixe, but with __ALT added to it. Half of the classes are created with the regular prefix and half with the ALT prefix. The ClassUnloadRequest you setup should match all the unloaded classes, but the 2nd ClassUnloadRequest I setup should only match the __ALT classes. That means the EventSet for a ClassUnloadEvent WITH the ALT name should contain two ClassUnloadEvents, one for each ClassUnloadRequest, whereas the EventSet for a ClassUnloadEvent WITHOUT the ALT name should contain one ClassUnloadEvent since it won't match the ALT ClassUnloadRequest.
> 
> I added a println of the EventSet that should help you understand this a bit better. Here's an example:
> 
> ```
> Running debugger
> EventSet: event set, policy:2, count:1 = {VMStartEvent in thread main}
> EventSet: event set, policy:0, count:1 = {ClassUnloadEvent}
> EventSet: event set, policy:0, count:2 = {ClassUnloadEvent, ClassUnloadEvent}
> EventSet: event set, policy:0, count:2 = {ClassUnloadEvent, ClassUnloadEvent}
> EventSet: event set, policy:0, count:1 = {ClassUnloadEvent}
> EventSet: event set, policy:0, count:2 = {ClassUnloadEvent, ClassUnloadEvent}
> EventSet: event set, policy:0, count:1 = {ClassUnloadEvent}
> EventSet: event set, policy:0, count:2 = {ClassUnloadEvent, ClassUnloadEvent}
> EventSet: event set, policy:0, count:1 = {ClassUnloadEvent}
> EventSet: event set, policy:0, count:2 = {ClassUnloadEvent, ClassUnloadEvent}
> EventSet: event set, policy:0, count:1 = {ClassUnloadEvent}
> EventSet: event set, policy:0, count:1 = {VMDeathEvent}
> ```
> 
> So you can see how half of the EventSets ended up with two ClassUnloadEvents, one for each ClassUnloadRequest, and the other half only one ClassUnloadEvent.

Thanks @plummercj

I incorporated your patch. 

> One issue is you have a big try block around the event handling code that is catching and not rethrowing exceptions. I'm not sure why that is needed. It is preventing exceptions for some new checks I added from propagating.
> 
This catch block intended to catch infrastructure failure, I changed `catch` statement to catch specific exceptions, that will allow your `RuntimeException` to propagate.

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

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

From hseigel at openjdk.org  Fri Jul  1 14:35:49 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Fri, 1 Jul 2022 14:35:49 GMT
Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options [v2]
In-Reply-To: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
References: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
Message-ID: <LZLFcctLrFK3Dpy3Kg4jfCPWQTrspYEEHImkZP-06DU=.d9c32764-18cf-43e4-9965-a87d6afffb31@github.com>

> Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits.  This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9338/files
  - new: https://git.openjdk.org/jdk/pull/9338/files/b71c60d8..7c973070

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

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

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

From hseigel at openjdk.org  Fri Jul  1 14:35:50 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Fri, 1 Jul 2022 14:35:50 GMT
Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options
In-Reply-To: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
References: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
Message-ID: <8E9_o0CLkKkyN0H3XRgZ9AMoWczAwVD7U8xy69jvXIk=.77b3b599-3584-4dc4-b838-ff7ecfdccfde@github.com>

On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits.  This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Thanks Coleen and David for the reviews!

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

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

From hseigel at openjdk.org  Fri Jul  1 14:35:52 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Fri, 1 Jul 2022 14:35:52 GMT
Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options [v2]
In-Reply-To: <feG1TKyNkpg2t7BV0WvmrEG7lLZX6vjTQWhwMEAMlV0=.2d220adc-ab26-455f-abf6-cbde6cbf19f5@github.com>
References: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
 <feG1TKyNkpg2t7BV0WvmrEG7lLZX6vjTQWhwMEAMlV0=.2d220adc-ab26-455f-abf6-cbde6cbf19f5@github.com>
Message-ID: <b6bSyPVlLgAlEgEExAxYCBf2AkkBhehPR-rqA8NaSEI=.5ab1f340-4546-4a0e-a9d8-7bc7dc38e34d@github.com>

On Fri, 1 Jul 2022 12:28:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright date
>
> src/hotspot/share/runtime/perfMemory.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> 2022

Fixed. Thanks!

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

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

From hseigel at openjdk.org  Fri Jul  1 14:35:53 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Fri, 1 Jul 2022 14:35:53 GMT
Subject: Integrated: 8289534: Change 'uncomplicated' hotspot runtime options
In-Reply-To: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
References: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
Message-ID: <2BSUfqtiSzV5aQTgb_etNzaBTT_Xp7gaPBhRVMQw0sI=.3adeb8a8-f159-4409-b1dd-3cd458552b56@github.com>

On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits.  This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 09b4032f
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09b4032f8b07335729e71b16b8f735514f3aebce
Stats:     42 lines in 10 files changed: 1 ins; 0 del; 41 mod

8289534: Change 'uncomplicated' hotspot runtime options

Reviewed-by: coleenp, dholmes

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

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

From dcubed at openjdk.org  Fri Jul  1 15:08:48 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 1 Jul 2022 15:08:48 GMT
Subject: [jdk19] RFR: 8289439: Clarify relationship between
 ThreadStart/ThreadEnd and can_support_virtual_threads capability
In-Reply-To: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
References: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
Message-ID: <b-78GNoRa02u4vA0yswRmUa04dtlBEdfcVelgXINoj0=.30f477a0-c1c4-4773-b186-3262b9c1d365@github.com>

On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The description of the ThreadStart/End events in the JVM TI spec needs rewording to make it clearer when these events are sent for virtual threads and when VirtualThreadXXX events are sent instead.

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/94

From dcubed at openjdk.org  Fri Jul  1 16:22:13 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 1 Jul 2022 16:22:13 GMT
Subject: [jdk19] RFR: 8289585: ProblemList
 sun/tools/jhsdb/JStackStressTest.java on linux-aarch64
Message-ID: <GRzsvARHl6-8pukA116zw4D17wVUxacolAuRcnA3UQA=.1c61efac-1312-4ab3-9376-d189bf62334e@github.com>

A trivial fix to  ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64.

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

Commit messages:
 - 8289585: ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64

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

PR: https://git.openjdk.org/jdk19/pull/100

From bpb at openjdk.org  Fri Jul  1 16:22:14 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 1 Jul 2022 16:22:14 GMT
Subject: [jdk19] RFR: 8289585: ProblemList
 sun/tools/jhsdb/JStackStressTest.java on linux-aarch64
In-Reply-To: <GRzsvARHl6-8pukA116zw4D17wVUxacolAuRcnA3UQA=.1c61efac-1312-4ab3-9376-d189bf62334e@github.com>
References: <GRzsvARHl6-8pukA116zw4D17wVUxacolAuRcnA3UQA=.1c61efac-1312-4ab3-9376-d189bf62334e@github.com>
Message-ID: <78YyUgtoJ2BW10nEv6UtQzVg4O8c9exdMs9Ai1kh_BQ=.4c510030-1411-45bb-8df4-e0e9038ddf33@github.com>

On Fri, 1 Jul 2022 16:12:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to  ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/100

From kevinw at openjdk.org  Fri Jul  1 16:22:14 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 1 Jul 2022 16:22:14 GMT
Subject: [jdk19] RFR: 8289585: ProblemList
 sun/tools/jhsdb/JStackStressTest.java on linux-aarch64
In-Reply-To: <GRzsvARHl6-8pukA116zw4D17wVUxacolAuRcnA3UQA=.1c61efac-1312-4ab3-9376-d189bf62334e@github.com>
References: <GRzsvARHl6-8pukA116zw4D17wVUxacolAuRcnA3UQA=.1c61efac-1312-4ab3-9376-d189bf62334e@github.com>
Message-ID: <6roNvo5oqzUb05xfSjf8IKcA0Xsa2VGWBq-sIsD2NpE=.fca2f1e9-0f29-4c56-b3ce-9487255179d9@github.com>

On Fri, 1 Jul 2022 16:12:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to  ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64.

Marked as reviewed by kevinw (Committer).

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

PR: https://git.openjdk.org/jdk19/pull/100

From dcubed at openjdk.org  Fri Jul  1 16:22:14 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 1 Jul 2022 16:22:14 GMT
Subject: [jdk19] RFR: 8289585: ProblemList
 sun/tools/jhsdb/JStackStressTest.java on linux-aarch64
In-Reply-To: <6roNvo5oqzUb05xfSjf8IKcA0Xsa2VGWBq-sIsD2NpE=.fca2f1e9-0f29-4c56-b3ce-9487255179d9@github.com>
References: <GRzsvARHl6-8pukA116zw4D17wVUxacolAuRcnA3UQA=.1c61efac-1312-4ab3-9376-d189bf62334e@github.com>
 <6roNvo5oqzUb05xfSjf8IKcA0Xsa2VGWBq-sIsD2NpE=.fca2f1e9-0f29-4c56-b3ce-9487255179d9@github.com>
Message-ID: <OUs3L-hH6w451sgI_LalqAwkJKqxNnvUkS24dtoJfbg=.5f320f7b-023b-4136-bdc0-152ff70e6b98@github.com>

On Fri, 1 Jul 2022 16:16:50 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> A trivial fix to  ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64.
>
> Marked as reviewed by kevinw (Committer).

@kevinjwalls - Thanks for the fast review!

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

PR: https://git.openjdk.org/jdk19/pull/100

From dcubed at openjdk.org  Fri Jul  1 16:22:14 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 1 Jul 2022 16:22:14 GMT
Subject: [jdk19] RFR: 8289585: ProblemList
 sun/tools/jhsdb/JStackStressTest.java on linux-aarch64
In-Reply-To: <78YyUgtoJ2BW10nEv6UtQzVg4O8c9exdMs9Ai1kh_BQ=.4c510030-1411-45bb-8df4-e0e9038ddf33@github.com>
References: <GRzsvARHl6-8pukA116zw4D17wVUxacolAuRcnA3UQA=.1c61efac-1312-4ab3-9376-d189bf62334e@github.com>
 <78YyUgtoJ2BW10nEv6UtQzVg4O8c9exdMs9Ai1kh_BQ=.4c510030-1411-45bb-8df4-e0e9038ddf33@github.com>
Message-ID: <OodGoxv-Sir2jtZ1Xw1AK9zm_P3JhoxVeKTMAnigCdU=.a2cd0120-f724-4a39-8923-9f531502438c@github.com>

On Fri, 1 Jul 2022 16:13:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to  ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the lightning fast review!

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

PR: https://git.openjdk.org/jdk19/pull/100

From dcubed at openjdk.org  Fri Jul  1 16:24:41 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 1 Jul 2022 16:24:41 GMT
Subject: [jdk19] Integrated: 8289585: ProblemList
 sun/tools/jhsdb/JStackStressTest.java on linux-aarch64
In-Reply-To: <GRzsvARHl6-8pukA116zw4D17wVUxacolAuRcnA3UQA=.1c61efac-1312-4ab3-9376-d189bf62334e@github.com>
References: <GRzsvARHl6-8pukA116zw4D17wVUxacolAuRcnA3UQA=.1c61efac-1312-4ab3-9376-d189bf62334e@github.com>
Message-ID: <ky7nuSJ6EwtV3uJ2Or0Fp0puKbmxriUqSDh061CdpXc=.6d0cb046-1faf-48bb-8647-e6eda0e54296@github.com>

On Fri, 1 Jul 2022 16:12:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to  ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64.

This pull request has now been integrated.

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

8289585: ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64

Reviewed-by: bpb, kevinw

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

PR: https://git.openjdk.org/jdk19/pull/100

From sspitsyn at openjdk.org  Fri Jul  1 16:46:45 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Jul 2022 16:46:45 GMT
Subject: [jdk19] RFR: 8289439: Clarify relationship between
 ThreadStart/ThreadEnd and can_support_virtual_threads capability
In-Reply-To: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
References: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
Message-ID: <wfyjb2tMTPuRAv3yw1Nnjh5W1UCtuZscqOxiqCxgDG0=.eb77ae19-227d-4011-9713-1d10b8bae379@github.com>

On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The description of the ThreadStart/End events in the JVM TI spec needs rewording to make it clearer when these events are sent for virtual threads and when VirtualThreadXXX events are sent instead.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/94

From sspitsyn at openjdk.org  Fri Jul  1 18:01:11 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Jul 2022 18:01:11 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread that
 has terminated
Message-ID: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>

This is fixing the JVM TI GetThreadState issue which returns for terminated virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bit early (before the values of `java_thread` and `thread_oop` are set). This was a root cause of the `GetThreadState` incorrect behavior.

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

Commit messages:
 - fixed one trailing space issue
 - 8288703: GetThreadState returns 0 for virtual thread that has terminated

Changes: https://git.openjdk.org/jdk19/pull/102/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=102&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288703
  Stats: 51 lines in 3 files changed: 46 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk19/pull/102.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/102/head:pull/102

PR: https://git.openjdk.org/jdk19/pull/102

From cjplummer at openjdk.org  Fri Jul  1 18:17:35 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Jul 2022 18:17:35 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v7]
In-Reply-To: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
Message-ID: <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>

> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
> 
> 
>         if (list != &otherThreads) {
>             setThreadLocalStorage(node->thread, (void*)node);
>         }

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

  provide a slightly more descriptive @summary

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/88/files
  - new: https://git.openjdk.org/jdk19/pull/88/files/96507bca..bb35374e

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

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

PR: https://git.openjdk.org/jdk19/pull/88

From cjplummer at openjdk.org  Fri Jul  1 18:39:47 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Jul 2022 18:39:47 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v12]
In-Reply-To: <1miMI1m2VJdL9K2Zfkmz7m3f_VuUwE0B36_8QoV1ha8=.abd05d40-03af-42a7-aa38-85866360f594@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <1miMI1m2VJdL9K2Zfkmz7m3f_VuUwE0B36_8QoV1ha8=.abd05d40-03af-42a7-aa38-85866360f594@github.com>
Message-ID: <jwzVChF70ehi09ce7V8tb9rJSsIu8Nib6ujiVwPBpYA=.f7dbd3d1-bcec-4797-ae9c-d4872c3c73c2@github.com>

On Fri, 1 Jul 2022 12:57:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporated plummercj's test changes

test/jdk/com/sun/jdi/TestClassUnloadEvents.java line 61:

> 59:                     return;
> 60:                 }
> 61:             }

I know you were having issues with the test sometimes failing and asked about if the GC's are deterministic, I assume this is the work around for that. My concern is if something were to change and the test started to never get any ClassUnloadEvents, that would go unnoticed. I'd rather you made it so the test failed after exiting this loop, and bump up MAX_RETRY to a high enough number so that we are unlikely to ever see that happen.

You should also have a look at the runtime/ClassUnload/UnloadTest.java and see how it handles class unloading. It relies on the ClassUnloadCommon library class. One difference I see there is that before doing a System.gc(), it first allocates 16m of memory in 1k chunks to force a young gen collection. I don't understand details of GC collection, but perhaps System.gc() is simply promoting from the youngGen and therefore not freeing any Class instance found there, so you need to promote first and then do the full GC.

test/jdk/com/sun/jdi/TestClassUnloadEvents.java line 182:

> 180:                 eventSet.resume();
> 181:             }
> 182:         } catch (InterruptedException | VMCannotBeModifiedException | IOException | IllegalConnectorArgumentsException | VMStartException e) {

I think you should remove the try/catch and just declare that this method throws Exception. That seems to be what other tests are doing.

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

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

From alanb at openjdk.org  Fri Jul  1 18:51:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Jul 2022 18:51:51 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v7]
In-Reply-To: <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
Message-ID: <msVcMp3-cAnZ6hQ2rw11pS_BXGNMxbq0sdAEIoKUBJ8=.c63d7074-366c-4f7e-8223-b8b1cc3054fa@github.com>

On Fri, 1 Jul 2022 18:17:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   provide a slightly more descriptive @summary

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/88

From cjplummer at openjdk.org  Fri Jul  1 18:53:33 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Jul 2022 18:53:33 GMT
Subject: [jdk19] RFR: 8289439: Clarify relationship between
 ThreadStart/ThreadEnd and can_support_virtual_threads capability
In-Reply-To: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
References: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
Message-ID: <RFLVLQ9vHBlvOi-EhbJdCc4nJYCjpNE3Ddy5zTpqKEQ=.95d0fa13-6052-4641-9a81-ec501eca603a@github.com>

On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The description of the ThreadStart/End events in the JVM TI spec needs rewording to make it clearer when these events are sent for virtual threads and when VirtualThreadXXX events are sent instead.

src/hotspot/share/prims/jvmti.xml line 12898:

> 12896:       <p/>
> 12897:       This event is generated by platform threads. It is also generated by
> 12898:       virtual threads when the capability

Is there a reason you chose to use "by" instead of "for"?  Although the thread that the event is generated "by" is the same as the thread it is generated "for", to me using "by" just reads kind of funny. The consumer of this event is usually not concerned about the thread the event is delivered on, only the thread it is delivered for.

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

PR: https://git.openjdk.org/jdk19/pull/94

From alanb at openjdk.org  Fri Jul  1 18:58:38 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Jul 2022 18:58:38 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated
In-Reply-To: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
Message-ID: <kLjgjVns-wuksrnMgbHglQznDSzi23qJHb6ilb3kwmg=.91fc5131-6b3d-4cfa-bf47-c10c409ca2e9@github.com>

On Fri, 1 Jul 2022 17:47:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is fixing the JVM TI GetThreadState issue which returns for terminated virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bit early (before the values of `java_thread` and `thread_oop` are set). This was a root cause of the `GetThreadState` incorrect behavior.

The fix looks good but I'm wondering why the SelfSuspendDisabledTest is being used to test this bug. I guess I expected to see a test for GetThreadState instead.

test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java line 60:

> 58:     }
> 59: 
> 60:     private static void testJvmtiThreadState(Thread thread, int expectedState) throws RuntimeException {

Minor nit, "throws RuntimeException" is not needed here.

test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/libSelfSuspendDisablerTest.cpp line 68:

> 66: }
> 67: 
> 68: }

it might be helpful to add 

// extern "C" 

after the brace as it confused me initially as to why there are two braces.

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

PR: https://git.openjdk.org/jdk19/pull/102

From amenkov at openjdk.org  Fri Jul  1 18:58:39 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 1 Jul 2022 18:58:39 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated
In-Reply-To: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
Message-ID: <r4ZKjRgkM6rBUWC5xvtQy3R9RCTTxSExLhd0s_PnJAY=.071a9537-d35f-4cf9-905d-cbb70b9e37da@github.com>

On Fri, 1 Jul 2022 17:47:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is fixing the JVM TI GetThreadState issue which returns for terminated virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bit early (before the values of `java_thread` and `thread_oop` are set). This was a root cause of the `GetThreadState` incorrect behavior.

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/102

From alanb at openjdk.org  Fri Jul  1 19:08:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Jul 2022 19:08:50 GMT
Subject: [jdk19] RFR: 8289439: Clarify relationship between
 ThreadStart/ThreadEnd and can_support_virtual_threads capability
In-Reply-To: <RFLVLQ9vHBlvOi-EhbJdCc4nJYCjpNE3Ddy5zTpqKEQ=.95d0fa13-6052-4641-9a81-ec501eca603a@github.com>
References: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
 <RFLVLQ9vHBlvOi-EhbJdCc4nJYCjpNE3Ddy5zTpqKEQ=.95d0fa13-6052-4641-9a81-ec501eca603a@github.com>
Message-ID: <6fIfmKil5sEcjSTfSuQ2doYOk5qZaxNsT4DRotsZBgo=.da7c4bb1-53dd-48bd-bcfa-94a281e68bb1@github.com>

On Fri, 1 Jul 2022 18:49:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Is there a reason you chose to use "by" instead of "for"? 

The specification of these two events have always used "generated by" in the first sentence of the description so it's just keeping it consistent. The thread lifecycle events are cases where it's important to be guaranteed that the events are reported on the threads themselves.

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

PR: https://git.openjdk.org/jdk19/pull/94

From cjplummer at openjdk.org  Fri Jul  1 20:02:40 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Jul 2022 20:02:40 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated
In-Reply-To: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
Message-ID: <WOzCZvzEaaUZlS6qzV6BxuaKKReuujCCfrng1Y972Ro=.a59a8484-f77b-4a34-9520-fb21c1ebd35a@github.com>

On Fri, 1 Jul 2022 17:47:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is fixing the JVM TI GetThreadState issue which returns for terminated virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bit early (before the values of `java_thread` and `thread_oop` are set). This was a root cause of the `GetThreadState` incorrect behavior.

Marked as reviewed by cjplummer (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java line 102:

> 100:         }
> 101: 
> 102:         testJvmtiThreadState(t2, SUSPENDED);

Not a useful check after the isSuspended(t2) call above, but no harm in it either.

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

PR: https://git.openjdk.org/jdk19/pull/102

From cjplummer at openjdk.org  Fri Jul  1 21:02:40 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Jul 2022 21:02:40 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v7]
In-Reply-To: <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
Message-ID: <NmTIjvxNA1zf-J9eU2X0Y-IOGmHdlFepmvU-78P_bHE=.e4909498-9359-479e-ae1c-d64f47471e35@github.com>

On Fri, 1 Jul 2022 18:17:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   provide a slightly more descriptive @summary

I decided to check the status of the target thread when the breakpoint was reached, and as expected it was incorrect in the virtual thread case due to [JDK-8288703](https://bugs.openjdk.org/browse/JDK-8288703). The status was THREAD_STATUS_UNKNOWN instead of THREAD_STATUS_ZOMBIE. I applied Serguei's JVMTI fix and that resolved the problem. Once Serguei pushes #102 I'll merge, verify my test changes, and then commit them for further review.

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

PR: https://git.openjdk.org/jdk19/pull/88

From sspitsyn at openjdk.org  Fri Jul  1 21:48:29 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 1 Jul 2022 21:48:29 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated [v2]
In-Reply-To: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
Message-ID: <iwujwTxD8gFzSuecLcBLk6SCZEExf8_kgJzDKzGLB6w=.47b8664c-262c-473d-9b04-1283c6f0ebf8@github.com>

> This is fixing the JVM TI GetThreadState issue which returns for terminated virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bit early (before the values of `java_thread` and `thread_oop` are set). This was a root cause of the `GetThreadState` incorrect behavior.

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

  fix serviceability/jvmti/thread/thrstat03 to except correct GetThreadState result for terminated vthreads

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/102/files
  - new: https://git.openjdk.org/jdk19/pull/102/files/85cb92ba..7199e962

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

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

PR: https://git.openjdk.org/jdk19/pull/102

From ccheung at openjdk.org  Fri Jul  1 21:49:47 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 1 Jul 2022 21:49:47 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v3]
In-Reply-To: <Z0lHSUzi5gdXlQ5_DMl6rO0hxg-b4rfeCX5hwZuHaHQ=.c267b32c-47bd-4efa-a248-aef033d64bf4@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <Z0lHSUzi5gdXlQ5_DMl6rO0hxg-b4rfeCX5hwZuHaHQ=.c267b32c-47bd-4efa-a248-aef033d64bf4@github.com>
Message-ID: <AVQXwvbd8IxMNBU7gF4NQ-M56hRQrq1Ar6r4Kfp9mAc=.01199773-f9b8-4fc8-99e5-6cdbe6f7f2e3@github.com>

On Tue, 28 Jun 2022 20:13:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There are only two implementations of these classes (one for windows, and one for posix):
>> 
>> - PlatformEvent
>> - PlatformParker
>> - PlatformMutex
>> - PlatformMonitor
>> - ThreadCrashProtection
>> 
>> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
>> 
>> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
>> 
>> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments

Looks good. Just one nit.

src/hotspot/share/runtime/mutex.cpp line 334:

> 332: }
> 333: 
> 334: 

Line 334 deleted by accident?

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

Marked as reviewed by ccheung (Reviewer).

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

From cjplummer at openjdk.org  Fri Jul  1 22:08:44 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 1 Jul 2022 22:08:44 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated [v2]
In-Reply-To: <iwujwTxD8gFzSuecLcBLk6SCZEExf8_kgJzDKzGLB6w=.47b8664c-262c-473d-9b04-1283c6f0ebf8@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
 <iwujwTxD8gFzSuecLcBLk6SCZEExf8_kgJzDKzGLB6w=.47b8664c-262c-473d-9b04-1283c6f0ebf8@github.com>
Message-ID: <xBgr5CkPCL5xUzWoelMfj00PXf3S5g44yNBzfv_hPuU=.51d89918-08a3-42a8-966c-d1e39bc3ac95@github.com>

On Fri, 1 Jul 2022 21:48:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is fixing the JVM TI GetThreadState issue which returns for terminated virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bit early (before the values of `java_thread` and `thread_oop` are set). This was a root cause of the `GetThreadState` incorrect behavior.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix serviceability/jvmti/thread/thrstat03 to except correct GetThreadState result for terminated vthreads

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/102

From sspitsyn at openjdk.org  Sat Jul  2 02:35:39 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 02:35:39 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v7]
In-Reply-To: <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
Message-ID: <uAKHOjVqzH5W0CkyIShkIwYdH1Kzw9CzwX0bnMa24TQ=.b92101d2-a15e-48bb-9535-aeaa1d2b546f@github.com>

On Fri, 1 Jul 2022 18:17:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   provide a slightly more descriptive @summary

test/jdk/com/sun/jdi/SuspendAfterDeath.java line 73:

> 71: 
> 72: public class SuspendAfterDeath extends TestScaffold {
> 73:     private volatile ThreadReference thread;

One minor naming suggestion:
The name `thread` is too generic. What about something like `targetThread` or `testedThread`?

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

PR: https://git.openjdk.org/jdk19/pull/88

From sspitsyn at openjdk.org  Sat Jul  2 02:41:40 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 02:41:40 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v7]
In-Reply-To: <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
Message-ID: <xNMAym_KKvfEqX93hSbw-JoH5E8mFUdfYLF5SI2_tgE=.07d6ebf4-7dfa-4742-be04-8625656e0d1f@github.com>

On Fri, 1 Jul 2022 18:17:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   provide a slightly more descriptive @summary

test/jdk/com/sun/jdi/TestScaffold.java line 976:

> 974:                 }
> 975:             });
> 976:             Thread.currentThread().setName(OLD_MAIN_THREAD_NAME);

Just want to understand what is this thread naming is about.
Is it just to properly name the threads, or there is some other reason for this?
Also, why OLD_MAIN_THREAD_NAME is a little bit strange and why old?

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

PR: https://git.openjdk.org/jdk19/pull/88

From sspitsyn at openjdk.org  Sat Jul  2 03:13:26 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 03:13:26 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated [v2]
In-Reply-To: <kLjgjVns-wuksrnMgbHglQznDSzi23qJHb6ilb3kwmg=.91fc5131-6b3d-4cfa-bf47-c10c409ca2e9@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
 <kLjgjVns-wuksrnMgbHglQznDSzi23qJHb6ilb3kwmg=.91fc5131-6b3d-4cfa-bf47-c10c409ca2e9@github.com>
Message-ID: <ogeb-rOgq_Xe2lFwxCzDkQipaVLk_4i6RPHdeUsuvAM=.ecbf081c-e089-47a0-9c5c-2b6ec3abf1ef@github.com>

On Fri, 1 Jul 2022 18:53:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix serviceability/jvmti/thread/thrstat03 to except correct GetThreadState result for terminated vthreads
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/libSelfSuspendDisablerTest.cpp line 68:
> 
>> 66: }
>> 67: 
>> 68: }
> 
> it might be helpful to add 
> 
> // extern "C" 
> 
> after the brace as it confused me initially as to why there are two braces.

Good catch. Fixed.

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

PR: https://git.openjdk.org/jdk19/pull/102

From sspitsyn at openjdk.org  Sat Jul  2 03:28:42 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 03:28:42 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated [v2]
In-Reply-To: <kLjgjVns-wuksrnMgbHglQznDSzi23qJHb6ilb3kwmg=.91fc5131-6b3d-4cfa-bf47-c10c409ca2e9@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
 <kLjgjVns-wuksrnMgbHglQznDSzi23qJHb6ilb3kwmg=.91fc5131-6b3d-4cfa-bf47-c10c409ca2e9@github.com>
Message-ID: <MXF1JBQWiKoxjshsdM6ETI1EK1GEUqVEBtbtSEgY7Fw=.49d6fb7d-b6ca-43b8-98bd-efca9aaa312a@github.com>

On Fri, 1 Jul 2022 18:51:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix serviceability/jvmti/thread/thrstat03 to except correct GetThreadState result for terminated vthreads
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java line 60:
> 
>> 58:     }
>> 59: 
>> 60:     private static void testJvmtiThreadState(Thread thread, int expectedState) throws RuntimeException {
> 
> Minor nit, "throws RuntimeException" is not needed here.

Ah, yes. I was thinking it is not needed but forgot to double-check.
Fixed now.

> The fix looks good but I'm wondering why the SelfSuspendDisabledTest is being used to test this bug. I guess I expected to see a test for GetThreadState instead.

The GetThreadState by its instrumental role can be used by many tests.
My initial intent was to check the terminated virtual thread case.
It looked as unneeded overhead to create a new test for this.
So, I've found this small test which already has convenient infrastructure to recreate needed conditions.
Then I decided to extend GetThreadState coverage in this test a little bit.
I can create a GetThreadState specific test if you think it is worth it.
 Interesting enough that I've found the existing test which already had needed coverage:
   ` test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat03`
But this test was adjusted to adopt to incorrect GetThreadState result for virtual threads, so I had to fix it now.
Strongly speaking, the update of SelfSuspendDisabledTest is not needed.
But I feel it is worth to keep it.

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

PR: https://git.openjdk.org/jdk19/pull/102

From sspitsyn at openjdk.org  Sat Jul  2 03:28:43 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 03:28:43 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated [v2]
In-Reply-To: <WOzCZvzEaaUZlS6qzV6BxuaKKReuujCCfrng1Y972Ro=.a59a8484-f77b-4a34-9520-fb21c1ebd35a@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
 <WOzCZvzEaaUZlS6qzV6BxuaKKReuujCCfrng1Y972Ro=.a59a8484-f77b-4a34-9520-fb21c1ebd35a@github.com>
Message-ID: <uY52mOjmMbSlfUFrxuaPFHGffHTqgzoQfnawFlgZvVA=.f4e17cd0-9011-41dc-b95b-d702cb9c5688@github.com>

On Fri, 1 Jul 2022 19:59:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix serviceability/jvmti/thread/thrstat03 to except correct GetThreadState result for terminated vthreads
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java line 102:
> 
>> 100:         }
>> 101: 
>> 102:         testJvmtiThreadState(t2, SUSPENDED);
> 
> Not a useful check after the isSuspended(t2) call above, but no harm in it either.

You are right in both cases. :)

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

PR: https://git.openjdk.org/jdk19/pull/102

From sspitsyn at openjdk.org  Sat Jul  2 03:28:46 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 03:28:46 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated [v2]
In-Reply-To: <ogeb-rOgq_Xe2lFwxCzDkQipaVLk_4i6RPHdeUsuvAM=.ecbf081c-e089-47a0-9c5c-2b6ec3abf1ef@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
 <kLjgjVns-wuksrnMgbHglQznDSzi23qJHb6ilb3kwmg=.91fc5131-6b3d-4cfa-bf47-c10c409ca2e9@github.com>
 <ogeb-rOgq_Xe2lFwxCzDkQipaVLk_4i6RPHdeUsuvAM=.ecbf081c-e089-47a0-9c5c-2b6ec3abf1ef@github.com>
Message-ID: <-C3_lYflAJGrTkf1z6v7hmoopY0ROdiyRgBX63vSQco=.17b26b9e-f840-4eb9-a2f7-eb813aacb26a@github.com>

On Sat, 2 Jul 2022 03:10:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/libSelfSuspendDisablerTest.cpp line 68:
>> 
>>> 66: }
>>> 67: 
>>> 68: }
>> 
>> it might be helpful to add 
>> 
>> // extern "C" 
>> 
>> after the brace as it confused me initially as to why there are two braces.
>
> Good catch. Fixed.

Good suggestion. Resolved.

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

PR: https://git.openjdk.org/jdk19/pull/102

From sspitsyn at openjdk.org  Sat Jul  2 03:35:11 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 03:35:11 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated [v3]
In-Reply-To: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
Message-ID: <A61HyxJB5JbOvlILJRDOaPQbF3Ck27cJIbjdhSGJcqM=.c508b282-752a-485a-b13d-82b84f14b678@github.com>

> This is fixing the JVM TI GetThreadState issue which returns for terminated virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bit early (before the values of `java_thread` and `thread_oop` are set). This was a root cause of the `GetThreadState` incorrect behavior.

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

  resolved minor comments for the SelfSuspendDisablerTest test

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/102/files
  - new: https://git.openjdk.org/jdk19/pull/102/files/7199e962..8c9e104b

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

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

PR: https://git.openjdk.org/jdk19/pull/102

From sspitsyn at openjdk.org  Sat Jul  2 03:39:29 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 03:39:29 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v7]
In-Reply-To: <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
Message-ID: <5VWnZpPAfigw465NgtlaDysDrqVSXYN5g-61EtjeK48=.0becc4d9-5149-4c57-a387-c1642ac37867@github.com>

On Fri, 1 Jul 2022 18:17:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   provide a slightly more descriptive @summary

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/88

From iklam at openjdk.org  Sat Jul  2 04:26:48 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 2 Jul 2022 04:26:48 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v4]
In-Reply-To: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
Message-ID: <nEYbWc6VGfEWGjwWUlXM2kyHHuvZhqKTibRpcncuU3M=.1889c4f0-eed9-4dcf-81eb-25d2f5fc8fd0@github.com>

> There are only two implementations of these classes (one for windows, and one for posix):
> 
> - PlatformEvent
> - PlatformParker
> - PlatformMutex
> - PlatformMonitor
> - ThreadCrashProtection
> 
> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
> 
> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
> 
> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).

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

 - removed unrelated newline change
 - Merge branch 'master' into 8289230-move-Platform-classes-out-of-os-xxx-hpp
 - @coleenp comments
 - fixed comments
 - fixed windows
 - Moved PlatformMutex/PlatformMonitor
 - move-PlatformParker-out-of-os-xxx-hpp
 - Moved ThreadCrashProtection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9303/files
  - new: https://git.openjdk.org/jdk/pull/9303/files/9d502ffb..bafda85c

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

  Stats: 8540 lines in 227 files changed: 5586 ins; 1406 del; 1548 mod
  Patch: https://git.openjdk.org/jdk/pull/9303.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9303/head:pull/9303

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

From alanb at openjdk.org  Sat Jul  2 05:09:41 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 2 Jul 2022 05:09:41 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated [v3]
In-Reply-To: <A61HyxJB5JbOvlILJRDOaPQbF3Ck27cJIbjdhSGJcqM=.c508b282-752a-485a-b13d-82b84f14b678@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
 <A61HyxJB5JbOvlILJRDOaPQbF3Ck27cJIbjdhSGJcqM=.c508b282-752a-485a-b13d-82b84f14b678@github.com>
Message-ID: <o8Ws0cIIbqCbX6yPGWfgG-llP_NR_yKAVsJoayVrrig=.4850e699-2d55-4f10-a048-4ebb7c77df13@github.com>

On Sat, 2 Jul 2022 03:35:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is fixing the JVM TI GetThreadState issue which returns for terminated virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bit early (before the values of `java_thread` and `thread_oop` are set). This was a root cause of the `GetThreadState` incorrect behavior.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   resolved minor comments for the SelfSuspendDisablerTest test

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/102

From alanb at openjdk.org  Sat Jul  2 05:09:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 2 Jul 2022 05:09:43 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated [v3]
In-Reply-To: <MXF1JBQWiKoxjshsdM6ETI1EK1GEUqVEBtbtSEgY7Fw=.49d6fb7d-b6ca-43b8-98bd-efca9aaa312a@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
 <kLjgjVns-wuksrnMgbHglQznDSzi23qJHb6ilb3kwmg=.91fc5131-6b3d-4cfa-bf47-c10c409ca2e9@github.com>
 <MXF1JBQWiKoxjshsdM6ETI1EK1GEUqVEBtbtSEgY7Fw=.49d6fb7d-b6ca-43b8-98bd-efca9aaa312a@github.com>
Message-ID: <ZU8gjaar73rO_CxgGtz17ZNlUI_r8HEKaoqs7Day78Y=.9d459928-2080-4ac3-a2c6-38b438bae671@github.com>

On Sat, 2 Jul 2022 03:22:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Interesting enough that I've found the existing test which already had needed coverage: ` test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat03` But this test was adjusted to adopt to incorrect GetThreadState result for virtual threads, so I had to fix it now. Strongly speaking, the update of SelfSuspendDisabledTest is not needed. But I feel it is worth to keep it.

This goes to my surprise that we didn't have a test already but you've found it, and found that it should have caught this bug except that it has been changed. Good to find this and I that is the right place to have a unit test for GetThreadState.

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

PR: https://git.openjdk.org/jdk19/pull/102

From cjplummer at openjdk.org  Sat Jul  2 05:27:28 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 2 Jul 2022 05:27:28 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v7]
In-Reply-To: <uAKHOjVqzH5W0CkyIShkIwYdH1Kzw9CzwX0bnMa24TQ=.b92101d2-a15e-48bb-9535-aeaa1d2b546f@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
 <uAKHOjVqzH5W0CkyIShkIwYdH1Kzw9CzwX0bnMa24TQ=.b92101d2-a15e-48bb-9535-aeaa1d2b546f@github.com>
Message-ID: <dLE5yc5HCfRgx3cq_N1k07IVxRLsBjEmelZgtDdHM1U=.78dcc6fc-94af-4fbe-aa0e-796ede621de8@github.com>

On Sat, 2 Jul 2022 02:32:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   provide a slightly more descriptive @summary
>
> test/jdk/com/sun/jdi/SuspendAfterDeath.java line 73:
> 
>> 71: 
>> 72: public class SuspendAfterDeath extends TestScaffold {
>> 73:     private volatile ThreadReference thread;
> 
> One minor naming suggestion:
> The name `thread` is too generic. What about something like `targetThread` or `testedThread`?

Ok. I'll rename to targetThread.

> test/jdk/com/sun/jdi/TestScaffold.java line 976:
> 
>> 974:                 }
>> 975:             });
>> 976:             Thread.currentThread().setName(OLD_MAIN_THREAD_NAME);
> 
> Just want to understand what is this thread naming is about.
> Is it just to properly name the threads, or there is some other reason for this?
> Also, why OLD_MAIN_THREAD_NAME is a little bit strange and why old?

The "main" debuggee thread is always launched as a platform thread. There's no choice in that since it is simply the main application thread. When using the virtual thread wrapper, the "main" thread will spawn a virtual thread to run the debuggee on. By default virtual threads have no name. For the nsk debugger tests, "main" was renamed to "old-m-a-i-n", and the new debuggee virtual thread named "main". For some reason that was never done for the com/sun/jdi tests. I only made this change because in `breakpointReached()` of the test it prints out the thread, and I noticed the name was empty.  I could leave this change out if you want and file a separate CR for it. The test should still run ok without it.

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

PR: https://git.openjdk.org/jdk19/pull/88

From cjplummer at openjdk.org  Sat Jul  2 05:29:41 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 2 Jul 2022 05:29:41 GMT
Subject: [jdk19] RFR: 8289439: Clarify relationship between
 ThreadStart/ThreadEnd and can_support_virtual_threads capability
In-Reply-To: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
References: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
Message-ID: <XyHOPL_elXxoq2Z6_ZC8sdaurYkjOr9y3j1_ckI5_Nc=.1685093c-6b62-41cb-8773-090f0701a076@github.com>

On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The description of the ThreadStart/End events in the JVM TI spec needs rewording to make it clearer when these events are sent for virtual threads and when VirtualThreadXXX events are sent instead.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/94

From sspitsyn at openjdk.org  Sat Jul  2 05:43:42 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 05:43:42 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v7]
In-Reply-To: <dLE5yc5HCfRgx3cq_N1k07IVxRLsBjEmelZgtDdHM1U=.78dcc6fc-94af-4fbe-aa0e-796ede621de8@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
 <uAKHOjVqzH5W0CkyIShkIwYdH1Kzw9CzwX0bnMa24TQ=.b92101d2-a15e-48bb-9535-aeaa1d2b546f@github.com>
 <dLE5yc5HCfRgx3cq_N1k07IVxRLsBjEmelZgtDdHM1U=.78dcc6fc-94af-4fbe-aa0e-796ede621de8@github.com>
Message-ID: <4MZaPXXqoxoRlmZGHQVVrd1IUmyS3ilPwG07QruKHMI=.eeea19ee-4883-4d7e-ae73-a79a72bb9dbc@github.com>

On Sat, 2 Jul 2022 05:23:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/jdk/com/sun/jdi/TestScaffold.java line 976:
>> 
>>> 974:                 }
>>> 975:             });
>>> 976:             Thread.currentThread().setName(OLD_MAIN_THREAD_NAME);
>> 
>> Just want to understand what is this thread naming is about.
>> Is it just to properly name the threads, or there is some other reason for this?
>> Also, why OLD_MAIN_THREAD_NAME is a little bit strange and why old?
>
> The "main" debuggee thread is always launched as a platform thread. There's no choice in that since it is simply the main application thread. When using the virtual thread wrapper, the "main" thread will spawn a virtual thread to run the debuggee on. By default virtual threads have no name. For the nsk debugger tests, "main" was renamed to "old-m-a-i-n", and the new debuggee virtual thread named "main". For some reason that was never done for the com/sun/jdi tests. I only made this change because in `breakpointReached()` of the test it prints out the thread, and I noticed the name was empty.  I could leave this change out if you want and file a separate CR for it. The test should still run ok without it.

Thank you for explaining. Just wanted to understand the motivation.

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

PR: https://git.openjdk.org/jdk19/pull/88

From sspitsyn at openjdk.org  Sat Jul  2 05:46:25 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 05:46:25 GMT
Subject: [jdk19] RFR: 8288703: GetThreadState returns 0 for virtual thread
 that has terminated [v3]
In-Reply-To: <A61HyxJB5JbOvlILJRDOaPQbF3Ck27cJIbjdhSGJcqM=.c508b282-752a-485a-b13d-82b84f14b678@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
 <A61HyxJB5JbOvlILJRDOaPQbF3Ck27cJIbjdhSGJcqM=.c508b282-752a-485a-b13d-82b84f14b678@github.com>
Message-ID: <-SZHKB2nKh--xjsLg9jmFea0e4wyCRqpmBBHYiyhHUc=.50825af6-60f7-40c4-885b-962862a2a250@github.com>

On Sat, 2 Jul 2022 03:35:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is fixing the JVM TI GetThreadState issue which returns for terminated virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bit early (before the values of `java_thread` and `thread_oop` are set). This was a root cause of the `GetThreadState` incorrect behavior.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   resolved minor comments for the SelfSuspendDisablerTest test

Alan, Alex and Chris, thank you for reviews and comments!

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

PR: https://git.openjdk.org/jdk19/pull/102

From sspitsyn at openjdk.org  Sat Jul  2 05:46:26 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 05:46:26 GMT
Subject: [jdk19] Integrated: 8288703: GetThreadState returns 0 for virtual
 thread that has terminated
In-Reply-To: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
References: <mk6zAloaNOmkyvd5CdWSffk5U3S72Vv4tRaFPT_FCeI=.5d32cf2f-4043-4159-8229-60adf604b5ea@github.com>
Message-ID: <F1OpvJZJl4IxPWFy-HNQCtxFrgpSUAueBrUbxWf-v_Y=.baca7432-1019-45a6-bc97-86b20ddd26b7@github.com>

On Fri, 1 Jul 2022 17:47:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is fixing the JVM TI GetThreadState issue which returns for terminated virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bit early (before the values of `java_thread` and `thread_oop` are set). This was a root cause of the `GetThreadState` incorrect behavior.

This pull request has now been integrated.

Changeset: 9515560c
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/9515560c54438156b37f1549229bcb5535df5fd1
Stats:     52 lines in 4 files changed: 46 ins; 2 del; 4 mod

8288703: GetThreadState returns 0 for virtual thread that has terminated

Reviewed-by: alanb, amenkov, cjplummer

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

PR: https://git.openjdk.org/jdk19/pull/102

From cjplummer at openjdk.org  Sat Jul  2 06:21:36 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 2 Jul 2022 06:21:36 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v8]
In-Reply-To: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
Message-ID: <_gZ-r6Jk7L_v1Wv9e2tMcMdxWb7mGgHq1xmShU2m-vc=.ee559b42-92a0-4f14-a54e-3c37524419dc@github.com>

> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
> 
> 
>         if (list != &otherThreads) {
>             setThreadLocalStorage(node->thread, (void*)node);
>         }

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

 - Merge branch 'master' of https://github.com/openjdk/jdk19 into 8287847_nb
   merge
 - provide a slightly more descriptive @summary
 - Add new SuspendAfterDeath test to jdk_jdi_sanity test group.
 - Always run test both in virtual and platform thread modes
 - No need to initialzie boolean to false.
 - Get rid of need to cast toArray() result to a String[]
 - fix indentation
 - fixed jcheck errors
 - Fix issue with suspending a virtual thread after it has terminated.

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/88/files
  - new: https://git.openjdk.org/jdk19/pull/88/files/bb35374e..17e4658e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=88&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=88&range=06-07

  Stats: 1123 lines in 39 files changed: 833 ins; 91 del; 199 mod
  Patch: https://git.openjdk.org/jdk19/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/88/head:pull/88

PR: https://git.openjdk.org/jdk19/pull/88

From cjplummer at openjdk.org  Sat Jul  2 06:30:13 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 2 Jul 2022 06:30:13 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v9]
In-Reply-To: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
Message-ID: <F7VZfshSavmH7b-zEfDnag80kVsftRyUYu-cQ_fUorQ=.87f3c4db-29a1-4707-bc5c-402dae8b763d@github.com>

> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
> 
> 
>         if (list != &otherThreads) {
>             setThreadLocalStorage(node->thread, (void*)node);
>         }

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

  Rename thread to targetThread. Verify targetThread state when the thread dies and when the breakpoint after the join() is reached.

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/88/files
  - new: https://git.openjdk.org/jdk19/pull/88/files/17e4658e..1ff59060

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=88&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=88&range=07-08

  Stats: 21 lines in 1 file changed: 13 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk19/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/88/head:pull/88

PR: https://git.openjdk.org/jdk19/pull/88

From cjplummer at openjdk.org  Sat Jul  2 06:30:15 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 2 Jul 2022 06:30:15 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v8]
In-Reply-To: <_gZ-r6Jk7L_v1Wv9e2tMcMdxWb7mGgHq1xmShU2m-vc=.ee559b42-92a0-4f14-a54e-3c37524419dc@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <_gZ-r6Jk7L_v1Wv9e2tMcMdxWb7mGgHq1xmShU2m-vc=.ee559b42-92a0-4f14-a54e-3c37524419dc@github.com>
Message-ID: <_karrVIDosBzzFeKNTWftrcXHEYK9Q8doEfX6SXZWBc=.5beb6527-7c20-40c6-846e-cc604a0a9530@github.com>

On Sat, 2 Jul 2022 06:21:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk19 into 8287847_nb
>    merge
>  - provide a slightly more descriptive @summary
>  - Add new SuspendAfterDeath test to jdk_jdi_sanity test group.
>  - Always run test both in virtual and platform thread modes
>  - No need to initialzie boolean to false.
>  - Get rid of need to cast toArray() result to a String[]
>  - fix indentation
>  - fixed jcheck errors
>  - Fix issue with suspending a virtual thread after it has terminated.

Serguei has pushed his JVMTI fix for the virtual thread state and I have pushed the test changes to verify the target thread's state. Please review. Thanks

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

PR: https://git.openjdk.org/jdk19/pull/88

From cjplummer at openjdk.org  Sat Jul  2 06:30:16 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 2 Jul 2022 06:30:16 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v7]
In-Reply-To: <dLE5yc5HCfRgx3cq_N1k07IVxRLsBjEmelZgtDdHM1U=.78dcc6fc-94af-4fbe-aa0e-796ede621de8@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <Z7hdSemjwl6NdhPgNvFVWx3ifCR6-87A3FRjvKhLSeE=.c0ee7fe6-581b-4612-a7b7-99ca25b6428c@github.com>
 <uAKHOjVqzH5W0CkyIShkIwYdH1Kzw9CzwX0bnMa24TQ=.b92101d2-a15e-48bb-9535-aeaa1d2b546f@github.com>
 <dLE5yc5HCfRgx3cq_N1k07IVxRLsBjEmelZgtDdHM1U=.78dcc6fc-94af-4fbe-aa0e-796ede621de8@github.com>
Message-ID: <VAX4lr3q3e_TiN2iTg3HGfRUTgkwBbDGaUuNInYnFkI=.06accd68-a798-4a33-a38d-e68f60306d5d@github.com>

On Sat, 2 Jul 2022 05:16:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/jdk/com/sun/jdi/SuspendAfterDeath.java line 73:
>> 
>>> 71: 
>>> 72: public class SuspendAfterDeath extends TestScaffold {
>>> 73:     private volatile ThreadReference thread;
>> 
>> One minor naming suggestion:
>> The name `thread` is too generic. What about something like `targetThread` or `testedThread`?
>
> Ok. I'll rename to targetThread.

Done.

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

PR: https://git.openjdk.org/jdk19/pull/88

From sspitsyn at openjdk.org  Sat Jul  2 07:02:40 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 07:02:40 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v9]
In-Reply-To: <F7VZfshSavmH7b-zEfDnag80kVsftRyUYu-cQ_fUorQ=.87f3c4db-29a1-4707-bc5c-402dae8b763d@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <F7VZfshSavmH7b-zEfDnag80kVsftRyUYu-cQ_fUorQ=.87f3c4db-29a1-4707-bc5c-402dae8b763d@github.com>
Message-ID: <x0a2FqANhHzUBa7_ld26YmivDFjzPbujHXmf8Nl4ruM=.d5ca4724-577c-4baf-b0e6-1f82fb6f2609@github.com>

On Sat, 2 Jul 2022 06:30:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename thread to targetThread. Verify targetThread state when the thread dies and when the breakpoint after the join() is reached.

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/88

From alanb at openjdk.org  Sat Jul  2 07:28:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 2 Jul 2022 07:28:50 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v9]
In-Reply-To: <F7VZfshSavmH7b-zEfDnag80kVsftRyUYu-cQ_fUorQ=.87f3c4db-29a1-4707-bc5c-402dae8b763d@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <F7VZfshSavmH7b-zEfDnag80kVsftRyUYu-cQ_fUorQ=.87f3c4db-29a1-4707-bc5c-402dae8b763d@github.com>
Message-ID: <v88XtUg2zFsmJ8ukbaw9L0U8OHPeMT_CKS9ZLkrbibo=.9a9761d6-4ae4-47b4-b6f8-4448808b5f57@github.com>

On Sat, 2 Jul 2022 06:30:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename thread to targetThread. Verify targetThread state when the thread dies and when the breakpoint after the join() is reached.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/88

From sspitsyn at openjdk.org  Sat Jul  2 09:13:41 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 09:13:41 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v9]
In-Reply-To: <F7VZfshSavmH7b-zEfDnag80kVsftRyUYu-cQ_fUorQ=.87f3c4db-29a1-4707-bc5c-402dae8b763d@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <F7VZfshSavmH7b-zEfDnag80kVsftRyUYu-cQ_fUorQ=.87f3c4db-29a1-4707-bc5c-402dae8b763d@github.com>
Message-ID: <mACJ9VifRhNp6Keg2ofY3STILr9yRyFg9Fuliq_ONWU=.2f8a7c68-621b-46b4-8492-034ff44d0c8b@github.com>

On Sat, 2 Jul 2022 06:30:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename thread to targetThread. Verify targetThread state when the thread dies and when the breakpoint after the join() is reached.

Chris,
I see the test SelfSuspendDisablerTest with my update failed in your sanity checks.

The problem is:
 ```
71     public static void main(String argv[]) throws Exception {
 72         Thread t1 = Thread.ofPlatform().factory().newThread(() -> {
 73             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
 74             selfSuspend();                       <== It does a self suspend here!!
 75         });
 76         Thread t2 = Thread.ofVirtual().factory().newThread(() -> {
 77             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
 78             while(!isSuspended(t1)) {
 79               Thread.yield();
 80             }
 81             Thread.yield(); // provoke unmount
 82 
 83             testJvmtiThreadState(t1, SUSPENDED);
 84 
 85             resume(t1);
 86 
 87             testJvmtiThreadState(t1, RUNNABLE);  <== This is wrong because of line 74!!
 88 
 89             suspendAllVirtualThreads();
 90         });

The line 87 has to be removed.
Could, you remove the lines 87-88 as part of your PR?
It?d be the simplest way to handle it.

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

PR: https://git.openjdk.org/jdk19/pull/88

From jwilhelm at openjdk.org  Sat Jul  2 11:15:24 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Sat, 2 Jul 2022 11:15:24 GMT
Subject: RFR: Merge jdk19
Message-ID: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8245268: -Xcomp is missing from java launcher documentation
 - 8288703: GetThreadState returns 0 for virtual thread that has terminated
 - 8288854: getLocalGraphicsEnvironment() on for multi-screen setups throws exception NPE
 - 8280320: C2: Loop opts are missing during OSR compilation
 - 8289570: SegmentAllocator:allocateUtf8String(String str) default behavior mismatch to spec
 - 8289585: ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64
 - 8289549: ISO 4217 Amendment 172 Update
 - 8284358: Unreachable loop is not removed from C2 IR, leading to a broken graph

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9354&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9354&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9354/files
  Stats: 382 lines in 14 files changed: 330 ins; 5 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/9354.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9354/head:pull/9354

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

From iklam at openjdk.org  Sat Jul  2 14:47:39 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 2 Jul 2022 14:47:39 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
 <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
Message-ID: <dCjeLmjfDmb-pcFUh7_Lp1COYwG-zWjBH2xK827Xpak=.082fba71-154b-4d0f-b207-6bfff08e734a@github.com>

On Tue, 28 Jun 2022 19:39:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed comments
>
> I very much like this incremental approach to reducing our over-inclusion.

Thanks @coleenp @calvinccheung @dholmes-ora for the review.

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

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

From iklam at openjdk.org  Sat Jul  2 14:47:40 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 2 Jul 2022 14:47:40 GMT
Subject: Integrated: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp
In-Reply-To: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
Message-ID: <vzewurbF5YHkstzu1cwTdlrG3lnxAACvS-RD0Qwj2l0=.f2dcb156-3799-4870-877a-2addc01ff4fc@github.com>

On Tue, 28 Jun 2022 06:16:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> There are only two implementations of these classes (one for windows, and one for posix):
> 
> - PlatformEvent
> - PlatformParker
> - PlatformMutex
> - PlatformMonitor
> - ThreadCrashProtection
> 
> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
> 
> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
> 
> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).

This pull request has now been integrated.

Changeset: cdf69792
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cdf697925953f62e17a7916ba611d7e789f09edf
Stats:     1172 lines in 36 files changed: 703 ins; 390 del; 79 mod

8289230: Move PlatformXXX class declarations out of os_xxx.hpp

Reviewed-by: coleenp, ccheung

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

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

From jwilhelm at openjdk.org  Sat Jul  2 18:13:28 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Sat, 2 Jul 2022 18:13:28 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>
References: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>
Message-ID: <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits:

 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8289603: Code change for JDK-8170762 breaks all build
   
   Reviewed-by: weijun
 - 8170762: Document that ISO10126Padding pads with random bytes
   
   Reviewed-by: weijun
 - 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB
   
   Reviewed-by: alanb
 - 8289257: Some custom loader tests failed due to symbol refcount not decremented
   
   Reviewed-by: iklam, coleenp
 - 8289534: Change 'uncomplicated' hotspot runtime options
   
   Reviewed-by: coleenp, dholmes
 - 8289512: Fix GCC 12 warnings for adlc output_c.cpp
   
   Reviewed-by: kvn, lucy
 - 8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2 with -XX:+TracePhaseCCP
   
   Reviewed-by: kvn, thartmann, chagedorn, dlong
 - 8288444: Remove the workaround for frame.pack() in ModalDialogTest
   
   Reviewed-by: azvegint
 - 8289434: x86_64: Improve comment on gen_continuation_enter()
   
   Reviewed-by: kvn
 - ... and 189 more: https://git.openjdk.org/jdk/compare/f5cdabad...20b15114

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

Changes: https://git.openjdk.org/jdk/pull/9354/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9354&range=01
  Stats: 79992 lines in 1361 files changed: 50048 ins; 16523 del; 13421 mod
  Patch: https://git.openjdk.org/jdk/pull/9354.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9354/head:pull/9354

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

From jwilhelm at openjdk.org  Sat Jul  2 18:13:29 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Sat, 2 Jul 2022 18:13:29 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>
References: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>
Message-ID: <vrcZn96qTXcrRhMsDhp5_kNYsPzJ4ScyoXMZNnptas4=.834e4eb5-6928-4279-9fc0-c726a9cf341d@github.com>

On Sat, 2 Jul 2022 11:03:38 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 70f56933
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70f5693356277c0685668219a79819707d099d9f
Stats:     382 lines in 14 files changed: 330 ins; 5 del; 47 mod

Merge

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

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

From duke at openjdk.org  Sat Jul  2 18:42:04 2022
From: duke at openjdk.org (kristylee88)
Date: Sat, 2 Jul 2022 18:42:04 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com>
References: <HSzW7Pju5o5Ot9TmoPp1Cedn5mglfvcaypeAhe3W14E=.cc43ec03-e146-45e4-8e37-aedffc9612a7@github.com>
 <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com>
Message-ID: <ERJ4_whPVB1lNQ1Y2QLJ2-5L-NMqiIFb9qdPhtekG5Y=.16799869-bd5c-4196-adf4-eff520095f9a@github.com>

On Sat, 2 Jul 2022 18:13:28 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Forwardport JDK 19 -> JDK 20
>
> Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits:
> 
>  - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
>  - 8289603: Code change for JDK-8170762 breaks all build
>    
>    Reviewed-by: weijun
>  - 8170762: Document that ISO10126Padding pads with random bytes
>    
>    Reviewed-by: weijun
>  - 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB
>    
>    Reviewed-by: alanb
>  - 8289257: Some custom loader tests failed due to symbol refcount not decremented
>    
>    Reviewed-by: iklam, coleenp
>  - 8289534: Change 'uncomplicated' hotspot runtime options
>    
>    Reviewed-by: coleenp, dholmes
>  - 8289512: Fix GCC 12 warnings for adlc output_c.cpp
>    
>    Reviewed-by: kvn, lucy
>  - 8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2 with -XX:+TracePhaseCCP
>    
>    Reviewed-by: kvn, thartmann, chagedorn, dlong
>  - 8288444: Remove the workaround for frame.pack() in ModalDialogTest
>    
>    Reviewed-by: azvegint
>  - 8289434: x86_64: Improve comment on gen_continuation_enter()
>    
>    Reviewed-by: kvn
>  - ... and 189 more: https://git.openjdk.org/jdk/compare/f5cdabad...20b15114

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

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

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

From sspitsyn at openjdk.org  Sat Jul  2 19:39:20 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 19:39:20 GMT
Subject: [jdk19] RFR: 8289619: JVMTI SelfSuspendDisablerTest.java failed with
 RuntimeException: Test FAILED: Unexpected thread state
Message-ID: <hlzpzJhAg4rhU15GLi7D8eKiHkT_mL9Vp0d_g02lK3s=.1b5093f1-29c9-4184-97bb-3959e44fcd04@github.com>

This regression was recently introduced with my update of this test.
One of the newly added checks is not stable/correct:


 71     public static void main(String argv[]) throws Exception {
 72         Thread t1 = Thread.ofPlatform().factory().newThread(() -> {
 73             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
 74             selfSuspend();
 75         });
 76         Thread t2 = Thread.ofVirtual().factory().newThread(() -> {
 77             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
 78             while(!isSuspended(t1)) {
 79               Thread.yield();
 80             }
 81             Thread.yield(); // provoke unmount
 82 
 83             testJvmtiThreadState(t1, SUSPENDED);
 84 
 85             resume(t1);
 86 
 87             testJvmtiThreadState(t1, RUNNABLE);  <== This line caused the test to fail!!
 88 
 89             suspendAllVirtualThreads();
 90         });

The line 87 needs to be removed.
There is a race here as the target platform thread can be already terminated.
However, the check is expecting the target thread to be in runnable state.

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

Commit messages:
 - 8289619: JVMTI SelfSuspendDisablerTest.java failed with RuntimeException: Test FAILED: Unexpected thread state

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

PR: https://git.openjdk.org/jdk19/pull/105

From alanb at openjdk.org  Sat Jul  2 19:39:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 2 Jul 2022 19:39:20 GMT
Subject: [jdk19] RFR: 8289619: JVMTI SelfSuspendDisablerTest.java failed
 with RuntimeException: Test FAILED: Unexpected thread state
In-Reply-To: <hlzpzJhAg4rhU15GLi7D8eKiHkT_mL9Vp0d_g02lK3s=.1b5093f1-29c9-4184-97bb-3959e44fcd04@github.com>
References: <hlzpzJhAg4rhU15GLi7D8eKiHkT_mL9Vp0d_g02lK3s=.1b5093f1-29c9-4184-97bb-3959e44fcd04@github.com>
Message-ID: <CSzFf06eRNskxQyiFx4SsI4Yje7-xExjA44Un_pVxk0=.f25ee7d2-d17d-4f13-beb6-c099369a000b@github.com>

On Sat, 2 Jul 2022 19:16:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This regression was recently introduced with my update of this test.
> One of the newly added checks is not stable/correct:
> 
> 
>  71     public static void main(String argv[]) throws Exception {
>  72         Thread t1 = Thread.ofPlatform().factory().newThread(() -> {
>  73             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
>  74             selfSuspend();
>  75         });
>  76         Thread t2 = Thread.ofVirtual().factory().newThread(() -> {
>  77             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
>  78             while(!isSuspended(t1)) {
>  79               Thread.yield();
>  80             }
>  81             Thread.yield(); // provoke unmount
>  82 
>  83             testJvmtiThreadState(t1, SUSPENDED);
>  84 
>  85             resume(t1);
>  86 
>  87             testJvmtiThreadState(t1, RUNNABLE);  <== This line caused the test to fail!!
>  88 
>  89             suspendAllVirtualThreads();
>  90         });
> 
> The line 87 needs to be removed.
> There is a race here as the target platform thread can be already terminated.
> However, the check is expecting the target thread to be in runnable state.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/105

From cjplummer at openjdk.org  Sat Jul  2 20:40:39 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 2 Jul 2022 20:40:39 GMT
Subject: [jdk19] RFR: 8289619: JVMTI SelfSuspendDisablerTest.java failed
 with RuntimeException: Test FAILED: Unexpected thread state
In-Reply-To: <hlzpzJhAg4rhU15GLi7D8eKiHkT_mL9Vp0d_g02lK3s=.1b5093f1-29c9-4184-97bb-3959e44fcd04@github.com>
References: <hlzpzJhAg4rhU15GLi7D8eKiHkT_mL9Vp0d_g02lK3s=.1b5093f1-29c9-4184-97bb-3959e44fcd04@github.com>
Message-ID: <08hjUmcdUq0vri3skIZUY9e9FXnp4MLGQ2wvbJTPa9I=.5ef77b27-5460-41d0-84c8-b95aa9ba391d@github.com>

On Sat, 2 Jul 2022 19:16:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This regression was recently introduced with my update of this test.
> One of the newly added checks is not stable/correct:
> 
> 
>  71     public static void main(String argv[]) throws Exception {
>  72         Thread t1 = Thread.ofPlatform().factory().newThread(() -> {
>  73             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
>  74             selfSuspend();
>  75         });
>  76         Thread t2 = Thread.ofVirtual().factory().newThread(() -> {
>  77             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
>  78             while(!isSuspended(t1)) {
>  79               Thread.yield();
>  80             }
>  81             Thread.yield(); // provoke unmount
>  82 
>  83             testJvmtiThreadState(t1, SUSPENDED);
>  84 
>  85             resume(t1);
>  86 
>  87             testJvmtiThreadState(t1, RUNNABLE);  <== This line caused the test to fail!!
>  88 
>  89             suspendAllVirtualThreads();
>  90         });
> 
> The line 87 needs to be removed.
> There is a race here as the target platform thread can be already terminated.
> However, the check is expecting the target thread to be in runnable state.

Approved and trivial, so feel free to push it now.

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

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/105

From sspitsyn at openjdk.org  Sat Jul  2 20:46:40 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 20:46:40 GMT
Subject: [jdk19] RFR: 8289619: JVMTI SelfSuspendDisablerTest.java failed
 with RuntimeException: Test FAILED: Unexpected thread state
In-Reply-To: <hlzpzJhAg4rhU15GLi7D8eKiHkT_mL9Vp0d_g02lK3s=.1b5093f1-29c9-4184-97bb-3959e44fcd04@github.com>
References: <hlzpzJhAg4rhU15GLi7D8eKiHkT_mL9Vp0d_g02lK3s=.1b5093f1-29c9-4184-97bb-3959e44fcd04@github.com>
Message-ID: <DDJASgDP2xmcWLsZJSLcjM_bdYm2Vw8_TvbTdhGdmio=.0f53680d-b8a0-416c-bed9-3dbce0158672@github.com>

On Sat, 2 Jul 2022 19:16:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This regression was recently introduced with my update of this test.
> One of the newly added checks is not stable/correct:
> 
> 
>  71     public static void main(String argv[]) throws Exception {
>  72         Thread t1 = Thread.ofPlatform().factory().newThread(() -> {
>  73             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
>  74             selfSuspend();
>  75         });
>  76         Thread t2 = Thread.ofVirtual().factory().newThread(() -> {
>  77             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
>  78             while(!isSuspended(t1)) {
>  79               Thread.yield();
>  80             }
>  81             Thread.yield(); // provoke unmount
>  82 
>  83             testJvmtiThreadState(t1, SUSPENDED);
>  84 
>  85             resume(t1);
>  86 
>  87             testJvmtiThreadState(t1, RUNNABLE);  <== This line caused the test to fail!!
>  88 
>  89             suspendAllVirtualThreads();
>  90         });
> 
> The line 87 needs to be removed.
> There is a race here as the target platform thread can be already terminated.
> However, the check is expecting the target thread to be in runnable state.

Thanks for review, Alan and Chris!

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

PR: https://git.openjdk.org/jdk19/pull/105

From sspitsyn at openjdk.org  Sat Jul  2 20:46:41 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Jul 2022 20:46:41 GMT
Subject: [jdk19] Integrated: 8289619: JVMTI SelfSuspendDisablerTest.java failed
 with RuntimeException: Test FAILED: Unexpected thread state
In-Reply-To: <hlzpzJhAg4rhU15GLi7D8eKiHkT_mL9Vp0d_g02lK3s=.1b5093f1-29c9-4184-97bb-3959e44fcd04@github.com>
References: <hlzpzJhAg4rhU15GLi7D8eKiHkT_mL9Vp0d_g02lK3s=.1b5093f1-29c9-4184-97bb-3959e44fcd04@github.com>
Message-ID: <n05cc6Fd_-9c-p-_6B_tkueggFuHq602_QR0cYYFcs4=.e94d6fe4-2c85-47cd-a710-5d8849f5c7db@github.com>

On Sat, 2 Jul 2022 19:16:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This regression was recently introduced with my update of this test.
> One of the newly added checks is not stable/correct:
> 
> 
>  71     public static void main(String argv[]) throws Exception {
>  72         Thread t1 = Thread.ofPlatform().factory().newThread(() -> {
>  73             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
>  74             selfSuspend();
>  75         });
>  76         Thread t2 = Thread.ofVirtual().factory().newThread(() -> {
>  77             testJvmtiThreadState(Thread.currentThread(), RUNNABLE);
>  78             while(!isSuspended(t1)) {
>  79               Thread.yield();
>  80             }
>  81             Thread.yield(); // provoke unmount
>  82 
>  83             testJvmtiThreadState(t1, SUSPENDED);
>  84 
>  85             resume(t1);
>  86 
>  87             testJvmtiThreadState(t1, RUNNABLE);  <== This line caused the test to fail!!
>  88 
>  89             suspendAllVirtualThreads();
>  90         });
> 
> The line 87 needs to be removed.
> There is a race here as the target platform thread can be already terminated.
> However, the check is expecting the target thread to be in runnable state.

This pull request has now been integrated.

Changeset: c4dcce4b
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/c4dcce4bca8808f8f733128f2e2b1dd48a28a322
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8289619: JVMTI SelfSuspendDisablerTest.java failed with RuntimeException: Test FAILED: Unexpected thread state

Reviewed-by: alanb, cjplummer

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

PR: https://git.openjdk.org/jdk19/pull/105

From cjplummer at openjdk.org  Sat Jul  2 21:19:55 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 2 Jul 2022 21:19:55 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v10]
In-Reply-To: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
Message-ID: <gms7aEq9OYg7QzMZg_f_lEhNVR0t8ZusHViZt0ZjQtM=.3a0004be-9925-4e2b-826e-1fdcf372ad82@github.com>

> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
> 
> 
>         if (list != &otherThreads) {
>             setThreadLocalStorage(node->thread, (void*)node);
>         }

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

 - Merge branch 'master' of https://github.com/openjdk/jdk19 into 8287847_nb
   merge
 - Rename thread to targetThread. Verify targetThread state when the thread dies and when the breakpoint after the join() is reached.
 - Merge branch 'master' of https://github.com/openjdk/jdk19 into 8287847_nb
   merge
 - provide a slightly more descriptive @summary
 - Add new SuspendAfterDeath test to jdk_jdi_sanity test group.
 - Always run test both in virtual and platform thread modes
 - No need to initialzie boolean to false.
 - Get rid of need to cast toArray() result to a String[]
 - fix indentation
 - fixed jcheck errors
 - ... and 1 more: https://git.openjdk.org/jdk19/compare/f74f7261...1d087b2f

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/88/files
  - new: https://git.openjdk.org/jdk19/pull/88/files/1ff59060..1d087b2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=88&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=88&range=08-09

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

PR: https://git.openjdk.org/jdk19/pull/88

From duke at openjdk.org  Sun Jul  3 00:59:46 2022
From: duke at openjdk.org (kristylee88)
Date: Sun, 3 Jul 2022 00:59:46 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v4]
In-Reply-To: <nEYbWc6VGfEWGjwWUlXM2kyHHuvZhqKTibRpcncuU3M=.1889c4f0-eed9-4dcf-81eb-25d2f5fc8fd0@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <nEYbWc6VGfEWGjwWUlXM2kyHHuvZhqKTibRpcncuU3M=.1889c4f0-eed9-4dcf-81eb-25d2f5fc8fd0@github.com>
Message-ID: <of343gVLCsk8FtdsT3zv3ilqPTHlOfs_2FKX2zciMvc=.018d10a7-3449-46e8-a4b3-c7d52895b0ee@github.com>

On Sat, 2 Jul 2022 04:26:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There are only two implementations of these classes (one for windows, and one for posix):
>> 
>> - PlatformEvent
>> - PlatformParker
>> - PlatformMutex
>> - PlatformMonitor
>> - ThreadCrashProtection
>> 
>> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
>> 
>> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
>> 
>> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - removed unrelated newline change
>  - Merge branch 'master' into 8289230-move-Platform-classes-out-of-os-xxx-hpp
>  - @coleenp comments
>  - fixed comments
>  - fixed windows
>  - Moved PlatformMutex/PlatformMonitor
>  - move-PlatformParker-out-of-os-xxx-hpp
>  - Moved ThreadCrashProtection

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

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

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

From duke at openjdk.org  Sun Jul  3 01:28:44 2022
From: duke at openjdk.org (kristylee88)
Date: Sun, 3 Jul 2022 01:28:44 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v4]
In-Reply-To: <nEYbWc6VGfEWGjwWUlXM2kyHHuvZhqKTibRpcncuU3M=.1889c4f0-eed9-4dcf-81eb-25d2f5fc8fd0@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <nEYbWc6VGfEWGjwWUlXM2kyHHuvZhqKTibRpcncuU3M=.1889c4f0-eed9-4dcf-81eb-25d2f5fc8fd0@github.com>
Message-ID: <0RDnszyg_IHLT64-8cM28uYDlMl1iJiUrnvUAzYtRu0=.2616eaaf-3baf-4c31-9b95-a181598046ec@github.com>

On Sat, 2 Jul 2022 04:26:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There are only two implementations of these classes (one for windows, and one for posix):
>> 
>> - PlatformEvent
>> - PlatformParker
>> - PlatformMutex
>> - PlatformMonitor
>> - ThreadCrashProtection
>> 
>> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
>> 
>> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
>> 
>> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - removed unrelated newline change
>  - Merge branch 'master' into 8289230-move-Platform-classes-out-of-os-xxx-hpp
>  - @coleenp comments
>  - fixed comments
>  - fixed windows
>  - Moved PlatformMutex/PlatformMonitor
>  - move-PlatformParker-out-of-os-xxx-hpp
>  - Moved ThreadCrashProtection

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

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

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

From sspitsyn at openjdk.org  Sun Jul  3 05:52:31 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 3 Jul 2022 05:52:31 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v10]
In-Reply-To: <gms7aEq9OYg7QzMZg_f_lEhNVR0t8ZusHViZt0ZjQtM=.3a0004be-9925-4e2b-826e-1fdcf372ad82@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <gms7aEq9OYg7QzMZg_f_lEhNVR0t8ZusHViZt0ZjQtM=.3a0004be-9925-4e2b-826e-1fdcf372ad82@github.com>
Message-ID: <lM4MSMPwkGb3ixKoG3r5W4W0GUrHuthxoqQFDsGYKB8=.27e5cb9b-49bb-443a-966e-faedf8174b77@github.com>

On Sat, 2 Jul 2022 21:19:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
>> 
>> 
>>         if (list != &otherThreads) {
>>             setThreadLocalStorage(node->thread, (void*)node);
>>         }
>
> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk19 into 8287847_nb
>    merge
>  - Rename thread to targetThread. Verify targetThread state when the thread dies and when the breakpoint after the join() is reached.
>  - Merge branch 'master' of https://github.com/openjdk/jdk19 into 8287847_nb
>    merge
>  - provide a slightly more descriptive @summary
>  - Add new SuspendAfterDeath test to jdk_jdi_sanity test group.
>  - Always run test both in virtual and platform thread modes
>  - No need to initialzie boolean to false.
>  - Get rid of need to cast toArray() result to a String[]
>  - fix indentation
>  - fixed jcheck errors
>  - ... and 1 more: https://git.openjdk.org/jdk19/compare/42a7f5bb...1d087b2f

In fact, webrev v9 does not have any changes.
Is it a merge with JDK 19?

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/88

From cjplummer at openjdk.org  Sun Jul  3 08:00:39 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sun, 3 Jul 2022 08:00:39 GMT
Subject: [jdk19] RFR: 8287847: Fatal Error when suspending virtual thread
 after it has terminated [v10]
In-Reply-To: <lM4MSMPwkGb3ixKoG3r5W4W0GUrHuthxoqQFDsGYKB8=.27e5cb9b-49bb-443a-966e-faedf8174b77@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
 <gms7aEq9OYg7QzMZg_f_lEhNVR0t8ZusHViZt0ZjQtM=.3a0004be-9925-4e2b-826e-1fdcf372ad82@github.com>
 <lM4MSMPwkGb3ixKoG3r5W4W0GUrHuthxoqQFDsGYKB8=.27e5cb9b-49bb-443a-966e-faedf8174b77@github.com>
Message-ID: <8JDAa7rvI82NnayQKCYECDNaNFCzLw_kGaXiAe6Gj3I=.07fbb732-e012-4689-a066-8bcbf87e71ae@github.com>

On Sun, 3 Jul 2022 05:48:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> In fact, webrev v9 does not have any changes.
> Is it a merge with JDK 19?

Yes, just a merge with the JDK 19 master branch.

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

PR: https://git.openjdk.org/jdk19/pull/88

From duke at openjdk.org  Tue Jul  5 04:30:27 2022
From: duke at openjdk.org (xpbob)
Date: Tue, 5 Jul 2022 04:30:27 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans
Message-ID: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>

Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
Results the following
![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

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

Commit messages:
 - 8289711: Add container configuration data to mbeans

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

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

From sspitsyn at openjdk.org  Tue Jul  5 17:24:28 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Jul 2022 17:24:28 GMT
Subject: RFR: 8289436: Make the redefine timer statistics more accurate
In-Reply-To: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>
References: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>
Message-ID: <wTq-SAplUBUoSQSQuxJ0DHPzqQO0S2uVv4W-F-5qk5g=.c2a69c96-cb96-4864-beba-8db747b3e8ec@github.com>

On Wed, 29 Jun 2022 08:30:12 GMT, Tongbao Zhang <duke at openjdk.org> wrote:

> Make the redefine timer statistics more accurate
> 
> After some significant performance improvements of the class redefinition, like: 
> https://bugs.openjdk.org/browse/JDK-8139551
> https://bugs.openjdk.org/browse/JDK-8078725
> 
> Some time-consumption operation were moved out the "redefine_single_class"
> So the time added by  phase 1 and phase 2 cannot be accurately represented to the time of "vmop_doit"

This looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From cjplummer at openjdk.org  Tue Jul  5 17:50:46 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 5 Jul 2022 17:50:46 GMT
Subject: [jdk19] Integrated: 8287847: Fatal Error when suspending virtual
 thread after it has terminated
In-Reply-To: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
References: <3ulcphUBpJx4Pmpjzm5Cr6GQKB7JPzI3a06XhcjW-wI=.8b3be4f9-5f60-4f48-ad61-066127bb803c@github.com>
Message-ID: <K2kH7j-_Ji1rC-aeA0S617kdEVTarxE6oFPkxn5DVw4=.dc11b7d7-8c72-4b5b-beb0-8d48d7c8ac6f@github.com>

On Tue, 28 Jun 2022 22:33:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This fixes a bug in the debug agent when there is a request to suspend a virtual thread that has already terminated. The issue was that unless the debug agent was currently under a "suspend all", it would not properly put the virtual thread on the `otherThreads` list, and instead added it to `runningVThreads`. This meant at the end of `insertThread()` the following code tried to do a JVMTI `SetThreadLocalStorage`, which can't be done on a terminated thread.
> 
> 
>         if (list != &otherThreads) {
>             setThreadLocalStorage(node->thread, (void*)node);
>         }

This pull request has now been integrated.

Changeset: 29ea6429
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/29ea6429d2f906a61331aab1aef172d0d854fb6f
Stats:     183 lines in 4 files changed: 180 ins; 1 del; 2 mod

8287847: Fatal Error when suspending virtual thread after it has terminated

Reviewed-by: alanb, sspitsyn

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

PR: https://git.openjdk.org/jdk19/pull/88

From cjplummer at openjdk.org  Tue Jul  5 17:45:24 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 5 Jul 2022 17:45:24 GMT
Subject: RFR: 8289436: Make the redefine timer statistics more accurate
In-Reply-To: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>
References: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>
Message-ID: <9vOGMA6gbtLaCeipmJgXrHjFWipHyzr61X1tahFlSOo=.0a1367bc-eeca-4549-9864-fb98576bbce6@github.com>

On Wed, 29 Jun 2022 08:30:12 GMT, Tongbao Zhang <duke at openjdk.org> wrote:

> Make the redefine timer statistics more accurate
> 
> After some significant performance improvements of the class redefinition, like: 
> https://bugs.openjdk.org/browse/JDK-8139551
> https://bugs.openjdk.org/browse/JDK-8078725
> 
> Some time-consumption operation were moved out the "redefine_single_class"
> So the time added by  phase 1 and phase 2 cannot be accurately represented to the time of "vmop_doit"

Marked as reviewed by cjplummer (Reviewer).

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

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

From djelinski at openjdk.org  Tue Jul  5 21:06:58 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 5 Jul 2022 21:06:58 GMT
Subject: RFR: 8289768: Clean up unused code
Message-ID: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>

This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 

The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.

I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.

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

Commit messages:
 - Remove unused variables (windows)
 - Remove unused variables (macos)
 - Remove unused variables (linux)

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

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

From iklam at openjdk.org  Wed Jul  6 01:07:04 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 6 Jul 2022 01:07:04 GMT
Subject: RFR: 8289780: Remove Forte::register_stub
Message-ID: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>

I removed `Remove Forte::register_stub` since it's used only by the Solaris Forte(TM) Performance Tools collector, which is no longer supported by the JDK.

I also fixed a couple of places where the stub name is computed unnecessarily.

Also renamed some `#ifndef IA64` around the code that I touched.

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

Commit messages:
 - 8289780: Remove Forte::register_stub

Changes: https://git.openjdk.org/jdk/pull/9386/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9386&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289780
  Stats: 112 lines in 8 files changed: 6 ins; 102 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9386.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9386/head:pull/9386

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

From lmesnik at openjdk.org  Wed Jul  6 00:02:41 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 6 Jul 2022 00:02:41 GMT
Subject: RFR: 8289436: Make the redefine timer statistics more accurate
In-Reply-To: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>
References: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>
Message-ID: <2GPjX7-TT1PXfj6eTRxgX-Pt6RZHvKv8z5HOYaYY2NQ=.8b789522-69ef-4291-8ef1-91381802ff84@github.com>

On Wed, 29 Jun 2022 08:30:12 GMT, Tongbao Zhang <duke at openjdk.org> wrote:

> Make the redefine timer statistics more accurate
> 
> After some significant performance improvements of the class redefinition, like: 
> https://bugs.openjdk.org/browse/JDK-8139551
> https://bugs.openjdk.org/browse/JDK-8078725
> 
> Some time-consumption operation were moved out the "redefine_single_class"
> So the time added by  phase 1 and phase 2 cannot be accurately represented to the time of "vmop_doit"

Marked as reviewed by lmesnik (Reviewer).

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

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

From djelinski at openjdk.org  Wed Jul  6 05:32:29 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Jul 2022 05:32:29 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
Message-ID: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>

> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
> 
> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
> 
> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.

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

 - Merge remote-tracking branch 'origin' into unused-variables
 - Remove unused variables (windows)
 - Remove unused variables (macos)
 - Remove unused variables (linux)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9383/files
  - new: https://git.openjdk.org/jdk/pull/9383/files/915680c0..b4cd5374

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

  Stats: 491 lines in 22 files changed: 458 ins; 5 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/9383.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383

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

From dfuchs at openjdk.org  Wed Jul  6 09:39:28 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 6 Jul 2022 09:39:28 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <KaJHebp-ApC21FZYke6AekCJZYJR09p-0dNQfAkLKkU=.a187d507-ab37-4086-86bc-e1f03e52a067@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

Changes to libnet look good. Please wait until you have obtained approvals from maintainers of the other areas to integrate,

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

Marked as reviewed by dfuchs (Reviewer).

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

From djelinski at openjdk.org  Wed Jul  6 08:57:23 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Jul 2022 08:57:23 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <cSxCo06RRmSKNsQWRjAe2_lf5fpbm9R_c-crab--ac8=.3cc175af-0bf3-43b2-a345-a16314862e88@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

test failure is unrelated, caused by [JDK-8289619](https://bugs.openjdk.org/browse/JDK-8289619)

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

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

From lancea at openjdk.org  Wed Jul  6 15:35:39 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 6 Jul 2022 15:35:39 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <LoVNDWlc51SJQBDzXcw8BTrvooN3L3-unDnIRLCHgek=.53cef1f1-2273-4da5-9d64-b3346f19814e@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

zlib looks fine given it is openjdk and not an upstream needed change

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

Marked as reviewed by lancea (Reviewer).

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

From alanb at openjdk.org  Wed Jul  6 06:02:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Jul 2022 06:02:39 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
Message-ID: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>

On Wed, 6 Jul 2022 03:52:30 GMT, xpbob <duke at openjdk.org> wrote:

>> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
>> Results the following
>> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update header

It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API?  I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting locked in. A possible standard point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management).

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

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

From duke at openjdk.org  Wed Jul  6 03:52:30 2022
From: duke at openjdk.org (xpbob)
Date: Wed, 6 Jul 2022 03:52:30 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

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

  update header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9372/files
  - new: https://git.openjdk.org/jdk/pull/9372/files/0f262911..8f63af82

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

  Stats: 52 lines in 4 files changed: 47 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9372.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372

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

From duke at openjdk.org  Wed Jul  6 07:34:50 2022
From: duke at openjdk.org (Tongbao Zhang)
Date: Wed, 6 Jul 2022 07:34:50 GMT
Subject: RFR: 8289436: Make the redefine timer statistics more accurate
In-Reply-To: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>
References: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>
Message-ID: <Tu3xlHrmNnFJVvk2SThAqRlCww3hRE5E9hbDsQv0-EU=.35445f78-7e2f-4553-a980-2bbd6c509e8e@github.com>

On Wed, 29 Jun 2022 08:30:12 GMT, Tongbao Zhang <duke at openjdk.org> wrote:

> Make the redefine timer statistics more accurate
> 
> After some significant performance improvements of the class redefinition, like: 
> https://bugs.openjdk.org/browse/JDK-8139551
> https://bugs.openjdk.org/browse/JDK-8078725
> 
> Some time-consumption operation were moved out the "redefine_single_class"
> So the time added by  phase 1 and phase 2 cannot be accurately represented to the time of "vmop_doit"

Thanks for the review

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

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

From duke at openjdk.org  Wed Jul  6 03:52:30 2022
From: duke at openjdk.org (xpbob)
Date: Wed, 6 Jul 2022 03:52:30 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <DkIFdjlyG7OMhMIMYI4LRtDTa_rco_7Xr2TFvtsdjv4=.0f98f102-15e9-4aba-90a5-d11169dbb973@github.com>

On Tue, 5 Jul 2022 04:21:55 GMT, xpbob <duke at openjdk.org> wrote:

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

@DamonFool 
Thanks for review.
The code has been updated

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

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

From bpb at openjdk.org  Wed Jul  6 16:36:29 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Jul 2022 16:36:29 GMT
Subject: [jdk19] RFR: 8289840: ProblemList
 vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
 when run with vthread wrapper
In-Reply-To: <UZpGiG0W8ge5gq2hPZYP9Xo2nyOP3j2cGce6Jln67RU=.d8fdee88-ae78-4ae8-9dba-68a1228c5fb0@github.com>
References: <UZpGiG0W8ge5gq2hPZYP9Xo2nyOP3j2cGce6Jln67RU=.d8fdee88-ae78-4ae8-9dba-68a1228c5fb0@github.com>
Message-ID: <__OcqZltNIzAJ_Z9P1rTvJNu6QasrD69h_Oaqb-DAik=.20a22f7e-c5ad-4b1b-a7f6-eeb23fb80362@github.com>

On Wed, 6 Jul 2022 16:23:59 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList
> vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
> when run with vthread wrapper.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/114

From iklam at openjdk.org  Wed Jul  6 17:50:54 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 6 Jul 2022 17:50:54 GMT
Subject: RFR: 8289780: Remove Forte::register_stub [v2]
In-Reply-To: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
Message-ID: <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>

> I removed `Remove Forte::register_stub` since it's used only by the Solaris Forte(TM) Performance Tools collector, which is no longer supported by the JDK.
> 
> I also fixed a couple of places where the stub name is computed unnecessarily.
> 
> Also renamed some `#ifndef IA64` around the code that I touched.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Do not remove Forte::register_stub as it is used on Linux as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9386/files
  - new: https://git.openjdk.org/jdk/pull/9386/files/a1523c9d..609350f1

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

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

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

From dcubed at openjdk.org  Wed Jul  6 16:36:29 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 6 Jul 2022 16:36:29 GMT
Subject: [jdk19] RFR: 8289840: ProblemList
 vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
 when run with vthread wrapper
In-Reply-To: <__OcqZltNIzAJ_Z9P1rTvJNu6QasrD69h_Oaqb-DAik=.20a22f7e-c5ad-4b1b-a7f6-eeb23fb80362@github.com>
References: <UZpGiG0W8ge5gq2hPZYP9Xo2nyOP3j2cGce6Jln67RU=.d8fdee88-ae78-4ae8-9dba-68a1228c5fb0@github.com>
 <__OcqZltNIzAJ_Z9P1rTvJNu6QasrD69h_Oaqb-DAik=.20a22f7e-c5ad-4b1b-a7f6-eeb23fb80362@github.com>
Message-ID: <bc-K65aYtSUFSVGHTQljBL-79WIEksRNXNWPU7IelXw=.9d8788b4-000f-4daf-9a35-8b5a443cdd69@github.com>

On Wed, 6 Jul 2022 16:32:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to ProblemList
>> vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
>> when run with vthread wrapper.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the fast review!

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

PR: https://git.openjdk.org/jdk19/pull/114

From iklam at openjdk.org  Wed Jul  6 17:52:04 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 6 Jul 2022 17:52:04 GMT
Subject: RFR: 8289780: Remove Forte::register_stub
In-Reply-To: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
Message-ID: <oabpSQ3UvHjg1rtuK0SETIUcdmr9mAz7KequwtB2Bw4=.8768c56e-6adc-46be-a534-959799ffb889@github.com>

On Wed, 6 Jul 2022 00:38:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I removed `Remove Forte::register_stub` since it's used only by the Solaris Forte(TM) Performance Tools collector, which is no longer supported by the JDK.
> 
> I also fixed a couple of places where the stub name is computed unnecessarily.
> 
> Also renamed some `#ifndef IA64` around the code that I touched.

It turns out that `collector_func_load` is used by OracleDeveloperStudio on Linux as well, so I can't remove the call to collector_func_load. I think this (weak) function will be non-null when OracleDeveloperStudio loads the JVM:


$ nm OracleDeveloperStudio12.6-linux-x86-bin/developerstudio12.6/lib/analyzer/amd64/libcollector.so \
     | grep collector_func_load
000000000002efd0 T __collector_func_load
000000000002efd0 W collector_func_load


So slight change of plan. I am adding a check to avoid computing the `blob_id`, etc, when Forte::is_enabled()` is false, which will be the case in most cases.

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

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

From dcubed at openjdk.org  Wed Jul  6 16:54:45 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 6 Jul 2022 16:54:45 GMT
Subject: [jdk19] Integrated: 8289840: ProblemList
 vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
 when run with vthread wrapper
In-Reply-To: <UZpGiG0W8ge5gq2hPZYP9Xo2nyOP3j2cGce6Jln67RU=.d8fdee88-ae78-4ae8-9dba-68a1228c5fb0@github.com>
References: <UZpGiG0W8ge5gq2hPZYP9Xo2nyOP3j2cGce6Jln67RU=.d8fdee88-ae78-4ae8-9dba-68a1228c5fb0@github.com>
Message-ID: <tuDof9T-JzNT3yvKIzD7n3diiADpCO84KK6SGaFdTt0=.008a7f36-c3f0-417b-85c7-b4e8ab05b7d9@github.com>

On Wed, 6 Jul 2022 16:23:59 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList
> vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
> when run with vthread wrapper.

This pull request has now been integrated.

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

8289840: ProblemList vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java when run with vthread wrapper

Reviewed-by: bpb

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

PR: https://git.openjdk.org/jdk19/pull/114

From weijun at openjdk.org  Wed Jul  6 16:44:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 6 Jul 2022 16:44:53 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <ZMpyNEU8PTGXpzZCkL5qkbpRdthjX3UpghdXRPILoeI=.9fd9bfdb-5f33-4537-8155-d1d3624f2236@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

Changes in security (`java.security.jgss`, `jdk.crypto.cryptoki`, `jdk.crypto.mscapi`) look fine to me.

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

Marked as reviewed by weijun (Reviewer).

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

From coleenp at openjdk.org  Wed Jul  6 17:04:40 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Jul 2022 17:04:40 GMT
Subject: RFR: 8289780: Remove Forte::register_stub
In-Reply-To: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
Message-ID: <7E0l2wIjQUx_Xd45WIODZS-Gt-lSlhmeqYwuK3rs4aE=.9fb4a2b7-d23b-4b5a-ab01-f248f520cf1d@github.com>

On Wed, 6 Jul 2022 00:38:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I removed `Remove Forte::register_stub` since it's used only by the Solaris Forte(TM) Performance Tools collector, which is no longer supported by the JDK.
> 
> I also fixed a couple of places where the stub name is computed unnecessarily.
> 
> Also renamed some `#ifndef IA64` around the code that I touched.

This looks good.  Leaving the name forte.cpp seems odd, even though some still refer to it that way.  My vote would have been for asyncGetCallTrace.cpp

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

Marked as reviewed by coleenp (Reviewer).

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

From jiefu at openjdk.org  Wed Jul  6 03:17:28 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 6 Jul 2022 03:17:28 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <yzmglxFMi64wcbFj5Vq04CrN42s2pgqxPv9jlt4VY1E=.56b8889b-2f7d-44c0-b5e5-0a434d98e540@github.com>

On Tue, 5 Jul 2022 04:21:55 GMT, xpbob <duke at openjdk.org> wrote:

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

src/java.base/share/classes/module-info.java line 233:

> 231:     exports jdk.internal.platform to
> 232:         jdk.management,
> 233:         java.management,

Maybe, we'd better put `jdk.management,` before `jdk.management,`.

src/java.management/share/classes/java/lang/management/ContainerMXBean.java line 1:

> 1: package java.lang.management;

Shall we add a copyright header for this new file?

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

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

From jwilhelm at openjdk.org  Wed Jul  6 13:11:34 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 6 Jul 2022 13:11:34 GMT
Subject: RFR: Merge jdk19
Message-ID: <wFiz24FTdK89_Yl1CYVEsZ6Ee0QXnm0jW48qV2wsc7Q=.329cdbf6-0442-455e-a6df-1e79e4ae6a9f@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc
 - 8289439: Clarify relationship between ThreadStart/ThreadEnd and can_support_virtual_threads capability
 - 8288128: S390X: Fix crashes after JDK-8284161 (Virtual Threads)
 - 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj()
 - 8287847: Fatal Error when suspending virtual thread after it has terminated
 - 8067757: Incorrect HTML generation for copied javadoc with multiple @throws tags
 - 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl
 - 8287851: C2 crash: assert(t->meet(t0) == t) failed: Not monotonic
 - 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
 - ... and 2 more: https://git.openjdk.org/jdk/compare/83a5d599...fbbc3300

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9397&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9397&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9397/files
  Stats: 888 lines in 24 files changed: 705 ins; 64 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/9397.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9397/head:pull/9397

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

From kevinw at openjdk.org  Thu Jul  7 08:45:22 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Jul 2022 08:45:22 GMT
Subject: Integrated: 8198668:
 MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001/TestDescription.java
 still failing
In-Reply-To: <P83M_JZIyCw6sqbI6H_RMjInL0iT0gJRrF6IOKphMoY=.9e25d10e-d495-4d3e-83c3-ff6925d9e4c5@github.com>
References: <P83M_JZIyCw6sqbI6H_RMjInL0iT0gJRrF6IOKphMoY=.9e25d10e-d495-4d3e-83c3-ff6925d9e4c5@github.com>
Message-ID: <jzts2e7jUK3VHDOdFFNrIwlVZ38leDg1QWvwC_BqEh4=.7bdd3148-c7d8-4e8b-a53a-be0ca05c9333@github.com>

On Tue, 28 Jun 2022 11:21:50 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test has been problemlisted for a long time due to intermittent failures.
> 
> This is a difficult test as it tries to monitor usage thresholds on Memory Pools which are outside its control.
> Not just Java heap pools, where the allocation it makes may or may not affect a particuclar pool, but non-heap pools such as CodeHeap and Metadata, where other activity in the VM can affect their usage and surprise the test.
> 
> The test iterates JMX memory pools where thresholds are supported, sets a threshold one byte higher than current usage, and makes an allocation.  This only makes sense on Java heap pools.  It is tempting to skip non-heap pools, but this test can still give a sanity test about threshold behaviour.  That is actually its main purpose, as the allocation is unlikely to affect the pool being tested.
> 
> With the changes here, I'm seeing the test and all its variations pass reliably, i.e. 50 iterations in each tested platform.
> 
> Skip testing a non-heap memory pool, e.g. CodeHeap, if it is hitting the threshold while we test, because that means it is changing outside our control.  Also re-test isExceeded on failure, as fetching the usage and isExceeded is a race.
> 
> Logging of more pool stats to better understand failures.

This pull request has now been integrated.

Changeset: d1249aa5
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1249aa5cbf3a3a3a24e85bcec30aecbc3e09bc0
Stats:     72 lines in 2 files changed: 33 ins; 11 del; 28 mod

8198668: MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001/TestDescription.java still failing

Reviewed-by: lmesnik, sspitsyn

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

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

From darcy at openjdk.org  Wed Jul  6 20:56:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Jul 2022 20:56:14 GMT
Subject: [jdk19] Integrated: 8289857: ProblemList
 jdk/jfr/event/runtime/TestActiveSettingEvent.java
In-Reply-To: <zVenXEKgxYCpMU40JNRrZojK8kzWtaKpOgBqgaEBiXI=.0e606a23-68ac-4e99-890b-f2deab9391f4@github.com>
References: <zVenXEKgxYCpMU40JNRrZojK8kzWtaKpOgBqgaEBiXI=.0e606a23-68ac-4e99-890b-f2deab9391f4@github.com>
Message-ID: <eRCNeSYA4oY6a--FJ1Qg9bdB3f_jSPWEHp5XLZ1LOS4=.8908be36-c399-4a67-8243-05d20c4ae654@github.com>

On Wed, 6 Jul 2022 20:45:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/117

From iklam at openjdk.org  Thu Jul  7 06:44:56 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 7 Jul 2022 06:44:56 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp dir
Message-ID: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>

Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).

This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)

Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.

I kept the use of `kill()` for stale file detection to be compatible with older JVMs.

I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.

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

Commit messages:
 - Merge branch 'master' into 8286030-avoid-jvm-crash-when-containers-share-tmp-dir
 - Cleaned up comments and avoid using the word "resource" to describe the shared mem file
 - fixed comments
 - Added test case
 - fix timing hole -- another JVM process can create file while I am trying to delete
 - working
 - temp-not-working

Changes: https://git.openjdk.org/jdk/pull/9406/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9406&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286030
  Stats: 286 lines in 3 files changed: 238 ins; 21 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/9406.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9406/head:pull/9406

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

From kevinw at openjdk.org  Thu Jul  7 08:29:46 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Jul 2022 08:29:46 GMT
Subject: RFR: 8198668:
 MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001/TestDescription.java
 still failing [v3]
In-Reply-To: <UOAKITAS6xD-PKyaU1EwFTKV6soe148-yJj0oDSOU_M=.5208b28f-676e-40e5-abe8-40afe999452d@github.com>
References: <P83M_JZIyCw6sqbI6H_RMjInL0iT0gJRrF6IOKphMoY=.9e25d10e-d495-4d3e-83c3-ff6925d9e4c5@github.com>
 <gsEbm70O5b6LfcMB6TM_P2a9BSEDjJCC7cRn3M-vgaI=.e164045b-2c6f-4238-a933-27cca7cbb212@github.com>
 <UOAKITAS6xD-PKyaU1EwFTKV6soe148-yJj0oDSOU_M=.5208b28f-676e-40e5-abe8-40afe999452d@github.com>
Message-ID: <dVSvrDlt-VlU4rcsEbfz6ce_YUmB4rstFTZd-IL_3Ms=.189f314b-02b4-48ff-8d42-cd535d58a16c@github.com>

On Wed, 6 Jul 2022 22:38:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> ...minor questions/comments...

Hi Serguei, yes updated those comments, thanks!

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

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

From kevinw at openjdk.org  Thu Jul  7 08:29:45 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 7 Jul 2022 08:29:45 GMT
Subject: RFR: 8198668:
 MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001/TestDescription.java
 still failing [v4]
In-Reply-To: <P83M_JZIyCw6sqbI6H_RMjInL0iT0gJRrF6IOKphMoY=.9e25d10e-d495-4d3e-83c3-ff6925d9e4c5@github.com>
References: <P83M_JZIyCw6sqbI6H_RMjInL0iT0gJRrF6IOKphMoY=.9e25d10e-d495-4d3e-83c3-ff6925d9e4c5@github.com>
Message-ID: <3Xm-URGAelfnguGHrHEgjdjHEJZCf6kCnU8fVsZBlbA=.152beeaf-78ee-4760-b9dd-6839e353d5b8@github.com>

> Test has been problemlisted for a long time due to intermittent failures.
> 
> This is a difficult test as it tries to monitor usage thresholds on Memory Pools which are outside its control.
> Not just Java heap pools, where the allocation it makes may or may not affect a particuclar pool, but non-heap pools such as CodeHeap and Metadata, where other activity in the VM can affect their usage and surprise the test.
> 
> The test iterates JMX memory pools where thresholds are supported, sets a threshold one byte higher than current usage, and makes an allocation.  This only makes sense on Java heap pools.  It is tempting to skip non-heap pools, but this test can still give a sanity test about threshold behaviour.  That is actually its main purpose, as the allocation is unlikely to affect the pool being tested.
> 
> With the changes here, I'm seeing the test and all its variations pass reliably, i.e. 50 iterations in each tested platform.
> 
> Skip testing a non-heap memory pool, e.g. CodeHeap, if it is hitting the threshold while we test, because that means it is changing outside our control.  Also re-test isExceeded on failure, as fetching the usage and isExceeded is a race.
> 
> Logging of more pool stats to better understand failures.

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

  Comment update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9309/files
  - new: https://git.openjdk.org/jdk/pull/9309/files/d2bf8b37..12e08d67

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

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

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

From coleenp at openjdk.org  Wed Jul  6 19:12:47 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Jul 2022 19:12:47 GMT
Subject: RFR: 8289780: Avoid formatting stub names when Forte is not
 enabled [v2]
In-Reply-To: <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
 <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
Message-ID: <QQHmKYvsk2XgQnX4L7kE8z4TE0gCZZALzL8vyQ5TFjc=.1019b684-75ba-4909-bad4-7a7c7df87356@github.com>

On Wed, 6 Jul 2022 17:50:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> `Forte::register_stub()` should be called only when the JVm is being instrumented by Forte (aka "Oracle Developer Studio")
>> 
>> https://www.oracle.com/tools/developerstudio/downloads/developer-studio-jsp.html
>> 
>> We currently always format the name of generated stubs and call `Forte::register_stub()`, which usually does nothing.
>> 
>> Example:
>> 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntime.cpp#L2686-L2697
>> 
>> To improve start-up, we should check if Forte is enabled before formatting the name.
>> 
>> I also renamed some `#ifndef IA64` around the code that I touched.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not remove Forte::register_stub as it is used on Linux as well

src/hotspot/share/prims/forte.hpp line 32:

> 30: class Forte : AllStatic {
> 31:  public:
> 32:    static bool is_enabled() NOT_JVMTI_RETURN_(false);

I don't think the rest of this forte code is disabled by JVMTI.

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

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

From duke at openjdk.org  Wed Jul  6 22:53:40 2022
From: duke at openjdk.org (Tongbao Zhang)
Date: Wed, 6 Jul 2022 22:53:40 GMT
Subject: Integrated: 8289436: Make the redefine timer statistics more accurate
In-Reply-To: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>
References: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>
Message-ID: <Y72HTtm2KjVVXt63I7dgD2cvPNOg0spiRHzY2OlqDCA=.b733e322-7c50-4fa6-b197-d729f937cec7@github.com>

On Wed, 29 Jun 2022 08:30:12 GMT, Tongbao Zhang <duke at openjdk.org> wrote:

> Make the redefine timer statistics more accurate
> 
> After some significant performance improvements of the class redefinition, like: 
> https://bugs.openjdk.org/browse/JDK-8139551
> https://bugs.openjdk.org/browse/JDK-8078725
> 
> Some time-consumption operation were moved out the "redefine_single_class"
> So the time added by  phase 1 and phase 2 cannot be accurately represented to the time of "vmop_doit"

This pull request has now been integrated.

Changeset: 403a9bc7
Author:    Tongbao Zhang <tobytbzhang at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/403a9bc79645018ee61b47bab67fe231577dd914
Stats:     10 lines in 2 files changed: 8 ins; 1 del; 1 mod

8289436: Make the redefine timer statistics more accurate

Reviewed-by: sspitsyn, cjplummer, lmesnik

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

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

From sspitsyn at openjdk.org  Wed Jul  6 22:40:52 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Jul 2022 22:40:52 GMT
Subject: RFR: 8198668:
 MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001/TestDescription.java
 still failing [v3]
In-Reply-To: <gsEbm70O5b6LfcMB6TM_P2a9BSEDjJCC7cRn3M-vgaI=.e164045b-2c6f-4238-a933-27cca7cbb212@github.com>
References: <P83M_JZIyCw6sqbI6H_RMjInL0iT0gJRrF6IOKphMoY=.9e25d10e-d495-4d3e-83c3-ff6925d9e4c5@github.com>
 <gsEbm70O5b6LfcMB6TM_P2a9BSEDjJCC7cRn3M-vgaI=.e164045b-2c6f-4238-a933-27cca7cbb212@github.com>
Message-ID: <UOAKITAS6xD-PKyaU1EwFTKV6soe148-yJj0oDSOU_M=.5208b28f-676e-40e5-abe8-40afe999452d@github.com>

On Thu, 30 Jun 2022 20:54:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Test has been problemlisted for a long time due to intermittent failures.
>> 
>> This is a difficult test as it tries to monitor usage thresholds on Memory Pools which are outside its control.
>> Not just Java heap pools, where the allocation it makes may or may not affect a particuclar pool, but non-heap pools such as CodeHeap and Metadata, where other activity in the VM can affect their usage and surprise the test.
>> 
>> The test iterates JMX memory pools where thresholds are supported, sets a threshold one byte higher than current usage, and makes an allocation.  This only makes sense on Java heap pools.  It is tempting to skip non-heap pools, but this test can still give a sanity test about threshold behaviour.  That is actually its main purpose, as the allocation is unlikely to affect the pool being tested.
>> 
>> With the changes here, I'm seeing the test and all its variations pass reliably, i.e. 50 iterations in each tested platform.
>> 
>> Skip testing a non-heap memory pool, e.g. CodeHeap, if it is hitting the threshold while we test, because that means it is changing outside our control.  Also re-test isExceeded on failure, as fetching the usage and isExceeded is a race.
>> 
>> Logging of more pool stats to better understand failures.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8198668_MBean_threshold_test
>  - Show log output
>  - 8198668: MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001/TestDescription.java still failing

Looks good to me.
I've posted a couple of minor questions/comments.
Thanks,
Serguei

test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001.java line 116:

> 114:             }
> 115: 
> 116:             // If used value is less than threshold, then isUsageThresholdExceeded()

Nit: Replace(?): "If used value" => "If peak used value"

test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001.java line 130:

> 128:                 }
> 129:             } else
> 130:             // If used value is greater or equal than threshold, then

Nit: Replace(?): "If used value" => "If peak used value"

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

Marked as reviewed by sspitsyn (Reviewer).

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

From naoto at openjdk.org  Wed Jul  6 19:46:33 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Jul 2022 19:46:33 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <sHbNPpkAlwc9slRcjKYbXCWOgpKXN-XEunqXoXX1644=.76ae69fd-5911-4090-923f-f7c47c8ca088@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

Marked as reviewed by naoto (Reviewer).

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

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

From dcubed at openjdk.org  Wed Jul  6 20:56:15 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 6 Jul 2022 20:56:15 GMT
Subject: [jdk19] Integrated: 8289857: ProblemList
 jdk/jfr/event/runtime/TestActiveSettingEvent.java
In-Reply-To: <eRCNeSYA4oY6a--FJ1Qg9bdB3f_jSPWEHp5XLZ1LOS4=.8908be36-c399-4a67-8243-05d20c4ae654@github.com>
References: <zVenXEKgxYCpMU40JNRrZojK8kzWtaKpOgBqgaEBiXI=.0e606a23-68ac-4e99-890b-f2deab9391f4@github.com>
 <eRCNeSYA4oY6a--FJ1Qg9bdB3f_jSPWEHp5XLZ1LOS4=.8908be36-c399-4a67-8243-05d20c4ae654@github.com>
Message-ID: <TgvyAJTjYgGPZUsD1kBv2vcd8GU7uwdz5dUYs_b-Rvw=.6682545d-ef50-4c0f-9571-2824e02019cb@github.com>

On Wed, 6 Jul 2022 20:48:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the fast review!

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

PR: https://git.openjdk.org/jdk19/pull/117

From dcubed at openjdk.org  Wed Jul  6 20:56:16 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 6 Jul 2022 20:56:16 GMT
Subject: [jdk19] Integrated: 8289857: ProblemList
 jdk/jfr/event/runtime/TestActiveSettingEvent.java
In-Reply-To: <zVenXEKgxYCpMU40JNRrZojK8kzWtaKpOgBqgaEBiXI=.0e606a23-68ac-4e99-890b-f2deab9391f4@github.com>
References: <zVenXEKgxYCpMU40JNRrZojK8kzWtaKpOgBqgaEBiXI=.0e606a23-68ac-4e99-890b-f2deab9391f4@github.com>
Message-ID: <qhi4OmSCnMuVuCG7M1HH3NOYf52dH4r3fdblTdr7-ow=.5d43120d-e44e-4230-8a8a-c4f747380861@github.com>

On Wed, 6 Jul 2022 20:45:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java.

This pull request has now been integrated.

Changeset: 55fa19b5
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/55fa19b508ab4d760d1c5ff71e37399c3b79d85c
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8289857: ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java

Reviewed-by: darcy

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

PR: https://git.openjdk.org/jdk19/pull/117

From jwilhelm at openjdk.org  Wed Jul  6 21:03:47 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 6 Jul 2022 21:03:47 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <wFiz24FTdK89_Yl1CYVEsZ6Ee0QXnm0jW48qV2wsc7Q=.329cdbf6-0442-455e-a6df-1e79e4ae6a9f@github.com>
References: <wFiz24FTdK89_Yl1CYVEsZ6Ee0QXnm0jW48qV2wsc7Q=.329cdbf6-0442-455e-a6df-1e79e4ae6a9f@github.com>
Message-ID: <eHz9yrlfhjAa1CTLQ_S7Ks8v1BnwjkFOQAaP26lKNo4=.3ebe6bd6-43fe-48df-bcf0-91af88bcc3fb@github.com>

On Wed, 6 Jul 2022 13:01:02 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 2a6ec88c
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a6ec88cd09adec43df3da1b22653271517b14a8
Stats:     888 lines in 24 files changed: 705 ins; 64 del; 119 mod

Merge

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

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

From dholmes at openjdk.org  Wed Jul  6 01:27:32 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Jul 2022 01:27:32 GMT
Subject: RFR: 8289780: Remove Forte::register_stub
In-Reply-To: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
Message-ID: <9iGaC4aFHNx6w3kzoJNFvidssIKlNdNl5TFB1MxhoTI=.1feed3a4-92a2-4272-86b8-38c310303a3e@github.com>

On Wed, 6 Jul 2022 00:38:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I removed `Remove Forte::register_stub` since it's used only by the Solaris Forte(TM) Performance Tools collector, which is no longer supported by the JDK.
> 
> I also fixed a couple of places where the stub name is computed unnecessarily.
> 
> Also renamed some `#ifndef IA64` around the code that I touched.

Cleanup looks good! Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From sgehwolf at openjdk.org  Wed Jul  6 10:03:39 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 6 Jul 2022 10:03:39 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
Message-ID: <t4YIcP-O2oILwO9Nt4MmqXzxNY5dPgHefv-Fv-qMhcg=.88502fc2-ccd1-4399-b63f-e8d7569c81d8@github.com>

On Wed, 6 Jul 2022 03:52:30 GMT, xpbob <duke at openjdk.org> wrote:

>> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
>> Results the following
>> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update header

I do think this could be useful.

Having said that, some of this has been discussed in https://bugs.openjdk.org/browse/JDK-8199944 (and been considered as won't fix at the time). I tend to agree that it should be a JDK (and even an OS) specific bean. The relevant information is only available on Linux. +1 on making this JDK specific. First step is probably to get consensus on a CSR.

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

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

From dcubed at openjdk.org  Wed Jul  6 16:36:29 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 6 Jul 2022 16:36:29 GMT
Subject: [jdk19] RFR: 8289840: ProblemList
 vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
 when run with vthread wrapper
Message-ID: <UZpGiG0W8ge5gq2hPZYP9Xo2nyOP3j2cGce6Jln67RU=.d8fdee88-ae78-4ae8-9dba-68a1228c5fb0@github.com>

A trivial fix to ProblemList
vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java
when run with vthread wrapper.

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

Commit messages:
 - 8289840: ProblemList vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java when run with vthread wrapper

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

PR: https://git.openjdk.org/jdk19/pull/114

From dcubed at openjdk.org  Wed Jul  6 20:56:13 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 6 Jul 2022 20:56:13 GMT
Subject: [jdk19] Integrated: 8289857: ProblemList
 jdk/jfr/event/runtime/TestActiveSettingEvent.java
Message-ID: <zVenXEKgxYCpMU40JNRrZojK8kzWtaKpOgBqgaEBiXI=.0e606a23-68ac-4e99-890b-f2deab9391f4@github.com>

A trivial fix to ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java.

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

Commit messages:
 - 8289857: ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java

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

PR: https://git.openjdk.org/jdk19/pull/117

From alanb at openjdk.org  Wed Jul  6 06:43:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Jul 2022 06:43:09 GMT
Subject: [jdk19] Integrated: 8289439: Clarify relationship between
 ThreadStart/ThreadEnd and can_support_virtual_threads capability
In-Reply-To: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
References: <AZxcgVu1aA05FlBFMnKgs1oNF7iaQFaNsKu97TiAhYQ=.ff497d10-e559-41c3-8973-5937c6ff9c1a@github.com>
Message-ID: <LPdKiMCW5dTHTeaGMLU4yd8a0DRv6EXz1oJ_VBpDA6s=.c300a415-548f-4861-95f3-0a7aa12b90d5@github.com>

On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The description of the ThreadStart/End events in the JVM TI spec needs rewording to make it clearer when these events are sent for virtual threads and when VirtualThreadXXX events are sent instead.

This pull request has now been integrated.

Changeset: b3a0e482
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/b3a0e482adc32946d03b10589f746bb31f9c9e5b
Stats:     29 lines in 2 files changed: 12 ins; 0 del; 17 mod

8289439: Clarify relationship between ThreadStart/ThreadEnd and can_support_virtual_threads capability

Reviewed-by: dholmes, dcubed, sspitsyn, cjplummer

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

PR: https://git.openjdk.org/jdk19/pull/94

From stuefe at openjdk.org  Thu Jul  7 14:38:46 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Jul 2022 14:38:46 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir
In-Reply-To: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
Message-ID: <Ft3NcErvL8MmXCkXTt3T1iWu7yegzNAsnb3YD2yrpQo=.9bdaa832-2b7c-421c-8780-f8aff1bf0904@github.com>

On Thu, 7 Jul 2022 06:01:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
> 
> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
> 
> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
> 
> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
> 
> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.

Hi Ioi,

not a full review, just a time-limited glance. Will take a closer look later.

Cheers, Thomas

src/hotspot/os/posix/perfMemory_posix.cpp line 708:

> 706:   fd = ::open(filename, O_RDONLY);
> 707:   if (fd >= 0) {
> 708:     is_locked = (flock(fd, LOCK_EX|LOCK_NB) != 0);

Out of the n error conditions for flock(), only EWOULDBLOCK indicates a occupied lock. I would handle the rest differently.

src/hotspot/os/posix/perfMemory_posix.cpp line 720:

> 718: 
> 719:   return is_locked;
> 720: }

The interface of this function seems weirdly unbalanced and threw me off at first. We hand in fd=-1, and it opens the fd, maybe closes the fd, maybe returns a valid fd (via reference, one has to look closely), maybe returns an invalid but valid-looking fd...

I would disentangle this a bit either bei moving the open and the close out to the caller and making this a simple 


static bool is_locked_by_another_process(int fd);


or, alternatively, just inlining the whole section into the one place where we use it.

src/hotspot/os/posix/perfMemory_posix.cpp line 770:

> 768:     // create_sharedmem_file() and is_locked_by_another_process().
> 769:     // If it's already locked by another process, then obviously it's
> 770:     // not stale

Period missing.

src/hotspot/os/posix/perfMemory_posix.cpp line 781:

> 779:     // signal the process, then the file is assumed to
> 780:     // be stale and is removed because the files for such a
> 781:     // process should be in a different user specific directory.

I am not sure this is good. If two conflicting hotspots share the same PID in tmp, from two different users, this will probably be a setup error. Is the best way really to provoke SIGBUS in the other VM? Seems a bit harsh. 

Also terminology would be wrong. Its not stale then, since the target process probably exists, is a VM, and uses that file.

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

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

From coleenp at openjdk.org  Thu Jul  7 15:16:40 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Jul 2022 15:16:40 GMT
Subject: RFR: 8289780: Avoid formatting stub names when Forte is not
 enabled [v2]
In-Reply-To: <QQHmKYvsk2XgQnX4L7kE8z4TE0gCZZALzL8vyQ5TFjc=.1019b684-75ba-4909-bad4-7a7c7df87356@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
 <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
 <QQHmKYvsk2XgQnX4L7kE8z4TE0gCZZALzL8vyQ5TFjc=.1019b684-75ba-4909-bad4-7a7c7df87356@github.com>
Message-ID: <Gt6kRzZju9U2xhD-RHH4HO-Moj7ErWbXJJkeARQqkh0=.7c0570df-3332-45fe-9274-20b979c87947@github.com>

On Wed, 6 Jul 2022 19:09:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not remove Forte::register_stub as it is used on Linux as well
>
> src/hotspot/share/prims/forte.hpp line 32:
> 
>> 30: class Forte : AllStatic {
>> 31:  public:
>> 32:    static bool is_enabled() NOT_JVMTI_RETURN_(false);
> 
> I don't think the rest of this forte code is disabled by JVMTI.

If the answer to whether it's enabled is something you want to be fast, and doesn't change, maybe make it check a variable?

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

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

From cjplummer at openjdk.org  Thu Jul  7 19:16:48 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 7 Jul 2022 19:16:48 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

Are you going to update copyrights?

I reviewed src/jdk.hotspot.agent, src/jdk.jdi/, src/jdk.jdwp.agent, and src/jdk.management. Looks good other than copyrights and the suggestion I made for additional cleanup in symtab.c.

src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308:

> 306:   ELF_SHDR* shbuf = NULL;
> 307:   ELF_SHDR* cursct = NULL;
> 308:   ELF_PHDR* phbuf = NULL;

phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too.

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

Changes requested by cjplummer (Reviewer).

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

From lmesnik at openjdk.org  Fri Jul  8 00:53:43 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 8 Jul 2022 00:53:43 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <dGq1uotyXJlQ3HTcsiMP6dG6n-5Q3lzNG-b8kG29OUU=.523bd006-466d-40e4-8845-51f2768cd226@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

Marked as reviewed by lmesnik (Reviewer).

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

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

From coleenp at openjdk.org  Thu Jul  7 23:30:25 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Jul 2022 23:30:25 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
Message-ID: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>

This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
Tested with tiers1-6.

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

Commit messages:
 - 8271707: migrate tests to use jdk.test.whitebox.WhiteBox

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

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

From iklam at openjdk.org  Thu Jul  7 22:02:29 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 7 Jul 2022 22:02:29 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v2]
In-Reply-To: <Ft3NcErvL8MmXCkXTt3T1iWu7yegzNAsnb3YD2yrpQo=.9bdaa832-2b7c-421c-8780-f8aff1bf0904@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <Ft3NcErvL8MmXCkXTt3T1iWu7yegzNAsnb3YD2yrpQo=.9bdaa832-2b7c-421c-8780-f8aff1bf0904@github.com>
Message-ID: <umqmxgDWuOfanUzHEWHi3cHLDQMXd1sXV3eSSKAns9g=.8e7dd2b1-8913-4c8d-a7c3-9e99c676d2bc@github.com>

On Thu, 7 Jul 2022 14:17:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @tstuefe comments
>
> src/hotspot/os/posix/perfMemory_posix.cpp line 708:
> 
>> 706:   fd = ::open(filename, O_RDONLY);
>> 707:   if (fd >= 0) {
>> 708:     is_locked = (flock(fd, LOCK_EX|LOCK_NB) != 0);
> 
> Out of the n error conditions for flock(), only EWOULDBLOCK indicates a occupied lock. I would handle the rest differently.

Fixed.

> src/hotspot/os/posix/perfMemory_posix.cpp line 720:
> 
>> 718: 
>> 719:   return is_locked;
>> 720: }
> 
> The interface of this function seems weirdly unbalanced and threw me off at first. We hand in fd=-1, and it opens the fd, maybe closes the fd, maybe returns a valid fd (via reference, one has to look closely), maybe returns an invalid but valid-looking fd...
> 
> I would disentangle this a bit either bei moving the open and the close out to the caller and making this a simple 
> 
> 
> static bool is_locked_by_another_process(int fd);
> 
> 
> or, alternatively, just inlining the whole section into the one place where we use it.

I inlined the whole function and added more error handling code.

> src/hotspot/os/posix/perfMemory_posix.cpp line 770:
> 
>> 768:     // create_sharedmem_file() and is_locked_by_another_process().
>> 769:     // If it's already locked by another process, then obviously it's
>> 770:     // not stale
> 
> Period missing.

Fixed

> src/hotspot/os/posix/perfMemory_posix.cpp line 781:
> 
>> 779:     // signal the process, then the file is assumed to
>> 780:     // be stale and is removed because the files for such a
>> 781:     // process should be in a different user specific directory.
> 
> I am not sure this is good. If two conflicting hotspots share the same PID in tmp, from two different users, this will probably be a setup error. Is the best way really to provoke SIGBUS in the other VM? Seems a bit harsh. 
> 
> Also terminology would be wrong. Its not stale then, since the target process probably exists, is a VM, and uses that file.

We will get a permission error from the `kill(pid, 0)` call only after we have successfully grabbed the flock on the file. Note that if the file was created by a live JVM process that has the flock fix (i.e., this PR), regardless of which user owns the process, we will never come to here.

That the value of the `pid` variable is misleading. It is the NSPID of another JVM that created the file. If the current JVM process runs in a different PID namespace, it cannot reliably determine whether the file is stale or not.

In general, I don't think we can trust `pid` at all when containers are involved. But that's OK -- if you want to use Java in containers that share the /tmp directory, you must upgrade to a JVM that has the flock fix. Otherwise the behavior is undefined.

Otherwise, if you are:

- Not using containers. or
- Using containers that don't share /tmp

The logic for handling the `kill(pid, 0)` error is not changed by this PR, so we are bug-for-bug compatible with older JVMs. If you think the behavior should be changed, may that should be done in a separate PR?

Or, if you run into problems like "my hsperf files are randomly deleted", a simple fix is to upgrade the JVM to one that has the flock fix :-)

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

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

From weijun at openjdk.org  Fri Jul  8 04:06:37 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Jul 2022 04:06:37 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after login
 failure
Message-ID: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>

Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

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

Commit messages:
 - more null check inside collections
 - implSpec, some javadoc cstyle change
 - the fix

Changes: https://git.openjdk.org/jdk/pull/9348/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9348&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282730
  Stats: 199 lines in 9 files changed: 148 ins; 2 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/9348.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9348/head:pull/9348

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

From dcubed at openjdk.org  Thu Jul  7 23:12:29 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 7 Jul 2022 23:12:29 GMT
Subject: [jdk19] Integrated: 8289951: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java on linux-x64 and macosx-x64
In-Reply-To: <TaUOc7eM7yiVHwrW_5oUVtxMQpc8-EUOf23dddWRQRk=.7f551954-8aae-407b-84c2-462cfb5a0d1f@github.com>
References: <TaUOc7eM7yiVHwrW_5oUVtxMQpc8-EUOf23dddWRQRk=.7f551954-8aae-407b-84c2-462cfb5a0d1f@github.com>
Message-ID: <NE0Gl6gM_ZUGuoVsfzJBwKZwsUztLTr7QU3eqPESINI=.3a11c28b-ca70-4a7e-bf55-4b2ead189d6b@github.com>

On Thu, 7 Jul 2022 22:59:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on linux-x64 and macosx-x64.

This pull request has now been integrated.

Changeset: 1304390b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/1304390b3e7ecb4c87108747defd33d9fc4045c4
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8289951: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on linux-x64 and macosx-x64

Reviewed-by: psandoz

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

PR: https://git.openjdk.org/jdk19/pull/123

From psandoz at openjdk.org  Thu Jul  7 23:12:28 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 7 Jul 2022 23:12:28 GMT
Subject: [jdk19] RFR: 8289951: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java on linux-x64 and macosx-x64
In-Reply-To: <TaUOc7eM7yiVHwrW_5oUVtxMQpc8-EUOf23dddWRQRk=.7f551954-8aae-407b-84c2-462cfb5a0d1f@github.com>
References: <TaUOc7eM7yiVHwrW_5oUVtxMQpc8-EUOf23dddWRQRk=.7f551954-8aae-407b-84c2-462cfb5a0d1f@github.com>
Message-ID: <CiNhVy6ZmdFEtfFHB-q8hVS_VU9Hu1OT0bTlrJww8MY=.a9783de5-22ca-4eb4-95ac-afad17cc1b02@github.com>

On Thu, 7 Jul 2022 22:59:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on linux-x64 and macosx-x64.

Marked as reviewed by psandoz (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/123

From iklam at openjdk.org  Thu Jul  7 21:21:27 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 7 Jul 2022 21:21:27 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v2]
In-Reply-To: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
Message-ID: <5p5eD9qSVMhpLk27d3tMC9dK1Pnb-P8cRpfMzlNgMB4=.2e3ca216-8392-4794-a805-c8507624cf6c@github.com>

> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
> 
> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
> 
> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
> 
> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
> 
> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @tstuefe comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9406/files
  - new: https://git.openjdk.org/jdk/pull/9406/files/fef8058f..43f67c4e

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

  Stats: 78 lines in 2 files changed: 39 ins; 22 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9406.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9406/head:pull/9406

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

From weijun at openjdk.org  Fri Jul  8 04:06:39 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Jul 2022 04:06:39 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <Tng9jgPX0V5AL7yrsmF95-uIGl9T6XYeFy11QVoOjBs=.f4a6876b-1ffa-4c28-a241-e1c1310d033f@github.com>

On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java line 485:

> 483:         if (supplementaryGroups != null) {
> 484:             for (int i = 0; i < supplementaryGroups.size(); i++) {
> 485:                 subject.getPrincipals().remove(supplementaryGroups.get(i));

To be safest, I can check if `supplementaryGroups.get(i)` is null too. Same in `NTLoginModule` and `UnixLoginModule`.

src/jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java line 368:

> 366:         }
> 367:         if (groups != null) {
> 368:             for (int i = 0; groups != null && i < groups.length; i++) {

Oops, `groups != null` is already checked here. Will revert.

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

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

From dcubed at openjdk.org  Thu Jul  7 23:06:13 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 7 Jul 2022 23:06:13 GMT
Subject: [jdk19] RFR: 8289951: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java on linux-x64 and macosx-x64
Message-ID: <TaUOc7eM7yiVHwrW_5oUVtxMQpc8-EUOf23dddWRQRk=.7f551954-8aae-407b-84c2-462cfb5a0d1f@github.com>

A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on linux-x64 and macosx-x64.

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

Commit messages:
 - 8289951: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on linux-x64 and macosx-x64

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

PR: https://git.openjdk.org/jdk19/pull/123

From dcubed at openjdk.org  Thu Jul  7 23:12:28 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 7 Jul 2022 23:12:28 GMT
Subject: [jdk19] RFR: 8289951: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java on linux-x64 and macosx-x64
In-Reply-To: <CiNhVy6ZmdFEtfFHB-q8hVS_VU9Hu1OT0bTlrJww8MY=.a9783de5-22ca-4eb4-95ac-afad17cc1b02@github.com>
References: <TaUOc7eM7yiVHwrW_5oUVtxMQpc8-EUOf23dddWRQRk=.7f551954-8aae-407b-84c2-462cfb5a0d1f@github.com>
 <CiNhVy6ZmdFEtfFHB-q8hVS_VU9Hu1OT0bTlrJww8MY=.a9783de5-22ca-4eb4-95ac-afad17cc1b02@github.com>
Message-ID: <OYM-JcEh0NGcaRUoQE6lZKt4FYTIKZnHjuKWWzPAPbU=.8db491ff-5148-4480-911d-76ccc27a93af@github.com>

On Thu, 7 Jul 2022 23:07:17 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on linux-x64 and macosx-x64.
>
> Marked as reviewed by psandoz (Reviewer).

@PaulSandoz - Thanks for the review!

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

PR: https://git.openjdk.org/jdk19/pull/123

From dholmes at openjdk.org  Fri Jul  8 06:15:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Jul 2022 06:15:42 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

I skimmed the diff and this seems fine.

Are we not going to remove the old WhiteBox at the same time?

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From stuefe at openjdk.org  Fri Jul  8 06:41:29 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Jul 2022 06:41:29 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v2]
In-Reply-To: <umqmxgDWuOfanUzHEWHi3cHLDQMXd1sXV3eSSKAns9g=.8e7dd2b1-8913-4c8d-a7c3-9e99c676d2bc@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <Ft3NcErvL8MmXCkXTt3T1iWu7yegzNAsnb3YD2yrpQo=.9bdaa832-2b7c-421c-8780-f8aff1bf0904@github.com>
 <umqmxgDWuOfanUzHEWHi3cHLDQMXd1sXV3eSSKAns9g=.8e7dd2b1-8913-4c8d-a7c3-9e99c676d2bc@github.com>
Message-ID: <IjBLXjuRKJUMHpKVV7W4oKoTFJrxBxJJbS6Ymqa2zJw=.9be77658-808a-4469-83eb-ed4408bcc2a7@github.com>

On Thu, 7 Jul 2022 21:58:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/os/posix/perfMemory_posix.cpp line 781:
>> 
>>> 779:     // signal the process, then the file is assumed to
>>> 780:     // be stale and is removed because the files for such a
>>> 781:     // process should be in a different user specific directory.
>> 
>> I am not sure this is good. If two conflicting hotspots share the same PID in tmp, from two different users, this will probably be a setup error. Is the best way really to provoke SIGBUS in the other VM? Seems a bit harsh. 
>> 
>> Also terminology would be wrong. Its not stale then, since the target process probably exists, is a VM, and uses that file.
>
> We will get a permission error from the `kill(pid, 0)` call only after we have successfully grabbed the flock on the file. Note that if the file was created by a live JVM process that has the flock fix (i.e., this PR), regardless of which user owns the process, we will never come to here.
> 
> That the value of the `pid` variable is misleading. It is the NSPID of another JVM that created the file. If the current JVM process runs in a different PID namespace, it cannot reliably determine whether the file is stale or not.
> 
> In general, I don't think we can trust `pid` at all when containers are involved. But that's OK -- if you want to use Java in containers that share the /tmp directory, you must upgrade to a JVM that has the flock fix. Otherwise the behavior is undefined.
> 
> Otherwise, if you are:
> 
> - Not using containers. or
> - Using containers that don't share /tmp
> 
> The logic for handling the `kill(pid, 0)` error is not changed by this PR, so we are bug-for-bug compatible with older JVMs. If you think the behavior should be changed, may that should be done in a separate PR?
> 
> Or, if you run into problems like "my hsperf files are randomly deleted", a simple fix is to upgrade the JVM to one that has the flock fix :-)

Okay, you convinced me.

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

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

From stuefe at openjdk.org  Fri Jul  8 07:13:25 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Jul 2022 07:13:25 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v2]
In-Reply-To: <5p5eD9qSVMhpLk27d3tMC9dK1Pnb-P8cRpfMzlNgMB4=.2e3ca216-8392-4794-a805-c8507624cf6c@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <5p5eD9qSVMhpLk27d3tMC9dK1Pnb-P8cRpfMzlNgMB4=.2e3ca216-8392-4794-a805-c8507624cf6c@github.com>
Message-ID: <-DMr6VOyh2yyRjnSHfNc8y1_ml8HmxBfg3cgyG15Fvk=.fec64859-0f94-45dd-b358-7042da4eb846@github.com>

On Thu, 7 Jul 2022 21:21:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
>> 
>> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
>> 
>> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
>> 
>> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
>> 
>> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @tstuefe comments

src/hotspot/os/posix/perfMemory_posix.cpp line 743:

> 741: 
> 742:     // We now have a file name that converts to a valid integer
> 743:     // that could represent a process id.

"could"? It does, or? Why being ambiguous? (If we change the scheme later, we can be more specific)

src/hotspot/os/posix/perfMemory_posix.cpp line 744:

> 742:     // We now have a file name that converts to a valid integer
> 743:     // that could represent a process id.
> 744:     //

Can you add a short introduction here similar to:

"On Linux, VMs may run in different PID namespaces and therefore their PIDs are not unique. Therefore, we first try to flock() the file ..."

src/hotspot/os/posix/perfMemory_posix.cpp line 759:

> 757:     // signal the process, then the file is assumed to
> 758:     // be stale and is removed because the files for such a
> 759:     // process should be in a different user specific directory.

Please add a short sentence like:

"Finally, if VMs from different containers share /tmp, we cannot reliably determine process liveness using kill. To avoid that, either stop sharing /tmp between containers or only run VMs with the JDK-8286030 fix."

src/hotspot/os/posix/perfMemory_posix.cpp line 766:

> 764:     // The locking protocol works only with JVMs that have the JDK-8286030 fix.
> 765:     // If you are sharing the /tmp difrectory among different containers, do not
> 766:     // use older JVMs that don't have this fix.

Could possible shorten this if you feel the long comment above explains it all already.

src/hotspot/os/posix/perfMemory_posix.cpp line 796:

> 794:     if (!is_locked_by_another_process) {
> 795:       if ((pid == os::current_process_id()) ||
> 796:           (kill(pid, 0) == OS_ERR && (errno == ESRCH || errno == EPERM))) {

Thinking about this, I now was confused. AFAICS this code is only ever called from `mmap_create_shared` with the directory containing our own pid. I do not see this called for PIDs from other processes. Why do we handle that case? Or am I overlooking something?

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

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

From coleenp at openjdk.org  Fri Jul  8 12:51:42 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 12:51:42 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
 <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com>
Message-ID: <Yrfv7H3auoYd296-igfoIn4LX5BpmuGxetYFtRrZzH8=.ea9f5a66-f00b-48d1-a465-0adb83acd4db@github.com>

On Fri, 8 Jul 2022 06:12:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
>> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
>> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
>> Tested with tiers1-6.
>
> I skimmed the diff and this seems fine.
> 
> Are we not going to remove the old WhiteBox at the same time?
> 
> Thanks.

@dholmes-ora We'll remove it with this patch JDK-8275662 and the other obsolete sun.hotspot test classes which will be easier to look at.
Thanks for reviewing.

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

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

From djelinski at openjdk.org  Fri Jul  8 07:08:50 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Jul 2022 07:08:50 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
 <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com>
Message-ID: <5lYmVui3caVoMyThlWMlQP1etBfuLQan6v6OUIBYh_o=.e1d33b03-8791-4462-a9e7-b13287df2aa8@github.com>

On Thu, 7 Jul 2022 19:06:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin' into unused-variables
>>  - Remove unused variables (windows)
>>  - Remove unused variables (macos)
>>  - Remove unused variables (linux)
>
> src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308:
> 
>> 306:   ELF_SHDR* shbuf = NULL;
>> 307:   ELF_SHDR* cursct = NULL;
>> 308:   ELF_PHDR* phbuf = NULL;
> 
> phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too.

Good catch! Also removed similar code from macOS version.

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

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

From cjplummer at openjdk.org  Fri Jul  8 07:20:46 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 8 Jul 2022 07:20:46 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
Message-ID: <HWiis80fIvQdlOVtea6thFNk_VbOGDHltnJPDJMdo68=.7b9929c1-1a6c-48e3-bef3-369b91fda72e@github.com>

On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove more unused variables

Marked as reviewed by cjplummer (Reviewer).

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

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

From djelinski at openjdk.org  Fri Jul  8 07:08:46 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Jul 2022 07:08:46 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
Message-ID: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>

> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
> 
> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
> 
> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.

Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright
 - Remove more unused variables

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9383/files
  - new: https://git.openjdk.org/jdk/pull/9383/files/b4cd5374..da30ef90

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

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

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

From alanb at openjdk.org  Fri Jul  8 08:03:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Jul 2022 08:03:39 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
Message-ID: <eHLckqcFYnMhyC7rkOqTdkPozbDzFLzUdXRMmSRtWfE=.937733de-7eec-4360-b491-bdd219ad8c38@github.com>

On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove more unused variables

Marked as reviewed by alanb (Reviewer).

src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c line 686:

> 684:     LPCWSTR lpFileName = jlong_to_ptr(pathAddress);
> 685:     PSECURITY_DESCRIPTOR pSecurityDescriptor = jlong_to_ptr(descAddress);
> 686:     DWORD lengthNeeded = 0;

lengthNeeded, it seems not :-)

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

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

From djelinski at openjdk.org  Fri Jul  8 07:12:44 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Jul 2022 07:12:44 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
Message-ID: <2_Xy-WrhqelW5xoQnKgSrnb1WSEENT6zlJ4ZRbnJDvo=.0e7b8752-9def-459a-ac6a-1172dbd3d5f7@github.com>

On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove more unused variables

Copyrights updated.

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

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

From coleenp at openjdk.org  Fri Jul  8 15:58:32 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 15:58:32 GMT
Subject: Integrated: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <7OYMQYFZ2rIDV87GtSdBA2jbeOcjjsCVQq_GWOPfEoU=.846e9278-06ec-4428-83e9-d2a883a04e5f@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

This pull request has now been integrated.

Changeset: e7795851
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7795851d2e02389e63950fef939084b18ec4bfb
Stats:     2994 lines in 984 files changed: 6 ins; 0 del; 2988 mod

8271707: migrate tests to use jdk.test.whitebox.WhiteBox

Reviewed-by: lmesnik, dholmes

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

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

From coleenp at openjdk.org  Fri Jul  8 15:58:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 15:58:31 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <2mTLTyDQH8b2csvKDlgLMlfVhSm7JJXvFcuNMeqnYO0=.ab170919-9813-40be-a097-43671975d984@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

Thanks Leonid!

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

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

From weijun at openjdk.org  Fri Jul  8 04:06:37 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Jul 2022 04:06:37 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after login
 failure
Message-ID: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>

Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

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

Commit messages:
 - more null check inside collections
 - implSpec, some javadoc cstyle change
 - the fix

Changes: https://git.openjdk.org/jdk/pull/9348/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9348&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282730
  Stats: 199 lines in 9 files changed: 148 ins; 2 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/9348.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9348/head:pull/9348

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

From iklam at openjdk.org  Fri Jul  8 18:37:42 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 8 Jul 2022 18:37:42 GMT
Subject: RFR: 8289780: Avoid formatting stub names when Forte is not
 enabled [v2]
In-Reply-To: <Gt6kRzZju9U2xhD-RHH4HO-Moj7ErWbXJJkeARQqkh0=.7c0570df-3332-45fe-9274-20b979c87947@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
 <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
 <QQHmKYvsk2XgQnX4L7kE8z4TE0gCZZALzL8vyQ5TFjc=.1019b684-75ba-4909-bad4-7a7c7df87356@github.com>
 <Gt6kRzZju9U2xhD-RHH4HO-Moj7ErWbXJJkeARQqkh0=.7c0570df-3332-45fe-9274-20b979c87947@github.com>
Message-ID: <rhpmCSL7oZmmotEHgAUBhSHD1S3ux3e6NX8U4YPsvkk=.41bcdcaf-2758-48a8-8dca-53f60fdbe8ee@github.com>

On Thu, 7 Jul 2022 15:12:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/prims/forte.hpp line 32:
>> 
>>> 30: class Forte : AllStatic {
>>> 31:  public:
>>> 32:    static bool is_enabled() NOT_JVMTI_RETURN_(false);
>> 
>> I don't think the rest of this forte code is disabled by JVMTI.
>
> If the answer to whether it's enabled is something you want to be fast, and doesn't change, maybe make it check a variable?

The code in the `Forte` class, as well as the non-trivial of `AsyncGetCallTrace()` in forte.cpp, are inside `#if INCLUDE_JVMTI`. That's why I use `NOT_JVMTI_RETURN_` for the new function.

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

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

From coleenp at openjdk.org  Fri Jul  8 18:53:47 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 18:53:47 GMT
Subject: RFR: 8289780: Avoid formatting stub names when Forte is not
 enabled [v2]
In-Reply-To: <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
 <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
Message-ID: <tIKR119KTb9wFNs0xIg4UPM7ev4jpOwGb5llyqoa850=.e5af5ee3-1f00-4386-a87e-dc1f493374cb@github.com>

On Wed, 6 Jul 2022 17:50:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> `Forte::register_stub()` should be called only when the JVm is being instrumented by Forte (aka "Oracle Developer Studio")
>> 
>> https://www.oracle.com/tools/developerstudio/downloads/developer-studio-jsp.html
>> 
>> We currently always format the name of generated stubs and call `Forte::register_stub()`, which usually does nothing.
>> 
>> Example:
>> 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntime.cpp#L2686-L2697
>> 
>> To improve start-up, we should check if Forte is enabled before formatting the name.
>> 
>> I also renamed some `#ifndef IA64` around the code that I touched.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not remove Forte::register_stub as it is used on Linux as well

Marked as reviewed by coleenp (Reviewer).

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

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

From coleenp at openjdk.org  Fri Jul  8 18:53:48 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 18:53:48 GMT
Subject: RFR: 8289780: Avoid formatting stub names when Forte is not
 enabled [v2]
In-Reply-To: <rhpmCSL7oZmmotEHgAUBhSHD1S3ux3e6NX8U4YPsvkk=.41bcdcaf-2758-48a8-8dca-53f60fdbe8ee@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
 <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
 <QQHmKYvsk2XgQnX4L7kE8z4TE0gCZZALzL8vyQ5TFjc=.1019b684-75ba-4909-bad4-7a7c7df87356@github.com>
 <Gt6kRzZju9U2xhD-RHH4HO-Moj7ErWbXJJkeARQqkh0=.7c0570df-3332-45fe-9274-20b979c87947@github.com>
 <rhpmCSL7oZmmotEHgAUBhSHD1S3ux3e6NX8U4YPsvkk=.41bcdcaf-2758-48a8-8dca-53f60fdbe8ee@github.com>
Message-ID: <QY0AfbmbdmGGz0j99w4Jn_KOiSECMQ9yMyFYBCFocTw=.a7d31671-45d1-4cc9-a600-303875eb9d24@github.com>

On Fri, 8 Jul 2022 18:35:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> If the answer to whether it's enabled is something you want to be fast, and doesn't change, maybe make it check a variable?
>
> The code in the `Forte` class, as well as the non-trivial of `AsyncGetCallTrace()` in forte.cpp, are inside `#if INCLUDE_JVMTI`. That's why I use `NOT_JVMTI_RETURN_` for the new function.

Ok, thanks for answering my question.

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

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

From dcubed at openjdk.org  Fri Jul  8 19:52:02 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 8 Jul 2022 19:52:02 GMT
Subject: [jdk19] Integrated: 8290033: ProblemList
 serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on
 windows-x64 in -Xcomp mode
Message-ID: <gI7WH6d8-u24SqJAr_oZNdgyyG6bYB4jajVgoKadAtY=.22d10edf-7d02-43db-929c-57fc134c9efd@github.com>

A trivial fix to ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java
on windows-x64 in -Xcomp mode.

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

Commit messages:
 - 8290033: ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on windows-x64 in -Xcomp mode

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

PR: https://git.openjdk.org/jdk19/pull/127

From azvegint at openjdk.org  Fri Jul  8 19:52:03 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 8 Jul 2022 19:52:03 GMT
Subject: [jdk19] Integrated: 8290033: ProblemList
 serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on
 windows-x64 in -Xcomp mode
In-Reply-To: <gI7WH6d8-u24SqJAr_oZNdgyyG6bYB4jajVgoKadAtY=.22d10edf-7d02-43db-929c-57fc134c9efd@github.com>
References: <gI7WH6d8-u24SqJAr_oZNdgyyG6bYB4jajVgoKadAtY=.22d10edf-7d02-43db-929c-57fc134c9efd@github.com>
Message-ID: <TFnS6KmhZbmM4z6xYeOXm-ipdXpcELXyXjkfFlpEWng=.f49faab2-ab53-44f9-b95d-86f3efa6f1d7@github.com>

On Fri, 8 Jul 2022 19:39:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java
> on windows-x64 in -Xcomp mode.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/127

From tschatzl at openjdk.org  Fri Jul  8 19:52:04 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 8 Jul 2022 19:52:04 GMT
Subject: [jdk19] Integrated: 8290033: ProblemList
 serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on
 windows-x64 in -Xcomp mode
In-Reply-To: <gI7WH6d8-u24SqJAr_oZNdgyyG6bYB4jajVgoKadAtY=.22d10edf-7d02-43db-929c-57fc134c9efd@github.com>
References: <gI7WH6d8-u24SqJAr_oZNdgyyG6bYB4jajVgoKadAtY=.22d10edf-7d02-43db-929c-57fc134c9efd@github.com>
Message-ID: <8NvBVaSGBO11b0nsn8Q8ck-oYxESp0VpYn_ABdWLfsE=.51a8587c-d4d8-4598-ad4f-40ccf824b95b@github.com>

On Fri, 8 Jul 2022 19:39:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java
> on windows-x64 in -Xcomp mode.

Marked as reviewed by tschatzl (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/127

From dcubed at openjdk.org  Fri Jul  8 19:52:05 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 8 Jul 2022 19:52:05 GMT
Subject: [jdk19] Integrated: 8290033: ProblemList
 serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on
 windows-x64 in -Xcomp mode
In-Reply-To: <TFnS6KmhZbmM4z6xYeOXm-ipdXpcELXyXjkfFlpEWng=.f49faab2-ab53-44f9-b95d-86f3efa6f1d7@github.com>
References: <gI7WH6d8-u24SqJAr_oZNdgyyG6bYB4jajVgoKadAtY=.22d10edf-7d02-43db-929c-57fc134c9efd@github.com>
 <TFnS6KmhZbmM4z6xYeOXm-ipdXpcELXyXjkfFlpEWng=.f49faab2-ab53-44f9-b95d-86f3efa6f1d7@github.com>
Message-ID: <RPk5wwA6ujsyBNTiE7FMu0NXK0tC9C3vHekisdKcvr4=.f2a98f80-5060-4ef8-a1c7-2b51e93e3882@github.com>

On Fri, 8 Jul 2022 19:40:34 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java
>> on windows-x64 in -Xcomp mode.
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint - Thanks for the lightning fast review!

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

PR: https://git.openjdk.org/jdk19/pull/127

From dcubed at openjdk.org  Fri Jul  8 19:52:05 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 8 Jul 2022 19:52:05 GMT
Subject: [jdk19] Integrated: 8290033: ProblemList
 serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on
 windows-x64 in -Xcomp mode
In-Reply-To: <8NvBVaSGBO11b0nsn8Q8ck-oYxESp0VpYn_ABdWLfsE=.51a8587c-d4d8-4598-ad4f-40ccf824b95b@github.com>
References: <gI7WH6d8-u24SqJAr_oZNdgyyG6bYB4jajVgoKadAtY=.22d10edf-7d02-43db-929c-57fc134c9efd@github.com>
 <8NvBVaSGBO11b0nsn8Q8ck-oYxESp0VpYn_ABdWLfsE=.51a8587c-d4d8-4598-ad4f-40ccf824b95b@github.com>
Message-ID: <3uoA--ra6mQN0gjzRdi9PvmeRfxDTG6oLeT4M3jj_1Y=.8482fee4-2e09-4132-8d4e-991ded862ca5@github.com>

On Fri, 8 Jul 2022 19:41:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java
>> on windows-x64 in -Xcomp mode.
>
> Marked as reviewed by tschatzl (Reviewer).

@tschatzl - Thanks for the fast review!

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

PR: https://git.openjdk.org/jdk19/pull/127

From dcubed at openjdk.org  Fri Jul  8 19:52:06 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 8 Jul 2022 19:52:06 GMT
Subject: [jdk19] Integrated: 8290033: ProblemList
 serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on
 windows-x64 in -Xcomp mode
In-Reply-To: <gI7WH6d8-u24SqJAr_oZNdgyyG6bYB4jajVgoKadAtY=.22d10edf-7d02-43db-929c-57fc134c9efd@github.com>
References: <gI7WH6d8-u24SqJAr_oZNdgyyG6bYB4jajVgoKadAtY=.22d10edf-7d02-43db-929c-57fc134c9efd@github.com>
Message-ID: <qrV-fxSWfwbcDQDbhtrl7NWlzksajYo2KS1dhElkHDI=.4b9c1e91-9f19-4f59-8e6f-3e40ffe72dfe@github.com>

On Fri, 8 Jul 2022 19:39:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java
> on windows-x64 in -Xcomp mode.

This pull request has now been integrated.

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

8290033: ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on windows-x64 in -Xcomp mode

Reviewed-by: azvegint, tschatzl

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

PR: https://git.openjdk.org/jdk19/pull/127

From coleenp at openjdk.org  Fri Jul  8 21:50:12 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 21:50:12 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
Message-ID: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>

This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
Tested with tier1-4.

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

Commit messages:
 - 8275662: remove test/lib/sun/hotspot

Changes: https://git.openjdk.org/jdk/pull/9434/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9434&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8275662
  Stats: 1484 lines in 99 files changed: 0 ins; 1367 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/9434.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9434/head:pull/9434

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

From mseledtsov at openjdk.org  Fri Jul  8 21:50:12 2022
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Fri, 8 Jul 2022 21:50:12 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <-s197KfRIxYZ-QIqR_c48nZlUjed9kTjHTOGOqlVHWg=.a11735f0-9e5b-44f4-907a-c11230540a87@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

Changes look good to me. Thank you.

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

Marked as reviewed by mseledtsov (Committer).

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

From coleenp at openjdk.org  Fri Jul  8 21:50:13 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 21:50:13 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <mHvkNKVdiw_51YR0B9NyTxjObGk7XJd-nout8YVRlQg=.4728997d-04e2-4315-ac5e-1dfff8460c18@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

Thanks Misha!

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

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

From sspitsyn at openjdk.org  Fri Jul  8 22:47:40 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Jul 2022 22:47:40 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <V52aYwVRH0kBLgBO3M-HXA1LMRwDAD_Qm5rKwslBTKE=.3f2c1837-f04e-440e-b8ce-030ef63337f6@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

This looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.org  Fri Jul  8 22:58:41 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Jul 2022 22:58:41 GMT
Subject: RFR: 8289780: Avoid formatting stub names when Forte is not
 enabled [v2]
In-Reply-To: <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
 <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
Message-ID: <BQUPV21ub9QZJ9xIAnUI0AgsW2ac_Efyts7H5YdIIJg=.166041e7-a042-4525-8629-1fd03564777d@github.com>

On Wed, 6 Jul 2022 17:50:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> `Forte::register_stub()` should be called only when the JVm is being instrumented by Forte (aka "Oracle Developer Studio")
>> 
>> https://www.oracle.com/tools/developerstudio/downloads/developer-studio-jsp.html
>> 
>> We currently always format the name of generated stubs and call `Forte::register_stub()`, which usually does nothing.
>> 
>> Example:
>> 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntime.cpp#L2686-L2697
>> 
>> To improve start-up, we should check if Forte is enabled before formatting the name.
>> 
>> I also renamed some `#ifndef IA64` around the code that I touched.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not remove Forte::register_stub as it is used on Linux as well

I've posed one comment.
Other than that the fix looks okay.
Thanks,
Serguei

src/hotspot/share/runtime/sharedRuntime.cpp line 2700:

> 2698:     if (JvmtiExport::should_post_dynamic_code_generated()) {
> 2699:       JvmtiExport::post_dynamic_code_generated(blob_id, new_adapter->content_begin(), new_adapter->content_end());
> 2700:     }

The lines 2698-2670 is better to move out of the if-statement at the line 2687.

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

Marked as reviewed by sspitsyn (Reviewer).

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

From iklam at openjdk.org  Fri Jul  8 23:09:46 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 8 Jul 2022 23:09:46 GMT
Subject: RFR: 8289780: Avoid formatting stub names when Forte is not
 enabled [v2]
In-Reply-To: <BQUPV21ub9QZJ9xIAnUI0AgsW2ac_Efyts7H5YdIIJg=.166041e7-a042-4525-8629-1fd03564777d@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
 <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
 <BQUPV21ub9QZJ9xIAnUI0AgsW2ac_Efyts7H5YdIIJg=.166041e7-a042-4525-8629-1fd03564777d@github.com>
Message-ID: <S5lFg5CUCpWwj38bfb5f6dODq15Ish212-lKE27tNwM=.eaa1946f-7912-48b4-a6d6-00736199d3ba@github.com>

On Fri, 8 Jul 2022 22:53:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not remove Forte::register_stub as it is used on Linux as well
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 2700:
> 
>> 2698:     if (JvmtiExport::should_post_dynamic_code_generated()) {
>> 2699:       JvmtiExport::post_dynamic_code_generated(blob_id, new_adapter->content_begin(), new_adapter->content_end());
>> 2700:     }
> 
> The lines 2698-2670 is better to move out of the if-statement at the line 2687.

HI Serguei, thanks for the review. Lines 2698-2700 need the blob_id which is generated at line 2688, so they have to stay inside the outer "if" block.

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

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

From sspitsyn at openjdk.org  Sat Jul  9 01:04:46 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 9 Jul 2022 01:04:46 GMT
Subject: RFR: 8289780: Avoid formatting stub names when Forte is not
 enabled [v2]
In-Reply-To: <S5lFg5CUCpWwj38bfb5f6dODq15Ish212-lKE27tNwM=.eaa1946f-7912-48b4-a6d6-00736199d3ba@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
 <zdYNm5Yp3FqvpmpuD4Lq7uJYgp1K8zzXeWjdOTqLNw4=.3f858191-726a-49b6-8787-484fef0dc2f2@github.com>
 <BQUPV21ub9QZJ9xIAnUI0AgsW2ac_Efyts7H5YdIIJg=.166041e7-a042-4525-8629-1fd03564777d@github.com>
 <S5lFg5CUCpWwj38bfb5f6dODq15Ish212-lKE27tNwM=.eaa1946f-7912-48b4-a6d6-00736199d3ba@github.com>
Message-ID: <LMXGdz8Plwj_Do6mCetMjDJPyVTWJmDsNmWncpWtVoQ=.431c3876-e80e-4969-b9cb-cf98fd83fa52@github.com>

On Fri, 8 Jul 2022 23:06:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/runtime/sharedRuntime.cpp line 2700:
>> 
>>> 2698:     if (JvmtiExport::should_post_dynamic_code_generated()) {
>>> 2699:       JvmtiExport::post_dynamic_code_generated(blob_id, new_adapter->content_begin(), new_adapter->content_end());
>>> 2700:     }
>> 
>> The lines 2698-2670 is better to move out of the if-statement at the line 2687.
>
> HI Serguei, thanks for the review. Lines 2698-2700 need the blob_id which is generated at line 2688, so they have to stay inside the outer "if" block.

Thanks, Ioi. You are right.

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

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

From lmesnik at openjdk.org  Sat Jul  9 03:46:42 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 9 Jul 2022 03:46:42 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <wNgBDP3zkdRDdWjFrf3COMshqrDcKAJgBo9qvRdZm9I=.d3eb8acd-c4e6-4348-a34f-2fbf842846cf@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

Marked as reviewed by lmesnik (Reviewer).

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

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

From iklam at openjdk.org  Sat Jul  9 03:48:50 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Jul 2022 03:48:50 GMT
Subject: RFR: 8289780: Avoid formatting stub names when Forte is not
 enabled [v2]
In-Reply-To: <9iGaC4aFHNx6w3kzoJNFvidssIKlNdNl5TFB1MxhoTI=.1feed3a4-92a2-4272-86b8-38c310303a3e@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
 <9iGaC4aFHNx6w3kzoJNFvidssIKlNdNl5TFB1MxhoTI=.1feed3a4-92a2-4272-86b8-38c310303a3e@github.com>
Message-ID: <AEBhyaCSurhXCRioqXVzNl6mnTvUsrN35UtvFRXvufQ=.25b4bfb9-86c4-4df1-9e5f-5fc5f3593bde@github.com>

On Wed, 6 Jul 2022 01:24:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not remove Forte::register_stub as it is used on Linux as well
>
> Cleanup looks good! Thanks.

Thanks @dholmes-ora, @sspitsyn, @coleenp for the review.

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

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

From iklam at openjdk.org  Sat Jul  9 03:49:59 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Jul 2022 03:49:59 GMT
Subject: Integrated: 8289780: Avoid formatting stub names when Forte is not
 enabled
In-Reply-To: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
References: <R6NngqNQTtQtu33L0H7EPsQfYX_eFxKQcG_s2dEhj0g=.80554a97-9a5c-48b4-ad7e-535ca3ea6453@github.com>
Message-ID: <E5EUdgxUJaNX0brUXaOe1XUTyli2Vkk82vdDD6tb6pQ=.4d8ed232-68b9-4c83-b11b-9eac4760a737@github.com>

On Wed, 6 Jul 2022 00:38:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `Forte::register_stub()` should be called only when the JVm is being instrumented by Forte (aka "Oracle Developer Studio")
> 
> https://www.oracle.com/tools/developerstudio/downloads/developer-studio-jsp.html
> 
> We currently always format the name of generated stubs and call `Forte::register_stub()`, which usually does nothing.
> 
> Example:
> 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntime.cpp#L2686-L2697
> 
> To improve start-up, we should check if Forte is enabled before formatting the name.
> 
> I also renamed some `#ifndef IA64` around the code that I touched.

This pull request has now been integrated.

Changeset: 3c08e6b3
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c08e6b311121e05e30b88c0e325317f364ef15d
Stats:     37 lines in 5 files changed: 18 ins; 3 del; 16 mod

8289780: Avoid formatting stub names when Forte is not enabled

Reviewed-by: dholmes, coleenp, sspitsyn

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

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

From iklam at openjdk.org  Sat Jul  9 05:09:41 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Jul 2022 05:09:41 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v2]
In-Reply-To: <-DMr6VOyh2yyRjnSHfNc8y1_ml8HmxBfg3cgyG15Fvk=.fec64859-0f94-45dd-b358-7042da4eb846@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <5p5eD9qSVMhpLk27d3tMC9dK1Pnb-P8cRpfMzlNgMB4=.2e3ca216-8392-4794-a805-c8507624cf6c@github.com>
 <-DMr6VOyh2yyRjnSHfNc8y1_ml8HmxBfg3cgyG15Fvk=.fec64859-0f94-45dd-b358-7042da4eb846@github.com>
Message-ID: <PrrxsQFdkCAQX9urb67PhewI73Hb7XEKP8ksJXj8M74=.f4ff56c0-9a2d-48e5-9b98-df9028f94d13@github.com>

On Fri, 8 Jul 2022 06:54:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @tstuefe comments
>
> src/hotspot/os/posix/perfMemory_posix.cpp line 743:
> 
>> 741: 
>> 742:     // We now have a file name that converts to a valid integer
>> 743:     // that could represent a process id.
> 
> "could"? It does, or? Why being ambiguous? (If we change the scheme later, we can be more specific)

The "could" is from the old comment. Maybe it means that the pid does not represent a live process?

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

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

From iklam at openjdk.org  Sat Jul  9 05:22:44 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Jul 2022 05:22:44 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v2]
In-Reply-To: <-DMr6VOyh2yyRjnSHfNc8y1_ml8HmxBfg3cgyG15Fvk=.fec64859-0f94-45dd-b358-7042da4eb846@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <5p5eD9qSVMhpLk27d3tMC9dK1Pnb-P8cRpfMzlNgMB4=.2e3ca216-8392-4794-a805-c8507624cf6c@github.com>
 <-DMr6VOyh2yyRjnSHfNc8y1_ml8HmxBfg3cgyG15Fvk=.fec64859-0f94-45dd-b358-7042da4eb846@github.com>
Message-ID: <OV42BSIZeR2eWUuhWvx0JSjREzuuOuoOBMNcc99Z4OM=.e9dcd3d4-b261-406f-a1fc-8aeba72f61bc@github.com>

On Fri, 8 Jul 2022 07:08:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @tstuefe comments
>
> src/hotspot/os/posix/perfMemory_posix.cpp line 796:
> 
>> 794:     if (!is_locked_by_another_process) {
>> 795:       if ((pid == os::current_process_id()) ||
>> 796:           (kill(pid, 0) == OS_ERR && (errno == ESRCH || errno == EPERM))) {
> 
> Thinking about this, I now was confused. AFAICS this code is only ever called from `mmap_create_shared` with the directory containing our own pid. I do not see this called for PIDs from other processes. Why do we handle that case? Or am I overlooking something?

The current JVM process only cleans up stale files in the current user's own directory. I.e., /tmp/hsperfdata_bob/. However,  when we see a file like /tmp/hsperfdata_bob/1234, it's possible that

- 1234 was a JVM process created by bob, but this process died without cleaning up
- A new process 1234 is now running, but it belongs to a different user, john

So if `kill(1234, 0)` fails, the JVM concludes that, "/tmp/hsperfdata_bob/1234 must belong to a terminated JVM process owned by bob".

I think this is the intention of the code, in spite of what the comment says above the `kill` call.

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

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

From iklam at openjdk.org  Sat Jul  9 06:32:29 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Jul 2022 06:32:29 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v3]
In-Reply-To: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
Message-ID: <iFHRgeQ9z8x5vKmWwTCx7ZMCam-LYJJ3hkkooMRt1Os=.a341b78c-cffb-4277-a3ea-4fdd8f4b5b73@github.com>

> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
> 
> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
> 
> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
> 
> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
> 
> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Simplified code and improved comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9406/files
  - new: https://git.openjdk.org/jdk/pull/9406/files/43f67c4e..f1efc476

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

  Stats: 69 lines in 1 file changed: 22 ins; 21 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/9406.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9406/head:pull/9406

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

From iklam at openjdk.org  Sat Jul  9 06:42:29 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Jul 2022 06:42:29 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v4]
In-Reply-To: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
Message-ID: <OCIcgM0P4I5DkGXpxn4ZUaiX1hioJbJ8zfy6Jk5M7t0=.f2bf5d8e-355c-4b9a-94cc-a8a34a7884d9@github.com>

> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
> 
> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
> 
> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
> 
> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
> 
> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  added more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9406/files
  - new: https://git.openjdk.org/jdk/pull/9406/files/f1efc476..73242937

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

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

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

From iklam at openjdk.org  Sat Jul  9 06:49:03 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Jul 2022 06:49:03 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v5]
In-Reply-To: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
Message-ID: <YxkFB9_hMSn03DPHSfRmq4gRLNHcgXWHFM1AyKUiY2s=.f78241b8-d0e4-4f86-ae09-ca34cccc6f90@github.com>

> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
> 
> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
> 
> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
> 
> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
> 
> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9406/files
  - new: https://git.openjdk.org/jdk/pull/9406/files/73242937..78254917

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

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

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

From iklam at openjdk.org  Sat Jul  9 06:49:04 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 9 Jul 2022 06:49:04 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v2]
In-Reply-To: <OV42BSIZeR2eWUuhWvx0JSjREzuuOuoOBMNcc99Z4OM=.e9dcd3d4-b261-406f-a1fc-8aeba72f61bc@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <5p5eD9qSVMhpLk27d3tMC9dK1Pnb-P8cRpfMzlNgMB4=.2e3ca216-8392-4794-a805-c8507624cf6c@github.com>
 <-DMr6VOyh2yyRjnSHfNc8y1_ml8HmxBfg3cgyG15Fvk=.fec64859-0f94-45dd-b358-7042da4eb846@github.com>
 <OV42BSIZeR2eWUuhWvx0JSjREzuuOuoOBMNcc99Z4OM=.e9dcd3d4-b261-406f-a1fc-8aeba72f61bc@github.com>
Message-ID: <-hx4vs55eC3dv35nVzryvW3AOhMh1_HQToUqzZAHDdE=.f3937738-925b-4ec9-9260-81c3cac0c58b@github.com>

On Sat, 9 Jul 2022 05:19:08 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/os/posix/perfMemory_posix.cpp line 796:
>> 
>>> 794:     if (!is_locked_by_another_process) {
>>> 795:       if ((pid == os::current_process_id()) ||
>>> 796:           (kill(pid, 0) == OS_ERR && (errno == ESRCH || errno == EPERM))) {
>> 
>> Thinking about this, I now was confused. AFAICS this code is only ever called from `mmap_create_shared` with the directory containing our own pid. I do not see this called for PIDs from other processes. Why do we handle that case? Or am I overlooking something?
>
> The current JVM process only cleans up stale files in the current user's own directory. I.e., /tmp/hsperfdata_bob/. However,  when we see a file like /tmp/hsperfdata_bob/1234, it's possible that
> 
> - 1234 was a JVM process created by bob, but this process died without cleaning up
> - A new process 1234 is now running, but it belongs to a different user, john
> 
> So if `kill(1234, 0)` fails, the JVM concludes that, "/tmp/hsperfdata_bob/1234 must belong to a terminated JVM process owned by bob".
> 
> I think this is the intention of the code, in spite of what the comment says above the `kill` call.

I simplified the code and restructured the comments to be interspersed with the code. Hopefully that would make the logic a little easier to understand.

Despite the large diff in cleanup_sharedmem_files(), the only actual change is to `flock` in the middle of the loop, and avoid deleting the file if the `flock` fails.

I removed this comment


// ... are removed because the resources for such a
// process should be in a different user specific directory.


and replaced it with something more comprehensive which hopefully makes more sense:


// This directory should be used only by JVM processes owned by the
// current user to store PerfMemory files. Any other files found
// in this directory may be removed.

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

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

From sspitsyn at openjdk.org  Sat Jul  9 06:49:21 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 9 Jul 2022 06:49:21 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions
Message-ID: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>

This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 

In short, the deadlock dependencies are:

- The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
- The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
- The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.

Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 

Testing: submitted mach5 job with 100 runs on 3 debug platforms.

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

Commit messages:
 - 8289709: fatal error: stuck in JvmtiVTMSTransitionDisabler::disable_VTMS_transitions

Changes: https://git.openjdk.org/jdk19/pull/129/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289709
  Stats: 35 lines in 2 files changed: 10 ins; 6 del; 19 mod
  Patch: https://git.openjdk.org/jdk19/pull/129.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/129/head:pull/129

PR: https://git.openjdk.org/jdk19/pull/129

From sspitsyn at openjdk.org  Sat Jul  9 07:34:48 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 9 Jul 2022 07:34:48 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v2]
In-Reply-To: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
Message-ID: <fu53UQmMv1abdGx8bzO7NKu3wDj2Ma9SL2WgD1UhSpI=.06ec0ed4-3044-4ad3-98bc-d5f4e4903606@github.com>

> This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 
> 
> In short, the deadlock dependencies are:
> 
> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
> - The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
> - The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.
> 
> Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 
> 
> Testing: submitted mach5 job with 100 runs on 3 debug platforms.

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

  adjusted max number of threads instead of adding explicit timeout

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/129/files
  - new: https://git.openjdk.org/jdk19/pull/129/files/27317b95..aaeb1b29

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

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

PR: https://git.openjdk.org/jdk19/pull/129

From alanb at openjdk.org  Sat Jul  9 17:16:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Jul 2022 17:16:50 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v2]
In-Reply-To: <fu53UQmMv1abdGx8bzO7NKu3wDj2Ma9SL2WgD1UhSpI=.06ec0ed4-3044-4ad3-98bc-d5f4e4903606@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
 <fu53UQmMv1abdGx8bzO7NKu3wDj2Ma9SL2WgD1UhSpI=.06ec0ed4-3044-4ad3-98bc-d5f4e4903606@github.com>
Message-ID: <Ul-bwujshFTYyDdPjTmxqA7meuE1ib7bJ2ep2rUkGSw=.10b23dda-bab9-4504-bdd6-3ad04df57846@github.com>

On Sat, 9 Jul 2022 07:34:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 
>> 
>> In short, the deadlock dependencies are:
>> 
>> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
>> - The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
>> - The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.
>> 
>> Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 
>> 
>> Testing: submitted mach5 job with 100 runs on 3 debug platforms.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjusted max number of threads instead of adding explicit timeout

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/libframepop02.cpp line 75:

> 73:   jvmtiThreadInfo inf;
> 74:   const char* TEST_THREAD_NAME_BASE = "Test Thread";
> 75:   check_jvmti_status(jni, jvmti->GetThreadInfo(thr, &inf), "Error in GetThreadInfo.");

In passing, should isTestThread deallocate inf.name to avoid leaking memory?

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

PR: https://git.openjdk.org/jdk19/pull/129

From alanb at openjdk.org  Sat Jul  9 17:24:54 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Jul 2022 17:24:54 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v2]
In-Reply-To: <fu53UQmMv1abdGx8bzO7NKu3wDj2Ma9SL2WgD1UhSpI=.06ec0ed4-3044-4ad3-98bc-d5f4e4903606@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
 <fu53UQmMv1abdGx8bzO7NKu3wDj2Ma9SL2WgD1UhSpI=.06ec0ed4-3044-4ad3-98bc-d5f4e4903606@github.com>
Message-ID: <e6Shvcc1BELKXOWH02SvbNPg_iC9smMhxqHpoeiHWMs=.e7190bc2-6f73-44ac-94d6-1dd12fd22bcf@github.com>

On Sat, 9 Jul 2022 07:34:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 
>> 
>> In short, the deadlock dependencies are:
>> 
>> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
>> - The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
>> - The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.
>> 
>> Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 
>> 
>> Testing: submitted mach5 job with 100 runs on 3 debug platforms.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjusted max number of threads instead of adding explicit timeout

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/libframepop02.cpp line 219:

> 217: 
> 218:   if (!isTestThread(jni, jvmti, thr)) {
> 219:     return; // not a tested thread

If I read the test correctly, NotifyFramePop will only be called with the test thread so therefore the FramePop callback should only be called by the test thread, is that correct? I'm asking because I'm wondering why FramePop also checks the thread is the test thread.

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

PR: https://git.openjdk.org/jdk19/pull/129

From sspitsyn at openjdk.org  Sun Jul 10 09:54:43 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 10 Jul 2022 09:54:43 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v2]
In-Reply-To: <Ul-bwujshFTYyDdPjTmxqA7meuE1ib7bJ2ep2rUkGSw=.10b23dda-bab9-4504-bdd6-3ad04df57846@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
 <fu53UQmMv1abdGx8bzO7NKu3wDj2Ma9SL2WgD1UhSpI=.06ec0ed4-3044-4ad3-98bc-d5f4e4903606@github.com>
 <Ul-bwujshFTYyDdPjTmxqA7meuE1ib7bJ2ep2rUkGSw=.10b23dda-bab9-4504-bdd6-3ad04df57846@github.com>
Message-ID: <UQqdjUUe0dXIOHLD-Sp1wrfSiQs75CJ4YUffzsiumWQ=.6361505a-92ac-4ff9-98da-a9bfc5fdf382@github.com>

On Sat, 9 Jul 2022 17:13:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjusted max number of threads instead of adding explicit timeout
>
> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/libframepop02.cpp line 75:
> 
>> 73:   jvmtiThreadInfo inf;
>> 74:   const char* TEST_THREAD_NAME_BASE = "Test Thread";
>> 75:   check_jvmti_status(jni, jvmti->GetThreadInfo(thr, &inf), "Error in GetThreadInfo.");
> 
> In passing, should isTestThread deallocate inf.name to avoid leaking memory?

Alan, thank you for looking at this fix.
Good suggestion.

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

PR: https://git.openjdk.org/jdk19/pull/129

From sspitsyn at openjdk.org  Sun Jul 10 09:59:42 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 10 Jul 2022 09:59:42 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v2]
In-Reply-To: <e6Shvcc1BELKXOWH02SvbNPg_iC9smMhxqHpoeiHWMs=.e7190bc2-6f73-44ac-94d6-1dd12fd22bcf@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
 <fu53UQmMv1abdGx8bzO7NKu3wDj2Ma9SL2WgD1UhSpI=.06ec0ed4-3044-4ad3-98bc-d5f4e4903606@github.com>
 <e6Shvcc1BELKXOWH02SvbNPg_iC9smMhxqHpoeiHWMs=.e7190bc2-6f73-44ac-94d6-1dd12fd22bcf@github.com>
Message-ID: <03cGXyOkW4Oy1ptpOZI9yweBaRGusO3xIqdL91SAtAA=.84d475bd-38d5-4e4f-b0c2-c18233a18fcd@github.com>

On Sat, 9 Jul 2022 17:21:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjusted max number of threads instead of adding explicit timeout
>
> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/libframepop02.cpp line 219:
> 
>> 217: 
>> 218:   if (!isTestThread(jni, jvmti, thr)) {
>> 219:     return; // not a tested thread
> 
> If I read the test correctly, NotifyFramePop will only be called with the test thread so therefore the FramePop callback should only be called by the test thread, is that correct? I'm asking because I'm wondering why FramePop also checks the thread is the test thread.

As I understand, it is kind of a double-check in this test.
I agree, we can simplify this code little bit.

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

PR: https://git.openjdk.org/jdk19/pull/129

From sspitsyn at openjdk.org  Sun Jul 10 10:10:51 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 10 Jul 2022 10:10:51 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v3]
In-Reply-To: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
Message-ID: <HQYs5UVduCwJPFORzABDDM5buWEWb05s__J1PIbRUv4=.6a02ef2a-7f76-482a-9584-1094926860c0@github.com>

> This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 
> 
> In short, the deadlock dependencies are:
> 
> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
> - The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
> - The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.
> 
> Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 
> 
> Testing: submitted mach5 job with 100 runs on 3 debug platforms.

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

  free inf.name in isTestThread and simplify event handlers

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/129/files
  - new: https://git.openjdk.org/jdk19/pull/129/files/aaeb1b29..046d3525

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

  Stats: 34 lines in 1 file changed: 10 ins; 6 del; 18 mod
  Patch: https://git.openjdk.org/jdk19/pull/129.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/129/head:pull/129

PR: https://git.openjdk.org/jdk19/pull/129

From sspitsyn at openjdk.org  Sun Jul 10 10:12:54 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 10 Jul 2022 10:12:54 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v4]
In-Reply-To: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
Message-ID: <qL21TS4oaG4bzgjZehy5w8F0lshTiF-wAvQqDOQ6vY8=.a9a75dd6-5cd7-4804-bfa0-4713bc3db76b@github.com>

> This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 
> 
> In short, the deadlock dependencies are:
> 
> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
> - The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
> - The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.
> 
> Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 
> 
> Testing: submitted mach5 job with 100 runs on 3 debug platforms.

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

  remove trailing white space

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/129/files
  - new: https://git.openjdk.org/jdk19/pull/129/files/046d3525..9ae069c6

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

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

PR: https://git.openjdk.org/jdk19/pull/129

From alanb at openjdk.org  Sun Jul 10 13:22:57 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 10 Jul 2022 13:22:57 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v4]
In-Reply-To: <qL21TS4oaG4bzgjZehy5w8F0lshTiF-wAvQqDOQ6vY8=.a9a75dd6-5cd7-4804-bfa0-4713bc3db76b@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
 <qL21TS4oaG4bzgjZehy5w8F0lshTiF-wAvQqDOQ6vY8=.a9a75dd6-5cd7-4804-bfa0-4713bc3db76b@github.com>
Message-ID: <ZkboTyIXBD5lyzES1kuxeDv0EaADZ2TyDnImIuGnGu4=.84425daa-22e7-489d-a891-44edf41464e1@github.com>

On Sun, 10 Jul 2022 10:12:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 
>> 
>> In short, the deadlock dependencies are:
>> 
>> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
>> - The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
>> - The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.
>> 
>> Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 
>> 
>> Testing: submitted mach5 job with 100 runs on 3 debug platforms.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing white space

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/129

From duke at openjdk.org  Sun Jul 10 14:38:43 2022
From: duke at openjdk.org (xpbob)
Date: Sun, 10 Jul 2022 14:38:43 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
Message-ID: <kxOD6wUeBsF29W9wk8t6GjPGEg4lfQDgL7_MbptZG0g=.feb5b19c-146f-4e21-92cf-1213ef72b586@github.com>

On Wed, 6 Jul 2022 05:59:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update header
>
> It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API?  I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting getting locked in. A possible starting point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management).

@AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR

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

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

From stuefe at openjdk.org  Mon Jul 11 05:17:07 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 11 Jul 2022 05:17:07 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v5]
In-Reply-To: <YxkFB9_hMSn03DPHSfRmq4gRLNHcgXWHFM1AyKUiY2s=.f78241b8-d0e4-4f86-ae09-ca34cccc6f90@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <YxkFB9_hMSn03DPHSfRmq4gRLNHcgXWHFM1AyKUiY2s=.f78241b8-d0e4-4f86-ae09-ca34cccc6f90@github.com>
Message-ID: <Ia2c6OkeRuJ7lGdhc-eGLUl0uFbC2Eb3uFKVrmO7ctc=.6e8914fd-161a-4c1f-ab32-277cdba22ca0@github.com>

On Sat, 9 Jul 2022 06:49:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
>> 
>> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
>> 
>> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
>> 
>> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
>> 
>> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo

Just nits and questions. I like the test (did not know we have Docker support for tests in jtreg).

src/hotspot/os/posix/perfMemory_posix.cpp line 733:

> 731:   while ((entry = os::readdir(dirp)) != NULL) {
> 732:     const char* filename = entry->d_name;
> 733:     pid_t pid = filename_to_pid(filename);

Pre-existing. An error value of -1 would be somewhat cleaner since strictly speaking pid 0 is a valid PID. (Feel free to ignore this comment)

src/hotspot/os/posix/perfMemory_posix.cpp line 760:

> 758:       // Something wrong happened. Ignore the error and don't try to remove the
> 759:       // file.
> 760:       errno = 0;

Can we have a debug or trace log line here?

src/hotspot/os/posix/perfMemory_posix.cpp line 804:

> 802:     }
> 803: 
> 804:  #if defined(LINUX)

Indentation

src/hotspot/os/posix/perfMemory_posix.cpp line 807:

> 805:     // Hold the lock until here to prevent other JVMs from using this file
> 806:     // while we are in the middle of deleting it.
> 807:     ::close(fd);

I don't understand this comment, it seems to contradict what you are doing. We are closing the only fd referring to this lock file, right? So the lock should get unlocked here too? If we want to keep the lock open, shouldn't we avoid closing the fd?

src/hotspot/os/posix/perfMemory_posix.cpp line 926:

> 924:                               (errno == EWOULDBLOCK) ?
> 925:                               "it is locked by another process" :
> 926:                               "flock() failed");

strerror would be helpful here, or at least errno

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

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

From michaelm at openjdk.org  Mon Jul 11 07:00:45 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 11 Jul 2022 07:00:45 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
Message-ID: <HkJBah90Rykst8JP7axwitZPwaRlj_eHFD0U-wbUK6g=.875e3af1-c0b0-475a-ad0f-bba7d785dc67@github.com>

On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove more unused variables

libnet changes look fine to me

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

Marked as reviewed by michaelm (Reviewer).

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

From chegar at openjdk.org  Mon Jul 11 08:13:45 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 11 Jul 2022 08:13:45 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
Message-ID: <0LufT1j0Gvkv3sFYqCQUR7aBmIU9lHIdOWBHVJyDc-M=.ee7f2980-e54f-4507-9ce3-73378faad4b8@github.com>

On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove more unused variables

LGTM

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

Marked as reviewed by chegar (Reviewer).

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

From sgehwolf at openjdk.org  Mon Jul 11 08:40:46 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Jul 2022 08:40:46 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
Message-ID: <o4hPY2In-ZwmxtN0_R1QwS_m-YkgzacDRA1xQnyoNjA=.eb1eb119-074d-49ac-962d-380d20415b98@github.com>

On Wed, 6 Jul 2022 05:59:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update header
>
> It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API?  I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting getting locked in. A possible starting point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management).

> @AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR

See https://wiki.openjdk.org/display/csr/CSR+FAQs

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

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

From alanb at openjdk.org  Mon Jul 11 09:34:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Jul 2022 09:34:31 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
Message-ID: <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>

On Wed, 6 Jul 2022 05:59:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update header
>
> It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API?  I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting getting locked in. A possible starting point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management).

> @AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR

It's too early to think about a CSR, probably a bit premature to create a PR too because it will take a few iterations to come to agreement on what API to expose, if any.

I don't think this should be a standard API, meaning java.management/java.lang.management.ContainerMXBean is not the right place for this. A JDK-specific MXBean is an option but it would only be usable on Linux and maybe only usable when running in a container environment. Working down, it's not clear to me how stable the attributes are and the mapping to both cgroup v1 and v2. There is also overlap with OperatingSystemMXBean which already defines the "TotalSwapSpaceSize" attribute.  There's another level of detail beyond that with unusual value -2 to distinguish "not available" from "not supported".  So I think there are a few things to think about there. 

Another direction to think about is not exposing an API that you can compile against but instead just register a MBean that provides access to the attributes that are interesting for the container environment. By this I mean ManagementFactory.getPlatformMBeanServer().registerMBean(...). This would be enough to browse the MBean and its attributes in any JMX console and may give you a bit more flexibility to expose attributes that are specific to the cgroup version. I'm not saying this is the right direction, I'm just listing here is something that you could be explored. If the main use case is JMX consoles rather than programmatic access then it may not be too bad.

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

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

From coleenp at openjdk.org  Mon Jul 11 13:11:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 11 Jul 2022 13:11:31 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <e4O1m9UgwgphpjdPzu_JPMkSG5dn52HNHFcu1IEK1s8=.dae503d1-d1fa-4c4e-b3b6-4daca7e6e581@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

Thanks Serguei and Leonid.

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

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

From coleenp at openjdk.org  Mon Jul 11 13:11:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 11 Jul 2022 13:11:31 GMT
Subject: Integrated: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <pZ-QyeoWcffbd2TfIqvEs8_VZTzzWBj-1tWqQX4JGe0=.76fe639c-a0a8-489f-96a8-1e992987ffb7@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: 0c370089
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c37008917789e7b631b5c18e6f54454b1bfe038
Stats:     1484 lines in 99 files changed: 0 ins; 1367 del; 117 mod

8275662: remove test/lib/sun/hotspot

Reviewed-by: mseledtsov, sspitsyn, lmesnik

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

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

From zgu at openjdk.org  Mon Jul 11 14:52:35 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 11 Jul 2022 14:52:35 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v13]
In-Reply-To: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
Message-ID: <cnWh-hlOZT8SuDCXcrZQFcnrg--jctOTcMKo0hJuWn4=.010e2178-7332-4f33-80d4-f933748f8ed6@github.com>

> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
> 
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
> 
> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
> 
> It also performs `commonRef_compact()` only when there are classes unloaded.
> 
> New test failed about 20% without patch, none with patch.
> 
> **Update**
> There are significant changes from early patch. 
> 
> The new approach:
> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
> 
> The new solution breaks up into two steps:
> - Collect all dead object tags with lock
> - Transition to `_in_native` state and post object free events in one batch
> 
> This way, JDI event handler can process object free events upon arrivals without delay.
> 
> **Update 2**
> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
> 
> // This checks for posting and rehashing before operations that
> // this tagmap table.  The calls from a JavaThread only rehash, posting is
> // only done before heap walks.
> void JvmtiTagMap::check_hashmap(bool post_events) {
> 
> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
> Even the events are posted earlier in old code, but they are only processed after next GC cycle.

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Fix test to ensure class unloading

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9168/files
  - new: https://git.openjdk.org/jdk/pull/9168/files/d265b764..b474927a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=11-12

  Stats: 40 lines in 1 file changed: 3 ins; 31 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9168.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168

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

From zgu at openjdk.org  Mon Jul 11 15:00:45 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 11 Jul 2022 15:00:45 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v12]
In-Reply-To: <jwzVChF70ehi09ce7V8tb9rJSsIu8Nib6ujiVwPBpYA=.f7dbd3d1-bcec-4797-ae9c-d4872c3c73c2@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <1miMI1m2VJdL9K2Zfkmz7m3f_VuUwE0B36_8QoV1ha8=.abd05d40-03af-42a7-aa38-85866360f594@github.com>
 <jwzVChF70ehi09ce7V8tb9rJSsIu8Nib6ujiVwPBpYA=.f7dbd3d1-bcec-4797-ae9c-d4872c3c73c2@github.com>
Message-ID: <7tFz8g3Six6b_7Ht6CxIpd-wxOkFH42qRYfnVQ6WV6k=.f12c4335-61a1-436f-926b-c601fba085ea@github.com>

On Fri, 1 Jul 2022 18:36:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporated plummercj's test changes
>
> test/jdk/com/sun/jdi/TestClassUnloadEvents.java line 61:
> 
>> 59:                     return;
>> 60:                 }
>> 61:             }
> 
> I know you were having issues with the test sometimes failing and asked about if the GC's are deterministic, I assume this is the work around for that. My concern is if something were to change and the test started to never get any ClassUnloadEvents, that would go unnoticed. I'd rather you made it so the test failed after exiting this loop, and bump up MAX_RETRY to a high enough number so that we are unlikely to ever see that happen.
> 
> You should also have a look at the runtime/ClassUnload/UnloadTest.java and see how it handles class unloading. It relies on the ClassUnloadCommon library class. One difference I see there is that before doing a System.gc(), it first allocates 16m of memory in 1k chunks to force a young gen collection. I don't understand details of GC collection, but perhaps System.gc() is simply promoting from the youngGen and therefore not freeing any Class instance found there, so you need to promote first and then do the full GC.

Changed to use `ClassUnloadCommon` for triggering class unloading.

> test/jdk/com/sun/jdi/TestClassUnloadEvents.java line 182:
> 
>> 180:                 eventSet.resume();
>> 181:             }
>> 182:         } catch (InterruptedException | VMCannotBeModifiedException | IOException | IllegalConnectorArgumentsException | VMStartException e) {
> 
> I think you should remove the try/catch and just declare that this method throws Exception. That seems to be what other tests are doing.

Done.

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

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

From zgu at openjdk.org  Mon Jul 11 15:00:41 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 11 Jul 2022 15:00:41 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v14]
In-Reply-To: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
Message-ID: <KOdzo7tXkxK964_WgW15mPd1YVrwBD-QlNO6Vb3NpkA=.8b09eef6-d40d-4737-8e98-d625f36576bb@github.com>

> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
> 
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
> 
> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
> 
> It also performs `commonRef_compact()` only when there are classes unloaded.
> 
> New test failed about 20% without patch, none with patch.
> 
> **Update**
> There are significant changes from early patch. 
> 
> The new approach:
> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
> 
> The new solution breaks up into two steps:
> - Collect all dead object tags with lock
> - Transition to `_in_native` state and post object free events in one batch
> 
> This way, JDI event handler can process object free events upon arrivals without delay.
> 
> **Update 2**
> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
> 
> // This checks for posting and rehashing before operations that
> // this tagmap table.  The calls from a JavaThread only rehash, posting is
> // only done before heap walks.
> void JvmtiTagMap::check_hashmap(bool post_events) {
> 
> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
> Even the events are posted earlier in old code, but they are only processed after next GC cycle.

Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge
 - plummercj's comment
 - Fix test to ensure class unloading
 - Incorporated plummercj's test changes
 - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event
 - Moved TestClassUnloadEvents.java to new location
 - Fix test
 - Use Shenandoah GC for debuggee for deterministic
 - debug test
 - Adding log for debugging test failure on Windows
 - ... and 21 more: https://git.openjdk.org/jdk/compare/0c370089...c45dd040

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

Changes: https://git.openjdk.org/jdk/pull/9168/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=13
  Stats: 465 lines in 12 files changed: 237 ins; 146 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/9168.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168

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

From mullan at openjdk.org  Mon Jul 11 18:55:43 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 11 Jul 2022 18:55:43 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <-F3_RMWJoYj6NeLHHLh30W38GT0bktYDwoWP8nUqBR0=.8b7a9bcd-d2aa-4343-98f6-0bd62254eb29@github.com>

On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

A couple of minor comments so far; still reviewing.

src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java line 483:

> 481:             subject.getPrincipals().remove(GIDPrincipal);
> 482:         }
> 483:         if (supplementaryGroups != null) {

This line is harmless, but you could take it out as supplementaryGroups is never null.

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 289:

> 287:             subject.getPrincipals().remove(GIDPrincipal);
> 288:         }
> 289:         if (supplementaryGroups != null) {

This line is harmless, but you could take it out as supplementaryGroups is never null.

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

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

From weijun at openjdk.org  Mon Jul 11 19:54:08 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Jul 2022 19:54:08 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <-F3_RMWJoYj6NeLHHLh30W38GT0bktYDwoWP8nUqBR0=.8b7a9bcd-d2aa-4343-98f6-0bd62254eb29@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <-F3_RMWJoYj6NeLHHLh30W38GT0bktYDwoWP8nUqBR0=.8b7a9bcd-d2aa-4343-98f6-0bd62254eb29@github.com>
Message-ID: <Pxiz_QIweF1r4LPXb0uvYEWmEHJgMORlpXNMvnT7gRw=.271dba19-4a26-4561-a848-674f28fb6cf1@github.com>

On Mon, 11 Jul 2022 18:49:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 289:
> 
>> 287:             subject.getPrincipals().remove(GIDPrincipal);
>> 288:         }
>> 289:         if (supplementaryGroups != null) {
> 
> This line is harmless, but you could take it out as supplementaryGroups is never null.

Yes, in fact, whenever `add()` is called, a `new UnixNumericGroupPrincipal(...)` is added. So it seems there is no need to check the elements inside as well. Same in `JndiLoginModule`. In `NTLoginModule`, while the `groups` array itself can be null, its element is also never null.

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

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

From mullan at openjdk.org  Mon Jul 11 20:32:47 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 11 Jul 2022 20:32:47 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <gZ4Izl3lAA0IAsFT9dgmEGWocMhP4o1lbX-tsQv9urA=.678243f0-3422-4bef-ab91-c866680069bf@github.com>

On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

Changes requested by mullan (Reviewer).

src/java.base/share/classes/javax/security/auth/spi/LoginModule.java line 231:

> 229:      *      before removing it from the Principals or Credentials set
> 230:      *      of a {@code Subject}, otherwise a {@code NullPointerException} will
> 231:      *      be thrown. This is especially important when this method is called

I might also add: "... will be thrown as these sets prohibit null elements." Even better, you could add a hyperlink "these sets prohibit null elements" to the `Subject` constructor which states this.

Also, I recommend updating the `Subject` constructors and clarifying that removing null elements also causes an NPE. Basically update the following sentence (change in italics):

These Sets also prohibit null elements, and attempts to add, *query, or remove* a null element will result in a NullPointerException.

src/java.base/share/classes/javax/security/auth/spi/LoginModule.java line 231:

> 229:      *      before removing it from the Principals or Credentials set
> 230:      *      of a {@code Subject}, otherwise a {@code NullPointerException} will
> 231:      *      be thrown. This is especially important when this method is called

s/when/if/

test/jdk/javax/security/auth/login/modules/SafeLogout.java line 37:

> 35:  * @bug 8282730
> 36:  * @key randomness
> 37:  * @summary LdapLoginModule throw NPE from logout method after login failure

I think the summary can be more descriptive here and doesn't have to match the bug description. How about "Check that all LoginModule implementations don't throw NPE from logout method after login failure"

test/jdk/javax/security/auth/login/modules/SafeLogout.java line 51:

> 49: 
> 50:     static void test(int pos) throws Exception {
> 51:         // Create random JAAS login config.

I'm probably missing something obvious, but can you explain why this test uses a random login config? I would add some comments explaining that more.

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

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

From weijun at openjdk.org  Mon Jul 11 21:05:57 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Jul 2022 21:05:57 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <gZ4Izl3lAA0IAsFT9dgmEGWocMhP4o1lbX-tsQv9urA=.678243f0-3422-4bef-ab91-c866680069bf@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <gZ4Izl3lAA0IAsFT9dgmEGWocMhP4o1lbX-tsQv9urA=.678243f0-3422-4bef-ab91-c866680069bf@github.com>
Message-ID: <UwPcRFlhBb7-naf8td6hPCL9g3XXpLCAwjyIl2ECoHY=.873b96f3-d217-477d-8aab-72038b6867db@github.com>

On Mon, 11 Jul 2022 20:09:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.
>
> test/jdk/javax/security/auth/login/modules/SafeLogout.java line 37:
> 
>> 35:  * @bug 8282730
>> 36:  * @key randomness
>> 37:  * @summary LdapLoginModule throw NPE from logout method after login failure
> 
> I think the summary can be more descriptive here and doesn't have to match the bug description. How about "Check that all LoginModule implementations don't throw NPE from logout method after login failure"

OK.

> test/jdk/javax/security/auth/login/modules/SafeLogout.java line 51:
> 
>> 49: 
>> 50:     static void test(int pos) throws Exception {
>> 51:         // Create random JAAS login config.
> 
> I'm probably missing something obvious, but can you explain why this test uses a random login config? I would add some comments explaining that more.

I cannot find a way to test all combinations so I make it random. If it really fails I make sure the login module name, flag, and whether there is a login attempt are printed out so I can reproduce it.

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

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

From mullan at openjdk.org  Mon Jul 11 21:20:39 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 11 Jul 2022 21:20:39 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <Pxiz_QIweF1r4LPXb0uvYEWmEHJgMORlpXNMvnT7gRw=.271dba19-4a26-4561-a848-674f28fb6cf1@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <-F3_RMWJoYj6NeLHHLh30W38GT0bktYDwoWP8nUqBR0=.8b7a9bcd-d2aa-4343-98f6-0bd62254eb29@github.com>
 <Pxiz_QIweF1r4LPXb0uvYEWmEHJgMORlpXNMvnT7gRw=.271dba19-4a26-4561-a848-674f28fb6cf1@github.com>
Message-ID: <57gnKKoaEwrb6gmhLtqoKQ0NujbJDGrPfSZh6-vNemA=.0cd1be66-ae3f-415a-bc52-6ba1be8e0f93@github.com>

On Mon, 11 Jul 2022 19:49:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 289:
>> 
>>> 287:             subject.getPrincipals().remove(GIDPrincipal);
>>> 288:         }
>>> 289:         if (supplementaryGroups != null) {
>> 
>> This line is harmless, but you could take it out as supplementaryGroups is never null.
>
> Yes, in fact, whenever `add()` is called, a `new UnixNumericGroupPrincipal(...)` is added. So it seems there is no need to check the elements inside as well. Same in `JndiLoginModule`. In `NTLoginModule`, while the `groups` array itself can be null, its element is also never null.

Right, agreed.

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

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

From weijun at openjdk.org  Mon Jul 11 21:42:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Jul 2022 21:42:47 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v2]
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <1ZHEi8CMhofV9fyWUc5peKwyEkjkpkY__iIiwtSv_A4=.5505724e-a98d-4300-9172-8a546abd92d6@github.com>

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:

 - null not in code
 - sean comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9348/files
  - new: https://git.openjdk.org/jdk/pull/9348/files/b3e1f541..810a0114

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

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

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

From weijun at openjdk.org  Mon Jul 11 21:42:49 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Jul 2022 21:42:49 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <jI94De9wTeVEx_Y9s-EqIANIF-XBqDCE8xC19KlHDSQ=.22b853cf-78c7-475f-84c7-024f6ef74863@github.com>

On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

New commits pushed. BTW, in the 2nd one, I reverted some `{@code null}` changes since it looks like "null" is used as an adjective here instead of a Java keyword. The same style appears multiple times in other places.

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

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

From amenkov at openjdk.org  Mon Jul 11 22:35:00 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 11 Jul 2022 22:35:00 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v4]
In-Reply-To: <qL21TS4oaG4bzgjZehy5w8F0lshTiF-wAvQqDOQ6vY8=.a9a75dd6-5cd7-4804-bfa0-4713bc3db76b@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
 <qL21TS4oaG4bzgjZehy5w8F0lshTiF-wAvQqDOQ6vY8=.a9a75dd6-5cd7-4804-bfa0-4713bc3db76b@github.com>
Message-ID: <0XxpqCm2cbRJ0iM2Cn-1ykKmh4xU8dqGQpZIe350zBg=.22570eee-d54f-47a9-8e85-30993a0d90e5@github.com>

On Sun, 10 Jul 2022 10:12:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 
>> 
>> In short, the deadlock dependencies are:
>> 
>> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
>> - The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
>> - The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.
>> 
>> Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 
>> 
>> Testing: submitted mach5 job with 100 runs on 3 debug platforms.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing white space

Looks good

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

Marked as reviewed by amenkov (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/129

From lmesnik at openjdk.org  Mon Jul 11 22:47:03 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 11 Jul 2022 22:47:03 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v4]
In-Reply-To: <qL21TS4oaG4bzgjZehy5w8F0lshTiF-wAvQqDOQ6vY8=.a9a75dd6-5cd7-4804-bfa0-4713bc3db76b@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
 <qL21TS4oaG4bzgjZehy5w8F0lshTiF-wAvQqDOQ6vY8=.a9a75dd6-5cd7-4804-bfa0-4713bc3db76b@github.com>
Message-ID: <S4-Q8UXHJ1U6wS3bJQjSpEU-T7d-1JKRWrnjOwFK1IM=.d593fba6-cd29-4e5e-9db2-cf81e6cdb57e@github.com>

On Sun, 10 Jul 2022 10:12:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 
>> 
>> In short, the deadlock dependencies are:
>> 
>> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
>> - The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
>> - The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.
>> 
>> Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 
>> 
>> Testing: submitted mach5 job with 100 runs on 3 debug platforms.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing white space

Looks good, assumint

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/libframepop02.cpp line 78:

> 76: 
> 77:   bool result = strncmp(inf.name, TEST_THREAD_NAME_BASE, strlen(TEST_THREAD_NAME_BASE)) == 0;
> 78:   jvmti->Deallocate((unsigned char *)inf.name);

Optional, we have 'deallocate' method in './jdk/test/lib/jvmti/jvmti_common.h' which check error status.

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

Marked as reviewed by lmesnik (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/129

From sspitsyn at openjdk.org  Mon Jul 11 22:47:05 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 11 Jul 2022 22:47:05 GMT
Subject: [jdk19] Integrated: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions
In-Reply-To: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
Message-ID: <uVJEcIDK0VXf5CtQVPnviYe7mcJWmZW__d2pIOEeN_c=.2184f137-d7f2-4f72-bf41-3b147ac7a6e5@github.com>

On Sat, 9 Jul 2022 06:43:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 
> 
> In short, the deadlock dependencies are:
> 
> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
> - The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
> - The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.
> 
> Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 
> 
> Testing: submitted mach5 job with 100 runs on 3 debug platforms.

This pull request has now been integrated.

Changeset: c3806b93
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/c3806b93c48f826e940eecd0ba29995d7f0c796b
Stats:     13 lines in 2 files changed: 8 ins; 0 del; 5 mod

8289709: fatal error: stuck in JvmtiVTMSTransitionDisabler::disable_VTMS_transitions

Reviewed-by: alanb, amenkov, lmesnik

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

PR: https://git.openjdk.org/jdk19/pull/129

From sspitsyn at openjdk.org  Mon Jul 11 22:47:03 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 11 Jul 2022 22:47:03 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v4]
In-Reply-To: <qL21TS4oaG4bzgjZehy5w8F0lshTiF-wAvQqDOQ6vY8=.a9a75dd6-5cd7-4804-bfa0-4713bc3db76b@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
 <qL21TS4oaG4bzgjZehy5w8F0lshTiF-wAvQqDOQ6vY8=.a9a75dd6-5cd7-4804-bfa0-4713bc3db76b@github.com>
Message-ID: <TzqeCQs1UjxuC0ardll36PObauvTLmgVGCBXqLlWtl8=.1db79755-8186-43d3-8a9c-3f48deb55a4b@github.com>

On Sun, 10 Jul 2022 10:12:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a test bug. The test should filter out non-tested threads to avoid generating such kind of deadlocks. 
>> 
>> In short, the deadlock dependencies are:
>> 
>> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry` event callback which grabbed the `agent_lock` raw monitor and calls JVM TI `GetFrameCount`. The `GetFrameCount` is blocked in disabling VTMS transitions because the `ForkJoinPool-1-worker-2` is at a mount (VTMS) transition.
>> - The `ForkJoinPool-1-worker-2` is at mount (VTMS) transition and blocked in `java.lang.ref.NativeReferenceQueue.poll()` when acquiring the `NativeReferenceQueue` lock which is held by the `Reference Handler` thread.
>> - The `Reference Handler` thread grabbed the `NativeReferenceQueue` lock and is entering the `signal()` method. It triggered a JVM TI `MethodEntry` event. The JVM TI agent `MethodEntry` event callback is blocked on grabbing the `agent_lock` raw monitor which is held by the `Common-Cleaner` thread.
>> 
>> Also, the `timeout=360 `is explicitly set to avoid frequent timeouts in locals runs. 
>> 
>> Testing: submitted mach5 job with 100 runs on 3 debug platforms.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing white space

Alan and Alex, thank you for reviews!

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

PR: https://git.openjdk.org/jdk19/pull/129

From cjplummer at openjdk.org  Mon Jul 11 22:53:56 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 11 Jul 2022 22:53:56 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v14]
In-Reply-To: <KOdzo7tXkxK964_WgW15mPd1YVrwBD-QlNO6Vb3NpkA=.8b09eef6-d40d-4737-8e98-d625f36576bb@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <KOdzo7tXkxK964_WgW15mPd1YVrwBD-QlNO6Vb3NpkA=.8b09eef6-d40d-4737-8e98-d625f36576bb@github.com>
Message-ID: <JKEH4QH7MrUUkbuKqoDjBPa7GJfALrpOQvO6ubAZMDM=.abaa176c-3360-44b8-872b-b79ff814b736@github.com>

On Mon, 11 Jul 2022 15:00:41 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge
>  - plummercj's comment
>  - Fix test to ensure class unloading
>  - Incorporated plummercj's test changes
>  - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event
>  - Moved TestClassUnloadEvents.java to new location
>  - Fix test
>  - Use Shenandoah GC for debuggee for deterministic
>  - debug test
>  - Adding log for debugging test failure on Windows
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/0c370089...c45dd040

The changes look good to me. Thanks for all your work on this!

I think @coleenp  and @sspitsyn  should give the JVMTI changes another look since it has been reworked since they last reviewed the code.

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

Marked as reviewed by cjplummer (Reviewer).

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

From cjplummer at openjdk.org  Mon Jul 11 23:24:00 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 11 Jul 2022 23:24:00 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v14]
In-Reply-To: <KOdzo7tXkxK964_WgW15mPd1YVrwBD-QlNO6Vb3NpkA=.8b09eef6-d40d-4737-8e98-d625f36576bb@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <KOdzo7tXkxK964_WgW15mPd1YVrwBD-QlNO6Vb3NpkA=.8b09eef6-d40d-4737-8e98-d625f36576bb@github.com>
Message-ID: <saSCe88_3chngBoTaooKHPFBZ9tHKmCibxwO7yBE_es=.f755966a-d5a4-4b95-a692-e3a6682da92d@github.com>

On Mon, 11 Jul 2022 15:00:41 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge
>  - plummercj's comment
>  - Fix test to ensure class unloading
>  - Incorporated plummercj's test changes
>  - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event
>  - Moved TestClassUnloadEvents.java to new location
>  - Fix test
>  - Use Shenandoah GC for debuggee for deterministic
>  - debug test
>  - Adding log for debugging test failure on Windows
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/0c370089...c45dd040

Actually I have one minor request. Rename the test to ClassUnloadEventTest.java to be consistent with other test names in the directory.

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

Changes requested by cjplummer (Reviewer).

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

From zgu at openjdk.org  Tue Jul 12 01:44:28 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 12 Jul 2022 01:44:28 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v15]
In-Reply-To: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
Message-ID: <m75YMxa685vxd3hnuE_8JLWcx3BMHkEZwhZ1OeUKJNc=.2fa009fb-3b63-4760-a194-3099227f3f54@github.com>

> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
> 
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
> 
> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
> 
> It also performs `commonRef_compact()` only when there are classes unloaded.
> 
> New test failed about 20% without patch, none with patch.
> 
> **Update**
> There are significant changes from early patch. 
> 
> The new approach:
> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
> 
> The new solution breaks up into two steps:
> - Collect all dead object tags with lock
> - Transition to `_in_native` state and post object free events in one batch
> 
> This way, JDI event handler can process object free events upon arrivals without delay.
> 
> **Update 2**
> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
> 
> // This checks for posting and rehashing before operations that
> // this tagmap table.  The calls from a JavaThread only rehash, posting is
> // only done before heap walks.
> void JvmtiTagMap::check_hashmap(bool post_events) {
> 
> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
> Even the events are posted earlier in old code, but they are only processed after next GC cycle.

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Rename test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9168/files
  - new: https://git.openjdk.org/jdk/pull/9168/files/c45dd040..92056334

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=13-14

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

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

From cjplummer at openjdk.org  Tue Jul 12 03:29:41 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Jul 2022 03:29:41 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v15]
In-Reply-To: <m75YMxa685vxd3hnuE_8JLWcx3BMHkEZwhZ1OeUKJNc=.2fa009fb-3b63-4760-a194-3099227f3f54@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <m75YMxa685vxd3hnuE_8JLWcx3BMHkEZwhZ1OeUKJNc=.2fa009fb-3b63-4760-a194-3099227f3f54@github.com>
Message-ID: <DSsYTM-1v55Y0NhSi8VfcRNIKSpcFcZx5sTgMK0PmQA=.1d835903-0a1d-4a93-8a3f-80c92844a456@github.com>

On Tue, 12 Jul 2022 01:44:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test

`vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/TestDescription.java` is failing for me on about 40% of test runs on all platforms. I'm looking into it now. Can you see if you can reproduce it?

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

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

From cjplummer at openjdk.org  Tue Jul 12 03:44:48 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Jul 2022 03:44:48 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v15]
In-Reply-To: <m75YMxa685vxd3hnuE_8JLWcx3BMHkEZwhZ1OeUKJNc=.2fa009fb-3b63-4760-a194-3099227f3f54@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <m75YMxa685vxd3hnuE_8JLWcx3BMHkEZwhZ1OeUKJNc=.2fa009fb-3b63-4760-a194-3099227f3f54@github.com>
Message-ID: <jjQ0sgtDFA2sYWmGp-N_2p7PR9HHvtI108UfI11uG_c=.b5327a4d-2eee-4c90-add3-4859d83c43b5@github.com>

On Tue, 12 Jul 2022 01:44:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test

CASE #4:
Allocating objects...
Start thread and making garbage collection
thread4 started.
- ap04t001.cpp, 326: Calling IterateOverInstancesOfClass...
- ap04t001.cpp, 254:   run: ForceGarbageCollection
- ap04t001.cpp, 333: IterateOverInstancesOfClass finished.
- ap04t001.cpp, 335: Iterations count: 100000
- ap04t001.cpp, 336: Events count: 0
- ap04t001.cpp, 339: Errors detected: 0
- ap04t001.cpp, 228:   event: GarbageCollectionStart
- ap04t001.cpp, 234:   event: GarbageCollectionFinish
thread4 finished.
All objects collected
Wait for thread to finish
CASE #4 finished.

- ap04t001.cpp, 431: Let debugee to finish
The following fake exception stacktrace is for failure analysis. 
nsk.share.Fake_Exception_for_RULE_Creation: (ap04t001.cpp:75) jvmti->RawMonitorExit(counterMonitor_ptr)
	at nsk_lvcomplain(nsk_tools.cpp:172)
# ERROR: ap04t001.cpp, 75: jvmti->RawMonitorExit(counterMonitor_ptr)
#   jvmti error: code=50, name=JVMTI_ERROR_INVALID_MONITOR
# ERROR: ap04t001.cpp, 69: jvmti->RawMonitorEnter(counterMonitor_ptr)
#   jvmti error: code=50, name=JVMTI_ERROR_INVALID_MONITOR


And these two ERRORs get repeated a large number of times. I think this is likely a test bug. It probably is freeing the monitor before heap iterating is complete. I'm just not sure how it relates to your JVMTI changes.

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

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

From cjplummer at openjdk.org  Tue Jul 12 06:33:52 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Jul 2022 06:33:52 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v15]
In-Reply-To: <m75YMxa685vxd3hnuE_8JLWcx3BMHkEZwhZ1OeUKJNc=.2fa009fb-3b63-4760-a194-3099227f3f54@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <m75YMxa685vxd3hnuE_8JLWcx3BMHkEZwhZ1OeUKJNc=.2fa009fb-3b63-4760-a194-3099227f3f54@github.com>
Message-ID: <R5BMQabjsPujJV6Agrc0aQg4bOiyvo2LRqDxZI51mRE=.40089b0e-03d3-419f-a39a-cd50eac4ffb8@github.com>

On Tue, 12 Jul 2022 01:44:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test

It seems during test shutdown, ObjectFree events are being delivered after JVMTI events have been disabled:


    nsk_jvmti_enableEvents(JVMTI_DISABLE, eventsCount, events, NULL);

    NSK_TRACE(jni->DeleteGlobalRef(debugeeClass));
    NSK_TRACE(jvmti->DestroyRawMonitor(counterMonitor_ptr));

    NSK_DISPLAY0("Let debugee to finish\n");


The first line is disabling events. A couple statements later the monitor is freed. After that a printf that we are seeing in the output. After the printf the ObjectFree events arrives and we try to use the freed monitor. Here's the stack trace when the event arrives (I got this by inserting an assert(0)):



#4  0x00007f451f6752af in increaseCounter (counterPtr=0x7f451f699ad8 <eventCount>) at /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S8484/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/fa6bd5a2-99f3-402f-b5bb-613077cc393c/runs/f384ea29-cdca-4da9-887c-7f0c9eff2c41/workspace/open/test/hotspot/jtreg/vmTestbase/nsk/share/native/JVMTITools.cpp:71
#5  0x00007f451dc10f13 in JvmtiExport::post_object_free(JvmtiEnv*, GrowableArray<long>*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
#6  0x00007f451dc4772d in JvmtiTagMap::post_dead_objects(GrowableArray<long>*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
#7  0x00007f451dc4804a in JvmtiTagMap::remove_and_post_dead_objects() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
#8  0x00007f451dc48615 in JvmtiTagMap::flush_all_object_free_events() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
#9  0x00007f451e15ed93 in ServiceThread::service_thread_entry(JavaThread*, JavaThread*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
#10 0x00007f451d8ff948 in JavaThread::thread_main_inner() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
#11 0x00007f451e31ec20 in Thread::call_run() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
#12 0x00007f451dfe1ef4 in thread_native_entry(Thread*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
#13 0x00007f451f17d1df in start_thread () from /lib64/libpthread.so.0
#14 0x00007f451ebe5dd3 in clone () from /lib64/libc.so.6


It's a little misleading because of some inlining. Here's the actual ObjectFree callback:


void JNICALL
ObjectFree(jvmtiEnv *jvmti_env, jlong tag) {
    increaseCounter(&eventCount);
//    NSK_DISPLAY0("  event: ObjectFree\n");
}


I'm a bit less sure now that this is a test bug. I wonder if some JVMTI synchronization is now being bypassed that would normally have blocked the test when it tried to disable events, and not allow the disabling until the ObjectFree events had all finished being posted.

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

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

From djelinski at openjdk.org  Tue Jul 12 11:34:43 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 12 Jul 2022 11:34:43 GMT
Subject: Integrated: 8289768: Clean up unused code
In-Reply-To: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
Message-ID: <fcOcK4urRUx8yHC5j19TBmdIOnwWsM_OrGjKl8gKkrE=.69dd372d-d6d4-463a-8eff-8c69dc5f3eee@github.com>

On Tue, 5 Jul 2022 20:19:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
> 
> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
> 
> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.

This pull request has now been integrated.

Changeset: 04c47da1
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04c47da118b2870d1c7525348a2ffdf9cd1cc0a4
Stats:     98 lines in 46 files changed: 0 ins; 69 del; 29 mod

8289768: Clean up unused code

Reviewed-by: dfuchs, lancea, weijun, naoto, cjplummer, alanb, michaelm, chegar

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

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

From zgu at openjdk.org  Tue Jul 12 17:02:54 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 12 Jul 2022 17:02:54 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v16]
In-Reply-To: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
Message-ID: <5Sv0tR7UtkxVEizjvNfMw5NsOX7n7pj6cTHyVYIsqj4=.daf4abce-96de-4f45-a318-5d187f07209f@github.com>

> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
> 
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
> 
> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
> 
> It also performs `commonRef_compact()` only when there are classes unloaded.
> 
> New test failed about 20% without patch, none with patch.
> 
> **Update**
> There are significant changes from early patch. 
> 
> The new approach:
> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
> 
> The new solution breaks up into two steps:
> - Collect all dead object tags with lock
> - Transition to `_in_native` state and post object free events in one batch
> 
> This way, JDI event handler can process object free events upon arrivals without delay.
> 
> **Update 2**
> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
> 
> // This checks for posting and rehashing before operations that
> // this tagmap table.  The calls from a JavaThread only rehash, posting is
> // only done before heap walks.
> void JvmtiTagMap::check_hashmap(bool post_events) {
> 
> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
> Even the events are posted earlier in old code, but they are only processed after next GC cycle.

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Fix race

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9168/files
  - new: https://git.openjdk.org/jdk/pull/9168/files/92056334..6f14f452

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=14-15

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

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

From sspitsyn at openjdk.org  Tue Jul 12 17:13:56 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 12 Jul 2022 17:13:56 GMT
Subject: [jdk19] RFR: 8289709: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::disable_VTMS_transitions [v4]
In-Reply-To: <S4-Q8UXHJ1U6wS3bJQjSpEU-T7d-1JKRWrnjOwFK1IM=.d593fba6-cd29-4e5e-9db2-cf81e6cdb57e@github.com>
References: <63nnjhT19WAWbf3sbA5reQzgJp2V-N5sGK4TODZsWnY=.0afaa45b-a65b-4d1e-8f4b-b1ceb2385b68@github.com>
 <qL21TS4oaG4bzgjZehy5w8F0lshTiF-wAvQqDOQ6vY8=.a9a75dd6-5cd7-4804-bfa0-4713bc3db76b@github.com>
 <S4-Q8UXHJ1U6wS3bJQjSpEU-T7d-1JKRWrnjOwFK1IM=.d593fba6-cd29-4e5e-9db2-cf81e6cdb57e@github.com>
Message-ID: <TfkiA01ZPRwvTHoEuSLgn1u-ZiPt-v5DkiEDcozGR1E=.725cedec-58cd-418e-a18a-286e60652cdc@github.com>

On Mon, 11 Jul 2022 22:41:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove trailing white space
>
> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/libframepop02.cpp line 78:
> 
>> 76: 
>> 77:   bool result = strncmp(inf.name, TEST_THREAD_NAME_BASE, strlen(TEST_THREAD_NAME_BASE)) == 0;
>> 78:   jvmti->Deallocate((unsigned char *)inf.name);
> 
> Optional, we have 'deallocate' method in './jdk/test/lib/jvmti/jvmti_common.h' which check error status.

Leonid, thank you for review. Yes, I know it. But there are other places with Deallocate. I decided to keep it consistent and avoid touching other spots to avoid unnecessary risk.

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

PR: https://git.openjdk.org/jdk19/pull/129

From jwilhelm at openjdk.org  Tue Jul 12 13:02:41 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 12 Jul 2022 13:02:41 GMT
Subject: RFR: Merge jdk19
Message-ID: <2YZUprz-2ZGbx7u2i3jBdnvJby6P1U10AT5PdRGBUpw=.6e72a7ee-78fc-4c77-bfee-0d0175c3be4c@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM
 - 8289709: fatal error: stuck in JvmtiVTMSTransitionDisabler::disable_VTMS_transitions
 - 8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows
 - 8287379: Using @inheritDoc in an inapplicable context shouldn't crash javadoc
 - 8287809: Revisit implementation of memory session

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9467&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9467&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9467/files
  Stats: 1307 lines in 41 files changed: 485 ins; 330 del; 492 mod
  Patch: https://git.openjdk.org/jdk/pull/9467.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9467/head:pull/9467

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

From zgu at openjdk.org  Tue Jul 12 13:13:49 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 12 Jul 2022 13:13:49 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v15]
In-Reply-To: <R5BMQabjsPujJV6Agrc0aQg4bOiyvo2LRqDxZI51mRE=.40089b0e-03d3-419f-a39a-cd50eac4ffb8@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <m75YMxa685vxd3hnuE_8JLWcx3BMHkEZwhZ1OeUKJNc=.2fa009fb-3b63-4760-a194-3099227f3f54@github.com>
 <R5BMQabjsPujJV6Agrc0aQg4bOiyvo2LRqDxZI51mRE=.40089b0e-03d3-419f-a39a-cd50eac4ffb8@github.com>
Message-ID: <tRg_VeQ3zjmwsNPhdF4pEV_mw54hI0d2VfYgWNh9j98=.70b2e5c2-ab63-4e52-979a-b9bdd07ce5e6@github.com>

On Tue, 12 Jul 2022 06:31:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> post_object_free

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

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

From zgu at openjdk.org  Tue Jul 12 14:31:50 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 12 Jul 2022 14:31:50 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v15]
In-Reply-To: <R5BMQabjsPujJV6Agrc0aQg4bOiyvo2LRqDxZI51mRE=.40089b0e-03d3-419f-a39a-cd50eac4ffb8@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <m75YMxa685vxd3hnuE_8JLWcx3BMHkEZwhZ1OeUKJNc=.2fa009fb-3b63-4760-a194-3099227f3f54@github.com>
 <R5BMQabjsPujJV6Agrc0aQg4bOiyvo2LRqDxZI51mRE=.40089b0e-03d3-419f-a39a-cd50eac4ffb8@github.com>
Message-ID: <IhOR-pH3R7bzOLcy033DRDMFg6xeuk5Qcq_F9rDMaB0=.ec795bb5-37eb-4e58-8131-14cccdfd447e@github.com>

On Tue, 12 Jul 2022 06:31:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> It seems during test shutdown, ObjectFree events are being delivered after JVMTI events have been disabled:
> 
> ```
>     nsk_jvmti_enableEvents(JVMTI_DISABLE, eventsCount, events, NULL);
> 
>     NSK_TRACE(jni->DeleteGlobalRef(debugeeClass));
>     NSK_TRACE(jvmti->DestroyRawMonitor(counterMonitor_ptr));
> 
>     NSK_DISPLAY0("Let debugee to finish\n");
> ```
> 
> The first line is disabling events. A couple statements later the monitor is freed. After that a printf that we are seeing in the output. After the printf the ObjectFree events arrives and we try to use the freed monitor. Here's the stack trace when the event arrives (I got this by inserting an assert(0)):
> 
> ```
> #4  0x00007f451f6752af in increaseCounter (counterPtr=0x7f451f699ad8 <eventCount>) at /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S8484/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/fa6bd5a2-99f3-402f-b5bb-613077cc393c/runs/f384ea29-cdca-4da9-887c-7f0c9eff2c41/workspace/open/test/hotspot/jtreg/vmTestbase/nsk/share/native/JVMTITools.cpp:71
> #5  0x00007f451dc10f13 in JvmtiExport::post_object_free(JvmtiEnv*, GrowableArray<long>*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> #6  0x00007f451dc4772d in JvmtiTagMap::post_dead_objects(GrowableArray<long>*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> #7  0x00007f451dc4804a in JvmtiTagMap::remove_and_post_dead_objects() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> #8  0x00007f451dc48615 in JvmtiTagMap::flush_all_object_free_events() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> #9  0x00007f451e15ed93 in ServiceThread::service_thread_entry(JavaThread*, JavaThread*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> #10 0x00007f451d8ff948 in JavaThread::thread_main_inner() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> #11 0x00007f451e31ec20 in Thread::call_run() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> #12 0x00007f451dfe1ef4 in thread_native_entry(Thread*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> #13 0x00007f451f17d1df in start_thread () from /lib64/libpthread.so.0
> #14 0x00007f451ebe5dd3 in clone () from /lib64/libc.so.6
> ```
> 
> It's a little misleading because of some inlining. Here's the actual ObjectFree callback:
> 
> ```
> void JNICALL
> ObjectFree(jvmtiEnv *jvmti_env, jlong tag) {
>     increaseCounter(&eventCount);
> //    NSK_DISPLAY0("  event: ObjectFree\n");
> }
> ```
> 
> I'm a bit less sure now that this is a test bug. I wonder if some JVMTI synchronization is now being bypassed that would normally have blocked the test when it tried to disable events, and not allow the disabling until the ObjectFree events had all finished being posted.

I am perplexed where is the synchronization, I believe, there is none. 

We were lucky to avoid this failure due to the test disables `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` along with `JVMTI_EVENT_OBJECT_FREE` at once. The old implementation was depending on `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` to flush `JVMTI_EVENT_OBJECT_FREE` events and `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` event is posted at safepoint, that gives illusion of synchronization.

I believe enabling/disabling events are always asynchronous vs posting them. Further more, setting event bits seems to require `JvmtiThreadState_lock` while reading does not.

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

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

From mullan at openjdk.org  Tue Jul 12 14:59:46 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Jul 2022 14:59:46 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v2]
In-Reply-To: <UwPcRFlhBb7-naf8td6hPCL9g3XXpLCAwjyIl2ECoHY=.873b96f3-d217-477d-8aab-72038b6867db@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <gZ4Izl3lAA0IAsFT9dgmEGWocMhP4o1lbX-tsQv9urA=.678243f0-3422-4bef-ab91-c866680069bf@github.com>
 <UwPcRFlhBb7-naf8td6hPCL9g3XXpLCAwjyIl2ECoHY=.873b96f3-d217-477d-8aab-72038b6867db@github.com>
Message-ID: <yEmSqmAaJeSsF6Tt32y91f7XXLFnQsst5nl2_bXUXwk=.7be090a8-0901-4e91-84ee-6f2db92e4a80@github.com>

On Mon, 11 Jul 2022 21:03:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/javax/security/auth/login/modules/SafeLogout.java line 51:
>> 
>>> 49: 
>>> 50:     static void test(int pos) throws Exception {
>>> 51:         // Create random JAAS login config.
>> 
>> I'm probably missing something obvious, but can you explain why this test uses a random login config? I would add some comments explaining that more.
>
> I cannot find a way to test all combinations so I make it random. If it really fails I make sure the login module name, flag, and whether there is a login attempt are printed out so I can reproduce it.

Why isn't it sufficient to just call logout once per each login module?

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

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

From poonam at openjdk.org  Tue Jul 12 15:46:50 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Tue, 12 Jul 2022 15:46:50 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
 <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>
Message-ID: <6AYtk3v3G_rDM1u4yz_Kio5qZyHa0WCUy_JRZoL6xnI=.3883d4c3-df6f-4b1f-8d52-6ab37fbb6ef9@github.com>

On Mon, 11 Jul 2022 09:30:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API?  I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting getting locked in. A possible starting point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management).
>
>> @AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR
> 
> It's too early to think about a CSR, probably a bit premature to create a PR too because it will take a few iterations to come to agreement on what API to expose, if any.
> 
> I don't think this should be a standard API, meaning java.management/java.lang.management.ContainerMXBean is not the right place for this. A JDK-specific MXBean is an option but it would only be usable on Linux and maybe only usable when running in a container environment. Working down, it's not clear to me how stable the attributes are and the mapping to both cgroup v1 and v2. There is also overlap with OperatingSystemMXBean which already defines the "TotalSwapSpaceSize" attribute.  There's another level of detail beyond that with unusual value -2 to distinguish "not available" from "not supported".  So I think there are a few things to think about there. 
> 
> Another direction to think about is not exposing an API that you can compile against but instead just register a MBean that provides access to the attributes that are interesting for the container environment. By this I mean ManagementFactory.getPlatformMBeanServer().registerMBean(...). This would be enough to browse the MBean and its attributes in any JMX console and may give you a bit more flexibility to expose attributes that are specific to the cgroup version. I'm not saying this is the right direction, I'm just listing it here as something that could be explored. If the main use case is JMX consoles rather than programmatic access then it may not be too bad.

@AlanBateman OperatingSystemMXBean makes the CPU and Memory related information for a process available regardless of whether that process is running in a native operating system environment or a containerized environment. It does not provide container configuration information such as its provider (crgoups v1 or v2), CPU shares, CPU quota etc, which can be useful for monitoring and troubleshooting purposes.

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

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

From alanb at openjdk.org  Tue Jul 12 15:52:42 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Jul 2022 15:52:42 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
 <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>
Message-ID: <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com>

On Mon, 11 Jul 2022 09:30:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API?  I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting getting locked in. A possible starting point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management).
>
>> @AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR
> 
> It's too early to think about a CSR, probably a bit premature to create a PR too because it will take a few iterations to come to agreement on what API to expose, if any.
> 
> I don't think this should be a standard API, meaning java.management/java.lang.management.ContainerMXBean is not the right place for this. A JDK-specific MXBean is an option but it would only be usable on Linux and maybe only usable when running in a container environment. Working down, it's not clear to me how stable the attributes are and the mapping to both cgroup v1 and v2. There is also overlap with OperatingSystemMXBean which already defines the "TotalSwapSpaceSize" attribute.  There's another level of detail beyond that with unusual value -2 to distinguish "not available" from "not supported".  So I think there are a few things to think about there. 
> 
> Another direction to think about is not exposing an API that you can compile against but instead just register a MBean that provides access to the attributes that are interesting for the container environment. By this I mean ManagementFactory.getPlatformMBeanServer().registerMBean(...). This would be enough to browse the MBean and its attributes in any JMX console and may give you a bit more flexibility to expose attributes that are specific to the cgroup version. I'm not saying this is the right direction, I'm just listing it here as something that could be explored. If the main use case is JMX consoles rather than programmatic access then it may not be too bad.

> @AlanBateman OperatingSystemMXBean makes the CPU and Memory related information for a process available regardless of whether that process is running in a native operating system environment or a containerized environment. It does not provide container configuration information such as its provider (crgoups v1 or v2), CPU shares, CPU quota etc, which can be useful for monitoring and troubleshooting purposes.

Yes, I know this but I think there is a lot more thought required before deciding to augment this with another API for the container environment. There are a couple of things to explore.

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

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

From jwilhelm at openjdk.org  Tue Jul 12 16:19:46 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 12 Jul 2022 16:19:46 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <2YZUprz-2ZGbx7u2i3jBdnvJby6P1U10AT5PdRGBUpw=.6e72a7ee-78fc-4c77-bfee-0d0175c3be4c@github.com>
References: <2YZUprz-2ZGbx7u2i3jBdnvJby6P1U10AT5PdRGBUpw=.6e72a7ee-78fc-4c77-bfee-0d0175c3be4c@github.com>
Message-ID: <bXTUMdJE-t4sgtC_7X1IGfKJhBCExVhyUFq_apnaLaw=.c5116b7c-882d-45cb-9b9c-f50df915be1a@github.com>

On Tue, 12 Jul 2022 12:53:58 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: d9ca438d
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9ca438d06166f153d11bb55c9ec672fc63c0e9e
Stats:     1307 lines in 41 files changed: 485 ins; 330 del; 492 mod

Merge

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

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

From zgu at openjdk.org  Tue Jul 12 19:32:15 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 12 Jul 2022 19:32:15 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v15]
In-Reply-To: <IhOR-pH3R7bzOLcy033DRDMFg6xeuk5Qcq_F9rDMaB0=.ec795bb5-37eb-4e58-8131-14cccdfd447e@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <m75YMxa685vxd3hnuE_8JLWcx3BMHkEZwhZ1OeUKJNc=.2fa009fb-3b63-4760-a194-3099227f3f54@github.com>
 <R5BMQabjsPujJV6Agrc0aQg4bOiyvo2LRqDxZI51mRE=.40089b0e-03d3-419f-a39a-cd50eac4ffb8@github.com>
 <IhOR-pH3R7bzOLcy033DRDMFg6xeuk5Qcq_F9rDMaB0=.ec795bb5-37eb-4e58-8131-14cccdfd447e@github.com>
Message-ID: <68ajCf7o-Hl7B8N80OXgRZiaHapLuT3Cq8IJOjMwDfs=.dff00e73-a4e7-487b-a6e6-7d128474f49e@github.com>

On Tue, 12 Jul 2022 14:28:18 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > It seems during test shutdown, ObjectFree events are being delivered after JVMTI events have been disabled:
> > ```
> >     nsk_jvmti_enableEvents(JVMTI_DISABLE, eventsCount, events, NULL);
> > 
> >     NSK_TRACE(jni->DeleteGlobalRef(debugeeClass));
> >     NSK_TRACE(jvmti->DestroyRawMonitor(counterMonitor_ptr));
> > 
> >     NSK_DISPLAY0("Let debugee to finish\n");
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > The first line is disabling events. A couple statements later the monitor is freed. After that a printf that we are seeing in the output. After the printf the ObjectFree events arrives and we try to use the freed monitor. Here's the stack trace when the event arrives (I got this by inserting an assert(0)):
> > ```
> > #4  0x00007f451f6752af in increaseCounter (counterPtr=0x7f451f699ad8 <eventCount>) at /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S8484/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/fa6bd5a2-99f3-402f-b5bb-613077cc393c/runs/f384ea29-cdca-4da9-887c-7f0c9eff2c41/workspace/open/test/hotspot/jtreg/vmTestbase/nsk/share/native/JVMTITools.cpp:71
> > #5  0x00007f451dc10f13 in JvmtiExport::post_object_free(JvmtiEnv*, GrowableArray<long>*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> > #6  0x00007f451dc4772d in JvmtiTagMap::post_dead_objects(GrowableArray<long>*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> > #7  0x00007f451dc4804a in JvmtiTagMap::remove_and_post_dead_objects() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> > #8  0x00007f451dc48615 in JvmtiTagMap::flush_all_object_free_events() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> > #9  0x00007f451e15ed93 in ServiceThread::service_thread_entry(JavaThread*, JavaThread*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> > #10 0x00007f451d8ff948 in JavaThread::thread_main_inner() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> > #11 0x00007f451e31ec20 in Thread::call_run() () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> > #12 0x00007f451dfe1ef4 in thread_native_entry(Thread*) () from /opt/mach5/mesos/work_dir/jib-master/install/2022-07-12-0516516.chris.plummer.zhengyu/linux-x64-debug.jdk/jdk-20/fastdebug/lib/server/libjvm.so
> > #13 0x00007f451f17d1df in start_thread () from /lib64/libpthread.so.0
> > #14 0x00007f451ebe5dd3 in clone () from /lib64/libc.so.6
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > It's a little misleading because of some inlining. Here's the actual ObjectFree callback:
> > ```
> > void JNICALL
> > ObjectFree(jvmtiEnv *jvmti_env, jlong tag) {
> >     increaseCounter(&eventCount);
> > //    NSK_DISPLAY0("  event: ObjectFree\n");
> > }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I'm a bit less sure now that this is a test bug. I wonder if some JVMTI synchronization is now being bypassed that would normally have blocked the test when it tried to disable events, and not allow the disabling until the ObjectFree events had all finished being posted.
> 
> I am perplexed where is the synchronization, I believe, there is none.
> 
> We were lucky to avoid this failure due to the test disables `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` along with `JVMTI_EVENT_OBJECT_FREE` at once. The old implementation was depending on `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` to flush `JVMTI_EVENT_OBJECT_FREE` events and `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` event is posted at safepoint, that gives illusion of synchronization.
> 
> I believe enabling/disabling events are always asynchronous vs posting them. Further more, setting event bits seems to require `JvmtiThreadState_lock` while reading does not.

Every time to enable/disable `JVMTI_EVENT_OBJECT_FREE` event, it does a flush. The problem is that it may race `ServiceThread` to flush dead objects. If `ServiceThread` tries to flush a `JvmtiTagMap` first and collect all dead objects, then blocked while another thread enables/disables `JVMTI_EVENT_OBJECT_FREE` event and completes a flush on the `JvmtiTagMap`, when `ServiceThread` unblocked and continues to flush, that causes the failure.

The solution is to serialize the flushes, so that above scenario can not happen.

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

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

From cjplummer at openjdk.org  Tue Jul 12 19:32:16 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Jul 2022 19:32:16 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v16]
In-Reply-To: <5Sv0tR7UtkxVEizjvNfMw5NsOX7n7pj6cTHyVYIsqj4=.daf4abce-96de-4f45-a318-5d187f07209f@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <5Sv0tR7UtkxVEizjvNfMw5NsOX7n7pj6cTHyVYIsqj4=.daf4abce-96de-4f45-a318-5d187f07209f@github.com>
Message-ID: <GSpUkfjWq0qV3aH-haJleadtk0YxJAHFX_LTLOSndyE=.46e8d302-286c-4d61-bc6c-592441fb1eaa@github.com>

On Tue, 12 Jul 2022 17:02:54 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix race

I haven't had a chance to review your change or to understand the sync issues, but I did test them out and it seems to have gotten rid of the issue. However, there is new assert that turned up once in 75 runs:


#  Internal Error (/<snip>/workspace/open/src/hotspot/share/runtime/interfaceSupport.inline.hpp:182), pid=3626508, tid=3626546
#  assert(!thread->owns_locks()) failed: must release all locks when leaving VM

V  [libjvm.so+0x138a807]  JvmtiJavaThreadEventTransition::JvmtiJavaThreadEventTransition(JavaThread*)+0x157
V  [libjvm.so+0x137eee5]  JvmtiExport::post_object_free(JvmtiEnv*, GrowableArray<long>*)+0xa5
V  [libjvm.so+0x13b571d]  JvmtiTagMap::post_dead_objects(GrowableArray<long>*)+0x5d
V  [libjvm.so+0x13b59dd]  JvmtiTagMap::iterate_over_heap(jvmtiHeapObjectFilter, Klass*, jvmtiIterationControl (*)(long, long, long*, void*), void const*)+0x23d
V  [libjvm.so+0x134d721]  JvmtiEnv::IterateOverInstancesOfClass(oop, jvmtiHeapObjectFilter, jvmtiIterationControl (*)(long, long, long*, void*), void const*)+0xd1
V  [libjvm.so+0x12dd823]  jvmti_IterateOverInstancesOfClass+0x1d3
C  [libap04t001.so+0xd1c6]  Java_nsk_jvmti_scenarios_allocation_AP04_ap04t001_runIterateOverInstancesOfClass+0xa6
j  nsk.jvmti.scenarios.allocation.AP04.ap04t001.runIterateOverInstancesOfClass()V+0
j  nsk.jvmti.scenarios.allocation.AP04.ap04t001ClassIterator.runIteration()V+0
j  nsk.jvmti.scenarios.allocation.AP04.ap04t001Thread.run()V+30
v  ~StubRoutines::call_stub 0x00007f55a0528d47
V  [libjvm.so+0x1036784]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x514
V  [libjvm.so+0x1037024]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x4b4
V  [libjvm.so+0x1037497]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x77
V  [libjvm.so+0x11c731b]  thread_entry(JavaThread*, JavaThread*)+0x12b
V  [libjvm.so+0x106d948]  JavaThread::thread_main_inner()+0x238
V  [libjvm.so+0x1a8cbd0]  Thread::call_run()+0x100
V  [libjvm.so+0x174fea4]  thread_native_entry(Thread*)+0x104

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

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

From mullan at openjdk.org  Tue Jul 12 19:43:46 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Jul 2022 19:43:46 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v2]
In-Reply-To: <Ec8Kl013J2bB-xzb4uJLUEKfLkPtSJbFIx_oRmzX86g=.7665f39d-77cd-4bdf-b3bf-9e31391a53c0@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <gZ4Izl3lAA0IAsFT9dgmEGWocMhP4o1lbX-tsQv9urA=.678243f0-3422-4bef-ab91-c866680069bf@github.com>
 <UwPcRFlhBb7-naf8td6hPCL9g3XXpLCAwjyIl2ECoHY=.873b96f3-d217-477d-8aab-72038b6867db@github.com>
 <yEmSqmAaJeSsF6Tt32y91f7XXLFnQsst5nl2_bXUXwk=.7be090a8-0901-4e91-84ee-6f2db92e4a80@github.com>
 <Ec8Kl013J2bB-xzb4uJLUEKfLkPtSJbFIx_oRmzX86g=.7665f39d-77cd-4bdf-b3bf-9e31391a53c0@github.com>
Message-ID: <4zzxq4aPLUpZWLZLo8_XIig32zMw3QAXkEmCOGKqWGs=.c0870ba3-60d0-4b2b-8e25-5e80d6646503@github.com>

On Tue, 12 Jul 2022 17:38:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Why isn't it sufficient to just call logout once per each login module?
>
> I meant to make the test more real. When there are multiple login modules, the principals and credentials sets could be different. For example, the `privateCredential` NPE in `KeyStoreLoginModule` you found can only happen if there are other private credentials in the subject. (That said, my test hasn't been able to caught it because I haven't used a read-only subject).
> 
> How about I add another method in the test for the single login module module?

It's probably not necessary, I just wanted to understand your rationale. I would add a comment to the test like what you just explained above for future reference.

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

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

From zgu at openjdk.org  Tue Jul 12 22:02:59 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 12 Jul 2022 22:02:59 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
Message-ID: <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>

> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
> 
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
> 
> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
> 
> It also performs `commonRef_compact()` only when there are classes unloaded.
> 
> New test failed about 20% without patch, none with patch.
> 
> **Update**
> There are significant changes from early patch. 
> 
> The new approach:
> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
> 
> The new solution breaks up into two steps:
> - Collect all dead object tags with lock
> - Transition to `_in_native` state and post object free events in one batch
> 
> This way, JDI event handler can process object free events upon arrivals without delay.
> 
> **Update 2**
> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
> 
> // This checks for posting and rehashing before operations that
> // this tagmap table.  The calls from a JavaThread only rehash, posting is
> // only done before heap walks.
> void JvmtiTagMap::check_hashmap(bool post_events) {
> 
> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
> Even the events are posted earlier in old code, but they are only processed after next GC cycle.

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Fix a bug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9168/files
  - new: https://git.openjdk.org/jdk/pull/9168/files/6f14f452..6ef6c2f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=15-16

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

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

From zgu at openjdk.org  Tue Jul 12 22:03:01 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 12 Jul 2022 22:03:01 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v16]
In-Reply-To: <GSpUkfjWq0qV3aH-haJleadtk0YxJAHFX_LTLOSndyE=.46e8d302-286c-4d61-bc6c-592441fb1eaa@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <5Sv0tR7UtkxVEizjvNfMw5NsOX7n7pj6cTHyVYIsqj4=.daf4abce-96de-4f45-a318-5d187f07209f@github.com>
 <GSpUkfjWq0qV3aH-haJleadtk0YxJAHFX_LTLOSndyE=.46e8d302-286c-4d61-bc6c-592441fb1eaa@github.com>
Message-ID: <C8RkJMUAtE6YD2bMmOoAxPgl1zXBqH7Ja1glmeaFo8w=.a22b79b1-99ee-41f1-b5ea-a98f9bf3aeb3@github.com>

On Tue, 12 Jul 2022 19:27:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I haven't had a chance to review your change or to understand the sync issues, but I did test them out and it seems to have gotten rid of the issue. However, there is new assert that turned up once in 75 runs:
> 
> ```
> #  Internal Error (/<snip>/workspace/open/src/hotspot/share/runtime/interfaceSupport.inline.hpp:182), pid=3626508, tid=3626546
> #  assert(!thread->owns_locks()) failed: must release all locks when leaving VM
> 
> V  [libjvm.so+0x138a807]  JvmtiJavaThreadEventTransition::JvmtiJavaThreadEventTransition(JavaThread*)+0x157
> V  [libjvm.so+0x137eee5]  JvmtiExport::post_object_free(JvmtiEnv*, GrowableArray<long>*)+0xa5
> V  [libjvm.so+0x13b571d]  JvmtiTagMap::post_dead_objects(GrowableArray<long>*)+0x5d
> V  [libjvm.so+0x13b59dd]  JvmtiTagMap::iterate_over_heap(jvmtiHeapObjectFilter, Klass*, jvmtiIterationControl (*)(long, long, long*, void*), void const*)+0x23d
> V  [libjvm.so+0x134d721]  JvmtiEnv::IterateOverInstancesOfClass(oop, jvmtiHeapObjectFilter, jvmtiIterationControl (*)(long, long, long*, void*), void const*)+0xd1
> V  [libjvm.so+0x12dd823]  jvmti_IterateOverInstancesOfClass+0x1d3
> C  [libap04t001.so+0xd1c6]  Java_nsk_jvmti_scenarios_allocation_AP04_ap04t001_runIterateOverInstancesOfClass+0xa6
> j  nsk.jvmti.scenarios.allocation.AP04.ap04t001.runIterateOverInstancesOfClass()V+0
> j  nsk.jvmti.scenarios.allocation.AP04.ap04t001ClassIterator.runIteration()V+0
> j  nsk.jvmti.scenarios.allocation.AP04.ap04t001Thread.run()V+30
> v  ~StubRoutines::call_stub 0x00007f55a0528d47
> V  [libjvm.so+0x1036784]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x514
> V  [libjvm.so+0x1037024]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x4b4
> V  [libjvm.so+0x1037497]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x77
> V  [libjvm.so+0x11c731b]  thread_entry(JavaThread*, JavaThread*)+0x12b
> V  [libjvm.so+0x106d948]  JavaThread::thread_main_inner()+0x238
> V  [libjvm.so+0x1a8cbd0]  Thread::call_run()+0x100
> V  [libjvm.so+0x174fea4]  thread_native_entry(Thread*)+0x104
> ```

Thanks for running the test. I missed a spot. Fixed.

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

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

From dcubed at openjdk.org  Tue Jul 12 22:07:15 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 12 Jul 2022 22:07:15 GMT
Subject: [jdk19] Integrated: 8290201: ProblemList
 com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode
Message-ID: <IA4RCeff22td7n_MYX_Q2uWhniAkJ9ZYCZe-36MfUKg=.0ca00318-4cb3-47d6-a731-269cd2d1f9de@github.com>

A trivial fix to ProblemList com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode.

The copyright header is missing in this ProblemList file and there is a duplicate entry. 
I'm fixing those also as long as I'm here.

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

Commit messages:
 - 8290201: ProblemList com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode

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

PR: https://git.openjdk.org/jdk19/pull/136

From bpb at openjdk.org  Tue Jul 12 22:07:15 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 12 Jul 2022 22:07:15 GMT
Subject: [jdk19] Integrated: 8290201: ProblemList
 com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode
In-Reply-To: <IA4RCeff22td7n_MYX_Q2uWhniAkJ9ZYCZe-36MfUKg=.0ca00318-4cb3-47d6-a731-269cd2d1f9de@github.com>
References: <IA4RCeff22td7n_MYX_Q2uWhniAkJ9ZYCZe-36MfUKg=.0ca00318-4cb3-47d6-a731-269cd2d1f9de@github.com>
Message-ID: <qZ9Ga8FFPDUAXWrznOI1AC_kWBaz4mZ-Zkxu4AN5AxM=.d7e8fdd4-0734-4156-baf1-493672b49cae@github.com>

On Tue, 12 Jul 2022 20:43:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode.
> 
> The copyright header is missing in this ProblemList file and there is a duplicate entry. 
> I'm fixing those also as long as I'm here.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/136

From dcubed at openjdk.org  Tue Jul 12 22:07:15 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 12 Jul 2022 22:07:15 GMT
Subject: [jdk19] Integrated: 8290201: ProblemList
 com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode
In-Reply-To: <qZ9Ga8FFPDUAXWrznOI1AC_kWBaz4mZ-Zkxu4AN5AxM=.d7e8fdd4-0734-4156-baf1-493672b49cae@github.com>
References: <IA4RCeff22td7n_MYX_Q2uWhniAkJ9ZYCZe-36MfUKg=.0ca00318-4cb3-47d6-a731-269cd2d1f9de@github.com>
 <qZ9Ga8FFPDUAXWrznOI1AC_kWBaz4mZ-Zkxu4AN5AxM=.d7e8fdd4-0734-4156-baf1-493672b49cae@github.com>
Message-ID: <waJoSzTvuOl4SPDKPUnRCmmxHyCWMGti0HzSNrqK4zs=.8c8222d0-0377-4b9d-968e-0277a5b612bc@github.com>

On Tue, 12 Jul 2022 20:46:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to ProblemList com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode.
>> 
>> The copyright header is missing in this ProblemList file and there is a duplicate entry. 
>> I'm fixing those also as long as I'm here.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the lightning fast review!

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

PR: https://git.openjdk.org/jdk19/pull/136

From dcubed at openjdk.org  Tue Jul 12 22:07:16 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 12 Jul 2022 22:07:16 GMT
Subject: [jdk19] Integrated: 8290201: ProblemList
 com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode
In-Reply-To: <IA4RCeff22td7n_MYX_Q2uWhniAkJ9ZYCZe-36MfUKg=.0ca00318-4cb3-47d6-a731-269cd2d1f9de@github.com>
References: <IA4RCeff22td7n_MYX_Q2uWhniAkJ9ZYCZe-36MfUKg=.0ca00318-4cb3-47d6-a731-269cd2d1f9de@github.com>
Message-ID: <vcMQpXCiD2CFPud-zX8WpDCgCthMQqEoDZs47_yPexg=.0584fb0d-aff9-4e7b-a2a1-19d021d0bdbc@github.com>

On Tue, 12 Jul 2022 20:43:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode.
> 
> The copyright header is missing in this ProblemList file and there is a duplicate entry. 
> I'm fixing those also as long as I'm here.

This pull request has now been integrated.

Changeset: fff7f353
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/fff7f35300f4a05046057fce80095fbec3fa275f
Stats:     26 lines in 1 file changed: 24 ins; 2 del; 0 mod

8290201: ProblemList com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode

Reviewed-by: bpb

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

PR: https://git.openjdk.org/jdk19/pull/136

From iklam at openjdk.org  Tue Jul 12 22:39:36 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 12 Jul 2022 22:39:36 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v6]
In-Reply-To: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
Message-ID: <atkEWyynzUQUlk7KK-NOovTxQWdMO8fQojBmptbXVZk=.00d66dcd-92ba-4819-9ca8-f65838e43ec2@github.com>

> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
> 
> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
> 
> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
> 
> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
> 
> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - add errno to log
 - added debug log and tweaked comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9406/files
  - new: https://git.openjdk.org/jdk/pull/9406/files/78254917..ecac352b

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

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

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

From stuefe at openjdk.org  Tue Jul 12 22:39:37 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 12 Jul 2022 22:39:37 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v6]
In-Reply-To: <atkEWyynzUQUlk7KK-NOovTxQWdMO8fQojBmptbXVZk=.00d66dcd-92ba-4819-9ca8-f65838e43ec2@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <atkEWyynzUQUlk7KK-NOovTxQWdMO8fQojBmptbXVZk=.00d66dcd-92ba-4819-9ca8-f65838e43ec2@github.com>
Message-ID: <qgrzlW5Nqvl_BvIyvLtffzpAU2vQP7kfxl237iV9N3Y=.5ebd35c6-f849-4deb-9fae-4df4a5013ff7@github.com>

On Tue, 12 Jul 2022 19:12:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
>> 
>> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
>> 
>> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
>> 
>> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
>> 
>> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add errno to log
>  - added debug log and tweaked comment

Looks good!

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

Marked as reviewed by stuefe (Reviewer).

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

From iklam at openjdk.org  Tue Jul 12 22:39:44 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 12 Jul 2022 22:39:44 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v5]
In-Reply-To: <Ia2c6OkeRuJ7lGdhc-eGLUl0uFbC2Eb3uFKVrmO7ctc=.6e8914fd-161a-4c1f-ab32-277cdba22ca0@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <YxkFB9_hMSn03DPHSfRmq4gRLNHcgXWHFM1AyKUiY2s=.f78241b8-d0e4-4f86-ae09-ca34cccc6f90@github.com>
 <Ia2c6OkeRuJ7lGdhc-eGLUl0uFbC2Eb3uFKVrmO7ctc=.6e8914fd-161a-4c1f-ab32-277cdba22ca0@github.com>
Message-ID: <wRgwYDnKIp5ks27NXY4fxwxZmjLsdf7_ZEU-N3pnhpw=.8e9cf43b-6e0f-443c-93db-e098eaa9fab8@github.com>

On Mon, 11 Jul 2022 04:53:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo
>
> src/hotspot/os/posix/perfMemory_posix.cpp line 733:
> 
>> 731:   while ((entry = os::readdir(dirp)) != NULL) {
>> 732:     const char* filename = entry->d_name;
>> 733:     pid_t pid = filename_to_pid(filename);
> 
> Pre-existing. An error value of -1 would be somewhat cleaner since strictly speaking pid 0 is a valid PID. (Feel free to ignore this comment)

I think I'll leave it for now to minimize the behavior changes of this PR. I read somewhere that pid 0 is the scheduler

https://unix.stackexchange.com/questions/83322/which-process-has-pid-0

So no actual JVM process will create a stale file with name "0". If such a file exists for some other reason we would remove it, which be consistent with the new comment "any other files found in this directory may be removed".

> src/hotspot/os/posix/perfMemory_posix.cpp line 760:
> 
>> 758:       // Something wrong happened. Ignore the error and don't try to remove the
>> 759:       // file.
>> 760:       errno = 0;
> 
> Can we have a debug or trace log line here?

Fixed

> src/hotspot/os/posix/perfMemory_posix.cpp line 804:
> 
>> 802:     }
>> 803: 
>> 804:  #if defined(LINUX)
> 
> Indentation

Fixed

> src/hotspot/os/posix/perfMemory_posix.cpp line 807:
> 
>> 805:     // Hold the lock until here to prevent other JVMs from using this file
>> 806:     // while we are in the middle of deleting it.
>> 807:     ::close(fd);
> 
> I don't understand this comment, it seems to contradict what you are doing. We are closing the only fd referring to this lock file, right? So the lock should get unlocked here too? If we want to keep the lock open, shouldn't we avoid closing the fd?

I want to prevent the following race condition. Let's assume this process has PID 10 and there's another process (in a different pid namespace) with PID 20. Both process see a file named "20".

0. No one holds a lock on this file.
1. Process 20 successfully locks the file in cleanup_sharedmem_files().
2. Process 20 gives up the lock.
3. Process 20 decides it can delete the file (PID 20 matches its own PID).
4. This process successfully locks the file in cleanup_sharedmem_files().
5. This process gives up the lock
6. This process decides it can delete the file (PID 20 does not exist in my pid namespace)
7. Process 20 deletes the file. Creates a new version of this file. Successfully locks the new file.
8. This process deletes the new version of this file (by name).

By holding the lock between steps 4 and 8, we can guaranteed that if a process can successfully lock the file in create_sharedmem_file(), this file will never be unintentionally deleted.

I changed the comment slightly:


    // Hold the lock until here to prevent other JVMs from using this file
-   // while we are in the middle of deleting it.
+   // while we were in the middle of deleting it.

> src/hotspot/os/posix/perfMemory_posix.cpp line 926:
> 
>> 924:                               (errno == EWOULDBLOCK) ?
>> 925:                               "it is locked by another process" :
>> 926:                               "flock() failed");
> 
> strerror would be helpful here, or at least errno

I added just the errno. Example:


[0.003s][warning][perf,memops] Cannot use file /tmp/hsperfdata_root/1 
because it is locked by another process (errno = 11)


If we print the `os::strerror()` it would look like this:


... because it is locked by another process (errno = 11, Operation would block) 


which seems too verbose and could be confusing.

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

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

From stuefe at openjdk.org  Tue Jul 12 22:39:45 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 12 Jul 2022 22:39:45 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v5]
In-Reply-To: <wRgwYDnKIp5ks27NXY4fxwxZmjLsdf7_ZEU-N3pnhpw=.8e9cf43b-6e0f-443c-93db-e098eaa9fab8@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <YxkFB9_hMSn03DPHSfRmq4gRLNHcgXWHFM1AyKUiY2s=.f78241b8-d0e4-4f86-ae09-ca34cccc6f90@github.com>
 <Ia2c6OkeRuJ7lGdhc-eGLUl0uFbC2Eb3uFKVrmO7ctc=.6e8914fd-161a-4c1f-ab32-277cdba22ca0@github.com>
 <wRgwYDnKIp5ks27NXY4fxwxZmjLsdf7_ZEU-N3pnhpw=.8e9cf43b-6e0f-443c-93db-e098eaa9fab8@github.com>
Message-ID: <Df6XLVapFdCx4pSvjIE0s2gSe123ruDpAwyHeGxnUSg=.464652e3-8a35-4ce7-b089-27dee442f0f1@github.com>

On Tue, 12 Jul 2022 18:38:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/os/posix/perfMemory_posix.cpp line 807:
>> 
>>> 805:     // Hold the lock until here to prevent other JVMs from using this file
>>> 806:     // while we are in the middle of deleting it.
>>> 807:     ::close(fd);
>> 
>> I don't understand this comment, it seems to contradict what you are doing. We are closing the only fd referring to this lock file, right? So the lock should get unlocked here too? If we want to keep the lock open, shouldn't we avoid closing the fd?
>
> I want to prevent the following race condition. Let's assume this process has PID 10 and there's another process (in a different pid namespace) with PID 20. Both process see a file named "20".
> 
> 0. No one holds a lock on this file.
> 1. Process 20 successfully locks the file in cleanup_sharedmem_files().
> 2. Process 20 gives up the lock.
> 3. Process 20 decides it can delete the file (PID 20 matches its own PID).
> 4. This process successfully locks the file in cleanup_sharedmem_files().
> 5. This process gives up the lock
> 6. This process decides it can delete the file (PID 20 does not exist in my pid namespace)
> 7. Process 20 deletes the file. Creates a new version of this file. Successfully locks the new file.
> 8. This process deletes the new version of this file (by name).
> 
> By holding the lock between steps 4 and 8, we can guaranteed that if a process can successfully lock the file in create_sharedmem_file(), this file will never be unintentionally deleted.
> 
> I changed the comment slightly:
> 
> 
>     // Hold the lock until here to prevent other JVMs from using this file
> -   // while we are in the middle of deleting it.
> +   // while we were in the middle of deleting it.

Makes sense, thanks for explaining, and the past tense in the comment helps.

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

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

From dcubed at openjdk.org  Tue Jul 12 22:53:10 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 12 Jul 2022 22:53:10 GMT
Subject: [jdk19] Integrated: 8290203: ProblemList
 vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java
 on linux-all
Message-ID: <8OL-Z6hxP1_upQuzR1bzbg5gdzzdQhkOSmj3jIfmSsE=.836548d3-287e-4bc3-9f43-7aa004977bb4@github.com>

A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java on linux-all.

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

Commit messages:
 - 8290203: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java on linux-all

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

PR: https://git.openjdk.org/jdk19/pull/137

From naoto at openjdk.org  Tue Jul 12 22:53:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 12 Jul 2022 22:53:10 GMT
Subject: [jdk19] Integrated: 8290203: ProblemList
 vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java
 on linux-all
In-Reply-To: <8OL-Z6hxP1_upQuzR1bzbg5gdzzdQhkOSmj3jIfmSsE=.836548d3-287e-4bc3-9f43-7aa004977bb4@github.com>
References: <8OL-Z6hxP1_upQuzR1bzbg5gdzzdQhkOSmj3jIfmSsE=.836548d3-287e-4bc3-9f43-7aa004977bb4@github.com>
Message-ID: <4uGC4JWGaxRdqN2mp9Hf0IK3lRZ-6flhlFs5Y5TJLbg=.64d41bb0-20ff-4cb9-8067-2fd81de78b8f@github.com>

On Tue, 12 Jul 2022 21:15:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java on linux-all.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/137

From dcubed at openjdk.org  Tue Jul 12 22:53:11 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 12 Jul 2022 22:53:11 GMT
Subject: [jdk19] Integrated: 8290203: ProblemList
 vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java
 on linux-all
In-Reply-To: <4uGC4JWGaxRdqN2mp9Hf0IK3lRZ-6flhlFs5Y5TJLbg=.64d41bb0-20ff-4cb9-8067-2fd81de78b8f@github.com>
References: <8OL-Z6hxP1_upQuzR1bzbg5gdzzdQhkOSmj3jIfmSsE=.836548d3-287e-4bc3-9f43-7aa004977bb4@github.com>
 <4uGC4JWGaxRdqN2mp9Hf0IK3lRZ-6flhlFs5Y5TJLbg=.64d41bb0-20ff-4cb9-8067-2fd81de78b8f@github.com>
Message-ID: <AEZqKtKVcf6v_YsknvWLxIpHKv3ovKisFbCRWjerEb0=.dc83d044-be7a-412a-946e-4cb5b5cf6ddc@github.com>

On Tue, 12 Jul 2022 21:22:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java on linux-all.
>
> Marked as reviewed by naoto (Reviewer).

@naotoj - Thanks for the fast code review.

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

PR: https://git.openjdk.org/jdk19/pull/137

From dcubed at openjdk.org  Tue Jul 12 22:53:12 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 12 Jul 2022 22:53:12 GMT
Subject: [jdk19] Integrated: 8290203: ProblemList
 vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java
 on linux-all
In-Reply-To: <8OL-Z6hxP1_upQuzR1bzbg5gdzzdQhkOSmj3jIfmSsE=.836548d3-287e-4bc3-9f43-7aa004977bb4@github.com>
References: <8OL-Z6hxP1_upQuzR1bzbg5gdzzdQhkOSmj3jIfmSsE=.836548d3-287e-4bc3-9f43-7aa004977bb4@github.com>
Message-ID: <Yr3D44NS0M-Rl5ygONJhE9NEUwJoJC3_lQsW3Kn_PLE=.7ece05b6-cf45-4575-901b-5999b752f277@github.com>

On Tue, 12 Jul 2022 21:15:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java on linux-all.

This pull request has now been integrated.

Changeset: ce36f6ea
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/ce36f6ea855a7ede02df969e6bb599ac36ac04fe
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8290203: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java on linux-all

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk19/pull/137

From cjplummer at openjdk.org  Wed Jul 13 01:35:48 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 13 Jul 2022 01:35:48 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
Message-ID: <FiGEM7cQFSIOlNw2DF0J2rDmI_rUswqVBhwgrVX-rwU=.60b7f17b-cc5b-461f-bae7-33aa4101ac1e@github.com>

On Tue, 12 Jul 2022 22:02:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a bug

Ok. Everything is passing after your latest fix.

I think the test still has a synchronization bug, but probably not something important enough to worry about, and I'm guessing a lot of tests have this issue. The test disables events and then frees the raw monitor used in the callback. The problem is that JVMTI might already be in the process of calling the callback, so the callback will still attempt to use the monitor. The test shutdown code and the test callback code need to be synchronized to avoid this issue. However, there is a chicken and egg problem here, because you need a raw monitor for the synchronization. I think the real solution is to just not bother freeing up the raw monitor. I think we may have done this recently in some other test. Perhaps @sspitsyn remembers.

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

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

From cjplummer at openjdk.org  Wed Jul 13 02:25:55 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 13 Jul 2022 02:25:55 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
Message-ID: <e_YHiQ8cNOylKnoKgaoGfON27LcwKC1LDrQ0f1hPJ8Q=.3a9b673a-533c-4d02-bcbf-abc5ce20130e@github.com>

On Tue, 12 Jul 2022 22:02:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a bug

Marked as reviewed by cjplummer (Reviewer).

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

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

From zgu at openjdk.org  Wed Jul 13 13:24:11 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 13 Jul 2022 13:24:11 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <FiGEM7cQFSIOlNw2DF0J2rDmI_rUswqVBhwgrVX-rwU=.60b7f17b-cc5b-461f-bae7-33aa4101ac1e@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
 <FiGEM7cQFSIOlNw2DF0J2rDmI_rUswqVBhwgrVX-rwU=.60b7f17b-cc5b-461f-bae7-33aa4101ac1e@github.com>
Message-ID: <XDbpzxOuXZiKkAsP_DNqUbBnhpo1Wpfs-qsdDKXkDpY=.84bf13e3-f2ed-4826-aa19-f378e28d24e4@github.com>

On Wed, 13 Jul 2022 01:14:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Ok. Everything is passing after your latest fix.
> 
> I think the test still has a synchronization bug, but probably not something important enough to worry about, and I'm guessing a lot of tests have this issue. The test disables events and then frees the raw monitor used in the callback. The problem is that JVMTI might already be in the process of calling the callback, so the callback will still attempt to use the monitor. The test shutdown code and the test callback code need to be synchronized to avoid this issue. However, there is a chicken and egg problem here, because you need a raw monitor for the synchronization. I think the real solution is to just not bother freeing up the raw monitor. I think we may have done this recently in some other test. Perhaps @sspitsyn remembers.

Me too have a concern on synchronization for enabling/disabling a JVMTI event:
While setting event bits is synchronized with `JvmtiThreadState_lock` in [JvmtiEventControllerPrivate::set_user_enabled()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEventController.cpp#L889), but reading [`is_enabled()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnvBase.hpp#L308) is unsynchronized. 

I don't know how it supposes to work, but at least [`_enabled_bits`](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEventController.hpp#L85) should be an `volatile`?

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

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

From itakiguchi at openjdk.org  Wed Jul 13 17:02:30 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 13 Jul 2022 17:02:30 GMT
Subject: RFR: 8290218: AIX build failure by JDK-8289780
Message-ID: <gy3uYyZWqfSIhQY70GXvCeZyYzof-lmKft4FxLlAIk8=.3ebb407e-48a7-4073-a286-b2301ca6295a@github.com>

AIX build was failed by following messages:

* For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
ld: 0711-317 ERROR: Undefined symbol: collector_func_load
ld: 0711-317 ERROR: Undefined symbol: .collector_func_load
ld: 0711-344 See the loadmap file /home/jdkbld/git/jdk/build/aix-ppc64-server-release/hotspot/variant-server/libjvm/objs/libjvm.loadmap for more information.

In my investigation, [JDK-8289780](https://bugs.openjdk.org/browse/JDK-8289780) affects this issue on src/hotspot/share/prims/forte.cpp.

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

Commit messages:
 - 8290218: AIX build failure by JDK-8289780

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

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

From cjplummer at openjdk.org  Wed Jul 13 18:50:15 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 13 Jul 2022 18:50:15 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
Message-ID: <_sxHrlzmJsi2i7KfnX9VA68-1j1-Rhaybwc_Xedz9gc=.28d48cea-7c22-43cc-8910-bca2e07e927d@github.com>

On Tue, 12 Jul 2022 22:02:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a bug

Actually I'm going to amend my previous comment about concerns with synchronization of the test. I think once the SetEventNotificationMode() call returns (after passing JVMTI_DISABLE), the caller should be guaranteed that any call to the event handler that was in progress has completed. So the caller should be able to safely free the raw monitor that is used in the callback. I'm not sure if JVMTI makes this guarantee however.

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

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

From iklam at openjdk.org  Wed Jul 13 19:41:07 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 13 Jul 2022 19:41:07 GMT
Subject: RFR: 8290218: AIX build failure by JDK-8289780
In-Reply-To: <gy3uYyZWqfSIhQY70GXvCeZyYzof-lmKft4FxLlAIk8=.3ebb407e-48a7-4073-a286-b2301ca6295a@github.com>
References: <gy3uYyZWqfSIhQY70GXvCeZyYzof-lmKft4FxLlAIk8=.3ebb407e-48a7-4073-a286-b2301ca6295a@github.com>
Message-ID: <rTYZVGUsVKLkmX7UXXwXf9pJ5FeXkesVrZY3xSuWLsM=.b0a3a472-d7f5-4d65-8b41-cf5839742283@github.com>

On Wed, 13 Jul 2022 16:55:38 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> AIX build was failed by following messages:
> 
> * For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
> ld: 0711-317 ERROR: Undefined symbol: collector_func_load
> ld: 0711-317 ERROR: Undefined symbol: .collector_func_load
> ld: 0711-344 See the loadmap file /home/jdkbld/git/jdk/build/aix-ppc64-server-release/hotspot/variant-server/libjvm/objs/libjvm.loadmap for more information.
> 
> In my investigation, [JDK-8289780](https://bugs.openjdk.org/browse/JDK-8289780) affects this issue on src/hotspot/share/prims/forte.cpp.

Changes requested by iklam (Reviewer).

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

> 668: // Because it is weakly bound, the calls become NOP's when the library
> 669: // isn't present.
> 670: #if defined(__APPLE__)

I think this can be combined with the condition below:


#if defined(__APPLE__) || defined(_AIX)


I am curious why `collector_func_load` worked before but `collector_func_load_enabled()` doesn't work, since they are using the same pattern. Anyway, I think the new change is better, since the profiling tool that requires `collector_func_load` isn't available on AIX.

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

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

From cjplummer at openjdk.org  Thu Jul 14 00:17:09 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 14 Jul 2022 00:17:09 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <XDbpzxOuXZiKkAsP_DNqUbBnhpo1Wpfs-qsdDKXkDpY=.84bf13e3-f2ed-4826-aa19-f378e28d24e4@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
 <FiGEM7cQFSIOlNw2DF0J2rDmI_rUswqVBhwgrVX-rwU=.60b7f17b-cc5b-461f-bae7-33aa4101ac1e@github.com>
 <XDbpzxOuXZiKkAsP_DNqUbBnhpo1Wpfs-qsdDKXkDpY=.84bf13e3-f2ed-4826-aa19-f378e28d24e4@github.com>
Message-ID: <l_m_UlAg09pgaIU-n-4efEGUquazjQwdFRA104DZT3k=.97d8e364-8017-4f61-bb07-458890a9e679@github.com>

On Wed, 13 Jul 2022 13:20:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Ok. Everything is passing after your latest fix.
>> 
>> I think the test still has a synchronization bug, but probably not something important enough to worry about, and I'm guessing a lot of tests have this issue. The test disables events and then frees the raw monitor used in the callback. The problem is that JVMTI might already be in the process of calling the callback, so the callback will still attempt to use the monitor. The test shutdown code and the test callback code need to be synchronized to avoid this issue. However, there is a chicken and egg problem here, because you need a raw monitor for the synchronization. I think the real solution is to just not bother freeing up the raw monitor. I think we may have done this recently in some other test. Perhaps @sspitsyn remembers.
>
>> Ok. Everything is passing after your latest fix.
>> 
>> I think the test still has a synchronization bug, but probably not something important enough to worry about, and I'm guessing a lot of tests have this issue. The test disables events and then frees the raw monitor used in the callback. The problem is that JVMTI might already be in the process of calling the callback, so the callback will still attempt to use the monitor. The test shutdown code and the test callback code need to be synchronized to avoid this issue. However, there is a chicken and egg problem here, because you need a raw monitor for the synchronization. I think the real solution is to just not bother freeing up the raw monitor. I think we may have done this recently in some other test. Perhaps @sspitsyn remembers.
> 
> Me too have a concern on synchronization for enabling/disabling a JVMTI event:
> While setting event bits is synchronized with `JvmtiThreadState_lock` in [JvmtiEventControllerPrivate::set_user_enabled()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEventController.cpp#L889), but reading [`is_enabled()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEnvBase.hpp#L308) is unsynchronized. 
> 
> I don't know how it supposes to work, but at least [`_enabled_bits`](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/jvmtiEventController.hpp#L85) should be an `volatile`?

@zhengyu123 I'll be OOO until tuesday, so after this evening I won't be able to respond. @sspitsyn will look at the JVMTI changes again and also help with some of your synchronization questions.

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

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

From itakiguchi at openjdk.org  Thu Jul 14 00:42:55 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 14 Jul 2022 00:42:55 GMT
Subject: RFR: 8290218: AIX build failure by JDK-8289780 [v2]
In-Reply-To: <gy3uYyZWqfSIhQY70GXvCeZyYzof-lmKft4FxLlAIk8=.3ebb407e-48a7-4073-a286-b2301ca6295a@github.com>
References: <gy3uYyZWqfSIhQY70GXvCeZyYzof-lmKft4FxLlAIk8=.3ebb407e-48a7-4073-a286-b2301ca6295a@github.com>
Message-ID: <a1o0L2UhO4OdtX5L4aAri_8auJ8mPGroKhHbnXIp7o0=.bad78999-9152-45c4-a41f-061afd2ddfc9@github.com>

> AIX build was failed by following messages:
> 
> * For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
> ld: 0711-317 ERROR: Undefined symbol: collector_func_load
> ld: 0711-317 ERROR: Undefined symbol: .collector_func_load
> ld: 0711-344 See the loadmap file /home/jdkbld/git/jdk/build/aix-ppc64-server-release/hotspot/variant-server/libjvm/objs/libjvm.loadmap for more information.
> 
> In my investigation, [JDK-8289780](https://bugs.openjdk.org/browse/JDK-8289780) affects this issue on src/hotspot/share/prims/forte.cpp.

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8290218: AIX build failure by JDK-8289780

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9482/files
  - new: https://git.openjdk.org/jdk/pull/9482/files/c3079ad3..6bd4b154

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

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

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

From iklam at openjdk.org  Thu Jul 14 02:54:59 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 14 Jul 2022 02:54:59 GMT
Subject: RFR: 8290218: AIX build failure by JDK-8289780 [v2]
In-Reply-To: <a1o0L2UhO4OdtX5L4aAri_8auJ8mPGroKhHbnXIp7o0=.bad78999-9152-45c4-a41f-061afd2ddfc9@github.com>
References: <gy3uYyZWqfSIhQY70GXvCeZyYzof-lmKft4FxLlAIk8=.3ebb407e-48a7-4073-a286-b2301ca6295a@github.com>
 <a1o0L2UhO4OdtX5L4aAri_8auJ8mPGroKhHbnXIp7o0=.bad78999-9152-45c4-a41f-061afd2ddfc9@github.com>
Message-ID: <8URXlYY2my6ky8cXiJ8dKOFB9fMH0EF-b2AOIJBedog=.3167e9ed-b328-4b78-8fc4-3e6a1190bc0c@github.com>

On Thu, 14 Jul 2022 00:42:55 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> AIX build was failed by following messages:
>> 
>> * For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
>> ld: 0711-317 ERROR: Undefined symbol: collector_func_load
>> ld: 0711-317 ERROR: Undefined symbol: .collector_func_load
>> ld: 0711-344 See the loadmap file /home/jdkbld/git/jdk/build/aix-ppc64-server-release/hotspot/variant-server/libjvm/objs/libjvm.loadmap for more information.
>> 
>> In my investigation, [JDK-8289780](https://bugs.openjdk.org/browse/JDK-8289780) affects this issue on src/hotspot/share/prims/forte.cpp.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290218: AIX build failure by JDK-8289780

LGTM and this can be considered as a trivial change that requires only one review.

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

Marked as reviewed by iklam (Reviewer).

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

From itakiguchi at openjdk.org  Thu Jul 14 02:55:01 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 14 Jul 2022 02:55:01 GMT
Subject: RFR: 8290218: AIX build failure by JDK-8289780 [v2]
In-Reply-To: <rTYZVGUsVKLkmX7UXXwXf9pJ5FeXkesVrZY3xSuWLsM=.b0a3a472-d7f5-4d65-8b41-cf5839742283@github.com>
References: <gy3uYyZWqfSIhQY70GXvCeZyYzof-lmKft4FxLlAIk8=.3ebb407e-48a7-4073-a286-b2301ca6295a@github.com>
 <rTYZVGUsVKLkmX7UXXwXf9pJ5FeXkesVrZY3xSuWLsM=.b0a3a472-d7f5-4d65-8b41-cf5839742283@github.com>
Message-ID: <zEA5DbnrnT-apIm28MfViiSdYr2UEg3uxtu9Ih3YoEA=.302a66ac-a8c8-42cc-85b0-0abec0caf287@github.com>

On Wed, 13 Jul 2022 19:37:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8290218: AIX build failure by JDK-8289780
>
> Changes requested by iklam (Reviewer).

Hello @iklam .
I appreciate your comment.
forte.cpp was updated.
Please review the file again.

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

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

From duke at openjdk.org  Thu Jul 14 03:01:14 2022
From: duke at openjdk.org (xpbob)
Date: Thu, 14 Jul 2022 03:01:14 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v3]
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <GjsL127dHAHz0je8_b1ViJy2f9SjT9bfKWnBcySNGF0=.88268da2-cfb8-4af6-b48e-2934f5ebab21@github.com>

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

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

  Add non-programmatic beans

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9372/files
  - new: https://git.openjdk.org/jdk/pull/9372/files/8f63af82..042885dc

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

  Stats: 517 lines in 7 files changed: 229 ins; 288 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9372.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372

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

From duke at openjdk.org  Thu Jul 14 03:16:30 2022
From: duke at openjdk.org (xpbob)
Date: Thu, 14 Jul 2022 03:16:30 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v4]
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <kMLrRe97aL7XVLK24EB7bZ1yrpvi9T9IaEEmEG7u0-s=.c0d6a3eb-9683-47c0-9236-4a0238d9b28c@github.com>

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

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

  Back to modify

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9372/files
  - new: https://git.openjdk.org/jdk/pull/9372/files/042885dc..1dcf96b8

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

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

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

From duke at openjdk.org  Thu Jul 14 03:18:40 2022
From: duke at openjdk.org (xpbob)
Date: Thu, 14 Jul 2022 03:18:40 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v5]
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <vRnqKQO-D5LJZTHeMHGGV8SDEr9rVoGDUscrY_5Inac=.a77b3686-a5ee-41bf-aa5f-e44f2fef74d8@github.com>

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

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

  Back to modify

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9372/files
  - new: https://git.openjdk.org/jdk/pull/9372/files/1dcf96b8..4a668926

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

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

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

From duke at openjdk.org  Thu Jul 14 03:27:07 2022
From: duke at openjdk.org (xpbob)
Date: Thu, 14 Jul 2022 03:27:07 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v6]
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <kfyEWLaJ6mBKWmmVVOys-r36-tra5HsE-LtniN7ku7I=.8e21e351-cbb4-403e-89ff-f63018193281@github.com>

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

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

  modify class name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9372/files
  - new: https://git.openjdk.org/jdk/pull/9372/files/4a668926..4d5faab3

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

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

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

From duke at openjdk.org  Thu Jul 14 03:36:04 2022
From: duke at openjdk.org (xpbob)
Date: Thu, 14 Jul 2022 03:36:04 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
 <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>
 <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com>
Message-ID: <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com>

On Tue, 12 Jul 2022 15:48:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> @AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR
>> 
>> It's too early to think about a CSR, probably a bit premature to create a PR too because it will take a few iterations to come to agreement on what API to expose, if any.
>> 
>> I don't think this should be a standard API, meaning java.management/java.lang.management.ContainerMXBean is not the right place for this. A JDK-specific MXBean is an option but it would only be usable on Linux and maybe only usable when running in a container environment. Working down, it's not clear to me how stable the attributes are and the mapping to both cgroup v1 and v2. There is also overlap with OperatingSystemMXBean which already defines the "TotalSwapSpaceSize" attribute.  There's another level of detail beyond that with unusual value -2 to distinguish "not available" from "not supported".  So I think there are a few things to think about there. 
>> 
>> Another direction to think about is not exposing an API that you can compile against but instead just register a MBean that provides access to the attributes that are interesting for the container environment. By this I mean ManagementFactory.getPlatformMBeanServer().registerMBean(...). This would be enough to browse the MBean and its attributes in any JMX console and may give you a bit more flexibility to expose attributes that are specific to the cgroup version. I'm not saying this is the right direction, I'm just listing it here as something that could be explored. If the main use case is JMX consoles rather than programmatic access then it may not be too bad.
>
>> @AlanBateman OperatingSystemMXBean makes the CPU and Memory related information for a process available regardless of whether that process is running in a native operating system environment or a containerized environment. It does not provide container configuration information such as its provider (crgoups v1 or v2), CPU shares, CPU quota etc, which can be useful for monitoring and troubleshooting purposes.
> 
> Yes, I know this but I think there is a lot more thought required before deciding to augment this with another API for the container environment. There are a couple of things to explore.

@AlanBateman @jerboaa @poonamparhar @DamonFool 
Thanks for review.
I add mBeans using the registerMBean method.
We can get configuration information through JConsole, JMX exporter

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

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

From stuefe at openjdk.org  Thu Jul 14 03:39:58 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 14 Jul 2022 03:39:58 GMT
Subject: RFR: 8290218: AIX build failure by JDK-8289780 [v2]
In-Reply-To: <a1o0L2UhO4OdtX5L4aAri_8auJ8mPGroKhHbnXIp7o0=.bad78999-9152-45c4-a41f-061afd2ddfc9@github.com>
References: <gy3uYyZWqfSIhQY70GXvCeZyYzof-lmKft4FxLlAIk8=.3ebb407e-48a7-4073-a286-b2301ca6295a@github.com>
 <a1o0L2UhO4OdtX5L4aAri_8auJ8mPGroKhHbnXIp7o0=.bad78999-9152-45c4-a41f-061afd2ddfc9@github.com>
Message-ID: <xtuyau8EQNioRWHsBElFQlzDm20dFIAag8RoJ0QOoyk=.a7acb67a-4a47-47c2-8c00-0e34c4ae5bef@github.com>

On Thu, 14 Jul 2022 00:42:55 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> AIX build was failed by following messages:
>> 
>> * For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
>> ld: 0711-317 ERROR: Undefined symbol: collector_func_load
>> ld: 0711-317 ERROR: Undefined symbol: .collector_func_load
>> ld: 0711-344 See the loadmap file /home/jdkbld/git/jdk/build/aix-ppc64-server-release/hotspot/variant-server/libjvm/objs/libjvm.loadmap for more information.
>> 
>> In my investigation, [JDK-8289780](https://bugs.openjdk.org/browse/JDK-8289780) affects this issue on src/hotspot/share/prims/forte.cpp.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290218: AIX build failure by JDK-8289780

LGTM

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

Marked as reviewed by stuefe (Reviewer).

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

From itakiguchi at openjdk.org  Thu Jul 14 04:39:57 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 14 Jul 2022 04:39:57 GMT
Subject: Integrated: 8290218: AIX build failure by JDK-8289780
In-Reply-To: <gy3uYyZWqfSIhQY70GXvCeZyYzof-lmKft4FxLlAIk8=.3ebb407e-48a7-4073-a286-b2301ca6295a@github.com>
References: <gy3uYyZWqfSIhQY70GXvCeZyYzof-lmKft4FxLlAIk8=.3ebb407e-48a7-4073-a286-b2301ca6295a@github.com>
Message-ID: <prLAkFptxUx6bLqogbCwjQlQnx9XzG8B6nJpOMAsXM8=.fe9344ae-2d18-494d-8b04-061e84e89b20@github.com>

On Wed, 13 Jul 2022 16:55:38 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> AIX build was failed by following messages:
> 
> * For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
> ld: 0711-317 ERROR: Undefined symbol: collector_func_load
> ld: 0711-317 ERROR: Undefined symbol: .collector_func_load
> ld: 0711-344 See the loadmap file /home/jdkbld/git/jdk/build/aix-ppc64-server-release/hotspot/variant-server/libjvm/objs/libjvm.loadmap for more information.
> 
> In my investigation, [JDK-8289780](https://bugs.openjdk.org/browse/JDK-8289780) affects this issue on src/hotspot/share/prims/forte.cpp.

This pull request has now been integrated.

Changeset: 5d588eda
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d588eda97aeab0c8fda6ad8d332d6a4cae31b05
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8290218: AIX build failure by JDK-8289780

Reviewed-by: iklam, stuefe

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

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

From alanb at openjdk.org  Thu Jul 14 07:08:54 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Jul 2022 07:08:54 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
 <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>
 <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com>
 <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com>
Message-ID: <YT5mMdSv0_0QEHDOdlbC5ZxcW9NzdJ4s7rw3LprVFcY=.cd270cc0-ff00-4fd9-98ab-5f04e9a2ec55@github.com>

On Thu, 14 Jul 2022 03:32:35 GMT, xpbob <duke at openjdk.org> wrote:

> Thanks for review.
> I add mBeans using the registerMBean method.
> We can get configuration information through JConsole, JMX exporter

This iteration is a bit confusing because it adds a public interface to java.lang.management. For the registerMBean prototype then you shouldn't need any API changes to the java.management module.

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

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

From duke at openjdk.org  Thu Jul 14 07:57:02 2022
From: duke at openjdk.org (xpbob)
Date: Thu, 14 Jul 2022 07:57:02 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <YT5mMdSv0_0QEHDOdlbC5ZxcW9NzdJ4s7rw3LprVFcY=.cd270cc0-ff00-4fd9-98ab-5f04e9a2ec55@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
 <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>
 <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com>
 <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com>
 <YT5mMdSv0_0QEHDOdlbC5ZxcW9NzdJ4s7rw3LprVFcY=.cd270cc0-ff00-4fd9-98ab-5f04e9a2ec55@github.com>
Message-ID: <yUsBFrXEsygGiKEzTmAPzYPnA5sYDi78BbgMRyVcDkc=.3772781b-55d4-48cc-b1b9-7fa78d494bb6@github.com>

On Thu, 14 Jul 2022 07:05:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Thanks for review.
> > I add mBeans using the registerMBean method.
> > We can get configuration information through JConsole, JMX exporter
> 
> This iteration is a bit confusing because it adds a public interface to java.lang.management. For the registerMBean prototype then you shouldn't need any API changes to the java.management module.
@AlanBateman Thanks for review.
The runtime information is already fetched through the OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the configuration data.Such an interface could be part of management.

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

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

From alanb at openjdk.org  Thu Jul 14 08:27:01 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Jul 2022 08:27:01 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <yUsBFrXEsygGiKEzTmAPzYPnA5sYDi78BbgMRyVcDkc=.3772781b-55d4-48cc-b1b9-7fa78d494bb6@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
 <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>
 <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com>
 <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com>
 <YT5mMdSv0_0QEHDOdlbC5ZxcW9NzdJ4s7rw3LprVFcY=.cd270cc0-ff00-4fd9-98ab-5f04e9a2ec55@github.com>
 <yUsBFrXEsygGiKEzTmAPzYPnA5sYDi78BbgMRyVcDkc=.3772781b-55d4-48cc-b1b9-7fa78d494bb6@github.com>
Message-ID: <0sZ6kqzuwDz6k4TFqvhwdWgR5wK0epStqZ7dD5OOH4I=.9c98a700-84d0-49d1-9a43-fdd645be5b61@github.com>

On Thu, 14 Jul 2022 07:54:56 GMT, xpbob <duke at openjdk.org> wrote:

> Thanks for review. The runtime information is already fetched through the OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the configuration data.Such an interface could be part of management.

I don't think this feature should be adding to the standard API. Can you move ContainerInfoMXBean to sun.management and do some experiments?

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

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

From duke at openjdk.org  Thu Jul 14 12:24:03 2022
From: duke at openjdk.org (xpbob)
Date: Thu, 14 Jul 2022 12:24:03 GMT
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <0sZ6kqzuwDz6k4TFqvhwdWgR5wK0epStqZ7dD5OOH4I=.9c98a700-84d0-49d1-9a43-fdd645be5b61@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
 <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>
 <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com>
 <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com>
 <YT5mMdSv0_0QEHDOdlbC5ZxcW9NzdJ4s7rw3LprVFcY=.cd270cc0-ff00-4fd9-98ab-5f04e9a2ec55@github.com>
 <yUsBFrXEsygGiKEzTmAPzYPnA5sYDi78BbgMRyVcDkc=.3772781b-55d4-48cc-b1b9-7fa78d494bb6@github.com>
 <0sZ6kqzuwDz6k4TFqvhwdWgR5wK0epStqZ7dD5OOH4I=.9c98a700-84d0-49d1-9a43-fdd645be5b61@github.com>
Message-ID: <sCxKtOd53bdgKInM9UxKev-yAADbxcvUKICuSpgxTh4=.1282c6ee-f6fc-48f9-878e-dae568732c13@github.com>

On Thu, 14 Jul 2022 08:23:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > Thanks for review.
>>> > I add mBeans using the registerMBean method.
>>> > We can get configuration information through JConsole, JMX exporter
>>> 
>>> This iteration is a bit confusing because it adds a public interface to java.lang.management. For the registerMBean prototype then you shouldn't need any API changes to the java.management module.
>> @AlanBateman Thanks for review.
>> The runtime information is already fetched through the OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the configuration data.Such an interface could be part of management.
>
>> Thanks for review. The runtime information is already fetched through the OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the configuration data.Such an interface could be part of management.
> 
> I don't think this feature should be adding to the standard API. Can you move ContainerInfoMXBean to sun.management and do some experiments?

Thanks for review. @AlanBateman 
I move ContainerInfoMXBean to sun.management, the data is not available,
![??](https://user-images.githubusercontent.com/7837910/178977950-3a058e90-86cc-4630-b496-5249f3e34a9f.png)
The red character indicates that it is not available

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

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

From larry.cable at oracle.com  Thu Jul 14 13:54:12 2022
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 14 Jul 2022 06:54:12 -0700
Subject: RFR: 8289711: Add container configuration data to mbeans [v2]
In-Reply-To: <0sZ6kqzuwDz6k4TFqvhwdWgR5wK0epStqZ7dD5OOH4I=.9c98a700-84d0-49d1-9a43-fdd645be5b61@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <v55wYacSdddiCJdaUKaDRMWJNwOJm7WsXN8G55a-4Dg=.250af122-c53a-4d5c-ba4d-fe7fede22d60@github.com>
 <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com>
 <LHML7kAQGdKpe2piphCl1NEGOp6cIsw3V3vePj7tKV4=.f18378bd-c84d-487c-893d-d6f4f6fcf5c6@github.com>
 <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com>
 <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com>
 <YT5mMdSv0_0QEHDOdlbC5ZxcW9NzdJ4s7rw3LprVFcY=.cd270cc0-ff00-4fd9-98ab-5f04e9a2ec55@github.com>
 <yUsBFrXEsygGiKEzTmAPzYPnA5sYDi78BbgMRyVcDkc=.3772781b-55d4-48cc-b1b9-7fa78d494bb6@github.com>
 <0sZ6kqzuwDz6k4TFqvhwdWgR5wK0epStqZ7dD5OOH4I=.9c98a700-84d0-49d1-9a43-fdd645be5b61@github.com>
Message-ID: <2684c46b-45fa-3d42-a051-f1c6cbccddf3@oracle.com>

agree Alan

On 7/14/22 1:27 AM, Alan Bateman wrote:
> On Thu, 14 Jul 2022 07:54:56 GMT, xpbob <duke at openjdk.org> wrote:
>
>> Thanks for review. The runtime information is already fetched through the OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the configuration data.Such an interface could be part of management.
> I don't think this feature should be adding to the standard API. Can you move ContainerInfoMXBean to sun.management and do some experiments?
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/9372


From iklam at openjdk.org  Thu Jul 14 21:44:06 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 14 Jul 2022 21:44:06 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v6]
In-Reply-To: <atkEWyynzUQUlk7KK-NOovTxQWdMO8fQojBmptbXVZk=.00d66dcd-92ba-4819-9ca8-f65838e43ec2@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <atkEWyynzUQUlk7KK-NOovTxQWdMO8fQojBmptbXVZk=.00d66dcd-92ba-4819-9ca8-f65838e43ec2@github.com>
Message-ID: <F6-4Q9qI2_YunouWTk3lE3rfJTKCQfltGmO_w8XwrdQ=.87e5f7a0-b967-4796-ae22-b7e8f79bcade@github.com>

On Tue, 12 Jul 2022 22:39:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
>> 
>> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
>> 
>> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
>> 
>> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
>> 
>> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add errno to log
>  - added debug log and tweaked comment

@jerboaa could you take a look? Thanks.

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

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

From duke at openjdk.org  Thu Jul 14 22:09:43 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 14 Jul 2022 22:09:43 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version
Message-ID: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>

This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").

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

Commit messages:
 - Updated copyright header.
 - Converted FileDescriptorCount shell tests to java tests.

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

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

From lmesnik at openjdk.org  Thu Jul 14 22:26:02 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Jul 2022 22:26:02 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version
In-Reply-To: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
Message-ID: <D9MLEUYUhBObN62xmYOzVFfrerLpo7rLIMaSA1RKTCQ=.1e9b422e-3e52-4501-be1a-b0090bf6d1dd@github.com>

On Thu, 14 Jul 2022 21:56:57 GMT, Bill Huang <duke at openjdk.org> wrote:

> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").

test/jdk/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.java line 29:

> 27:  * @summary Basic unit test of UnixOperatingSystemMXBean.getMaxFileDescriptorCount()
> 28:  * @author  Steve Bohne
> 29:  * @requires (os.family=="linux")

please add spaces, braces are not required, see examples in jtreg tests
@requires os.family == "linux"

test/jdk/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.java line 31:

> 29:  * @requires (os.family=="linux")
> 30:  *
> 31:  * @run main/othervm GetMaxFileDescriptorCount

is othervm required here?

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

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

From duke at openjdk.org  Thu Jul 14 22:41:02 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 14 Jul 2022 22:41:02 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version
In-Reply-To: <D9MLEUYUhBObN62xmYOzVFfrerLpo7rLIMaSA1RKTCQ=.1e9b422e-3e52-4501-be1a-b0090bf6d1dd@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <D9MLEUYUhBObN62xmYOzVFfrerLpo7rLIMaSA1RKTCQ=.1e9b422e-3e52-4501-be1a-b0090bf6d1dd@github.com>
Message-ID: <e7OlF5ABQXX-uUA9zR1RACEfcze_4Fu37BzM2PLEFkg=.339b69ba-de22-47cd-a877-68bcba0b67a9@github.com>

On Thu, 14 Jul 2022 22:21:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").
>
> test/jdk/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.java line 31:
> 
>> 29:  * @requires (os.family=="linux")
>> 30:  *
>> 31:  * @run main/othervm GetMaxFileDescriptorCount
> 
> is othervm required here?

No, it is not needed. I will remove it.

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

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

From duke at openjdk.org  Thu Jul 14 22:46:09 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 14 Jul 2022 22:46:09 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v2]
In-Reply-To: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
Message-ID: <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>

> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Removed othervm option and fixed @requires coding style.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9503/files
  - new: https://git.openjdk.org/jdk/pull/9503/files/69ed7ea8..13d99c69

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

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

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

From lmesnik at openjdk.org  Thu Jul 14 22:46:10 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Jul 2022 22:46:10 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v2]
In-Reply-To: <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
Message-ID: <UIJXKjdyBSEo3rv44_E1fmf2Xn52pygtAozJNiavd_E=.307d7a49-fe54-46cf-afd2-f1069b47e9ac@github.com>

On Thu, 14 Jul 2022 22:42:45 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed othervm option and fixed @requires coding style.

Marked as reviewed by lmesnik (Reviewer).

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

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

From lmesnik at openjdk.org  Thu Jul 14 22:51:05 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Jul 2022 22:51:05 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v2]
In-Reply-To: <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
Message-ID: <Vw9owKoQugbyyW6n3ms_BK79hj7SZ7DDDFg1uxXK51U=.2f0beaca-643b-4723-9e27-276aea25924d@github.com>

On Thu, 14 Jul 2022 22:46:09 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed othervm option and fixed @requires coding style.

There are some possible cleanups in the tests (comments, unused args, variable name style) but seem out of scope for this PR.

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

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

From duke at openjdk.org  Thu Jul 14 22:58:03 2022
From: duke at openjdk.org (Bill Huang)
Date: Thu, 14 Jul 2022 22:58:03 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v2]
In-Reply-To: <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
Message-ID: <hg1JStqaCi-rspxgWAWUgoPaceM5EYvHC4xaTW_RR94=.5793e3c2-71ff-4349-a9de-9fa789f4db48@github.com>

On Thu, 14 Jul 2022 22:46:09 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed othervm option and fixed @requires coding style.

It is not out of scope. I can do the clean up along with this PR. Can you please give me some hints what could be optimized?

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

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

From amenkov at openjdk.org  Thu Jul 14 23:04:11 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 14 Jul 2022 23:04:11 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v2]
In-Reply-To: <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
Message-ID: <qJ3tkayugc_l9JlJl9sa9WRsKiJ9tDRBXTS3NMixcfE=.08849111-8618-4dbd-8ac5-b76b8150d02c@github.com>

On Thu, 14 Jul 2022 22:46:09 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed othervm option and fixed @requires coding style.

Marked as reviewed by amenkov (Reviewer).

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

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

From lmesnik at openjdk.org  Thu Jul 14 23:04:11 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 14 Jul 2022 23:04:11 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v2]
In-Reply-To: <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
Message-ID: <NQDLCKF7Apjs69rZNNpdWBbwBcJ_xY83pscOd5MVXEs=.97db0e26-5670-45a2-b6e0-43059f8e8f04@github.com>

On Thu, 14 Jul 2022 22:46:09 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed othervm option and fixed @requires coding style.

The variables should use camelCase. Like min_count_for_pass -> minCountForPass 
Variable trace not needed, just print count always
The mention of Solaris should be removed from comments, also I don't know if instructions for manual testing are needed, but it would be better to say "to know actual value run smth".

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

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

From dholmes at openjdk.org  Fri Jul 15 01:59:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 15 Jul 2022 01:59:58 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v2]
In-Reply-To: <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
Message-ID: <xfwc_KNC6_sCcQAWzJ-IbmRzPo-4wlVOrpTHx2LIYy4=.64863c97-16c2-4a3b-b031-7ff7c2f7b8e6@github.com>

On Thu, 14 Jul 2022 22:46:09 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed othervm option and fixed @requires coding style.

Is the restriction to run on Linux actually still valid? Shouldn't this work on any of our Posix-like  platforms? I suspect you need to read "Linux" as "not Solaris or Windows" when looking at this test (and possibly others).

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

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

From sgehwolf at openjdk.org  Fri Jul 15 12:10:07 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 15 Jul 2022 12:10:07 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v6]
In-Reply-To: <atkEWyynzUQUlk7KK-NOovTxQWdMO8fQojBmptbXVZk=.00d66dcd-92ba-4819-9ca8-f65838e43ec2@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <atkEWyynzUQUlk7KK-NOovTxQWdMO8fQojBmptbXVZk=.00d66dcd-92ba-4819-9ca8-f65838e43ec2@github.com>
Message-ID: <pLFEZ9I9vR37BW3ida0S7qXoINpCCCPFhVgtPcpZzxs=.7aee52d7-23a6-48bb-8b33-075788b6bedb@github.com>

On Tue, 12 Jul 2022 22:39:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
>> 
>> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
>> 
>> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
>> 
>> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
>> 
>> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add errno to log
>  - added debug log and tweaked comment

test/hotspot/jtreg/containers/docker/ShareTmpDir.java line 124:

> 122:             // This should be the common case -- the first started process in a container should
> 123:             // have pid==1.
> 124:             // One of the two contains must fail to create the hsperf file.

`s/contains/containers/`

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

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

From sgehwolf at openjdk.org  Fri Jul 15 12:20:06 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 15 Jul 2022 12:20:06 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v6]
In-Reply-To: <atkEWyynzUQUlk7KK-NOovTxQWdMO8fQojBmptbXVZk=.00d66dcd-92ba-4819-9ca8-f65838e43ec2@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <atkEWyynzUQUlk7KK-NOovTxQWdMO8fQojBmptbXVZk=.00d66dcd-92ba-4819-9ca8-f65838e43ec2@github.com>
Message-ID: <FcOevI2ttW8SNrqhcV0wj9y1ofXvPSTuj0KWoETIW8A=.32e12426-c806-4adc-adf0-1c5a8108b912@github.com>

On Tue, 12 Jul 2022 22:39:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
>> 
>> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
>> 
>> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
>> 
>> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
>> 
>> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add errno to log
>  - added debug log and tweaked comment

LGTM. My manual tests of this work as expected as well.


$ podman run --rm -ti --userns=keep-id -u $(id -u) -v $(pwd)/shared-tmp:/tmp:z -v /disk/openjdk/upstream-sources/git/jdk-jdk/build/linux-x86_64-server-release/images/jdk:/opt/jdk:z -v $(pwd)/test:/opt/test:z fedora:36 /opt/jdk/bin/java -Xlog:perf+memops=debug -cp /opt/test HelloWait
[0.001s][debug][perf,memops] PerfDataMemorySize = 32768, os::vm_allocation_granularity = 4096, adjusted size = 32768
[0.001s][info ][perf,memops] Trying to open /tmp/hsperfdata_sgehwolf/1
[0.001s][info ][perf,memops] Successfully opened
[0.001s][debug][perf,memops] PerfMemory created: address = 0x00007fac290dd000, size = 32768
Hello!
$ podman run --rm -ti --userns=keep-id -u $(id -u) -v $(pwd)/shared-tmp:/tmp:z -v /disk/openjdk/upstream-sources/git/jdk-jdk/build/linux-x86_64-server-release/images/jdk:/opt/jdk:z -v $(pwd)/test:/opt/test:z fedora:36 /opt/jdk/bin/java -Xlog:perf+memops=debug -cp /opt/test HelloWait
[0.001s][debug][perf,memops] PerfDataMemorySize = 32768, os::vm_allocation_granularity = 4096, adjusted size = 32768
[0.001s][debug][perf,memops] flock for stale file check failed for /tmp/hsperfdata_sgehwolf/1
[0.001s][info ][perf,memops] Trying to open /tmp/hsperfdata_sgehwolf/1
[0.001s][warning][perf,memops] Cannot use file /tmp/hsperfdata_sgehwolf/1 because it is locked by another process (errno = 11)
[0.001s][debug  ][perf,memops] PerfMemory created: address = 0x00007fc60bc79000, size = 32768
Hello!

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

Marked as reviewed by sgehwolf (Reviewer).

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

From duke at openjdk.org  Fri Jul 15 16:49:50 2022
From: duke at openjdk.org (Bill Huang)
Date: Fri, 15 Jul 2022 16:49:50 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v2]
In-Reply-To: <xfwc_KNC6_sCcQAWzJ-IbmRzPo-4wlVOrpTHx2LIYy4=.64863c97-16c2-4a3b-b031-7ff7c2f7b8e6@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
 <xfwc_KNC6_sCcQAWzJ-IbmRzPo-4wlVOrpTHx2LIYy4=.64863c97-16c2-4a3b-b031-7ff7c2f7b8e6@github.com>
Message-ID: <5ReLEM9TnAX_MEkB7Tc56BDXf7ASUgUhpcZ0ARZI7Kg=.2aea5792-5bf6-4853-990b-42c8fb824313@github.com>

On Fri, 15 Jul 2022 01:56:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed othervm option and fixed @requires coding style.
>
> Is the restriction to run on Linux actually still valid? Shouldn't this work on any of our Posix-like  platforms? I suspect you need to read "Linux" as "not Solaris or Windows" when looking at this test (and possibly others).

@dholmes-ora I agreed. These tests should be working on any unix-based system. I can change the restriction to be not Windows. The other question is should we include Solaris as it is also unix based.

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

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

From duke at openjdk.org  Fri Jul 15 17:55:55 2022
From: duke at openjdk.org (Bill Huang)
Date: Fri, 15 Jul 2022 17:55:55 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v3]
In-Reply-To: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
Message-ID: <CC1-Z8C5UidgTv6havh3cQzrLsm6MiJe0aq7tPJ90FE=.bf2015ff-0126-4273-ba0e-dc42527b3d0b@github.com>

> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Cleaned up tests and changed OS restriction to not windows.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9503/files
  - new: https://git.openjdk.org/jdk/pull/9503/files/13d99c69..76c46d03

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

  Stats: 53 lines in 2 files changed: 1 ins; 34 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9503.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9503/head:pull/9503

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

From duke at openjdk.org  Fri Jul 15 18:02:58 2022
From: duke at openjdk.org (Bill Huang)
Date: Fri, 15 Jul 2022 18:02:58 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v2]
In-Reply-To: <NQDLCKF7Apjs69rZNNpdWBbwBcJ_xY83pscOd5MVXEs=.97db0e26-5670-45a2-b6e0-43059f8e8f04@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
 <NQDLCKF7Apjs69rZNNpdWBbwBcJ_xY83pscOd5MVXEs=.97db0e26-5670-45a2-b6e0-43059f8e8f04@github.com>
Message-ID: <h7hej0r1h1CFdh5d5GMVSrkX2oimgaZO5FOUOhgEw_4=.173bf4dc-6d61-43b2-9bb0-9f1a68e78ea8@github.com>

On Thu, 14 Jul 2022 23:01:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed othervm option and fixed @requires coding style.
>
> The variables should use camelCase. Like min_count_for_pass -> minCountForPass 
> Variable trace not needed, just print count always
> The mention of Solaris should be removed from comments, also I don't know if instructions for manual testing are needed, but it would be better to say "to know actual value run smth".

@lmesnik I've completely removed the comments for manual tests because I don't think manual tests are necessary in this scenario. If the purpose of the tests is to compare FD count from the Java API to the system properties, it can be done in automated tests. Potential test cases could be opening a new file and observing the opened FD count for increment, or checking the value from the system call. We can address this in a separate ticket if we want.

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

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

From duke at openjdk.org  Fri Jul 15 18:09:08 2022
From: duke at openjdk.org (Bill Huang)
Date: Fri, 15 Jul 2022 18:09:08 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v4]
In-Reply-To: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
Message-ID: <hcecRnt04PpJe1DA99Q5HBi_Sx6bzbZw7XJSzCZ5Kok=.8d1a3c03-1099-4a19-9d60-4a5f259c50a9@github.com>

> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Removed unwanted whitespaces.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9503/files
  - new: https://git.openjdk.org/jdk/pull/9503/files/76c46d03..fed0b270

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

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

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

From lmesnik at openjdk.org  Fri Jul 15 18:31:04 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 15 Jul 2022 18:31:04 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v4]
In-Reply-To: <hcecRnt04PpJe1DA99Q5HBi_Sx6bzbZw7XJSzCZ5Kok=.8d1a3c03-1099-4a19-9d60-4a5f259c50a9@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <hcecRnt04PpJe1DA99Q5HBi_Sx6bzbZw7XJSzCZ5Kok=.8d1a3c03-1099-4a19-9d60-4a5f259c50a9@github.com>
Message-ID: <q0EyagVUrUDKcuevkKzoyCsYCHLeBVtRRLp3np2Hs7w=.0df2d1a3-c768-4e35-8fdd-f48a8b09b345@github.com>

On Fri, 15 Jul 2022 18:09:08 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unwanted whitespaces.

Marked as reviewed by lmesnik (Reviewer).

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

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

From amenkov at openjdk.org  Fri Jul 15 21:40:03 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 15 Jul 2022 21:40:03 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v4]
In-Reply-To: <hcecRnt04PpJe1DA99Q5HBi_Sx6bzbZw7XJSzCZ5Kok=.8d1a3c03-1099-4a19-9d60-4a5f259c50a9@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <hcecRnt04PpJe1DA99Q5HBi_Sx6bzbZw7XJSzCZ5Kok=.8d1a3c03-1099-4a19-9d60-4a5f259c50a9@github.com>
Message-ID: <HqdEilMO_QBY4G7UlxagMOaIyg7vfNLjv3hwtJQVnlU=.f8e3ef42-87db-4f55-b045-f7befa632ad3@github.com>

On Fri, 15 Jul 2022 18:09:08 GMT, Bill Huang <duke at openjdk.org> wrote:

>> This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux").
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unwanted whitespaces.

Still good to me

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

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

From weijun at openjdk.org  Sat Jul 16 13:46:58 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 16 Jul 2022 13:46:58 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v3]
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <UqMU7DhaoXfwQOo0lW8mUdfpTkZs9ri5ZomMCTeoUrc=.fe42548b-22ff-4874-b2a2-02ae147766fc@github.com>

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9348/files
  - new: https://git.openjdk.org/jdk/pull/9348/files/810a0114..86c1fd65

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

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

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

From dholmes at openjdk.org  Sun Jul 17 23:03:37 2022
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 17 Jul 2022 23:03:37 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
Message-ID: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>

Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.

All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:

The Java manpage was missing updates from:
- [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.

The Java manpage has slight formatting differences from:
- [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
- [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS

The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)


The keytool manpage was missing updates from:
- [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
- [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA

The jar manpage was missing updates from:
- [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)

The jarsigner manpage was missing updates from:
- [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
- [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA

The javadoc manpage was missing updates from:
- [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option

The jmod manpage was missing updates from:
- [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)

The jpackage manpage was missing updates from:
- [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
- [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
- [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code

The jshell manpage was missing updates from:
- [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

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

Commit messages:
 - 8278274: Update nroff pages in JDK 19 before RC

Changes: https://git.openjdk.org/jdk19/pull/145/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=145&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8278274
  Stats: 515 lines in 28 files changed: 431 ins; 16 del; 68 mod
  Patch: https://git.openjdk.org/jdk19/pull/145.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/145/head:pull/145

PR: https://git.openjdk.org/jdk19/pull/145

From dholmes at openjdk.org  Mon Jul 18 02:05:48 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Jul 2022 02:05:48 GMT
Subject: RFR: 8290180: Convert
 com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to
 jtreg java version [v2]
In-Reply-To: <5ReLEM9TnAX_MEkB7Tc56BDXf7ASUgUhpcZ0ARZI7Kg=.2aea5792-5bf6-4853-990b-42c8fb824313@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
 <4JMcN4QLYZVP1DmL8iAvHVj_Uw8GSRngxZtamOh6caU=.0855f1b8-3b07-4d4f-988a-f832a8b9cd88@github.com>
 <xfwc_KNC6_sCcQAWzJ-IbmRzPo-4wlVOrpTHx2LIYy4=.64863c97-16c2-4a3b-b031-7ff7c2f7b8e6@github.com>
 <5ReLEM9TnAX_MEkB7Tc56BDXf7ASUgUhpcZ0ARZI7Kg=.2aea5792-5bf6-4853-990b-42c8fb824313@github.com>
Message-ID: <E3QWbXWBLFQm8fHsDBNnwgVtTRyWO4orH4BvI8Svw0w=.8ba3eb75-1be1-40c0-9454-ae203ca8cd67@github.com>

On Fri, 15 Jul 2022 16:46:43 GMT, Bill Huang <duke at openjdk.org> wrote:

> The other question is should we include Solaris as it is also unix based.

@bwhuang-us there is no Solaris support in mainline.

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

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

From iklam at openjdk.org  Mon Jul 18 03:25:18 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 18 Jul 2022 03:25:18 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v7]
In-Reply-To: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
Message-ID: <INHTxw8T3_iyQy6URWN5YT3wDyFbL8bnEQk33kqSFKw=.ec0e1946-51fc-4a3e-ad16-86b024bd31f6@github.com>

> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
> 
> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
> 
> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
> 
> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
> 
> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.

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

 - Merge branch 'master' of https://github.com/openjdk/jdk into 8286030-avoid-jvm-crash-when-containers-share-tmp-dir
 - Fixed typo in comments
 - add errno to log
 - added debug log and tweaked comment
 - fixed typo
 - added more comments
 - Simplified code and improved comments
 - @tstuefe comments
 - Merge branch 'master' into 8286030-avoid-jvm-crash-when-containers-share-tmp-dir
 - Cleaned up comments and avoid using the word "resource" to describe the shared mem file
 - ... and 5 more: https://git.openjdk.org/jdk/compare/7575df9c...efc00f6e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9406/files
  - new: https://git.openjdk.org/jdk/pull/9406/files/ecac352b..efc00f6e

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

  Stats: 85601 lines in 1888 files changed: 43830 ins; 26943 del; 14828 mod
  Patch: https://git.openjdk.org/jdk/pull/9406.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9406/head:pull/9406

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

From iklam at openjdk.org  Mon Jul 18 04:13:37 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 18 Jul 2022 04:13:37 GMT
Subject: RFR: 8286030: Avoid JVM crash when containers share the same /tmp
 dir [v6]
In-Reply-To: <qgrzlW5Nqvl_BvIyvLtffzpAU2vQP7kfxl237iV9N3Y=.5ebd35c6-f849-4deb-9fae-4df4a5013ff7@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
 <atkEWyynzUQUlk7KK-NOovTxQWdMO8fQojBmptbXVZk=.00d66dcd-92ba-4819-9ca8-f65838e43ec2@github.com>
 <qgrzlW5Nqvl_BvIyvLtffzpAU2vQP7kfxl237iV9N3Y=.5ebd35c6-f849-4deb-9fae-4df4a5013ff7@github.com>
Message-ID: <OzYfsi74Nr3qSjUIgx26WdGISu2mgBKl2-rAd6BWjN0=.92456eb9-5bf5-4cee-8d73-a4f38db1a128@github.com>

On Tue, 12 Jul 2022 18:56:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add errno to log
>>  - added debug log and tweaked comment
>
> Looks good!

Thanks to @tstuefe and @jerboaa for the review.

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

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

From iklam at openjdk.org  Mon Jul 18 04:13:38 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 18 Jul 2022 04:13:38 GMT
Subject: Integrated: 8286030: Avoid JVM crash when containers share the same
 /tmp dir
In-Reply-To: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
References: <yIJMqTz0YEzjYO6T5A6qB0biP2qQIc0xJBxsuOocvT0=.02e4c325-8029-4ebf-abf9-7b4398841648@github.com>
Message-ID: <cThmu1iVTrs-A-lYds6gnNhJeyjrEtvDmvWBhhZ1Rkc=.527d441e-6826-4139-b129-fc415c567329@github.com>

On Thu, 7 Jul 2022 06:01:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
> 
> This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883)
> 
> Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`.
> 
> I kept the use of `kill()` for stale file detection to be compatible with older JVMs.
> 
> I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead.

This pull request has now been integrated.

Changeset: 84f23149
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84f23149e22561173feb0e34bca31a7345b43c89
Stats:     324 lines in 3 files changed: 267 ins; 27 del; 30 mod

8286030: Avoid JVM crash when containers share the same /tmp dir

Reviewed-by: stuefe, sgehwolf

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

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

From zgu at openjdk.org  Mon Jul 18 12:43:16 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 18 Jul 2022 12:43:16 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3]
In-Reply-To: <Z-sUd4fUs58nvGk-qtbMShPtZbo0rWp5Hz6fiibzMgs=.aa3d0953-810c-40a6-a824-16e1ca0b1138@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <Y83Zl-pBC2BuAE20h7i0KihsUpZwNGMUuNrGKsGtJts=.6ffc3c80-cfe4-4913-acb6-dcab4f47db38@github.com>
 <Z-sUd4fUs58nvGk-qtbMShPtZbo0rWp5Hz6fiibzMgs=.aa3d0953-810c-40a6-a824-16e1ca0b1138@github.com>
Message-ID: <OAU1-burGu42p_P9n4LtF47UTyETs0tSxfC2u1AjvQg=.4d1be962-7d77-495a-83bd-5db624ec998a@github.com>

On Fri, 24 Jun 2022 09:08:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Zhengyu Gu 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 18 additional commits since the last revision:
>> 
>>  - Improve naming and cleanup
>>  - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event
>>  - v4
>>  - v3
>>  - v2
>>  - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event
>>  - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event
>>  - v0
>>  - v2
>>  - v1
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/4ef44ac3...559b4bf1
>
> In general, the JVMTI fixes look okay to me at the first glance. Will make another pass tomorrow.

@sspitsyn and @coleenp 

Could you please review? Thanks!

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

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

From jjg at openjdk.org  Mon Jul 18 15:24:06 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 18 Jul 2022 15:24:06 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
Message-ID: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>

On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
> 
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
> 
> The Java manpage was missing updates from:
> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
> 
> The Java manpage has slight formatting differences from:
> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
> 
> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
> 
> 
> The keytool manpage was missing updates from:
> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The jar manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jarsigner manpage was missing updates from:
> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The javadoc manpage was missing updates from:
> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
> 
> The jmod manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jpackage manpage was missing updates from:
> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
> 
> The jshell manpage was missing updates from:
> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

src/java.base/share/man/keytool.1 line 456:

> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
> 455: keystore.
> 456: This option is used to sign the certificate with the signer?s private

Not a problem with this PR as such, but we still have a `?` character in the output.

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

PR: https://git.openjdk.org/jdk19/pull/145

From jjg at openjdk.org  Mon Jul 18 15:30:09 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 18 Jul 2022 15:30:09 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
Message-ID: <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>

On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
> 
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
> 
> The Java manpage was missing updates from:
> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
> 
> The Java manpage has slight formatting differences from:
> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
> 
> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
> 
> 
> The keytool manpage was missing updates from:
> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The jar manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jarsigner manpage was missing updates from:
> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The javadoc manpage was missing updates from:
> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
> 
> The jmod manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jpackage manpage was missing updates from:
> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
> 
> The jshell manpage was missing updates from:
> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

The version changes in each file look good (`19-ea` to `19`).
The changes for javadoc look good.

I looked over the other changes for other files, and while they look good, I cannot speak for their technical accuracy. That being said, this is an automated process deriving info from upstream, so is likely OK.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/145

From mullan at openjdk.org  Mon Jul 18 15:53:43 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 18 Jul 2022 15:53:43 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v3]
In-Reply-To: <UqMU7DhaoXfwQOo0lW8mUdfpTkZs9ri5ZomMCTeoUrc=.fe42548b-22ff-4874-b2a2-02ae147766fc@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <UqMU7DhaoXfwQOo0lW8mUdfpTkZs9ri5ZomMCTeoUrc=.fe42548b-22ff-4874-b2a2-02ae147766fc@github.com>
Message-ID: <1aNdi1otctsMilW_hV8c8KVYdrdnqqGF3pH4EjDf74M=.24bf0523-545a-4bba-9ef8-d3eb5bc21382@github.com>

On Sat, 16 Jul 2022 13:46:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comment

I can also review the CSR when it is ready.

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

Marked as reviewed by mullan (Reviewer).

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

From weijun at openjdk.org  Mon Jul 18 17:54:09 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 18 Jul 2022 17:54:09 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v3]
In-Reply-To: <UqMU7DhaoXfwQOo0lW8mUdfpTkZs9ri5ZomMCTeoUrc=.fe42548b-22ff-4874-b2a2-02ae147766fc@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <UqMU7DhaoXfwQOo0lW8mUdfpTkZs9ri5ZomMCTeoUrc=.fe42548b-22ff-4874-b2a2-02ae147766fc@github.com>
Message-ID: <BpA-ZGs_Y2Qe_8SCxpZa-IRUwwHlE_3cetmkgQgIjSA=.bcd1b6cb-0b8c-46f8-95f9-96006434cdfb@github.com>

On Sat, 16 Jul 2022 13:46:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comment

Thanks. CSR is filed at https://bugs.openjdk.org/browse/JDK-8290119. I've also written a release note at https://bugs.openjdk.org/browse/JDK-8290467. Please take a review.

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

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

From sspitsyn at openjdk.org  Mon Jul 18 18:58:13 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 18 Jul 2022 18:58:13 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3]
In-Reply-To: <OAU1-burGu42p_P9n4LtF47UTyETs0tSxfC2u1AjvQg=.4d1be962-7d77-495a-83bd-5db624ec998a@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <Y83Zl-pBC2BuAE20h7i0KihsUpZwNGMUuNrGKsGtJts=.6ffc3c80-cfe4-4913-acb6-dcab4f47db38@github.com>
 <Z-sUd4fUs58nvGk-qtbMShPtZbo0rWp5Hz6fiibzMgs=.aa3d0953-810c-40a6-a824-16e1ca0b1138@github.com>
 <OAU1-burGu42p_P9n4LtF47UTyETs0tSxfC2u1AjvQg=.4d1be962-7d77-495a-83bd-5db624ec998a@github.com>
Message-ID: <f-SV02DegOjHaGSYd3fqpSH1HdyVVuJ3IgbpkC6eIos=.7576e371-b08a-4b2d-a035-fe5cc8a84cf6@github.com>

On Mon, 18 Jul 2022 12:41:09 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> In general, the JVMTI fixes look okay to me at the first glance. Will make another pass tomorrow.
>
> @sspitsyn and @coleenp 
> 
> Could you please review? Thanks!

@zhengyu123
Yes, I'm looking at it.

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

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

From zgu at openjdk.org  Mon Jul 18 19:03:14 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 18 Jul 2022 19:03:14 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3]
In-Reply-To: <OAU1-burGu42p_P9n4LtF47UTyETs0tSxfC2u1AjvQg=.4d1be962-7d77-495a-83bd-5db624ec998a@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <Y83Zl-pBC2BuAE20h7i0KihsUpZwNGMUuNrGKsGtJts=.6ffc3c80-cfe4-4913-acb6-dcab4f47db38@github.com>
 <Z-sUd4fUs58nvGk-qtbMShPtZbo0rWp5Hz6fiibzMgs=.aa3d0953-810c-40a6-a824-16e1ca0b1138@github.com>
 <OAU1-burGu42p_P9n4LtF47UTyETs0tSxfC2u1AjvQg=.4d1be962-7d77-495a-83bd-5db624ec998a@github.com>
Message-ID: <nWlrTXf34gMOopV8uHoiX0FcQ-KHNaC7hhg0aq5PrGM=.2f994582-f050-4222-823d-d671fddac73a@github.com>

On Mon, 18 Jul 2022 12:41:09 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> In general, the JVMTI fixes look okay to me at the first glance. Will make another pass tomorrow.
>
> @sspitsyn and @coleenp 
> 
> Could you please review? Thanks!

> @zhengyu123 Yes, I'm looking at it.

Thanks, @sspitsyn

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

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

From coleenp at openjdk.org  Mon Jul 18 20:09:23 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 18 Jul 2022 20:09:23 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
Message-ID: <vXiwlpM2qmHHwbL3R8wJl2FA672oReZ4NJfyBtLKTHk=.75948d35-5bf8-4b68-999e-ea7c8d23b7d5@github.com>

On Tue, 12 Jul 2022 22:02:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a bug

I read the JvmtiTagMap changes. I had a couple of questions, but basically looks okay.

src/hotspot/share/prims/jvmtiTagMap.cpp line 1223:

> 1221:       MonitorLocker ml(lock(), Mutex::_no_safepoint_check_flag);
> 1222:       // If another thread is posting events, let it finish
> 1223:       bool posting = _posting_events;

Should this be volatile or use OrderAccess::load_acquire() so it's reread?

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

Marked as reviewed by coleenp (Reviewer).

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

From coleenp at openjdk.org  Mon Jul 18 20:09:32 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 18 Jul 2022 20:09:32 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v11]
In-Reply-To: <94jebIPMnMRr3obVGKOyo79vlzdoqzpDuI2-lkicel4=.705ed9cc-bfd6-4ce2-ba6c-e24949575f69@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <94jebIPMnMRr3obVGKOyo79vlzdoqzpDuI2-lkicel4=.705ed9cc-bfd6-4ce2-ba6c-e24949575f69@github.com>
Message-ID: <Pulzrlz4viSTCD90WOl8223_Rrs8SYQkZZ8WDvPg8t0=.ab175fe2-9f89-4d07-8825-2e296712d445@github.com>

On Thu, 30 Jun 2022 14:59:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu 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 27 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event
>  - Moved TestClassUnloadEvents.java to new location
>  - Fix test
>  - Use Shenandoah GC for debuggee for deterministic
>  - debug test
>  - Adding log for debugging test failure on Windows
>  - Removed HiddenClass test from Problem.txt and cleanup test
>  - Renamed eventHandler_synthesizeUnloadEvent
>  - v5
>  - Improve naming and cleanup
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/93213306...a07b3737

src/hotspot/share/prims/jvmtiTagMap.cpp line 1144:

> 1142:                                    heap_object_callback,
> 1143:                                    user_data);
> 1144:   Arena dead_object_arena(mtInternal);

This should be mtServiceability, not Internal.  This is an unusual use of Arena in the JVM. Does it get cleaned up completely when it goes out of scope?

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

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

From zgu at openjdk.org  Mon Jul 18 23:12:00 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 18 Jul 2022 23:12:00 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
Message-ID: <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>

> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
> 
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
> 
> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
> 
> It also performs `commonRef_compact()` only when there are classes unloaded.
> 
> New test failed about 20% without patch, none with patch.
> 
> **Update**
> There are significant changes from early patch. 
> 
> The new approach:
> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
> 
> The new solution breaks up into two steps:
> - Collect all dead object tags with lock
> - Transition to `_in_native` state and post object free events in one batch
> 
> This way, JDI event handler can process object free events upon arrivals without delay.
> 
> **Update 2**
> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
> 
> // This checks for posting and rehashing before operations that
> // this tagmap table.  The calls from a JavaThread only rehash, posting is
> // only done before heap walks.
> void JvmtiTagMap::check_hashmap(bool post_events) {
> 
> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
> Even the events are posted earlier in old code, but they are only processed after next GC cycle.

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Coleen's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9168/files
  - new: https://git.openjdk.org/jdk/pull/9168/files/6ef6c2f1..fce565d7

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

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

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

From zgu at openjdk.org  Mon Jul 18 23:12:08 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 18 Jul 2022 23:12:08 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v11]
In-Reply-To: <Pulzrlz4viSTCD90WOl8223_Rrs8SYQkZZ8WDvPg8t0=.ab175fe2-9f89-4d07-8825-2e296712d445@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <94jebIPMnMRr3obVGKOyo79vlzdoqzpDuI2-lkicel4=.705ed9cc-bfd6-4ce2-ba6c-e24949575f69@github.com>
 <Pulzrlz4viSTCD90WOl8223_Rrs8SYQkZZ8WDvPg8t0=.ab175fe2-9f89-4d07-8825-2e296712d445@github.com>
Message-ID: <wIRVMwaFhK-tcTKByRpXBF7hgesf_BuC1UOeOLR9_wg=.b2b9f110-adf5-4f40-94ef-e1e5fbe1b6ec@github.com>

On Thu, 30 Jun 2022 19:30:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Zhengyu Gu 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 27 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event
>>  - Moved TestClassUnloadEvents.java to new location
>>  - Fix test
>>  - Use Shenandoah GC for debuggee for deterministic
>>  - debug test
>>  - Adding log for debugging test failure on Windows
>>  - Removed HiddenClass test from Problem.txt and cleanup test
>>  - Renamed eventHandler_synthesizeUnloadEvent
>>  - v5
>>  - Improve naming and cleanup
>>  - ... and 17 more: https://git.openjdk.org/jdk/compare/b5c7df58...a07b3737
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 1144:
> 
>> 1142:                                    heap_object_callback,
>> 1143:                                    user_data);
>> 1144:   Arena dead_object_arena(mtInternal);
> 
> This should be mtServiceability, not Internal.  This is an unusual use of Arena in the JVM. Does it get cleaned up completely when it goes out of scope?

Changed mtInternal to mtServiceability.
Yes,  Arena's destructor calls `destruct_contents()`

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

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

From zgu at openjdk.org  Mon Jul 18 23:12:11 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 18 Jul 2022 23:12:11 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <vXiwlpM2qmHHwbL3R8wJl2FA672oReZ4NJfyBtLKTHk=.75948d35-5bf8-4b68-999e-ea7c8d23b7d5@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
 <vXiwlpM2qmHHwbL3R8wJl2FA672oReZ4NJfyBtLKTHk=.75948d35-5bf8-4b68-999e-ea7c8d23b7d5@github.com>
Message-ID: <wDScQ2_Gj7vPcpH43nFZOR0sqmV8HBfSv0uD80Jd_B4=.1df3dbe6-40a8-4ead-a2d1-d6af2e5ff74d@github.com>

On Mon, 18 Jul 2022 20:04:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix a bug
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 1223:
> 
>> 1221:       MonitorLocker ml(lock(), Mutex::_no_safepoint_check_flag);
>> 1222:       // If another thread is posting events, let it finish
>> 1223:       bool posting = _posting_events;
> 
> Should this be volatile or use OrderAccess::load_acquire() so it's reread?

No, setting and reading `_posting_events` are done under lock, so it is safe.

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

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

From amenkov at openjdk.org  Mon Jul 18 23:29:37 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 18 Jul 2022 23:29:37 GMT
Subject: RFR: 8286844: com/sun/jdi/RedefineCrossEvent.java failed with 1
 threads completed while VM suspended
Message-ID: <DfdQQXiu2Bjo25PDkNxfpubVT_DNn1RDOdBFia74Y9U=.646163d1-5281-45bd-adfc-167068a8f95a@github.com>

The test verifies that JDI threads are daemon threads.
But enumerating threads at breakpoint it performs sanity check that all threads returned by ThreadGroup.enumerate hasn't terminated.
But this is wrong assumption,  as the test enumerates _debugger_ threads and not _debuggee_ threads.

The fix drops this sanity check.

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

Commit messages:
 - removed incorrect check from the test

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

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

From dholmes at openjdk.org  Mon Jul 18 23:32:04 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Jul 2022 23:32:04 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>
Message-ID: <Bx5KJ0K1oEDxEkvQf_xBVYiL1foF38AVFPy9tLp6YTg=.f851a628-86b6-4edf-89b1-c91f13728a51@github.com>

On Mon, 18 Jul 2022 15:26:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
>> 
>> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
>> 
>> The Java manpage was missing updates from:
>> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
>> 
>> The Java manpage has slight formatting differences from:
>> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
>> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
>> 
>> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
>> 
>> 
>> The keytool manpage was missing updates from:
>> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
>> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
>> 
>> The jar manpage was missing updates from:
>> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
>> 
>> The jarsigner manpage was missing updates from:
>> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
>> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
>> 
>> The javadoc manpage was missing updates from:
>> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
>> 
>> The jmod manpage was missing updates from:
>> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
>> 
>> The jpackage manpage was missing updates from:
>> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
>> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
>> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
>> 
>> The jshell manpage was missing updates from:
>> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.
>
> The version changes in each file look good (`19-ea` to `19`).
> The changes for javadoc look good.
> 
> I looked over the other changes for other files, and while they look good, I cannot speak for their technical accuracy. That being said, this is an automated process deriving info from upstream, so is likely OK.

Thanks for the review @jonathan-gibbons ! I'll wait a day in case there are any further comments.

> src/java.base/share/man/keytool.1 line 456:
> 
>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
>> 455: keystore.
>> 456: This option is used to sign the certificate with the signer?s private
> 
> Not a problem with this PR as such, but we still have a `?` character in the output.

Yeah I spotted that too, but it would need to be fixed in source and nroff.  Must be some kind of "smart quote" from an editor. Do you think this needs to be fixed or just handle it in mainline?

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

PR: https://git.openjdk.org/jdk19/pull/145

From sspitsyn at openjdk.org  Tue Jul 19 02:31:40 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 19 Jul 2022 02:31:40 GMT
Subject: RFR: 8286844: com/sun/jdi/RedefineCrossEvent.java failed with 1
 threads completed while VM suspended
In-Reply-To: <DfdQQXiu2Bjo25PDkNxfpubVT_DNn1RDOdBFia74Y9U=.646163d1-5281-45bd-adfc-167068a8f95a@github.com>
References: <DfdQQXiu2Bjo25PDkNxfpubVT_DNn1RDOdBFia74Y9U=.646163d1-5281-45bd-adfc-167068a8f95a@github.com>
Message-ID: <RG10XkidgbwJ_l7F2Uk95g1RfN9dN0G_94umt7GeIgM=.07b588e0-ad6f-4d7e-9ae4-5317d6cce2fc@github.com>

On Mon, 18 Jul 2022 23:13:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test verifies that JDI threads are daemon threads.
> But enumerating threads at breakpoint it performs sanity check that all threads returned by ThreadGroup.enumerate hasn't terminated.
> But this is wrong assumption,  as the test enumerates _debugger_ threads and not _debuggee_ threads.
> 
> The fix drops this sanity check.

Looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From duke at openjdk.org  Tue Jul 19 06:39:32 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 19 Jul 2022 06:39:32 GMT
Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows
 platform
Message-ID: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>

Failed tests call java.lang.ProcessBuilder in direct, so not used command options specified when jtreg command run. 
To run non-localized tests, the locale options should be added in ProcessBuilder.

Could you review this fix, please?

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

Commit messages:
 - 8290497: some tests in com/sun/jdi fail on localized Windows platform

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

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

From coleenp at openjdk.org  Tue Jul 19 12:44:54 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 19 Jul 2022 12:44:54 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
Message-ID: <tZRV5JjTdwniB4U3x3LZ0RL3PID45lb6ZkIkH-Exe5I=.ca38be19-01db-4a28-afe2-828e29dba7ae@github.com>

On Mon, 18 Jul 2022 23:12:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's comments

Marked as reviewed by coleenp (Reviewer).

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

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

From sgehwolf at openjdk.org  Tue Jul 19 14:22:08 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 19 Jul 2022 14:22:08 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: <grcB53MECidwDisL8X5U8trdNJVnJeRfZdYwhuBkhwg=.ae494d6f-7a37-4be0-ac62-361a1cac23dd@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.

It's still on my plate to work on, but priorities keep this pushed to the bottom...

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

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

From tschatzl at openjdk.org  Tue Jul 19 15:55:26 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 19 Jul 2022 15:55:26 GMT
Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector
Message-ID: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com>

Hi all,

  can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read.

Testing: tier1-3

Thanks,
  Thomas

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

Commit messages:
 - fix copyright years
 - Fix verification - needs to be uninitialized (nullptr)
 - initial version

Changes: https://git.openjdk.org/jdk/pull/9560/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9560&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290525
  Stats: 79 lines in 14 files changed: 28 ins; 32 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/9560.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9560/head:pull/9560

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

From sspitsyn at openjdk.org  Tue Jul 19 23:39:51 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 19 Jul 2022 23:39:51 GMT
Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows
 platform
In-Reply-To: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
Message-ID: <bMj6gZGek4GtRqIBrWw1ii6ewtuhSx4TXuUuutR6wiU=.3ecc4fbc-ec2e-4f06-9238-4d9adf38e26b@github.com>

On Tue, 19 Jul 2022 06:30:09 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Failed tests call java.lang.ProcessBuilder in direct, so not used command options specified when jtreg command run. 
> To run non-localized tests, the locale options should be added in ProcessBuilder.
> 
> Could you review this fix, please?

This looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From dholmes at openjdk.org  Wed Jul 20 04:44:05 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Jul 2022 04:44:05 GMT
Subject: [jdk19] Integrated: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
Message-ID: <AMZ5T-Qky56FldFenzaRAnlaGG4Nxts3inu5GfIlS3c=.7e260c05-107b-48dd-b04b-48e791d0a7d6@github.com>

On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
> 
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
> 
> The Java manpage was missing updates from:
> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
> 
> The Java manpage has slight formatting differences from:
> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
> 
> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
> 
> 
> The keytool manpage was missing updates from:
> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The jar manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jarsigner manpage was missing updates from:
> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The javadoc manpage was missing updates from:
> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
> 
> The jmod manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jpackage manpage was missing updates from:
> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
> 
> The jshell manpage was missing updates from:
> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

This pull request has now been integrated.

Changeset: 618f3a82
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/618f3a82a4d45cdb66b86259ae60dd1c322b987b
Stats:     515 lines in 28 files changed: 431 ins; 16 del; 68 mod

8278274: Update nroff pages in JDK 19 before RC

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jdk19/pull/145

From dholmes at openjdk.org  Wed Jul 20 05:37:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Jul 2022 05:37:13 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <Bx5KJ0K1oEDxEkvQf_xBVYiL1foF38AVFPy9tLp6YTg=.f851a628-86b6-4edf-89b1-c91f13728a51@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>
 <Bx5KJ0K1oEDxEkvQf_xBVYiL1foF38AVFPy9tLp6YTg=.f851a628-86b6-4edf-89b1-c91f13728a51@github.com>
Message-ID: <BhpRMQOoet5mjjrvmhiT1okUnn9PAbPuGa4PE3HNaAM=.2461be8a-096b-4e18-88f2-10b9e2dc519d@github.com>

On Mon, 18 Jul 2022 23:27:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/man/keytool.1 line 456:
>> 
>>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
>>> 455: keystore.
>>> 456: This option is used to sign the certificate with the signer?s private
>> 
>> Not a problem with this PR as such, but we still have a `?` character in the output.
>
> Yeah I spotted that too, but it would need to be fixed in source and nroff.  Must be some kind of "smart quote" from an editor. Do you think this needs to be fixed or just handle it in mainline?

Filed [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626). It can easily be fixed before RDP2.

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

PR: https://git.openjdk.org/jdk19/pull/145

From duke at openjdk.org  Wed Jul 20 06:47:04 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 20 Jul 2022 06:47:04 GMT
Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows
 platform
In-Reply-To: <bMj6gZGek4GtRqIBrWw1ii6ewtuhSx4TXuUuutR6wiU=.3ecc4fbc-ec2e-4f06-9238-4d9adf38e26b@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
 <bMj6gZGek4GtRqIBrWw1ii6ewtuhSx4TXuUuutR6wiU=.3ecc4fbc-ec2e-4f06-9238-4d9adf38e26b@github.com>
Message-ID: <M3Hz-gqEvF6J1GLzHJfpPrgaJ0asiPSpJeTyydLGljc=.76d4bd85-47aa-46e5-9e44-1343a3a20de1@github.com>

On Tue, 19 Jul 2022 23:36:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Failed tests call java.lang.ProcessBuilder in direct, so not used command options specified when jtreg command run. 
>> To run non-localized tests, the locale options should be added in ProcessBuilder.
>> 
>> Could you review this fix, please?
>
> This looks good.
> Thanks,
> Serguei

@sspitsyn 
Thank you for your review. Coud you integrate this fix, please?

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

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

From sspitsyn at openjdk.org  Wed Jul 20 07:44:49 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Jul 2022 07:44:49 GMT
Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows
 platform
In-Reply-To: <M3Hz-gqEvF6J1GLzHJfpPrgaJ0asiPSpJeTyydLGljc=.76d4bd85-47aa-46e5-9e44-1343a3a20de1@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
 <bMj6gZGek4GtRqIBrWw1ii6ewtuhSx4TXuUuutR6wiU=.3ecc4fbc-ec2e-4f06-9238-4d9adf38e26b@github.com>
 <M3Hz-gqEvF6J1GLzHJfpPrgaJ0asiPSpJeTyydLGljc=.76d4bd85-47aa-46e5-9e44-1343a3a20de1@github.com>
Message-ID: <DFmB_GB-FYx3rDZLwwdgc5KX9dDiedyc11BJO4XTYIc=.dc0abf3f-b117-4c48-83e8-336338120258@github.com>

On Wed, 20 Jul 2022 06:43:33 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> This looks good.
>> Thanks,
>> Serguei
>
> @sspitsyn 
> Thank you for your review. Coud you integrate this fix, please?

@tkiriyama Normally, two reviews are required in Serviceability area.

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

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

From sspitsyn at openjdk.org  Wed Jul 20 09:03:07 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Jul 2022 09:03:07 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3]
In-Reply-To: <nWlrTXf34gMOopV8uHoiX0FcQ-KHNaC7hhg0aq5PrGM=.2f994582-f050-4222-823d-d671fddac73a@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <Y83Zl-pBC2BuAE20h7i0KihsUpZwNGMUuNrGKsGtJts=.6ffc3c80-cfe4-4913-acb6-dcab4f47db38@github.com>
 <Z-sUd4fUs58nvGk-qtbMShPtZbo0rWp5Hz6fiibzMgs=.aa3d0953-810c-40a6-a824-16e1ca0b1138@github.com>
 <OAU1-burGu42p_P9n4LtF47UTyETs0tSxfC2u1AjvQg=.4d1be962-7d77-495a-83bd-5db624ec998a@github.com>
 <nWlrTXf34gMOopV8uHoiX0FcQ-KHNaC7hhg0aq5PrGM=.2f994582-f050-4222-823d-d671fddac73a@github.com>
Message-ID: <cIuR4xrU2VCqCW1862g7-2sIpXn6UJw6nVfPd0jmtn8=.5c1957eb-b644-4e05-a519-1a0e3798ad0e@github.com>

On Mon, 18 Jul 2022 18:59:50 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> @sspitsyn and @coleenp 
>> 
>> Could you please review? Thanks!
>
>> @zhengyu123 Yes, I'm looking at it.
> 
> Thanks, @sspitsyn

@zhengyu123  I've posted my comment but I'm not sure you see it.

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

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

From zgu at openjdk.org  Wed Jul 20 12:02:50 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 20 Jul 2022 12:02:50 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
Message-ID: <5KfRxlE-OSwPaVob_7EI0gnb-TAlpGkdH8l7V7G0jvo=.5b915c65-5268-4b11-b757-c3e2b6ab1433@github.com>

On Mon, 18 Jul 2022 23:12:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's comments

> 

@sspitsyn No, I have not seen any of your new comments. Your latest comment was 25 days old.

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

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

From sspitsyn at openjdk.org  Wed Jul 20 16:56:52 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Jul 2022 16:56:52 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
Message-ID: <9KFYGbTQp0r4ADv8mIsuLfPvJB3C26pzCYVvTLohkd4=.6df6777f-e449-4e54-8ea9-a52e3dca511b@github.com>

On Mon, 18 Jul 2022 23:12:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's comments

Thanks.
I see my comment as pending but have no idea why it was not posted.
Let me just repeat it again.

src/hotspot/share/prims/jvmtiTagMap.cpp#diff
@@ -1330,7 +1352,7 @@ jvmtiError JvmtiTagMap::get_objects_with_tags(const jlong* tags,
    entry_iterate(&collector);
  }
  if (collector.some_dead_found() && env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) {
 -   post_dead_objects_on_vm_thread();
 +  remove_and_post_dead_objects();


The function `remove_and_post_dead_objects()` is also called from the `flush_object_free_events()`. This function is using some sync protocol. It is waiting under protection of the monitor `lock()` for `_posting_events` to become false and then sets `_posting_events` to true. It is also notifying the other such waiting threads after clearing the `_posting_events`. Should the function `get_objects_with_tags()` follow the same protocol? Do I understand it right that the goal was to serialize the `remove_and_post_dead_objects()` calls? If not then why do we need this sync protocol in function `flush_object_free_events()`?

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

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

From cjplummer at openjdk.org  Wed Jul 20 17:01:13 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 20 Jul 2022 17:01:13 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <9KFYGbTQp0r4ADv8mIsuLfPvJB3C26pzCYVvTLohkd4=.6df6777f-e449-4e54-8ea9-a52e3dca511b@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
 <9KFYGbTQp0r4ADv8mIsuLfPvJB3C26pzCYVvTLohkd4=.6df6777f-e449-4e54-8ea9-a52e3dca511b@github.com>
Message-ID: <gfGIt4b291Kqo0RGyjRZEitTj-R7zJvWxtkW4WRcZII=.945545eb-518c-4d8b-8819-69d04b5fc650@github.com>

On Wed, 20 Jul 2022 16:53:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I see my comment as pending but have no idea why it was not posted.

Your comment is pending because you clicked on "Start a review" instead of "Add single comment", and then never finished the review by clicking on "Review changes".

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

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

From sspitsyn at openjdk.org  Wed Jul 20 17:21:39 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Jul 2022 17:21:39 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <gfGIt4b291Kqo0RGyjRZEitTj-R7zJvWxtkW4WRcZII=.945545eb-518c-4d8b-8819-69d04b5fc650@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
 <9KFYGbTQp0r4ADv8mIsuLfPvJB3C26pzCYVvTLohkd4=.6df6777f-e449-4e54-8ea9-a52e3dca511b@github.com>
 <gfGIt4b291Kqo0RGyjRZEitTj-R7zJvWxtkW4WRcZII=.945545eb-518c-4d8b-8819-69d04b5fc650@github.com>
Message-ID: <2TeUPTNEmLWeUjx9f2GVot7S0mc8odG9A3FsQoDexZo=.fdfb031e-97f7-43b2-ab33-63b27e42bfd6@github.com>

On Wed, 20 Jul 2022 16:57:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > I see my comment as pending but have no idea why it was not posted.
> 
> Your comment is pending because you clicked on "Start a review" instead of "Add single comment", and then never finished the review by clicking on "Review changes".

I never click "Start a review". I tried to inline my comment related to the source fragment.
But you can be right. As I see a mark "started a review".

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

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

From zgu at openjdk.org  Wed Jul 20 18:34:12 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 20 Jul 2022 18:34:12 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <9KFYGbTQp0r4ADv8mIsuLfPvJB3C26pzCYVvTLohkd4=.6df6777f-e449-4e54-8ea9-a52e3dca511b@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
 <9KFYGbTQp0r4ADv8mIsuLfPvJB3C26pzCYVvTLohkd4=.6df6777f-e449-4e54-8ea9-a52e3dca511b@github.com>
Message-ID: <3XbrvfXoEW2rHDLqkMjNKPaM0rScjztKKkD1qeYfQ3o=.20ba4f2d-1569-4761-94c8-299e7e4a924f@github.com>

On Wed, 20 Jul 2022 16:53:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> get_objects_with_tags

@sspitsyn Good catch!

I believe it should be synchronized if `JvmtiEnv::GetObjectsWithTags()` call can overlap disable/enable `ObjectFree` event.

But it raises a question: why it needs `remove_and_post_dead_objects()` here? `JvmtiEnv::GetObjectsWithTags()` returns live objects, posting `ObjectFree` event does not have immediate effect due to queuing in old implementation. Could we have ServiceThread to deal with it instead?

Thanks.

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

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

From cjplummer at openjdk.org  Wed Jul 20 20:51:07 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 20 Jul 2022 20:51:07 GMT
Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows
 platform
In-Reply-To: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
Message-ID: <4LsvH1L6mGnyveMMsZpL08KCf9FnwYSKEP9QEK9kohs=.59165639-3745-40d9-a801-842129fa7a10@github.com>

On Tue, 19 Jul 2022 06:30:09 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Failed tests call java.lang.ProcessBuilder in direct, so not used command options specified when jtreg command run. 
> To run non-localized tests, the locale options should be added in ProcessBuilder.
> 
> Could you review this fix, please?

It's unclear to me when/why this is needed. For example, I see we are doing something similar in list003 and repeat001, but these are both recently added tests. None of the other jdb tests are doing this, and I'm not sure what inspired the author of these 2 tests to add the locale support. Why is it that some jdb tests (and many non-jdb tests) require the -J-Duser.language=en -J-Duser.country=US and some don't? I'm just trying to better understand the problem.

Also, can you include more log output in the CR if it would be useful in clarifying what is going wrong when running the test. Is there any useful output other than the exception, which isn't very informative.

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

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

From cjplummer at openjdk.org  Wed Jul 20 21:05:52 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 20 Jul 2022 21:05:52 GMT
Subject: RFR: 8286844: com/sun/jdi/RedefineCrossEvent.java failed with 1
 threads completed while VM suspended
In-Reply-To: <DfdQQXiu2Bjo25PDkNxfpubVT_DNn1RDOdBFia74Y9U=.646163d1-5281-45bd-adfc-167068a8f95a@github.com>
References: <DfdQQXiu2Bjo25PDkNxfpubVT_DNn1RDOdBFia74Y9U=.646163d1-5281-45bd-adfc-167068a8f95a@github.com>
Message-ID: <8qCcyj1QzIB0lKlh8kAManuJZ8RT0gUs-dwAZkQ8ioE=.779042dd-46c4-4eda-9778-0d3b72d29715@github.com>

On Mon, 18 Jul 2022 23:13:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test verifies that JDI threads are daemon threads.
> But enumerating threads at breakpoint it performs sanity check that all threads returned by ThreadGroup.enumerate hasn't terminated.
> But this is wrong assumption,  as the test enumerates _debugger_ threads and not _debuggee_ threads.
> 
> The fix drops this sanity check.

Marked as reviewed by cjplummer (Reviewer).

I think the `finishedThreads` check was actually to verify that no JDI threads completed while the debuggee was suspend. But that was back in the old days when hotpot and JDK didn't spontaneously create and delete various threads quite so readily. So removing this check seems necessary, and I can think of a reasonable way to check the status of the JDI threads (nor see a reason to).

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

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

From cjplummer at openjdk.org  Wed Jul 20 22:29:43 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 20 Jul 2022 22:29:43 GMT
Subject: RFR: 8290687: serviceability/sa/TestClassDump.java could leave files
 owned by root on macOS
Message-ID: <VZM48qo-4gG4k8FpxtdeQ8rJc7jBSDrDn51IWAo4EDY=.522b09b4-02da-404b-84b5-d20c6cad4b0e@github.com>

Unless this test is run as root, it needs sudo privileges. If it gets them, the test runs fine, but leaves around files with root ownership so jtreg cannot delete them, and you see errors when "make clean" tries to delete them. It's best that we just don't run the test on OSX if sudo privileges.

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

Commit messages:
 - Disable test on OSX if adding privilleges is required.

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

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

From dcubed at openjdk.org  Wed Jul 20 22:44:07 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Jul 2022 22:44:07 GMT
Subject: RFR: Merge jdk19
Message-ID: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>

Merge jdk19 -> jdk20.

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

Commit messages:
 - Merge
 - 8290625: Test jdk/javadoc/tool/CheckManPageOptions.java after manpage update
 - 8278274: Update nroff pages in JDK 19 before RC
 - 8287916: Address the inconsistency between the constant array and pool size
 - 8285407: Improve Xalan supports
 - 8282676: Improve subject handling
 - 8284370: Improve zlib usage
 - 8283190: Improve MIDI processing
 - 8281866: Enhance MethodHandle invocations
 - 8281859: Improve class compilation
 - ... and 3 more: https://git.openjdk.org/jdk/compare/b1817a30...aaca8b9d

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/9578/files
  Stats: 504 lines in 28 files changed: 428 ins; 16 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/9578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9578/head:pull/9578

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

From dcubed at openjdk.org  Wed Jul 20 22:59:25 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Jul 2022 22:59:25 GMT
Subject: RFR: Merge jdk19
In-Reply-To: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
References: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
Message-ID: <ejPn-O0FlUDlzib8bV49EnPrKYeCQTWUAxRY9CayeqY=.76121730-cfaa-40f3-8be6-6c71897bbe0b@github.com>

On Wed, 20 Jul 2022 22:20:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Merge jdk19 -> jdk20.

Mach5 Tier1 passed.

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

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

From dcubed at openjdk.org  Wed Jul 20 22:59:26 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Jul 2022 22:59:26 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
References: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
Message-ID: <NlbvRtErZWaBJsWsUjWLzQw8ZBrSn6f81MI1KQ_VE_k=.28531e99-8501-4f25-b621-52c51ef0b37c@github.com>

On Wed, 20 Jul 2022 22:20:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Merge jdk19 -> jdk20.

This pull request has now been integrated.

Changeset: 9c19d89c
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c19d89c9c564e436732c5f7851f4960fb5d783c
Stats:     504 lines in 28 files changed: 428 ins; 16 del; 60 mod

Merge

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

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

From amenkov at openjdk.org  Thu Jul 21 00:28:58 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 21 Jul 2022 00:28:58 GMT
Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows
 platform
In-Reply-To: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
Message-ID: <tudlR-8o41sfd8wGDQGrxjrQlMLZJYtm8bpCSu-mQ0U=.2ade5bf7-55ef-43f7-be3a-8c04d4b33271@github.com>

On Tue, 19 Jul 2022 06:30:09 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Failed tests call java.lang.ProcessBuilder in direct, so not used command options specified when jtreg command run. 
> To run non-localized tests, the locale options should be added in ProcessBuilder.
> 
> Could you review this fix, please?

I agree with Chris, it would be nice to see the failure logs to understand the issue.
Also I see 2 tests which use lib.jdb.Jdb class directly: JdbArgTest and JdbOptions.
So it would be better to fix Jdb class itself and not JdbTest

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

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

From dholmes at openjdk.org  Thu Jul 21 00:43:38 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Jul 2022 00:43:38 GMT
Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20
Message-ID: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>

The version will be 20-ea and the copyright year 2023 (for March 2023 release date).

Thanks.

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

Commit messages:
 - 8290489: Initial nroff manpage generation for JDK 20

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

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

From dcubed at openjdk.org  Thu Jul 21 01:07:02 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 21 Jul 2022 01:07:02 GMT
Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20
In-Reply-To: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
References: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
Message-ID: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com>

On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The version will be 20-ea and the copyright year 2023 (for March 2023 release date).
> 
> Thanks.

Thumbs up. This is a trivial change.

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

Marked as reviewed by dcubed (Reviewer).

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

From amenkov at openjdk.org  Thu Jul 21 01:08:04 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 21 Jul 2022 01:08:04 GMT
Subject: RFR: 8290687: serviceability/sa/TestClassDump.java could leave
 files owned by root on macOS
In-Reply-To: <VZM48qo-4gG4k8FpxtdeQ8rJc7jBSDrDn51IWAo4EDY=.522b09b4-02da-404b-84b5-d20c6cad4b0e@github.com>
References: <VZM48qo-4gG4k8FpxtdeQ8rJc7jBSDrDn51IWAo4EDY=.522b09b4-02da-404b-84b5-d20c6cad4b0e@github.com>
Message-ID: <jKVnJGltiHsW89-KMEcmTmewADcHQKlk57I165_umVM=.942d37a6-66f8-404b-969a-a5e91da88a1b@github.com>

On Wed, 20 Jul 2022 22:21:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Unless this test is run as root, it needs sudo privileges. If it gets them, the test runs fine, but leaves around files with root ownership so jtreg cannot delete them, and you see errors when "make clean" tries to delete them. It's best that we just don't run the test on OSX if sudo privileges.

Marked as reviewed by amenkov (Reviewer).

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

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

From sspitsyn at openjdk.org  Thu Jul 21 03:56:08 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Jul 2022 03:56:08 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <_sxHrlzmJsi2i7KfnX9VA68-1j1-Rhaybwc_Xedz9gc=.28d48cea-7c22-43cc-8910-bca2e07e927d@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
 <_sxHrlzmJsi2i7KfnX9VA68-1j1-Rhaybwc_Xedz9gc=.28d48cea-7c22-43cc-8910-bca2e07e927d@github.com>
Message-ID: <cdEIrAIKMQMtCWvICW1jtj1YkagcmGRPudFpSDcWnpM=.4da84758-b5d4-4242-a939-04059f569f25@github.com>

On Wed, 13 Jul 2022 18:46:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> `Actually I'm going to amend my previous comment about concerns with synchronization of the test. I think once the SetEventNotificationMode() call returns (after passing JVMTI_DISABLE), the caller should be guaranteed that any call to the event handler that was in progress has completed. So the caller should be able to safely free the raw monitor that is used in the callback. I'm not sure if JVMTI makes this guarantee however.`

The following RN is related to this question:
https://bugs.openjdk.org/browse/JDK-8256558
It explicitly says: `SetNotificationMode can be used to explicitly flush ObjectFree events, if needed.`
This RN is related to the bug pointed out by @zhengyu123 above: [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879)
However, I feel that we still need to test it heavily to make sure there are no surprises.

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

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

From cjplummer at openjdk.org  Thu Jul 21 04:15:08 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 21 Jul 2022 04:15:08 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <cdEIrAIKMQMtCWvICW1jtj1YkagcmGRPudFpSDcWnpM=.4da84758-b5d4-4242-a939-04059f569f25@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
 <_sxHrlzmJsi2i7KfnX9VA68-1j1-Rhaybwc_Xedz9gc=.28d48cea-7c22-43cc-8910-bca2e07e927d@github.com>
 <cdEIrAIKMQMtCWvICW1jtj1YkagcmGRPudFpSDcWnpM=.4da84758-b5d4-4242-a939-04059f569f25@github.com>
Message-ID: <jA-kvAtCFDwMIGMyFYuLLxTreSR1CeMquVpxNto9Kos=.06d33e0b-dfb8-43d8-ba38-e2af4f1f9dbc@github.com>

On Thu, 21 Jul 2022 03:51:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The following RN is related to this question:
> https://bugs.openjdk.org/browse/JDK-8256558
> It explicitly says: `SetNotificationMode can be used to explicitly flush ObjectFree events, if needed.`

That wasn't quite what I was getting at. My comment / question was much more general. If you call SetEventNotificationMode() to disable a specific event, once it returns are you guaranteed that no more events will be delivered. This means that if JVMTI was in the middle of calling the event handler at the same time that SetEventNotificationMode() is called, then before returning, SetEventNotificationMode() will block until the event handler returns.

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

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

From lmesnik at openjdk.org  Thu Jul 21 04:54:00 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 21 Jul 2022 04:54:00 GMT
Subject: RFR: 8290687: serviceability/sa/TestClassDump.java could leave
 files owned by root on macOS
In-Reply-To: <VZM48qo-4gG4k8FpxtdeQ8rJc7jBSDrDn51IWAo4EDY=.522b09b4-02da-404b-84b5-d20c6cad4b0e@github.com>
References: <VZM48qo-4gG4k8FpxtdeQ8rJc7jBSDrDn51IWAo4EDY=.522b09b4-02da-404b-84b5-d20c6cad4b0e@github.com>
Message-ID: <ciOZ0W1WvnzTqJHZwTU1ahWyj46n7dOPhLJqonLoKiM=.9a0d57a0-8141-4b99-ab7e-cf0e18ff8030@github.com>

On Wed, 20 Jul 2022 22:21:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Unless this test is run as root, it needs sudo privileges. If it gets them, the test runs fine, but leaves around files with root ownership so jtreg cannot delete them, and you see errors when "make clean" tries to delete them. It's best that we just don't run the test on OSX if sudo privileges.

Marked as reviewed by lmesnik (Reviewer).

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

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

From sspitsyn at openjdk.org  Thu Jul 21 05:48:09 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Jul 2022 05:48:09 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <jA-kvAtCFDwMIGMyFYuLLxTreSR1CeMquVpxNto9Kos=.06d33e0b-dfb8-43d8-ba38-e2af4f1f9dbc@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
 <_sxHrlzmJsi2i7KfnX9VA68-1j1-Rhaybwc_Xedz9gc=.28d48cea-7c22-43cc-8910-bca2e07e927d@github.com>
 <cdEIrAIKMQMtCWvICW1jtj1YkagcmGRPudFpSDcWnpM=.4da84758-b5d4-4242-a939-04059f569f25@github.com>
 <jA-kvAtCFDwMIGMyFYuLLxTreSR1CeMquVpxNto9Kos=.06d33e0b-dfb8-43d8-ba38-e2af4f1f9dbc@github.com>
Message-ID: <TUvWBiCOpMmSZBO4eKW2y-XEBGeb-EjvNvplT3f6C78=.0ef7323a-8d9c-463d-bb1b-d10d0fc58ea3@github.com>

On Thu, 21 Jul 2022 04:11:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > The following RN is related to this question:
> > https://bugs.openjdk.org/browse/JDK-8256558
> > It explicitly says: `SetNotificationMode can be used to explicitly flush ObjectFree events, if needed.`
> 
> That wasn't quite what I was getting at. My comment / question was much more general. If you call SetEventNotificationMode() to disable a specific event, once it returns are you guaranteed that no more events will be delivered. This means that if JVMTI was in the middle of calling the event handler at the same time that SetEventNotificationMode() is called, then before returning, SetEventNotificationMode() will block until the event handler returns.

There is no such general guarantee with calls to the `SetEventNotificationMode`. It is not in the `JVM TI` spec. My view of the `JVM TI `design is that it is up to the native agents to provide synchronization if needed. For instance, I spent some time in the past to fix several problems related to the `JDWP` agent shutdown as the `WRONG_PHASE` error code was appearing in the middle of an event handler execution.

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

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

From dholmes at openjdk.org  Thu Jul 21 05:49:57 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Jul 2022 05:49:57 GMT
Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20
In-Reply-To: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com>
References: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
 <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com>
Message-ID: <gZuNsiJo3fWnsEb8TsdEbuKySkKHTvKtpP6T_zaRfuI=.04048e7d-88cf-43ba-959d-67a5b14eb833@github.com>

On Thu, 21 Jul 2022 01:03:46 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The version will be 20-ea and the copyright year 2023 (for March 2023 release date).
>> 
>> Thanks.
>
> Thumbs up. This is a trivial change.

Thanks @dcubed-ojdk !

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

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

From kbarrett at openjdk.org  Thu Jul 21 06:25:48 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 21 Jul 2022 06:25:48 GMT
Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector
In-Reply-To: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com>
References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com>
Message-ID: <R2ZdYbjTKlv4VEe8rZ62ftHoVL_B3CpiDvkZWZG987I=.982c54fe-5307-4a44-8486-28d22069788f@github.com>

On Tue, 19 Jul 2022 15:47:01 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

Looks good.  Just one minor formatting nit.

src/hotspot/share/gc/g1/g1FullCollector.hpp line 93:

> 91:   G1FullGCHeapRegionAttr _region_attr_table;
> 92: 
> 93:   HeapWord*volatile *_compaction_tops;

Spacing in the type is strange.  `HeapWord* volatile* _compaction_tops;` is (I think) more usual for our code.

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

Marked as reviewed by kbarrett (Reviewer).

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

From sspitsyn at openjdk.org  Thu Jul 21 06:54:11 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Jul 2022 06:54:11 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <3XbrvfXoEW2rHDLqkMjNKPaM0rScjztKKkD1qeYfQ3o=.20ba4f2d-1569-4761-94c8-299e7e4a924f@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
 <9KFYGbTQp0r4ADv8mIsuLfPvJB3C26pzCYVvTLohkd4=.6df6777f-e449-4e54-8ea9-a52e3dca511b@github.com>
 <3XbrvfXoEW2rHDLqkMjNKPaM0rScjztKKkD1qeYfQ3o=.20ba4f2d-1569-4761-94c8-299e7e4a924f@github.com>
Message-ID: <wMYh36uWgoRT2mrtY90Og4zYkizaEyjksGUgmiQfrWI=.e78183a2-4af7-466f-ae93-51147a3f33cd@github.com>

On Wed, 20 Jul 2022 18:30:43 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > get_objects_with_tags
> 
> @sspitsyn Good catch!
> 
> I believe it should be synchronized if `JvmtiEnv::GetObjectsWithTags()` call can overlap disable/enable `ObjectFree` event.
> 
> But it raises a question: why it needs `remove_and_post_dead_objects()` here? `JvmtiEnv::GetObjectsWithTags()` returns live objects, posting `ObjectFree` event does not have immediate effect due to queuing in old implementation. Could we have ServiceThread to deal with it instead?
> 
> Thanks.
> 
> @coleenp
> 
> ```
> if (collector.some_dead_found() && env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) {
>    post_dead_objects_on_vm_thread();
> ```
> 
> came in from [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), could you comment why it is needed?
> 
> Thanks!

I do not remember the exact motivation to add this call.
It could be added because some of the tests started failing.
The GetObjectsWithTags spec says nothing about it.
Will look at the CSR if there is any.

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

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

From tschatzl at openjdk.org  Thu Jul 21 08:02:05 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 21 Jul 2022 08:02:05 GMT
Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector
 [v2]
In-Reply-To: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com>
References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com>
Message-ID: <ECqk-3QabON8Mbv7mHWPuyl1nyIKEZuAg5_7pPoTOCY=.e8b8d031-7283-4a26-a01b-bfa4d13e1f4d@github.com>

> Hi all,
> 
>   can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  kbarrett review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9560/files
  - new: https://git.openjdk.org/jdk/pull/9560/files/16d264f6..57d69c14

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

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

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

From kbarrett at openjdk.org  Thu Jul 21 11:18:04 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 21 Jul 2022 11:18:04 GMT
Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector
 [v2]
In-Reply-To: <ECqk-3QabON8Mbv7mHWPuyl1nyIKEZuAg5_7pPoTOCY=.e8b8d031-7283-4a26-a01b-bfa4d13e1f4d@github.com>
References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com>
 <ECqk-3QabON8Mbv7mHWPuyl1nyIKEZuAg5_7pPoTOCY=.e8b8d031-7283-4a26-a01b-bfa4d13e1f4d@github.com>
Message-ID: <eMyZqp20xEObzhvHZgrXK4R-JQAzsh_TPj2BUmi9JKc=.9653946e-3c59-427b-813b-4571f408a525@github.com>

On Thu, 21 Jul 2022 08:02:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read.
>> 
>> Testing: tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett review

Marked as reviewed by kbarrett (Reviewer).

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

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

From coleenp at openjdk.org  Thu Jul 21 13:22:20 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 21 Jul 2022 13:22:20 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
Message-ID: <fuPtnbhErWseFReUKlp8a2CzCbvuSIs5fDeKD-4oBPA=.e2841cf6-d6c0-49b9-94ac-a576f3e1a04a@github.com>

On Mon, 18 Jul 2022 23:12:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's comments

Hi, it was added because some tests were failing.  With the concurrent posting, we were missing events and flushing them made the tests pass.

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

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

From zgu at openjdk.org  Thu Jul 21 13:37:00 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 21 Jul 2022 13:37:00 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <fuPtnbhErWseFReUKlp8a2CzCbvuSIs5fDeKD-4oBPA=.e2841cf6-d6c0-49b9-94ac-a576f3e1a04a@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
 <fuPtnbhErWseFReUKlp8a2CzCbvuSIs5fDeKD-4oBPA=.e2841cf6-d6c0-49b9-94ac-a576f3e1a04a@github.com>
Message-ID: <Xw1KW876pGQ-j8T2YxF9L0A6TDN0UGC3zy7SkcRcR7M=.c52fc787-fe20-4601-b290-0260d1d76a7b@github.com>

On Thu, 21 Jul 2022 13:18:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi, it was added because some tests were failing. With the concurrent posting, we were missing events and flushing them made the tests pass.

Thanks, @coleenp 
Can you recall what were those tests? 

I removed the block and passed vmTestbase_nsk_jdi, vmTestbase_nsk_jdwp and hotspot_serviceability on Linux x86_64, I know Oracle has more tests.

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

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

From sspitsyn at openjdk.org  Thu Jul 21 14:30:16 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Jul 2022 14:30:16 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <Xw1KW876pGQ-j8T2YxF9L0A6TDN0UGC3zy7SkcRcR7M=.c52fc787-fe20-4601-b290-0260d1d76a7b@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
 <fuPtnbhErWseFReUKlp8a2CzCbvuSIs5fDeKD-4oBPA=.e2841cf6-d6c0-49b9-94ac-a576f3e1a04a@github.com>
 <Xw1KW876pGQ-j8T2YxF9L0A6TDN0UGC3zy7SkcRcR7M=.c52fc787-fe20-4601-b290-0260d1d76a7b@github.com>
Message-ID: <RGbyaS-8_4T3nfiCEMEDuf-n6Tr7cueKmx-pGvXfce4=.b05f44ca-4be6-4dd9-a14e-6755b37c8035@github.com>

On Thu, 21 Jul 2022 13:33:01 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > Hi, it was added because some tests were failing. With the concurrent posting, we were missing events and flushing them made the tests pass.
> 
> Thanks, @coleenp Can you recall what were those tests?
> 
> I removed the block and passed `vmTestbase_nsk_jdi`, `vmTestbase_nsk_jdwp` and `hotspot_serviceability` on Linux x86_64, I know Oracle has more tests.

I'd suggest to run additionally: `vmTestbase_nsk_jvmti`, `vmTestbase_nsk_jdb` and `jdk_jdi` (jdk/com/sun/jdi).

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

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

From coleenp at openjdk.org  Thu Jul 21 14:34:22 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 21 Jul 2022 14:34:22 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <Xw1KW876pGQ-j8T2YxF9L0A6TDN0UGC3zy7SkcRcR7M=.c52fc787-fe20-4601-b290-0260d1d76a7b@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
 <fuPtnbhErWseFReUKlp8a2CzCbvuSIs5fDeKD-4oBPA=.e2841cf6-d6c0-49b9-94ac-a576f3e1a04a@github.com>
 <Xw1KW876pGQ-j8T2YxF9L0A6TDN0UGC3zy7SkcRcR7M=.c52fc787-fe20-4601-b290-0260d1d76a7b@github.com>
Message-ID: <3QJtGIBRotzfEtSNe4ZI_jfxhp1LHyCzat4Rr_b11hw=.6576a611-7048-4adf-bb73-262e5ff67d9a@github.com>

On Thu, 21 Jul 2022 13:33:01 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Hi, it was added because some tests were failing.  With the concurrent posting, we were missing events and flushing them made the tests pass.
>
>> Hi, it was added because some tests were failing. With the concurrent posting, we were missing events and flushing them made the tests pass.
> 
> Thanks, @coleenp 
> Can you recall what were those tests? 
> 
> I removed the block and passed `vmTestbase_nsk_jdi`, `vmTestbase_nsk_jdwp` and `hotspot_serviceability` on Linux x86_64, I know Oracle has more tests.

@zhengyu123 try the tests with stress shendandoah flags if you have them.  I think I had a lot of failures with ZGC and ZCG ZFragmentationLimit=0.1 or something like that.

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

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

From cjplummer at openjdk.org  Thu Jul 21 15:28:11 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 21 Jul 2022 15:28:11 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <Xw1KW876pGQ-j8T2YxF9L0A6TDN0UGC3zy7SkcRcR7M=.c52fc787-fe20-4601-b290-0260d1d76a7b@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
 <fuPtnbhErWseFReUKlp8a2CzCbvuSIs5fDeKD-4oBPA=.e2841cf6-d6c0-49b9-94ac-a576f3e1a04a@github.com>
 <Xw1KW876pGQ-j8T2YxF9L0A6TDN0UGC3zy7SkcRcR7M=.c52fc787-fe20-4601-b290-0260d1d76a7b@github.com>
Message-ID: <WvXvjsDiyQFRyX15RsYqlg5nDqFe5LOunch5fcJs1Jw=.d203eb1f-fea6-42c6-a6af-6ee282cd41bb@github.com>

On Thu, 21 Jul 2022 13:33:01 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Hi, it was added because some tests were failing.  With the concurrent posting, we were missing events and flushing them made the tests pass.
>
>> Hi, it was added because some tests were failing. With the concurrent posting, we were missing events and flushing them made the tests pass.
> 
> Thanks, @coleenp 
> Can you recall what were those tests? 
> 
> I removed the block and passed `vmTestbase_nsk_jdi`, `vmTestbase_nsk_jdwp` and `hotspot_serviceability` on Linux x86_64, I know Oracle has more tests.

> @zhengyu123 try the tests with stress shendandoah flags if you have them. I think I had a lot of failures with ZGC and ZCG ZFragmentationLimit=0.1 or something like that.

[JDK-8255987](https://bugs.openjdk.org/browse/JDK-8255987)?

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

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

From cjplummer at openjdk.org  Thu Jul 21 15:35:12 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 21 Jul 2022 15:35:12 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <TUvWBiCOpMmSZBO4eKW2y-XEBGeb-EjvNvplT3f6C78=.0ef7323a-8d9c-463d-bb1b-d10d0fc58ea3@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
 <_sxHrlzmJsi2i7KfnX9VA68-1j1-Rhaybwc_Xedz9gc=.28d48cea-7c22-43cc-8910-bca2e07e927d@github.com>
 <cdEIrAIKMQMtCWvICW1jtj1YkagcmGRPudFpSDcWnpM=.4da84758-b5d4-4242-a939-04059f569f25@github.com>
 <jA-kvAtCFDwMIGMyFYuLLxTreSR1CeMquVpxNto9Kos=.06d33e0b-dfb8-43d8-ba38-e2af4f1f9dbc@github.com>
 <TUvWBiCOpMmSZBO4eKW2y-XEBGeb-EjvNvplT3f6C78=.0ef7323a-8d9c-463d-bb1b-d10d0fc58ea3@github.com>
Message-ID: <tm8PYihhRiXzIPwyDwZKbeEGoVbsV8ER18xWhdYVhNM=.5ec8aa2f-d111-42b4-ad22-7425019daba1@github.com>

On Thu, 21 Jul 2022 05:42:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > That wasn't quite what I was getting at. My comment / question was much more general. If you call SetEventNotificationMode() to disable a specific event, once it returns are you guaranteed that no more events will be delivered. This means that if JVMTI was in the middle of calling the event handler at the same time that SetEventNotificationMode() is called, then before returning, SetEventNotificationMode() will block until the event handler returns.
> 
> There is no such general guarantee with calls to the `SetEventNotificationMode`. It is not in the `JVM TI` spec. My view is that it is racy by the `JVM TI` design. I spent some time in the past to fix several problems related to the `JDWP` agent shutdown as the `WRONG_PHASE` error code was appearing in the middle of an event handler execution. The `WRONG_PHASE` problem is similar kind of sync problem. `JVM TI` does not guarantee that all event callbacks are completed before the `JVM TI `phase is switched to `JVMTI_PHASE_DEAD`.

This becomes a problem with the test tries to free a raw monitor on exit. It first disable events, then it frees the raw monitor that the even handler synchronizes on. However, it's possible that an event can be in flight when doing this (an event that was triggered before disabling events, but not fully delivered yet). So now you have a chicken-and-egg problem because you need a 2nd raw monitor to synchronize around freeing the 1st raw monitor. So the end result is you can't always safely cleanup on test exit the way we currently are. I think we are getting away with it because the set of events we expect is fixed or predictable. So once the test decides it is done, it won't get more events, even if they are not disabled. Thus we can free the raw monitor after disabling events without worry of some spurious event causing an untimely entry into the event handler. However, I thought there was one test you fixed where we had this exact problem, and you fixed it by not freeing the raw m
 onitor on exit. ThreadStart and ThreadDeath events come to mind, since these are now notoriously unpredictable.

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

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

From amenkov at openjdk.org  Thu Jul 21 18:19:03 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 21 Jul 2022 18:19:03 GMT
Subject: Integrated: 8286844: com/sun/jdi/RedefineCrossEvent.java failed with 1
 threads completed while VM suspended
In-Reply-To: <DfdQQXiu2Bjo25PDkNxfpubVT_DNn1RDOdBFia74Y9U=.646163d1-5281-45bd-adfc-167068a8f95a@github.com>
References: <DfdQQXiu2Bjo25PDkNxfpubVT_DNn1RDOdBFia74Y9U=.646163d1-5281-45bd-adfc-167068a8f95a@github.com>
Message-ID: <68_XmoUWXmVgx-26D5WjBAZUMA9L0YJx7ntwzGYTVWI=.4d872ed1-17bd-41be-9c73-1f70ddc3ff6e@github.com>

On Mon, 18 Jul 2022 23:13:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test verifies that JDI threads are daemon threads.
> But enumerating threads at breakpoint it performs sanity check that all threads returned by ThreadGroup.enumerate hasn't terminated.
> But this is wrong assumption,  as the test enumerates _debugger_ threads and not _debuggee_ threads.
> 
> The fix drops this sanity check.

This pull request has now been integrated.

Changeset: 7ec0132a
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ec0132ad3129b805664c85351fe6d55041066fa
Stats:     7 lines in 1 file changed: 0 ins; 6 del; 1 mod

8286844: com/sun/jdi/RedefineCrossEvent.java failed with 1 threads completed while VM suspended

Reviewed-by: sspitsyn, cjplummer

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

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

From zgu at openjdk.org  Thu Jul 21 19:25:25 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 21 Jul 2022 19:25:25 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v19]
In-Reply-To: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
Message-ID: <z3UAEE1KG4I2F3aM1yXr5wsLRghFlc_preeoktRnDRw=.e10849a7-d581-4d08-a135-6869a2b697be@github.com>

> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
> 
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
> 
> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
> 
> It also performs `commonRef_compact()` only when there are classes unloaded.
> 
> New test failed about 20% without patch, none with patch.
> 
> **Update**
> There are significant changes from early patch. 
> 
> The new approach:
> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
> 
> The new solution breaks up into two steps:
> - Collect all dead object tags with lock
> - Transition to `_in_native` state and post object free events in one batch
> 
> This way, JDI event handler can process object free events upon arrivals without delay.
> 
> **Update 2**
> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
> 
> // This checks for posting and rehashing before operations that
> // this tagmap table.  The calls from a JavaThread only rehash, posting is
> // only done before heap walks.
> void JvmtiTagMap::check_hashmap(bool post_events) {
> 
> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
> Even the events are posted earlier in old code, but they are only processed after next GC cycle.

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Don't freeing objects and posting events from JvmtiEnv::GetObjectsWithTags()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9168/files
  - new: https://git.openjdk.org/jdk/pull/9168/files/fce565d7..902f0ffb

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

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

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

From zgu at openjdk.org  Thu Jul 21 19:25:26 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 21 Jul 2022 19:25:26 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <Xw1KW876pGQ-j8T2YxF9L0A6TDN0UGC3zy7SkcRcR7M=.c52fc787-fe20-4601-b290-0260d1d76a7b@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
 <fuPtnbhErWseFReUKlp8a2CzCbvuSIs5fDeKD-4oBPA=.e2841cf6-d6c0-49b9-94ac-a576f3e1a04a@github.com>
 <Xw1KW876pGQ-j8T2YxF9L0A6TDN0UGC3zy7SkcRcR7M=.c52fc787-fe20-4601-b290-0260d1d76a7b@github.com>
Message-ID: <ebmWWT2xDpbcYtPXSlNXla_-1EJo7JZKNrViSl5ULws=.90b03180-978a-4638-875b-a3410d5d72db@github.com>

On Thu, 21 Jul 2022 13:33:01 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Hi, it was added because some tests were failing.  With the concurrent posting, we were missing events and flushing them made the tests pass.
>
>> Hi, it was added because some tests were failing. With the concurrent posting, we were missing events and flushing them made the tests pass.
> 
> Thanks, @coleenp 
> Can you recall what were those tests? 
> 
> I removed the block and passed `vmTestbase_nsk_jdi`, `vmTestbase_nsk_jdwp` and `hotspot_serviceability` on Linux x86_64, I know Oracle has more tests.

> > @zhengyu123 try the tests with stress shendandoah flags if you have them. I think I had a lot of failures with ZGC and ZCG ZFragmentationLimit=0.1 or something like that.
> 
> [JDK-8255987](https://bugs.openjdk.org/browse/JDK-8255987)?

Tested on Linux x86_64 (fastdebug)
Test: `vmTestbase_nsk_jdi`, `vmTestbase_nsk_jdwp`, `vmTestbase_nsk_jvmti` `vmTestbase_nsk_jdb' and `jdk_jdi`

- [x] default, no failure
- [x] ShenandoahGC + aggressive, one timeout [1]
- [x] ZGC with -Xmx2g -XX:ZCollectionInterval=0.01, one timeout
- [x] ZGC with -XX:ZFragmentationLimit=0.1, no failure

[1] `vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/TestDescription.java`

I pushed update that removed the block, could you please run it through Oracle's internal tests?

Thanks!

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

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

From cjplummer at openjdk.org  Thu Jul 21 21:37:45 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 21 Jul 2022 21:37:45 GMT
Subject: Integrated: 8290687: serviceability/sa/TestClassDump.java could leave
 files owned by root on macOS
In-Reply-To: <VZM48qo-4gG4k8FpxtdeQ8rJc7jBSDrDn51IWAo4EDY=.522b09b4-02da-404b-84b5-d20c6cad4b0e@github.com>
References: <VZM48qo-4gG4k8FpxtdeQ8rJc7jBSDrDn51IWAo4EDY=.522b09b4-02da-404b-84b5-d20c6cad4b0e@github.com>
Message-ID: <kiXNSUBgoFA0LOGJeJBlw83LKl0OymrrctNYLyL-AUk=.16508766-5bd8-4032-a6de-968cbdf4e938@github.com>

On Wed, 20 Jul 2022 22:21:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Unless this test is run as root, it needs sudo privileges. If it gets them, the test runs fine, but leaves around files with root ownership so jtreg cannot delete them, and you see errors when "make clean" tries to delete them. It's best that we just don't run the test on OSX if sudo privileges.

This pull request has now been integrated.

Changeset: 59d85bad
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/59d85bad348f7787533ff38942dab2811c4eb623
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8290687: serviceability/sa/TestClassDump.java could leave files owned by root on macOS

Reviewed-by: amenkov, lmesnik

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

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

From sspitsyn at openjdk.org  Thu Jul 21 21:55:14 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Jul 2022 21:55:14 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <tm8PYihhRiXzIPwyDwZKbeEGoVbsV8ER18xWhdYVhNM=.5ec8aa2f-d111-42b4-ad22-7425019daba1@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
 <_sxHrlzmJsi2i7KfnX9VA68-1j1-Rhaybwc_Xedz9gc=.28d48cea-7c22-43cc-8910-bca2e07e927d@github.com>
 <cdEIrAIKMQMtCWvICW1jtj1YkagcmGRPudFpSDcWnpM=.4da84758-b5d4-4242-a939-04059f569f25@github.com>
 <jA-kvAtCFDwMIGMyFYuLLxTreSR1CeMquVpxNto9Kos=.06d33e0b-dfb8-43d8-ba38-e2af4f1f9dbc@github.com>
 <TUvWBiCOpMmSZBO4eKW2y-XEBGeb-EjvNvplT3f6C78=.0ef7323a-8d9c-463d-bb1b-d10d0fc58ea3@github.com>
 <tm8PYihhRiXzIPwyDwZKbeEGoVbsV8ER18xWhdYVhNM=.5ec8aa2f-d111-42b4-ad22-7425019daba1@github.com>
Message-ID: <MCC2I4Yd07q95Wip5KiMOr3N783-DKFja97YrKMZCps=.4b1def14-6c7f-4e0e-985e-d751f3c0a2fc@github.com>

On Thu, 21 Jul 2022 15:31:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This becomes a problem when the test tries to free a raw monitor on exit. It first disable events, then it frees the raw monitor that the even handler synchronizes on. However, it's possible that an event can be in flight when doing this (an event that was triggered before disabling events, but not fully delivered yet). So now you have a chicken-and-egg problem because you need a 2nd raw monitor to synchronize around freeing the 1st raw monitor. So the end result is you can't always safely cleanup on test exit the way we currently are. I think we are getting away with it because the set of events we expect is fixed or predictable. So once the test decides it is done, it won't get more events, even if they are not disabled. Thus we can free the raw monitor after disabling events without worry of some spurious event causing an untimely entry into the event handler. However, I thought there was one test you fixed where we had this exact problem, and you fixed it by not freeing the raw
  monitor on exit. `ThreadStart` and `ThreadDeath` events come to mind, since these are now notoriously unpredictable.

I fixed it this way for simplicity. However, it is still possible to correctly sync if necessary.

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

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

From lmesnik at openjdk.org  Thu Jul 21 22:41:28 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 21 Jul 2022 22:41:28 GMT
Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options
Message-ID: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>

Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid.

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

Commit messages:
 - 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options

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

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

From cjplummer at openjdk.org  Thu Jul 21 23:07:59 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 21 Jul 2022 23:07:59 GMT
Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM
 options
In-Reply-To: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
References: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
Message-ID: <T-LZ35vhH8Gm8iKz6s5FUxCNo-IH19KGuFptuYEpTZ4=.00a8b17f-9e74-4380-912d-549aef5a5f72@github.com>

On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid.

test/jdk/sun/tools/jstatd/JstatGCUtilParser.java line 48:

> 46:         S0(GcStatisticsType.PERCENTAGE_OR_DASH),
> 47:         S1(GcStatisticsType.PERCENTAGE_OR_DASH),
> 48:         E(GcStatisticsType.PERCENTAGE_OR_DASH),

I don't see jstat tests in the zgc problem list. Is this fixing known test failures?

test/jdk/sun/tools/jstatd/JstatdTest.java line 131:

> 129:     private OutputAnalyzer runJps() throws Exception {
> 130:         JDKToolLauncher launcher = JDKToolLauncher.createUsingTestJDK("jps");
> 131:         launcher.addVMArgs(Utils.getFilteredTestJavaOpts("-XX:+UsePerfData"));

I assume this is removed because jps only requires that the target JVMs be run with UsePerfData, but not jps itself.

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

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

From sspitsyn at openjdk.org  Thu Jul 21 23:33:17 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 21 Jul 2022 23:33:17 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v18]
In-Reply-To: <ebmWWT2xDpbcYtPXSlNXla_-1EJo7JZKNrViSl5ULws=.90b03180-978a-4638-875b-a3410d5d72db@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <3XnL97A-qbaxmuK3-WW0ZQ-blH8dsFnNvdQnqJlY-Nk=.a30a8a4e-e4d2-48cb-bc5d-8df16d8132b5@github.com>
 <fuPtnbhErWseFReUKlp8a2CzCbvuSIs5fDeKD-4oBPA=.e2841cf6-d6c0-49b9-94ac-a576f3e1a04a@github.com>
 <Xw1KW876pGQ-j8T2YxF9L0A6TDN0UGC3zy7SkcRcR7M=.c52fc787-fe20-4601-b290-0260d1d76a7b@github.com>
 <ebmWWT2xDpbcYtPXSlNXla_-1EJo7JZKNrViSl5ULws=.90b03180-978a-4638-875b-a3410d5d72db@github.com>
Message-ID: <_JA234omuTUScNWe2HOBqFWHmco-J0dxByT0HqNjTvE=.2b8b9083-e51d-4723-9195-0495f09cc228@github.com>

On Thu, 21 Jul 2022 19:18:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I pushed update that removed the block, could you please run it through Oracle's internal tests?

I think, you can run all the needed tests by yourself.
But I'll also submit mach5 jobs to be safe.

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

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

From lmesnik at openjdk.org  Fri Jul 22 00:09:05 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 22 Jul 2022 00:09:05 GMT
Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM
 options
In-Reply-To: <T-LZ35vhH8Gm8iKz6s5FUxCNo-IH19KGuFptuYEpTZ4=.00a8b17f-9e74-4380-912d-549aef5a5f72@github.com>
References: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
 <T-LZ35vhH8Gm8iKz6s5FUxCNo-IH19KGuFptuYEpTZ4=.00a8b17f-9e74-4380-912d-549aef5a5f72@github.com>
Message-ID: <r6QiasIZNZne4FNEbniLCm6988TmYlwewaApchL6FpE=.7b9f6187-fb4e-4f57-a0cb-0864958dcc19@github.com>

On Thu, 21 Jul 2022 23:01:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid.
>
> test/jdk/sun/tools/jstatd/JstatGCUtilParser.java line 48:
> 
>> 46:         S0(GcStatisticsType.PERCENTAGE_OR_DASH),
>> 47:         S1(GcStatisticsType.PERCENTAGE_OR_DASH),
>> 48:         E(GcStatisticsType.PERCENTAGE_OR_DASH),
> 
> I don't see jstat tests in the zgc problem list. Is this fixing known test failures?

Yes, ZGC reports dash for eden and survivor spaces.

> test/jdk/sun/tools/jstatd/JstatdTest.java line 131:
> 
>> 129:     private OutputAnalyzer runJps() throws Exception {
>> 130:         JDKToolLauncher launcher = JDKToolLauncher.createUsingTestJDK("jps");
>> 131:         launcher.addVMArgs(Utils.getFilteredTestJavaOpts("-XX:+UsePerfData"));
> 
> I assume this is removed because jps only requires that the target JVMs be run with UsePerfData, but not jps itself.

jps doesn't require all vm options which we use for test VM. 
The Utils.getFilteredTestJavaOpts("-XX:+UsePerfData") don't filter anything really, because it use regexp. So we just don't set GC for jps.

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

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

From cjplummer at openjdk.org  Fri Jul 22 00:56:04 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 22 Jul 2022 00:56:04 GMT
Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM
 options
In-Reply-To: <r6QiasIZNZne4FNEbniLCm6988TmYlwewaApchL6FpE=.7b9f6187-fb4e-4f57-a0cb-0864958dcc19@github.com>
References: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
 <T-LZ35vhH8Gm8iKz6s5FUxCNo-IH19KGuFptuYEpTZ4=.00a8b17f-9e74-4380-912d-549aef5a5f72@github.com>
 <r6QiasIZNZne4FNEbniLCm6988TmYlwewaApchL6FpE=.7b9f6187-fb4e-4f57-a0cb-0864958dcc19@github.com>
Message-ID: <LDMT4Zpnw-PPBF7DMY22qZ_N-VsL7VB1babpvOlXf04=.b1b961a9-e3ed-451f-bdc4-9bbdf5fd7cbb@github.com>

On Fri, 22 Jul 2022 00:03:26 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/jdk/sun/tools/jstatd/JstatGCUtilParser.java line 48:
>> 
>>> 46:         S0(GcStatisticsType.PERCENTAGE_OR_DASH),
>>> 47:         S1(GcStatisticsType.PERCENTAGE_OR_DASH),
>>> 48:         E(GcStatisticsType.PERCENTAGE_OR_DASH),
>> 
>> I don't see jstat tests in the zgc problem list. Is this fixing known test failures?
>
> Yes, ZGC reports dash for eden and survivor spaces.

So shouldn't we have ZGC test failures then?

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

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

From lmesnik at openjdk.org  Fri Jul 22 03:13:57 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 22 Jul 2022 03:13:57 GMT
Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM
 options
In-Reply-To: <LDMT4Zpnw-PPBF7DMY22qZ_N-VsL7VB1babpvOlXf04=.b1b961a9-e3ed-451f-bdc4-9bbdf5fd7cbb@github.com>
References: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
 <T-LZ35vhH8Gm8iKz6s5FUxCNo-IH19KGuFptuYEpTZ4=.00a8b17f-9e74-4380-912d-549aef5a5f72@github.com>
 <r6QiasIZNZne4FNEbniLCm6988TmYlwewaApchL6FpE=.7b9f6187-fb4e-4f57-a0cb-0864958dcc19@github.com>
 <LDMT4Zpnw-PPBF7DMY22qZ_N-VsL7VB1babpvOlXf04=.b1b961a9-e3ed-451f-bdc4-9bbdf5fd7cbb@github.com>
Message-ID: <-si3mHhUSWEO_Pjo2ID0jovGkEZnNSEK5kbd_6skr4k=.bca9eaa2-58a7-40c6-9c9c-63298ac61f80@github.com>

On Fri, 22 Jul 2022 00:52:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yes, ZGC reports dash for eden and survivor spaces.
>
> So shouldn't we have ZGC test failures then?

No, test passes with ZGC.

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

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

From dholmes at openjdk.org  Fri Jul 22 04:45:03 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Jul 2022 04:45:03 GMT
Subject: Integrated: 8290489: Initial nroff manpage generation for JDK 20
In-Reply-To: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
References: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
Message-ID: <2vnXOAQlpH9CGjFVkGkL4pWyCPxneNmWrxV8V6j5b_w=.c951b25d-e0cd-4902-ad79-200ca4238f91@github.com>

On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The version will be 20-ea and the copyright year 2023 (for March 2023 release date).
> 
> Thanks.

This pull request has now been integrated.

Changeset: e9f97b2e
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9f97b2e8cf301ba6b69101e5efc5c71d26bc87b
Stats:     28 lines in 28 files changed: 0 ins; 0 del; 28 mod

8290489: Initial nroff manpage generation for JDK 20

Reviewed-by: dcubed

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

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

From sspitsyn at openjdk.org  Fri Jul 22 09:01:13 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 22 Jul 2022 09:01:13 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v19]
In-Reply-To: <z3UAEE1KG4I2F3aM1yXr5wsLRghFlc_preeoktRnDRw=.e10849a7-d581-4d08-a135-6869a2b697be@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <z3UAEE1KG4I2F3aM1yXr5wsLRghFlc_preeoktRnDRw=.e10849a7-d581-4d08-a135-6869a2b697be@github.com>
Message-ID: <kZs-6zXI-bKsHJaOo5GPahz0ZtWvIg9Wo9V_SuBrAok=.cc650b74-b69b-4cb2-8026-caeacf9ce06f@github.com>

On Thu, 21 Jul 2022 19:25:25 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't freeing objects and posting events from JvmtiEnv::GetObjectsWithTags()

Marked as reviewed by sspitsyn (Reviewer).

My mach5 debug test results looks good.

Without extra flags:
 nsk.jvmti: https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-nsk-jvmti-20220721-2323-34749955
 nsk.jdi:     https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-nsk-jdi-20220721-2349-34750723
 nsk.jdb:    https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-nsk-jdb-20220721-2350-34750749
 jdk_jdi:     https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-jdk-jdi-20220721-2351-34750797

With flags `-XX:+UseZGC -XX:ZFragmentationLimit=0.1` :
nsk.jvmti:  https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-zgc-nsk-jvmtii-20220721-2358-34750947
nsk.jdi:      https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-zgc-nsk-jdi-20220721-2359-34750968

With flags `-XX:+UseZGC -XX:ZCollectionInterval=0.1` :
nsk.jvmti:  https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-zgc-nsk-jvmtii-20220722-0621-34758939
nsk.jdi:      https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-zgc-nsk-jdi-20220722-0623-34758978

Some test runs on Window got `HARNESS ERROR`.

I'm not sure how to reproduce the issues Coleen observed when fixed the [JDK-8255987](https://bugs.openjdk.org/browse/JDK-8255987) .

Approved the fix.

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

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

From coleenp at openjdk.org  Fri Jul 22 12:26:26 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 22 Jul 2022 12:26:26 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v19]
In-Reply-To: <z3UAEE1KG4I2F3aM1yXr5wsLRghFlc_preeoktRnDRw=.e10849a7-d581-4d08-a135-6869a2b697be@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <z3UAEE1KG4I2F3aM1yXr5wsLRghFlc_preeoktRnDRw=.e10849a7-d581-4d08-a135-6869a2b697be@github.com>
Message-ID: <gE0t1bbOuT84HI4J-J3SnwBTfOFEaigjhg7MHUquM18=.1678f7fb-eb73-4d77-aa64-8ad8e5bbb441@github.com>

On Thu, 21 Jul 2022 19:25:25 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
>> 
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
>> 
>> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
>> 
>> It also performs `commonRef_compact()` only when there are classes unloaded.
>> 
>> New test failed about 20% without patch, none with patch.
>> 
>> **Update**
>> There are significant changes from early patch. 
>> 
>> The new approach:
>> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
>> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
>> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
>> 
>> The new solution breaks up into two steps:
>> - Collect all dead object tags with lock
>> - Transition to `_in_native` state and post object free events in one batch
>> 
>> This way, JDI event handler can process object free events upon arrivals without delay.
>> 
>> **Update 2**
>> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
>> 
>> // This checks for posting and rehashing before operations that
>> // this tagmap table.  The calls from a JavaThread only rehash, posting is
>> // only done before heap walks.
>> void JvmtiTagMap::check_hashmap(bool post_events) {
>> 
>> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
>> Even the events are posted earlier in old code, but they are only processed after next GC cycle.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't freeing objects and posting events from JvmtiEnv::GetObjectsWithTags()

Ok. I believe you. Thanks for all the testing.

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

Marked as reviewed by coleenp (Reviewer).

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

From zgu at openjdk.org  Fri Jul 22 12:26:27 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 22 Jul 2022 12:26:27 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v17]
In-Reply-To: <tm8PYihhRiXzIPwyDwZKbeEGoVbsV8ER18xWhdYVhNM=.5ec8aa2f-d111-42b4-ad22-7425019daba1@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <RcY-C3vuVRg6FGEZ9cniHOilF1H0qdQsidlVvoEcrlY=.fd84a88a-d878-402e-ad46-0653199d59c0@github.com>
 <_sxHrlzmJsi2i7KfnX9VA68-1j1-Rhaybwc_Xedz9gc=.28d48cea-7c22-43cc-8910-bca2e07e927d@github.com>
 <cdEIrAIKMQMtCWvICW1jtj1YkagcmGRPudFpSDcWnpM=.4da84758-b5d4-4242-a939-04059f569f25@github.com>
 <jA-kvAtCFDwMIGMyFYuLLxTreSR1CeMquVpxNto9Kos=.06d33e0b-dfb8-43d8-ba38-e2af4f1f9dbc@github.com>
 <TUvWBiCOpMmSZBO4eKW2y-XEBGeb-EjvNvplT3f6C78=.0ef7323a-8d9c-463d-bb1b-d10d0fc58ea3@github.com>
 <tm8PYihhRiXzIPwyDwZKbeEGoVbsV8ER18xWhdYVhNM=.5ec8aa2f-d111-42b4-ad22-7425019daba1@github.com>
Message-ID: <erqVQLlIRvCI8E--LICjhoZNDkRlamc7daGL2hErY2E=.bda0f4ea-9678-47b4-8c69-a0bedaf82f55@github.com>

On Thu, 21 Jul 2022 15:31:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> > The following RN is related to this question:
>>> > https://bugs.openjdk.org/browse/JDK-8256558
>>> > It explicitly says: `SetNotificationMode can be used to explicitly flush ObjectFree events, if needed.`
>>> 
>>> That wasn't quite what I was getting at. My comment / question was much more general. If you call SetEventNotificationMode() to disable a specific event, once it returns are you guaranteed that no more events will be delivered. This means that if JVMTI was in the middle of calling the event handler at the same time that SetEventNotificationMode() is called, then before returning, SetEventNotificationMode() will block until the event handler returns.
>> 
>> There is no such general guarantee with calls to the `SetEventNotificationMode`. It is not in the `JVM TI` spec. My view is that it is racy by the `JVM TI` design. I spent some time in the past to fix several problems related to the `JDWP` agent shutdown as the `WRONG_PHASE` error code was appearing in the middle of an event handler execution. The  `WRONG_PHASE` problem is similar kind of sync problem. `JVM TI` does not guarantee that all event callbacks are completed before the `JVM TI `phase is switched to `JVMTI_PHASE_DEAD`.
>
>> > That wasn't quite what I was getting at. My comment / question was much more general. If you call SetEventNotificationMode() to disable a specific event, once it returns are you guaranteed that no more events will be delivered. This means that if JVMTI was in the middle of calling the event handler at the same time that SetEventNotificationMode() is called, then before returning, SetEventNotificationMode() will block until the event handler returns.
>> 
>> There is no such general guarantee with calls to the `SetEventNotificationMode`. It is not in the `JVM TI` spec. My view is that it is racy by the `JVM TI` design. I spent some time in the past to fix several problems related to the `JDWP` agent shutdown as the `WRONG_PHASE` error code was appearing in the middle of an event handler execution. The `WRONG_PHASE` problem is similar kind of sync problem. `JVM TI` does not guarantee that all event callbacks are completed before the `JVM TI `phase is switched to `JVMTI_PHASE_DEAD`.
> 
> This becomes a problem when the test tries to free a raw monitor on exit. It first disable events, then it frees the raw monitor that the even handler synchronizes on. However, it's possible that an event can be in flight when doing this (an event that was triggered before disabling events, but not fully delivered yet). So now you have a chicken-and-egg problem because you need a 2nd raw monitor to synchronize around freeing the 1st raw monitor. So the end result is you can't always safely cleanup on test exit the way we currently are. I think we are getting away with it because the set of events we expect is fixed or predictable. So once the test decides it is done, it won't get more events, even if they are not disabled. Thus we can free the raw monitor after disabling events without worry of some spurious event causing an untimely entry into the event handler. However, I thought there was one test you fixed where we had this exact problem, and you fixed it by not freeing the raw
  monitor on exit. ThreadStart and ThreadDeath events come to mind, since these are now notoriously unpredictable.

Thanks, @plummercj @sspitsyn  and @coleenp

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

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

From zgu at openjdk.org  Fri Jul 22 12:31:17 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 22 Jul 2022 12:31:17 GMT
Subject: Integrated: 8256811: Delayed/missed jdwp class unloading events
In-Reply-To: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
Message-ID: <5eKnw2zKBmrjgV_4yKqr0Iiszff87riMB03X8kW-F1g=.ead48ae7-c9aa-41f1-b151-14cfa016d358@github.com>

On Wed, 15 Jun 2022 12:53:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Currently, jdi only check and process class unloading event when it detects a new GC cycle.
> 
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever.
> 
> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`.
> 
> It also performs `commonRef_compact()` only when there are classes unloaded.
> 
> New test failed about 20% without patch, none with patch.
> 
> **Update**
> There are significant changes from early patch. 
> 
> The new approach:
> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues:
> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state
> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state
> 
> The new solution breaks up into two steps:
> - Collect all dead object tags with lock
> - Transition to `_in_native` state and post object free events in one batch
> 
> This way, JDI event handler can process object free events upon arrivals without delay.
> 
> **Update 2**
> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks.
> 
> // This checks for posting and rehashing before operations that
> // this tagmap table.  The calls from a JavaThread only rehash, posting is
> // only done before heap walks.
> void JvmtiTagMap::check_hashmap(bool post_events) {
> 
> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. 
> Even the events are posted earlier in old code, but they are only processed after next GC cycle.

This pull request has now been integrated.

Changeset: 54854d93
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54854d9300479c22c416fd9d2fdb5c29fc1884bc
Stats:     494 lines in 12 files changed: 253 ins; 149 del; 92 mod

8256811: Delayed/missed jdwp class unloading events

Co-authored-by: Chris Plummer <cjplummer at openjdk.org>
Reviewed-by: cjplummer, coleenp, sspitsyn

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

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

From sspitsyn at openjdk.org  Fri Jul 22 17:55:11 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 22 Jul 2022 17:55:11 GMT
Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v19]
In-Reply-To: <gE0t1bbOuT84HI4J-J3SnwBTfOFEaigjhg7MHUquM18=.1678f7fb-eb73-4d77-aa64-8ad8e5bbb441@github.com>
References: <LCUKfEwGFv9LnhLwspXZG98oWZar2xiPFpgv877Ahvw=.a71934db-8962-428d-ad10-a7f3d1d97df4@github.com>
 <z3UAEE1KG4I2F3aM1yXr5wsLRghFlc_preeoktRnDRw=.e10849a7-d581-4d08-a135-6869a2b697be@github.com>
 <gE0t1bbOuT84HI4J-J3SnwBTfOFEaigjhg7MHUquM18=.1678f7fb-eb73-4d77-aa64-8ad8e5bbb441@github.com>
Message-ID: <YeWn4dNndm_oCTZxlnYbvIBdqWcfDTSI0V00_yLNOBY=.3aa34923-2c06-4e46-a4ed-7f839ef4b582@github.com>

On Fri, 22 Jul 2022 12:21:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Ok. I believe you. Thanks for all the testing.

I'm afraid that the potential problem can be highly intermittent and did not show up in my testing.
To catch it we need to know the exact test and run it many times.
But if we discover such an issue then we can file a bug and address it separately.

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

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

From achung at openjdk.org  Sat Jul 23 03:11:02 2022
From: achung at openjdk.org (Alisen Chung)
Date: Sat, 23 Jul 2022 03:11:02 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop
 10
Message-ID: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>

open l10n msg drop
All tests passed.

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

Commit messages:
 - open l10n drop

Changes: https://git.openjdk.org/jdk19/pull/154/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290889
  Stats: 3930 lines in 44 files changed: 3336 ins; 540 del; 54 mod
  Patch: https://git.openjdk.org/jdk19/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154

PR: https://git.openjdk.org/jdk19/pull/154

From lmesnik at openjdk.org  Sun Jul 24 12:41:15 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 24 Jul 2022 12:41:15 GMT
Subject: RFR: 8244976: vmTestbase/nsk/jdi/Event/request/request001.java doesn'
 initialize eName
Message-ID: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>

Fixed tests that use eName to print event name to print the class name. Plus some minor refactoring.

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

Commit messages:
 - 8244976: vmTestbase/nsk/jdi/Event/request/request001.java doesn' initialize eName

Changes: https://git.openjdk.org/jdk/pull/9624/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9624&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8244976
  Stats: 45 lines in 3 files changed: 10 ins; 20 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/9624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9624/head:pull/9624

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

From shade at openjdk.org  Mon Jul 25 08:23:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 25 Jul 2022 08:23:11 GMT
Subject: RFR: 8244976: vmTestbase/nsk/jdi/Event/request/request001.java
 doesn' initialize eName
In-Reply-To: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
References: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
Message-ID: <PTG7ES6Gy2hCVnef-1OEXI0RrfjaLRPe3u_cUoiMcK0=.4a2a6dae-48fe-4497-b7eb-9b3febdaad53@github.com>

On Sat, 23 Jul 2022 19:41:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Fixed tests that use eName to print event name to print the class name. Plus some minor refactoring.

Looks reasonable.

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

Marked as reviewed by shade (Reviewer).

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

From sspitsyn at openjdk.org  Mon Jul 25 09:32:08 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 25 Jul 2022 09:32:08 GMT
Subject: RFR: 8244976: vmTestbase/nsk/jdi/Event/request/request001.java
 doesn' initialize eName
In-Reply-To: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
References: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
Message-ID: <6MKmsH4hcg2PL9IMRS4XagDoXcOi5ADPnAj4wbixBkE=.5c3ba865-3fd4-4825-a935-66c9b1d41f44@github.com>

On Sat, 23 Jul 2022 19:41:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Fixed tests that use eName to print event name to print the class name. Plus some minor refactoring.

I've added a couple of nits.
Otherwise, it looks good.
Thanks,
Serguei

test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001.java line 553:

> 551:                     log3("ERROR: else clause in detecting type of event1");
> 552:                     testExitCode = FAILED;
> 553:                     throw new JDITestRuntimeException("** unexpected event **");

It is better to print the event type (or, at least, something) in this case.

test/hotspot/jtreg/vmTestbase/nsk/jdi/EventIterator/nextEvent/nextevent001.java line 543:

> 541:                     log3("ERROR: else clause in detecting type of event1");
> 542:                     testExitCode = FAILED;
> 543:                     throw new JDITestRuntimeException("** unexpected event **");

The same as commented above.

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

Marked as reviewed by sspitsyn (Reviewer).

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

From duke at openjdk.org  Mon Jul 25 09:39:43 2022
From: duke at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 25 Jul 2022 09:39:43 GMT
Subject: RFR: 8290074: Remove implicit arguments for RegisterMap constructor
Message-ID: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>

8290074: Remove implicit arguments for RegisterMap constructor

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

Commit messages:
 - Fix spurious semicolon
 - Change to scoped enum
 - 8290074: Remove implicit arguments for RegisterMap constructor
 - 8290074: Remove implicit arguments for RegisterMap constructor
 - 8290074: Remove implicit arguments for RegisterMap constructor

Changes: https://git.openjdk.org/jdk/pull/9455/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9455&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290074
  Stats: 434 lines in 40 files changed: 317 ins; 0 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/9455.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9455/head:pull/9455

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

From eosterlund at openjdk.org  Mon Jul 25 09:39:44 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 25 Jul 2022 09:39:44 GMT
Subject: RFR: 8290074: Remove implicit arguments for RegisterMap
 constructor
In-Reply-To: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>
References: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>
Message-ID: <lkDai1f5pppRTTq4iFQz987rXdLMFgwAr_Hx8yzjOLg=.432566d0-b68c-4334-87e0-56792d981f08@github.com>

On Mon, 11 Jul 2022 14:58:07 GMT, Axel Boldt-Christmas <duke at openjdk.org> wrote:

> 8290074: Remove implicit arguments for RegisterMap constructor

Looks good except for a spurious semicolon. Don't need another review for that.

src/hotspot/share/runtime/frame.cpp line 85:

> 83: RegisterMap::RegisterMap(oop continuation, UpdateMap update_map) {
> 84:   _thread         = NULL;
> 85:   _update_map     = update_map == UpdateMap::yes;;

One semicolon too many.

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

Marked as reviewed by eosterlund (Reviewer).

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

From cjplummer at openjdk.org  Mon Jul 25 17:00:10 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 25 Jul 2022 17:00:10 GMT
Subject: RFR: 8244976: vmTestbase/nsk/jdi/Event/request/request001.java
 doesn' initialize eName
In-Reply-To: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
References: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
Message-ID: <Tvo95npfYjB1VABwtXOY7ID_OF36j8aoKSqloOC6rJY=.7c119395-ffba-4688-a6d9-a38df5fe9f0c@github.com>

On Sat, 23 Jul 2022 19:41:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Fixed tests that use eName to print event name to print the class name. Plus some minor refactoring.

Changes requested by cjplummer (Reviewer).

test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001.java line 560:

> 558:                 if ((flagsCopy & flag) == 0) {
> 559:                     log3("ERROR: event duplication. flafsCopy = " + Integer.toBinaryString(flagsCopy)
> 560:                             + " flag = " + Integer.toBinaryString(flag));

typo: flafsCopy

I think you should print the event also.

test/hotspot/jtreg/vmTestbase/nsk/jdi/LocatableEvent/thread/thread001.java line 448:

> 446:                     throw new JDITestRuntimeException("** unexpected event **");
> 447:                 }
> 448:                 log2("--------> got: " + event1.getClass().getName() + " index: " + index);

Why not print the event rather than just its name.

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

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

From cjplummer at openjdk.org  Mon Jul 25 17:00:12 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 25 Jul 2022 17:00:12 GMT
Subject: RFR: 8244976: vmTestbase/nsk/jdi/Event/request/request001.java
 doesn' initialize eName
In-Reply-To: <6MKmsH4hcg2PL9IMRS4XagDoXcOi5ADPnAj4wbixBkE=.5c3ba865-3fd4-4825-a935-66c9b1d41f44@github.com>
References: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
 <6MKmsH4hcg2PL9IMRS4XagDoXcOi5ADPnAj4wbixBkE=.5c3ba865-3fd4-4825-a935-66c9b1d41f44@github.com>
Message-ID: <ZVX56JR3qJ8o48v1jGAauw8nPruy_GuHi5B_bEz4NlM=.41f81571-49d0-405d-bdce-e599c0ac41d4@github.com>

On Mon, 25 Jul 2022 09:27:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Fixed tests that use eName to print event name to print the class name. Plus some minor refactoring.
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/Event/request/request001.java line 553:
> 
>> 551:                     log3("ERROR: else clause in detecting type of event1");
>> 552:                     testExitCode = FAILED;
>> 553:                     throw new JDITestRuntimeException("** unexpected event **");
> 
> It is better to print the event type (or, at least, something) in this case.

Just add ` + event`.

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

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

From naoto at openjdk.org  Mon Jul 25 17:05:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 25 Jul 2022 17:05:38 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <H6f17TB5GpzVnnzK7uUw7zQeqXFv4hr_-adfUI5D5D4=.a1cd4524-a11c-4749-b253-cb6c24303849@github.com>

On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> open l10n msg drop
> All tests passed.

Changes requested by naoto (Reviewer).

src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

These currency symbols (`XXX=XXX`) are all in the base `CurrencyNames.properties`, so not needed in each localized resources (They are in the base in order to avoid throwing exceptions).

Also, the localized files should not reside in `java.base`, but to be merged with the ones in `jdk.localedata` module

These comments hold for all localized resources (de, ja, zh-CN). For furure reference, it may be good to add some comment in the base `CurrencyNames.properties` about this.

src/java.base/share/data/currency/CurrencyData_de.properties line 1:

> 1: #

`CurrencyData.properties` is not a localizable resource bundle, but a properties file containing currency data. No need to add these localized resources.

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

PR: https://git.openjdk.org/jdk19/pull/154

From asemenyuk at openjdk.org  Mon Jul 25 18:52:15 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 25 Jul 2022 18:52:15 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com>

On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> open l10n msg drop
> All tests passed.

Why `MSG_Help_mac_launcher` in [src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties](https://github.com/openjdk/jdk19/pull/154/files#diff-2e1b121e201e1040827d5b68ebdd852615e611904db783806a753dc6980e97fa) is left not localized? Is it intended to be localized in the next drop?

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

PR: https://git.openjdk.org/jdk19/pull/154

From lmesnik at openjdk.org  Tue Jul 26 04:55:21 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 26 Jul 2022 04:55:21 GMT
Subject: RFR: 8244976: vmTestbase/nsk/jdi/Event/request/request001.java
 doesn' initialize eName [v2]
In-Reply-To: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
References: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
Message-ID: <6zGZqzE89fqJJ_Bow6lkm2dGGGdsYKV8O1fCGU8JrVE=.55d24366-5b85-41d0-865d-cabedecafc4d@github.com>

> Fixed tests that use eName to print event name to print the class name. Plus some minor refactoring.

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:

 - fixes
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8244976
 - 8244976: vmTestbase/nsk/jdi/Event/request/request001.java doesn' initialize eName

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9624/files
  - new: https://git.openjdk.org/jdk/pull/9624/files/c6f79264..438229b2

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

  Stats: 442 lines in 28 files changed: 284 ins; 86 del; 72 mod
  Patch: https://git.openjdk.org/jdk/pull/9624.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9624/head:pull/9624

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

From duke at openjdk.org  Tue Jul 26 06:29:12 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 26 Jul 2022 06:29:12 GMT
Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows
 platform [v2]
In-Reply-To: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
Message-ID: <fMmeENPJSAUj4ZPPFb5-AJvEujEiHxWmiLwTofFne54=.43f3c5ef-a6d7-41a4-b760-02b21ef0fb81@github.com>

> Failed tests call java.lang.ProcessBuilder in direct, so not used command options specified when jtreg command run. 
> To run non-localized tests, the locale options should be added in ProcessBuilder.
> 
> Could you review this fix, please?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8290497: some tests in com/sun/jdi fail on localized Windows platform

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9549/files
  - new: https://git.openjdk.org/jdk/pull/9549/files/b539d15a..682be18f

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

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

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

From duke at openjdk.org  Tue Jul 26 06:30:22 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 26 Jul 2022 06:30:22 GMT
Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows
 platform
In-Reply-To: <4LsvH1L6mGnyveMMsZpL08KCf9FnwYSKEP9QEK9kohs=.59165639-3745-40d9-a801-842129fa7a10@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
 <4LsvH1L6mGnyveMMsZpL08KCf9FnwYSKEP9QEK9kohs=.59165639-3745-40d9-a801-842129fa7a10@github.com>
Message-ID: <xg483HNlGFzmoWsJDNT7QdEZ7ObcgiPFX5NYhSaddxk=.77e7cdb8-3fd8-45ce-9413-804033292228@github.com>

On Wed, 20 Jul 2022 20:47:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Failed tests call java.lang.ProcessBuilder in direct, so not used command options specified when jtreg command run. 
>> To run non-localized tests, the locale options should be added in ProcessBuilder.
>> 
>> Could you review this fix, please?
>
> It's unclear to me when/why this is needed. For example, I see we are doing something similar in list003 and repeat001, but these are both recently added tests. None of the other jdb tests are doing this, and I'm not sure what inspired the author of these 2 tests to add the locale support. Why is it that some jdb tests (and many non-jdb tests) require the -J-Duser.language=en -J-Duser.country=US and some don't? I'm just trying to better understand the problem.
> 
> Also, can you include more log output in the CR if it would be useful in clarifying what is going wrong when running the test. Is there any useful output other than the exception, which isn't very informative.

@plummercj @alexmenkov 

> Why is it that some jdb tests (and many non-jdb tests) require the -J-Duser.language=en -J-Duser.country=US and some don't? I'm just trying to better understand the problem.

This problem ocuurs only when the output of jdb command is localized, such as the usage. Some tests expect non-localized output, such as "Usage:"

> Also, can you include more log output in the CR if it would be useful in clarifying what is going wrong when running the test. Is there any useful output other than the exception, which isn't very informative.

Many tests use jdk.test.lib.process.OutputAnalyzer to check the output of jdb command. OutputAnalyzer prints the localized output of jdb command. We can use this output in the log.

> I agree with Chris, it would be nice to see the failure logs to understand the issue. Also I see 2 tests which use lib.jdb.Jdb class directly: JdbArgTest and JdbOptions. So it would be better to fix Jdb class itself and not JdbTest

The output of jdb command in JdbArgTest and JdbOptions is not localizes. Therefore, 2 tests are passed on localized environment. However, I think it would be better to fix Jdb class itself. I fixed it.

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

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

From sspitsyn at openjdk.org  Tue Jul 26 06:58:58 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 26 Jul 2022 06:58:58 GMT
Subject: RFR: 8244976: vmTestbase/nsk/jdi/Event/request/request001.java
 doesn' initialize eName [v2]
In-Reply-To: <6zGZqzE89fqJJ_Bow6lkm2dGGGdsYKV8O1fCGU8JrVE=.55d24366-5b85-41d0-865d-cabedecafc4d@github.com>
References: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
 <6zGZqzE89fqJJ_Bow6lkm2dGGGdsYKV8O1fCGU8JrVE=.55d24366-5b85-41d0-865d-cabedecafc4d@github.com>
Message-ID: <boPNgm_PToqVU-jgr91cx5tldYooktrkZR5au35jxJE=.d8fb07f2-ac84-4340-b1cc-91ad26de3e0d@github.com>

On Tue, 26 Jul 2022 04:55:21 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed tests that use eName to print event name to print the class name. Plus some minor refactoring.
>
> 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:
> 
>  - fixes
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8244976
>  - 8244976: vmTestbase/nsk/jdi/Event/request/request001.java doesn' initialize eName

Marked as reviewed by sspitsyn (Reviewer).

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

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

From asotona at openjdk.org  Tue Jul 26 08:32:00 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Jul 2022 08:32:00 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v14]
In-Reply-To: <cg1cvzaYh2RZByrgkAI6sPvZ1J0B4JAOiqVe4ib_e34=.9ec074a6-f3c0-4226-8b8c-8064fefd393b@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <cg1cvzaYh2RZByrgkAI6sPvZ1J0B4JAOiqVe4ib_e34=.9ec074a6-f3c0-4226-8b8c-8064fefd393b@github.com>
Message-ID: <KXflC0s1JhTfM6RXbd-Cnord8y7OMmsLCcl4ixuWGE0=.f8327203-6dba-42d1-9563-e6fa563aa61d@github.com>

On Mon, 27 Jun 2022 09:25:58 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:
> 
>   re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le

ping to keep the PR open

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

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

From tschatzl at openjdk.org  Tue Jul 26 16:30:50 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 26 Jul 2022 16:30:50 GMT
Subject: RFR: 8290074: Remove implicit arguments for RegisterMap
 constructor
In-Reply-To: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>
References: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>
Message-ID: <8txeHYkmwTumyrOClXP67vNUaCQYzDgiI2qIG-Qk3Jg=.6cc0c63b-b85c-4ca3-b418-e80ba2b1ea38@github.com>

On Mon, 11 Jul 2022 14:58:07 GMT, Axel Boldt-Christmas <duke at openjdk.org> wrote:

> Currently the `RegisterMap` constructor uses implicit boolean arguments to configure its function. Implicit boolean arguments makes code harder to understand and reason about at the call site. Using explicit scoped enums instead makes it both clear what is being configured and the type safety makes mistakes less likely. 
> 
> Update `RegisterMap` constructors to use these scoped enum types instead of booleans.
> ```C++
> enum class UpdateMap { skip, yes };
> enum class ProcessFrames { skip, yes };
> enum class WalkContinuation { skip, yes };
> 
> 
> Testing: tier1-3

Feel free to ignore my comment, seems good otherwise.

src/hotspot/share/runtime/registerMap.hpp line 75:

> 73:   enum class UpdateMap { skip, yes };
> 74:   enum class ProcessFrames { skip, yes };
> 75:   enum class WalkContinuation   { skip, yes };

Instead of `yes` I would recommend using like `include` (or `add') as `yes` seems relatively unspecific compared to `skip`.

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

Marked as reviewed by tschatzl (Reviewer).

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

From cjplummer at openjdk.org  Tue Jul 26 18:02:52 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 26 Jul 2022 18:02:52 GMT
Subject: RFR: 8244976: vmTestbase/nsk/jdi/Event/request/request001.java
 doesn' initialize eName [v2]
In-Reply-To: <6zGZqzE89fqJJ_Bow6lkm2dGGGdsYKV8O1fCGU8JrVE=.55d24366-5b85-41d0-865d-cabedecafc4d@github.com>
References: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
 <6zGZqzE89fqJJ_Bow6lkm2dGGGdsYKV8O1fCGU8JrVE=.55d24366-5b85-41d0-865d-cabedecafc4d@github.com>
Message-ID: <DI9J-Ma6DKw7CC7BqiiYLR6cmqbZZ4KCViE8AnkXMf8=.1c83bf09-0863-4c27-8855-b013f1042560@github.com>

On Tue, 26 Jul 2022 04:55:21 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed tests that use eName to print event name to print the class name. Plus some minor refactoring.
>
> 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:
> 
>  - fixes
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8244976
>  - 8244976: vmTestbase/nsk/jdi/Event/request/request001.java doesn' initialize eName

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.org  Tue Jul 26 18:06:40 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 26 Jul 2022 18:06:40 GMT
Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows
 platform [v2]
In-Reply-To: <fMmeENPJSAUj4ZPPFb5-AJvEujEiHxWmiLwTofFne54=.43f3c5ef-a6d7-41a4-b760-02b21ef0fb81@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
 <fMmeENPJSAUj4ZPPFb5-AJvEujEiHxWmiLwTofFne54=.43f3c5ef-a6d7-41a4-b760-02b21ef0fb81@github.com>
Message-ID: <qwYvCmSYnSIyuGG_iEre5D2QQrw1CdEJfjBIn0HTg8M=.c40f0766-6eba-479f-8d2a-8ecaa02cd299@github.com>

On Tue, 26 Jul 2022 06:29:12 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> Failed tests call java.lang.ProcessBuilder in direct, so not used command options specified when jtreg command run. 
>> To run non-localized tests, the locale options should be added in ProcessBuilder.
>> 
>> Could you review this fix, please?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290497: some tests in com/sun/jdi fail on localized Windows platform

Marked as reviewed by cjplummer (Reviewer).

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

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

From amenkov at openjdk.org  Tue Jul 26 18:17:12 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 26 Jul 2022 18:17:12 GMT
Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows
 platform [v2]
In-Reply-To: <fMmeENPJSAUj4ZPPFb5-AJvEujEiHxWmiLwTofFne54=.43f3c5ef-a6d7-41a4-b760-02b21ef0fb81@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
 <fMmeENPJSAUj4ZPPFb5-AJvEujEiHxWmiLwTofFne54=.43f3c5ef-a6d7-41a4-b760-02b21ef0fb81@github.com>
Message-ID: <GVlzR17ifKWXLC4MGJXPu6pb5gaE4chuj1HrWkTtNUI=.62c79d33-6620-40ce-b41e-1fdb6ee60f0b@github.com>

On Tue, 26 Jul 2022 06:29:12 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> Failed tests call java.lang.ProcessBuilder in direct, so not used command options specified when jtreg command run. 
>> To run non-localized tests, the locale options should be added in ProcessBuilder.
>> 
>> Could you review this fix, please?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290497: some tests in com/sun/jdi fail on localized Windows platform

Marked as reviewed by amenkov (Reviewer).

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

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

From achung at openjdk.org  Tue Jul 26 18:34:58 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 26 Jul 2022 18:34:58 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com>
Message-ID: <C1YU7iK0K6YjRCepyBlgesZDowUHqG11k9-7EuUwrlo=.fabcf888-a415-47c3-bdc2-2cf37684108b@github.com>

On Mon, 25 Jul 2022 18:48:25 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Why `MSG_Help_mac_launcher` in [src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties](https://github.com/openjdk/jdk19/pull/154/files#diff-2e1b121e201e1040827d5b68ebdd852615e611904db783806a753dc6980e97fa) is left not localized? Is it intended to be localized in the next drop?

Probably will be left for next drop

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

PR: https://git.openjdk.org/jdk19/pull/154

From lmesnik at openjdk.org  Tue Jul 26 19:06:54 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 26 Jul 2022 19:06:54 GMT
Subject: Integrated: 8244976: vmTestbase/nsk/jdi/Event/request/request001.java
 doesn' initialize eName
In-Reply-To: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
References: <JVw9AhFMvhjKGeif3eh8Ba7DdUBcTrTvRP017eHDIW4=.c5e6e9b0-844e-44d2-b662-a41b2462a8c2@github.com>
Message-ID: <b4MSNdvR6vbDYJ6gb_bvFbPvP_0z7WIOqAkGX5Q9fs8=.8ea7a258-49c2-4395-a8a3-e5c0b7799648@github.com>

On Sat, 23 Jul 2022 19:41:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Fixed tests that use eName to print event name to print the class name. Plus some minor refactoring.

This pull request has now been integrated.

Changeset: 14516423
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1451642317dbe9f941172945e9f366000434653f
Stats:     49 lines in 3 files changed: 13 ins; 20 del; 16 mod

8244976: vmTestbase/nsk/jdi/Event/request/request001.java doesn' initialize eName

Reviewed-by: shade, sspitsyn, cjplummer

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

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

From achung at openjdk.org  Tue Jul 26 20:24:14 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 26 Jul 2022 20:24:14 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <dZ3e2I9I68fQ6AR4dLBeLnXlwgYejqstcByber6aIBs=.bae6a5fa-59be-4fea-b44d-1cdde31ee22b@github.com>

> open l10n msg drop
> All tests passed.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  merged currencyname property files into localedata

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/154/files
  - new: https://git.openjdk.org/jdk19/pull/154/files/334f4c76..7ab703ed

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

  Stats: 1540 lines in 7 files changed: 3 ins; 1534 del; 3 mod
  Patch: https://git.openjdk.org/jdk19/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154

PR: https://git.openjdk.org/jdk19/pull/154

From achung at openjdk.org  Tue Jul 26 20:31:44 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 26 Jul 2022 20:31:44 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <kyU6nIIGoMX_otMTj_M8I7RVJwm85FOaTi05QHsi1nM=.2d4a5ec1-411f-4eaa-9def-b0b7239e632c@github.com>

> open l10n msg drop
> All tests passed.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed localized files from base

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/154/files
  - new: https://git.openjdk.org/jdk19/pull/154/files/7ab703ed..6776bd0f

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

  Stats: 1722 lines in 3 files changed: 0 ins; 1722 del; 0 mod
  Patch: https://git.openjdk.org/jdk19/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154

PR: https://git.openjdk.org/jdk19/pull/154

From duke at openjdk.org  Wed Jul 27 07:53:10 2022
From: duke at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 27 Jul 2022 07:53:10 GMT
Subject: RFR: 8290074: Remove implicit arguments for RegisterMap
 constructor
In-Reply-To: <8txeHYkmwTumyrOClXP67vNUaCQYzDgiI2qIG-Qk3Jg=.6cc0c63b-b85c-4ca3-b418-e80ba2b1ea38@github.com>
References: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>
 <8txeHYkmwTumyrOClXP67vNUaCQYzDgiI2qIG-Qk3Jg=.6cc0c63b-b85c-4ca3-b418-e80ba2b1ea38@github.com>
Message-ID: <FbxDW91wqZgQfsE6HOoZCaPtjqWt_TYp65NPdlYEtas=.a9963e9e-ef92-4170-a2ef-167ac6388891@github.com>

On Tue, 26 Jul 2022 16:25:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Currently the `RegisterMap` constructor uses implicit boolean arguments to configure its function. Implicit boolean arguments makes code harder to understand and reason about at the call site. Using explicit scoped enums instead makes it both clear what is being configured and the type safety makes mistakes less likely. 
>> 
>> Update `RegisterMap` constructors to use these scoped enum types instead of booleans.
>> ```C++
>> enum class UpdateMap { skip, yes };
>> enum class ProcessFrames { skip, yes };
>> enum class WalkContinuation { skip, yes };
>> 
>> 
>> Testing: tier1-3
>
> src/hotspot/share/runtime/registerMap.hpp line 75:
> 
>> 73:   enum class UpdateMap { skip, yes };
>> 74:   enum class ProcessFrames { skip, yes };
>> 75:   enum class WalkContinuation   { skip, yes };
> 
> Instead of `yes` I would recommend using like `include` (or `add') as `yes` seems relatively unspecific compared to `skip`.

`include` is probably better. I was trying to think of a good word to use, first I thought of `do` and `skip` because the enums are actions/verbs. But the reverse order (as in `UpdateMap :: do`) sounds a bit weird. Thought of it more as a question instead, `Action? :: yes/skip`. But `include` fits better with respects to `skip`, `yes`/`no` is an alternative. But `skip`/`include` is nicer. Also an excuse to fix that double space on line 75.

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

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

From duke at openjdk.org  Wed Jul 27 09:45:25 2022
From: duke at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 27 Jul 2022 09:45:25 GMT
Subject: RFR: 8290074: Remove implicit arguments for RegisterMap
 constructor [v2]
In-Reply-To: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>
References: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>
Message-ID: <2yemnBYAHLTI95rmFZnwpiK0N_XhtzBZr_jaOpTNjuA=.bc0a617f-ea88-4298-bc94-c031c679010f@github.com>

> Currently the `RegisterMap` constructor uses implicit boolean arguments to configure its function. Implicit boolean arguments makes code harder to understand and reason about at the call site. Using explicit scoped enums instead makes it both clear what is being configured and the type safety makes mistakes less likely. 
> 
> Update `RegisterMap` constructors to use these scoped enum types instead of booleans.
> ```C++
> enum class UpdateMap { skip, yes };
> enum class ProcessFrames { skip, yes };
> enum class WalkContinuation { skip, yes };
> 
> 
> Testing: tier1-3

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Rename yes to include

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9455/files
  - new: https://git.openjdk.org/jdk/pull/9455/files/2ba1c708..f597fcbb

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

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

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

From tschatzl at openjdk.org  Wed Jul 27 12:22:54 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 27 Jul 2022 12:22:54 GMT
Subject: RFR: 8290074: Remove implicit arguments for RegisterMap
 constructor [v2]
In-Reply-To: <2yemnBYAHLTI95rmFZnwpiK0N_XhtzBZr_jaOpTNjuA=.bc0a617f-ea88-4298-bc94-c031c679010f@github.com>
References: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>
 <2yemnBYAHLTI95rmFZnwpiK0N_XhtzBZr_jaOpTNjuA=.bc0a617f-ea88-4298-bc94-c031c679010f@github.com>
Message-ID: <CEKVPjIdxkXOFTBlE5-ocmRjnPCzDamK_K3KKy-MvBI=.5933bb04-954a-4f6b-80d3-eaa9a69410a1@github.com>

On Wed, 27 Jul 2022 09:45:25 GMT, Axel Boldt-Christmas <duke at openjdk.org> wrote:

>> Currently the `RegisterMap` constructor uses implicit boolean arguments to configure its function. Implicit boolean arguments makes code harder to understand and reason about at the call site. Using explicit scoped enums instead makes it both clear what is being configured and the type safety makes mistakes less likely. 
>> 
>> Update `RegisterMap` constructors to use these scoped enum types instead of booleans.
>> ```C++
>> enum class UpdateMap { skip, yes };
>> enum class ProcessFrames { skip, yes };
>> enum class WalkContinuation { skip, yes };
>> 
>> 
>> Testing: tier1-3
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename yes to include

Lgtm. Thanks.

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

Marked as reviewed by tschatzl (Reviewer).

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

From duke at openjdk.org  Wed Jul 27 12:54:36 2022
From: duke at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 27 Jul 2022 12:54:36 GMT
Subject: Integrated: 8290074: Remove implicit arguments for RegisterMap
 constructor
In-Reply-To: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>
References: <RW1OzVk646JQHyviZI_YGH1I6jbc6urxKyZiGLGrlMc=.62329e3b-d84d-4fef-a86f-4e72f1a27234@github.com>
Message-ID: <FC-tOvJPDa-0xOMgOO7ZwCP4VmDC2gRnF8e6tl0HO5s=.58f2c893-7b70-4ec7-b293-2feefd2c79ee@github.com>

On Mon, 11 Jul 2022 14:58:07 GMT, Axel Boldt-Christmas <duke at openjdk.org> wrote:

> Currently the `RegisterMap` constructor uses implicit boolean arguments to configure its function. Implicit boolean arguments makes code harder to understand and reason about at the call site. Using explicit scoped enums instead makes it both clear what is being configured and the type safety makes mistakes less likely. 
> 
> Update `RegisterMap` constructors to use these scoped enum types instead of booleans.
> ```C++
> enum class UpdateMap { skip, yes };
> enum class ProcessFrames { skip, yes };
> enum class WalkContinuation { skip, yes };
> 
> 
> Testing: tier1-3

This pull request has now been integrated.

Changeset: 2f3e494b
Author:    Axel Boldt-Christmas <axel.boldt-christmas at oracle.com>
Committer: Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f3e494b80cce8e357ceac9a897c42d7e8f54af5
Stats:     434 lines in 40 files changed: 317 ins; 0 del; 117 mod

8290074: Remove implicit arguments for RegisterMap constructor

Reviewed-by: eosterlund, tschatzl

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

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

From duke at openjdk.org  Wed Jul 27 13:37:38 2022
From: duke at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 27 Jul 2022 13:37:38 GMT
Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic
Message-ID: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>

The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object:
```C++
class DeoptimizationMarkerClosure : StackObj {
public:
  virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0;
};

This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. 
```C++
{
  NoSafepointVerifier nsv;
  assert_locked_or_safepoint(Compile_lock);
  marker_closure.marker_do(MarkFn());
  anything_deoptimized = deoptimize_all_marked();
}
if (anything_deoptimized) {
  run_deoptimize_closure();
}

This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound.

The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok.

An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. 

Testing: Tier 1-5

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

Commit messages:
 - JDK-8291237: Encapsulate nmethod Deoptimization logic

Changes: https://git.openjdk.org/jdk/pull/9655/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291237
  Stats: 719 lines in 21 files changed: 362 ins; 250 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/9655.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655

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

From cjplummer at openjdk.org  Wed Jul 27 21:42:24 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 27 Jul 2022 21:42:24 GMT
Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM
 options
In-Reply-To: <-si3mHhUSWEO_Pjo2ID0jovGkEZnNSEK5kbd_6skr4k=.bca9eaa2-58a7-40c6-9c9c-63298ac61f80@github.com>
References: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
 <T-LZ35vhH8Gm8iKz6s5FUxCNo-IH19KGuFptuYEpTZ4=.00a8b17f-9e74-4380-912d-549aef5a5f72@github.com>
 <r6QiasIZNZne4FNEbniLCm6988TmYlwewaApchL6FpE=.7b9f6187-fb4e-4f57-a0cb-0864958dcc19@github.com>
 <LDMT4Zpnw-PPBF7DMY22qZ_N-VsL7VB1babpvOlXf04=.b1b961a9-e3ed-451f-bdc4-9bbdf5fd7cbb@github.com>
 <-si3mHhUSWEO_Pjo2ID0jovGkEZnNSEK5kbd_6skr4k=.bca9eaa2-58a7-40c6-9c9c-63298ac61f80@github.com>
Message-ID: <zARySbNEU_LpanojN2SeyxwVMDwGOLhHNol1b4WCVRI=.55a307f7-ef02-4f1f-9e37-4d8e721b27ef@github.com>

On Fri, 22 Jul 2022 03:10:11 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> So shouldn't we have ZGC test failures then?
>
> No, test passes with ZGC.

I meant shouldn't we see ZGC failures before your changes. Otherwise I don't understand why this change is needed.

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

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

From lmesnik at openjdk.org  Wed Jul 27 21:42:24 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 27 Jul 2022 21:42:24 GMT
Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM
 options
In-Reply-To: <zARySbNEU_LpanojN2SeyxwVMDwGOLhHNol1b4WCVRI=.55a307f7-ef02-4f1f-9e37-4d8e721b27ef@github.com>
References: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
 <T-LZ35vhH8Gm8iKz6s5FUxCNo-IH19KGuFptuYEpTZ4=.00a8b17f-9e74-4380-912d-549aef5a5f72@github.com>
 <r6QiasIZNZne4FNEbniLCm6988TmYlwewaApchL6FpE=.7b9f6187-fb4e-4f57-a0cb-0864958dcc19@github.com>
 <LDMT4Zpnw-PPBF7DMY22qZ_N-VsL7VB1babpvOlXf04=.b1b961a9-e3ed-451f-bdc4-9bbdf5fd7cbb@github.com>
 <-si3mHhUSWEO_Pjo2ID0jovGkEZnNSEK5kbd_6skr4k=.bca9eaa2-58a7-40c6-9c9c-63298ac61f80@github.com>
 <zARySbNEU_LpanojN2SeyxwVMDwGOLhHNol1b4WCVRI=.55a307f7-ef02-4f1f-9e37-4d8e721b27ef@github.com>
Message-ID: <wMPN1a-DKu2DmSiD3G1OXF0bLQ6pEMKg_jWVEHeZUrc=.727b99fa-754a-45f0-bd13-1b0777698a6d@github.com>

On Fri, 22 Jul 2022 19:27:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> No, test passes with ZGC.
>
> I meant shouldn't we see ZGC failures before your changes. Otherwise I don't understand why this change is needed.

Before my changes test just silently ignored any GC setting and always use G1.

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

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

From cjplummer at openjdk.org  Wed Jul 27 22:34:35 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 27 Jul 2022 22:34:35 GMT
Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM
 options
In-Reply-To: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
References: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
Message-ID: <ZORr2fpdox12TZjZw5K-nUjimurrc0n__xwKM6JyczA=.8d8f3b6b-30cc-44a3-8080-1ff4a1f6a7e7@github.com>

On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid.

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.org  Wed Jul 27 22:34:37 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 27 Jul 2022 22:34:37 GMT
Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM
 options
In-Reply-To: <wMPN1a-DKu2DmSiD3G1OXF0bLQ6pEMKg_jWVEHeZUrc=.727b99fa-754a-45f0-bd13-1b0777698a6d@github.com>
References: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
 <T-LZ35vhH8Gm8iKz6s5FUxCNo-IH19KGuFptuYEpTZ4=.00a8b17f-9e74-4380-912d-549aef5a5f72@github.com>
 <r6QiasIZNZne4FNEbniLCm6988TmYlwewaApchL6FpE=.7b9f6187-fb4e-4f57-a0cb-0864958dcc19@github.com>
 <LDMT4Zpnw-PPBF7DMY22qZ_N-VsL7VB1babpvOlXf04=.b1b961a9-e3ed-451f-bdc4-9bbdf5fd7cbb@github.com>
 <-si3mHhUSWEO_Pjo2ID0jovGkEZnNSEK5kbd_6skr4k=.bca9eaa2-58a7-40c6-9c9c-63298ac61f80@github.com>
 <zARySbNEU_LpanojN2SeyxwVMDwGOLhHNol1b4WCVRI=.55a307f7-ef02-4f1f-9e37-4d8e721b27ef@github.com>
 <wMPN1a-DKu2DmSiD3G1OXF0bLQ6pEMKg_jWVEHeZUrc=.727b99fa-754a-45f0-bd13-1b0777698a6d@github.com>
Message-ID: <xoB46cN14xIrZJLiZtYtiHcz4EmqeTrA5GrSUI8Jji8=.5042b02a-78e5-47ef-a2c8-98e9ca5751d1@github.com>

On Wed, 27 Jul 2022 21:39:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> I meant shouldn't we see ZGC failures before your changes. Otherwise I don't understand why this change is needed.
>
> Before my changes test just silently ignored any GC setting and always use G1.

Ah, ok. That makes sense now.

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

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

From sspitsyn at openjdk.org  Wed Jul 27 23:21:33 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 27 Jul 2022 23:21:33 GMT
Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM
 options
In-Reply-To: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
References: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
Message-ID: <iUKAlVGFO3_aK6tt6PkBDwuknL_PFukuXB94eQueqIA=.a0df95b8-4674-42fb-93fc-81c759eac194@github.com>

On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid.

Looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From lmesnik at openjdk.org  Thu Jul 28 00:07:44 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 28 Jul 2022 00:07:44 GMT
Subject: Integrated: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM
 options
In-Reply-To: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
References: <jxQ8E5XZnum6dzvNsKC_SYAOLFWZ5NyQscaWz09O_50=.178703c6-5ebd-42fb-b921-8624b1271d40@github.com>
Message-ID: <daVjj1DoSRJuZY-FJMYrrGdqRFxgyD7_MAULyZxQrdk=.b1716e98-ba56-42c7-9fcf-4d34b3fe22e4@github.com>

On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid.

This pull request has now been integrated.

Changeset: 348a0521
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/348a0521e1cd602c4093955310f838cf4ce4daae
Stats:     5 lines in 2 files changed: 1 ins; 1 del; 3 mod

8290846: sun/tools/jstatd/JstatdTest* tests should use VM options

Reviewed-by: cjplummer, sspitsyn

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

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

From duke at openjdk.org  Thu Jul 28 15:16:42 2022
From: duke at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 28 Jul 2022 15:16:42 GMT
Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic
In-Reply-To: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
Message-ID: <petM7LbgbkT2-Xv68QGfkcTwUo3fggeiJ-jgx1_KD6w=.bf55ccd5-b478-48b9-95f3-daa96c809a94@github.com>

On Wed, 27 Jul 2022 12:55:04 GMT, Axel Boldt-Christmas <duke at openjdk.org> wrote:

> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object:
> ```C++
> class DeoptimizationMarkerClosure : StackObj {
> public:
>   virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0;
> };
> 
> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. 
> ```C++
> {
>   NoSafepointVerifier nsv;
>   assert_locked_or_safepoint(Compile_lock);
>   marker_closure.marker_do(MarkFn());
>   anything_deoptimized = deoptimize_all_marked();
> }
> if (anything_deoptimized) {
>   run_deoptimize_closure();
> }
> 
> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound.
> 
> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok.
> 
> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. 
> 
> Testing: Tier 1-5

@fisk suggested using a RAII context object instead of a closure to guarantee the encapsulated invariants. Testing the patch now and will push when done. Not having to create a closure everywhere makes the code less verbose and more readable.

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

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

From aoqi at openjdk.org  Thu Jul 28 16:18:44 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 28 Jul 2022 16:18:44 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations"
Message-ID: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>

`vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti".

The issue could be reproduced by zero.

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

Commit messages:
 - 8291508: Fix some tests with "requires vm.continuations"

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

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

From naoto at openjdk.org  Thu Jul 28 20:54:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 28 Jul 2022 20:54:21 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <kyU6nIIGoMX_otMTj_M8I7RVJwm85FOaTi05QHsi1nM=.2d4a5ec1-411f-4eaa-9def-b0b7239e632c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <kyU6nIIGoMX_otMTj_M8I7RVJwm85FOaTi05QHsi1nM=.2d4a5ec1-411f-4eaa-9def-b0b7239e632c@github.com>
Message-ID: <bhXKuIFtr_FTB_j6ewaj0WeGlxOXZZVs4tdVq7odvoQ=.3ad74be2-d23d-4140-b706-35c454576231@github.com>

On Tue, 26 Jul 2022 20:31:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed localized files from base

- src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_US.properties: this should not be moved from `java.base` module
- I still need some comments explaining `XXX=XXX` in the root bundle of `CurrencyNames`. Something like 

These currency symbol entries are for the root bundle only to avoid throwing a MissingResourceException. Should not be copied into each localized resource bundle.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: CNY=\uffe5

Do not remove the original translation.

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

Changes requested by naoto (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/154

From sangheki at openjdk.org  Thu Jul 28 21:11:34 2022
From: sangheki at openjdk.org (Sangheon Kim)
Date: Thu, 28 Jul 2022 21:11:34 GMT
Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector
 [v2]
In-Reply-To: <ECqk-3QabON8Mbv7mHWPuyl1nyIKEZuAg5_7pPoTOCY=.e8b8d031-7283-4a26-a01b-bfa4d13e1f4d@github.com>
References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com>
 <ECqk-3QabON8Mbv7mHWPuyl1nyIKEZuAg5_7pPoTOCY=.e8b8d031-7283-4a26-a01b-bfa4d13e1f4d@github.com>
Message-ID: <sCSxyDsrDxEJTRJ3PF_l9cRETFAPE3kdZ_KzsRVIyQs=.851868d2-c2db-449a-95c4-32bdaa57c71e@github.com>

On Thu, 21 Jul 2022 08:02:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read.
>> 
>> Testing: tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett review

Looks good.

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

Marked as reviewed by sangheki (Reviewer).

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

From tschatzl at openjdk.org  Fri Jul 29 15:45:45 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 29 Jul 2022 15:45:45 GMT
Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector
 [v2]
In-Reply-To: <eMyZqp20xEObzhvHZgrXK4R-JQAzsh_TPj2BUmi9JKc=.9653946e-3c59-427b-813b-4571f408a525@github.com>
References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com>
 <ECqk-3QabON8Mbv7mHWPuyl1nyIKEZuAg5_7pPoTOCY=.e8b8d031-7283-4a26-a01b-bfa4d13e1f4d@github.com>
 <eMyZqp20xEObzhvHZgrXK4R-JQAzsh_TPj2BUmi9JKc=.9653946e-3c59-427b-813b-4571f408a525@github.com>
Message-ID: <nrLm83LzQ2dd_45Nii0auxfMGhVUG7wlCWb2Ku_DfJA=.1ebf9fb5-647a-47e1-a3d1-53bd5149b110@github.com>

On Thu, 21 Jul 2022 11:14:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kbarrett review
>
> Marked as reviewed by kbarrett (Reviewer).

Thanks @kimbarrett @sangheon for your reviews.

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

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

From tschatzl at openjdk.org  Fri Jul 29 15:48:45 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 29 Jul 2022 15:48:45 GMT
Subject: Integrated: 8290525: Move HeapRegion::_compaction_top to
 G1FullCollector
In-Reply-To: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com>
References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com>
Message-ID: <XYNkzxFTbjg2KRRsZPyVmWyryRFN267EOPUBPK-IVPk=.3fab2379-c997-4391-badd-749e1c8dd7c2@github.com>

On Tue, 19 Jul 2022 15:47:01 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 95fc16bd
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/95fc16bdfa7325ce9f6f8220964f78e6ab63078e
Stats:     79 lines in 14 files changed: 28 ins; 32 del; 19 mod

8290525: Move HeapRegion::_compaction_top to G1FullCollector

Reviewed-by: kbarrett, sangheki

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

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

From achung at openjdk.org  Fri Jul 29 18:13:25 2022
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 29 Jul 2022 18:13:25 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>

> open l10n msg drop
> All tests passed.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/154/files
  - new: https://git.openjdk.org/jdk19/pull/154/files/6776bd0f..737b253f

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

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

PR: https://git.openjdk.org/jdk19/pull/154

From sspitsyn at openjdk.org  Fri Jul 29 19:17:20 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Jul 2022 19:17:20 GMT
Subject: RFR: 8282666: nsk/jvmti/PopFrame/popframe004 failed with: TEST FAILED:
 30 JVMTI events were generated by the function PopFrame()
Message-ID: <7U_GmEp3rv8Way4tSPN7fbkzKoVk5_BlL0BYWRAfcsg=.51991236-d09b-49d5-ae28-38972786e80f@github.com>

The nsk.jvmti test popframe004 is failing with the JVM args:
  `-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation`

The call to join() below should not have a timeout parameter.

        try {
            if (popFrameClsThr.isAlive())
                popFrameClsThr.join(2000);
        } catch (InterruptedException e) {
            out.println("TEST INCOMPLETE: caught " + e);
            totRes = FAILED;
        }
        if (popFrameClsThr.isAlive()) {
            out.println("TEST FAILED: thread with the method of " +
                "the popped frame is still alive");
            totRes = FAILED;
        } 

If the execution is slow by any reason (e.g. because of a compilation) then it causes the main thread to fail joining with the target thread which is why the test is failing with these symptoms.

This problem is hard to reproduce even in 1000's of runs on mach5.

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

Commit messages:
 - 8282666: nsk/jvmti/PopFrame/popframe004 failed with: TEST FAILED: 30 JVMTI events were generated by the function PopFrame()

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

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

From lmesnik at openjdk.org  Fri Jul 29 19:59:39 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 29 Jul 2022 19:59:39 GMT
Subject: RFR: 8282666: nsk/jvmti/PopFrame/popframe004 failed with: TEST
 FAILED: 30 JVMTI events were generated by the function PopFrame()
In-Reply-To: <7U_GmEp3rv8Way4tSPN7fbkzKoVk5_BlL0BYWRAfcsg=.51991236-d09b-49d5-ae28-38972786e80f@github.com>
References: <7U_GmEp3rv8Way4tSPN7fbkzKoVk5_BlL0BYWRAfcsg=.51991236-d09b-49d5-ae28-38972786e80f@github.com>
Message-ID: <oJ05llCrlJfwnF_h4JXtQPyWusWrKrqI8JYN7zJHUS0=.b0470af2-4a1a-4a78-99a1-dfd9d450f4ff@github.com>

On Fri, 29 Jul 2022 19:08:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The nsk.jvmti test popframe004 is failing with the JVM args:
>   `-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation`
> 
> The call to join() below should not have a timeout parameter.
> 
>         try {
>             if (popFrameClsThr.isAlive())
>                 popFrameClsThr.join(2000);
>         } catch (InterruptedException e) {
>             out.println("TEST INCOMPLETE: caught " + e);
>             totRes = FAILED;
>         }
>         if (popFrameClsThr.isAlive()) {
>             out.println("TEST FAILED: thread with the method of " +
>                 "the popped frame is still alive");
>             totRes = FAILED;
>         } 
> 
> If the execution is slow by any reason (e.g. because of a compilation) then it causes the main thread to fail joining with the target thread which is why the test is failing with these symptoms.
> 
> This problem is hard to reproduce even in 1000's of runs on mach5.

looks good

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

Marked as reviewed by lmesnik (Reviewer).

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

From amenkov at openjdk.org  Fri Jul 29 19:59:40 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 29 Jul 2022 19:59:40 GMT
Subject: RFR: 8282666: nsk/jvmti/PopFrame/popframe004 failed with: TEST
 FAILED: 30 JVMTI events were generated by the function PopFrame()
In-Reply-To: <7U_GmEp3rv8Way4tSPN7fbkzKoVk5_BlL0BYWRAfcsg=.51991236-d09b-49d5-ae28-38972786e80f@github.com>
References: <7U_GmEp3rv8Way4tSPN7fbkzKoVk5_BlL0BYWRAfcsg=.51991236-d09b-49d5-ae28-38972786e80f@github.com>
Message-ID: <Q0z2Dm6E6hBWN32Z_6h8-PID4rj1TCo5y_TuWJ-v8Bk=.5a8ae91a-819d-4160-b59a-c528050fc5c6@github.com>

On Fri, 29 Jul 2022 19:08:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The nsk.jvmti test popframe004 is failing with the JVM args:
>   `-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation`
> 
> The call to join() below should not have a timeout parameter.
> 
>         try {
>             if (popFrameClsThr.isAlive())
>                 popFrameClsThr.join(2000);
>         } catch (InterruptedException e) {
>             out.println("TEST INCOMPLETE: caught " + e);
>             totRes = FAILED;
>         }
>         if (popFrameClsThr.isAlive()) {
>             out.println("TEST FAILED: thread with the method of " +
>                 "the popped frame is still alive");
>             totRes = FAILED;
>         } 
> 
> If the execution is slow by any reason (e.g. because of a compilation) then it causes the main thread to fail joining with the target thread which is why the test is failing with these symptoms.
> 
> This problem is hard to reproduce even in 1000's of runs on mach5.

Marked as reviewed by amenkov (Reviewer).

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

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

From sspitsyn at openjdk.org  Fri Jul 29 21:49:47 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Jul 2022 21:49:47 GMT
Subject: RFR: 8282666: nsk/jvmti/PopFrame/popframe004 failed with: TEST
 FAILED: 30 JVMTI events were generated by the function PopFrame()
In-Reply-To: <7U_GmEp3rv8Way4tSPN7fbkzKoVk5_BlL0BYWRAfcsg=.51991236-d09b-49d5-ae28-38972786e80f@github.com>
References: <7U_GmEp3rv8Way4tSPN7fbkzKoVk5_BlL0BYWRAfcsg=.51991236-d09b-49d5-ae28-38972786e80f@github.com>
Message-ID: <OluXWFCK_lFVFL3y-jSEb94U_5q_5OKkEPAlfF1fEVw=.71ad4fef-2161-426b-8683-efdeca12c87c@github.com>

On Fri, 29 Jul 2022 19:08:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The nsk.jvmti test popframe004 is failing with the JVM args:
>   `-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation`
> 
> The call to join() below should not have a timeout parameter.
> 
>         try {
>             if (popFrameClsThr.isAlive())
>                 popFrameClsThr.join(2000);
>         } catch (InterruptedException e) {
>             out.println("TEST INCOMPLETE: caught " + e);
>             totRes = FAILED;
>         }
>         if (popFrameClsThr.isAlive()) {
>             out.println("TEST FAILED: thread with the method of " +
>                 "the popped frame is still alive");
>             totRes = FAILED;
>         } 
> 
> If the execution is slow by any reason (e.g. because of a compilation) then it causes the main thread to fail joining with the target thread which is why the test is failing with these symptoms.
> 
> This problem is hard to reproduce even in 1000's of runs on mach5.

Alex and Leonid, thank you for quick review!
I will integrate this now as the fix is pretty trivial.

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

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

From sspitsyn at openjdk.org  Fri Jul 29 21:53:41 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 29 Jul 2022 21:53:41 GMT
Subject: Integrated: 8282666: nsk/jvmti/PopFrame/popframe004 failed with: TEST
 FAILED: 30 JVMTI events were generated by the function PopFrame()
In-Reply-To: <7U_GmEp3rv8Way4tSPN7fbkzKoVk5_BlL0BYWRAfcsg=.51991236-d09b-49d5-ae28-38972786e80f@github.com>
References: <7U_GmEp3rv8Way4tSPN7fbkzKoVk5_BlL0BYWRAfcsg=.51991236-d09b-49d5-ae28-38972786e80f@github.com>
Message-ID: <wKG5HjDvm0vRpmEDasi3dRTkSNVw1FowohUJtMLlTsg=.35896b53-0976-41ca-88f8-273c0c906d48@github.com>

On Fri, 29 Jul 2022 19:08:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The nsk.jvmti test popframe004 is failing with the JVM args:
>   `-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation`
> 
> The call to join() below should not have a timeout parameter.
> 
>         try {
>             if (popFrameClsThr.isAlive())
>                 popFrameClsThr.join(2000);
>         } catch (InterruptedException e) {
>             out.println("TEST INCOMPLETE: caught " + e);
>             totRes = FAILED;
>         }
>         if (popFrameClsThr.isAlive()) {
>             out.println("TEST FAILED: thread with the method of " +
>                 "the popped frame is still alive");
>             totRes = FAILED;
>         } 
> 
> If the execution is slow by any reason (e.g. because of a compilation) then it causes the main thread to fail joining with the target thread which is why the test is failing with these symptoms.
> 
> This problem is hard to reproduce even in 1000's of runs on mach5.

This pull request has now been integrated.

Changeset: 15943e42
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15943e424244abb2fd033521f3ca562f3539e8fd
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8282666: nsk/jvmti/PopFrame/popframe004 failed with: TEST FAILED: 30 JVMTI events were generated by the function PopFrame()

Reviewed-by: lmesnik, amenkov

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

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