From dcubed at openjdk.java.net  Sat May  1 00:19:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 1 May 2021 00:19:39 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v4]
In-Reply-To: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
Message-ID: <VlbHbaAxdw2Yl5sWNr-tAIvCLU-_NwIQ-w1CvjMuh0I=.11aa26b2-f6ca-4065-a5e0-65178c313715@github.com>

> The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
> 
> Currently running the new test thru Mach5 Tier[1-7].
> I've run the test thru several 12 hour runs on my MBP13 and
> on my Linux-X64 server.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary "@library /test/lib".

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3478/files
  - new: https://git.openjdk.java.net/jdk/pull/3478/files/3b4004d8..bac63a79

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

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

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

From whuang at openjdk.java.net  Sat May  1 04:15:14 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 1 May 2021 04:15:14 GMT
Subject: RFR: 8266187: Memory leak in appendBootClassPath() [v2]
In-Reply-To: <HvVBxde2QmtjzRLnVYe34CeZSHFEu9CGTnv5xj_dLf4=.99d24eb6-615b-445b-a9fe-1ab60fb92466@github.com>
References: <HvVBxde2QmtjzRLnVYe34CeZSHFEu9CGTnv5xj_dLf4=.99d24eb6-615b-445b-a9fe-1ab60fb92466@github.com>
Message-ID: <q2vSHDSKaNocr-BXPQYkUkAqJezkQBwDxji5Z_pLAyM=.e43ed8ad-b743-421c-908d-638e9f1055e8@github.com>

> Dear All, 
>     I find a memory leak in `appendBootClassPath()`
> https://github.com/openjdk/jdk/blob/75a2354dc276e107d64516d20fc72bc7ef3d5f86/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#L950
> * we malloc `resolved` from resolve(parent, path)
> * we use `resolved` in line 951 
> * we don't free() this memory after using.
> 
> I think we can fix this bug by adding a free() after line 951 as my commit.
> Thank you for your review. Any suggestion is welcome.
> 
> Yours , 
> Wang Huang

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

  update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3751/files
  - new: https://git.openjdk.java.net/jdk/pull/3751/files/c973192e..c2899578

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

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

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

From whuang at openjdk.java.net  Sat May  1 04:15:14 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Sat, 1 May 2021 04:15:14 GMT
Subject: RFR: 8266187: Memory leak in appendBootClassPath()
In-Reply-To: <Fwfyy3DJMOkXdrJTfKW_7lM08dj_R0eP5-FIaPdqIMs=.86480989-409c-4f8f-8091-c55c39fcc154@github.com>
References: <HvVBxde2QmtjzRLnVYe34CeZSHFEu9CGTnv5xj_dLf4=.99d24eb6-615b-445b-a9fe-1ab60fb92466@github.com>
 <Fwfyy3DJMOkXdrJTfKW_7lM08dj_R0eP5-FIaPdqIMs=.86480989-409c-4f8f-8091-c55c39fcc154@github.com>
Message-ID: <qKbxJvqg1N93N_c38a5GpEe3_06ncjgUs5pBmFneHJ8=.ba943af2-5c60-4985-b4d1-c9b4af7f0014@github.com>

On Fri, 30 Apr 2021 10:17:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Oops - please update the copyright year, thanks! (second year in the header is currently 2019, should become 2021).

Thank you for your suggestion.  I have update that.

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

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

From github.com+3094961+buddyliao at openjdk.java.net  Sat May  1 11:37:08 2021
From: github.com+3094961+buddyliao at openjdk.java.net (BuddyLiao)
Date: Sat, 1 May 2021 11:37:08 GMT
Subject: RFR: 8266193: BasicJMapTest should include testHistoParallel methods
Message-ID: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com>

The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included.

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

Commit messages:
 - 8266193: BasicJMapTest should include testHistoParallel methods

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

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

From vromero at openjdk.java.net  Sun May  2 02:10:26 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sun, 2 May 2021 02:10:26 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v6]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <Q1hazTs6avdgmK4wPDgVdT6Ki77SbjGfYOwCSz_8Yho=.7a7afb71-d34a-4fb0-a98e-3542a1e13949@github.com>

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

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

  restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/2744f615..304fd76a

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

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

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

From david.holmes at oracle.com  Sun May  2 05:48:22 2021
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 2 May 2021 15:48:22 +1000
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
In-Reply-To: <4VOXQ7X3vPyTIQJQ38PdExpGKj3f_ABeABa2ZDquBSg=.813d4dba-f14e-421f-811e-f2b65420fdaa@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com>
 <4VOXQ7X3vPyTIQJQ38PdExpGKj3f_ABeABa2ZDquBSg=.813d4dba-f14e-421f-811e-f2b65420fdaa@github.com>
Message-ID: <47438cf3-dc38-f77b-e558-60eb2d7b707c@oracle.com>

On 1/05/2021 6:57 am, Daniel D.Daugherty wrote:
> On Wed, 28 Apr 2021 12:55:18 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 137:
>>
>>> 135:         }
>>> 136:
>>> 137:         System.exit(run(timeMax, System.out) + exit_delta);
>>
>> jtreg tests don't use System.exit!
> 
> Hmmm... that's  generally true, but this is a test that must be run as
> "othervm" so this style of exit with the "+ exit_delta" logic has been
> used for these kinds of stress tests. I think this style came from the
> VMTestbase tests and I've used it with other stress tests.

Hmmm... this is a legacy style/approach that is not necessary any more. 
If the test fails it should throw an exception from the main thread and 
that will produce a non-zero exit value. I think seeing this legacy 
style in new tests will just confuse people.

YMMV.

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3478
> 

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Sun May  2 16:07:26 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya)
Date: Sun, 2 May 2021 16:07:26 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation [v3]
In-Reply-To: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
Message-ID: <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>

> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
> This PR changes to use `Long.hashCode` instead.

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

  Add some more SA's classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3522/files
  - new: https://git.openjdk.java.net/jdk/pull/3522/files/d1e30f77..ac5c2660

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

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

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

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Sun May  2 16:14:01 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya)
Date: Sun, 2 May 2021 16:14:01 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation [v3]
In-Reply-To: <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>
Message-ID: <nL7WGUWJX81PbTHctY9tojfm5X6lsIIcwsOqlmzhs2Q=.1fe2683a-0664-4fb0-87fb-e8b94a10ae1c@github.com>

On Sun, 2 May 2021 16:07:26 GMT, Mitsuru kariya <github.com+2217224+kariya-mitsuru at openjdk.org> wrote:

>> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
>> This PR changes to use `Long.hashCode` instead.
>
> Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some more SA's classes

I found that `WindbgAARCH64Thread` is the same, so I changed it together.

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

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

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Sun May  2 16:19:55 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya)
Date: Sun, 2 May 2021 16:19:55 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation [v3]
In-Reply-To: <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>
Message-ID: <YpyYxvRANiukwdLzT8TOTEnIHFY65144Whew-19xBP0=.f182d534-a578-42e5-9dec-122efeb617fe@github.com>

On Sun, 2 May 2021 16:07:26 GMT, Mitsuru kariya <github.com+2217224+kariya-mitsuru at openjdk.org> wrote:

>> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
>> This PR changes to use `Long.hashCode` instead.
>
> Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some more SA's classes

I have changed the title of this PR but I cannot change the title of issue JDK-8264734.
Would it have been better if I hadn't changed the title?

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

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

From ysuenaga at openjdk.java.net  Mon May  3 01:43:53 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 3 May 2021 01:43:53 GMT
Subject: RFR: 8265505: findsym does not work on remote debug server [v2]
In-Reply-To: <MSNm6K4fp1_B11Y_TMktfs9Tita0O5V5ok4p7OPZN7E=.b67b3932-c084-4ba5-9ce5-90e1413b00d7@github.com>
References: <vYTOMCGRIq4iAeYyBrn8eX8qG7kFzNPOEi8FuMcjg2s=.c08a4b69-1112-479e-9e72-72494ee11009@github.com>
 <MSNm6K4fp1_B11Y_TMktfs9Tita0O5V5ok4p7OPZN7E=.b67b3932-c084-4ba5-9ce5-90e1413b00d7@github.com>
Message-ID: <ro57Qs1PLjbD7DsnPdxKXHyc0ZzdQQmDHvpPSdqiSmo=.818cd076-8de6-44de-aef6-5a1ffc741984@github.com>

On Tue, 20 Apr 2021 23:18:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can see following error when we run `findsym` on CLHSDB which connects to remote debug server.
>> 
>> 
>> hsdb> verbose true
>> hsdb> findsym gHotSpotVMTypes
>> 0x00007f913d4a45b0Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null
>> java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$7.doit(CommandProcessor.java:618)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2116)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2086)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1957)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:282)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493)
>> 
>> 
>> The cause of this NPE is that CDebugger is null.  It happens when the debugger is running on debugd server.
>> Command line debugger like CLHSDB can delegate the command to debugd, like `pmap` and `pstack`. `findsym` can also use this scheme.
>> 
>> This PR has passed serviceability/sa tests on Linux x64.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

Ping: Could you review this PR? I need one more reviewer to push.

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

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

From fmatte at openjdk.java.net  Mon May  3 04:17:54 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Mon, 3 May 2021 04:17:54 GMT
Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails
 with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to
 double[][][] [v2]
In-Reply-To: <WDzJhktGgp7dKFMJ9ya1bsIIQtx1TVhcDvLACYB8GWE=.f83e8406-40d0-4ac4-86be-fbcd8674d6a0@github.com>
References: <CRhws_bAZAxKJwu_vUdY7mYDE91HClhs6VhmMwIJGvQ=.8686ea0c-2c3a-4d0e-99bf-8013b6574f53@github.com>
 <WDzJhktGgp7dKFMJ9ya1bsIIQtx1TVhcDvLACYB8GWE=.f83e8406-40d0-4ac4-86be-fbcd8674d6a0@github.com>
Message-ID: <BbFcmAbz-M72jgdGlW2yu4Rg1tQqFvst2_4tlPC2KrU=.c4444bb8-c926-4625-a222-49fc740754bc@github.com>

On Thu, 29 Apr 2021 07:58:26 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

>> findComponentType() logic is wrong. In findComponentType() method, We always get vm.classesByName() retruns empty list
>> list = vm.classesByName(parser.typeName());
>> We have "parser.typeName()" retruns " double[][]"
>> vm.classesByName("") is expecting the fully qualified name example "java.lang.Double"
>> This always returns empty list, resulting into ClassNotLoadedException as it assumes the Component class has not yet been loaded, hence the test case fails.
>> 
>> There was a suggested fix from Egor Ushakov from JetBrains, I am proposing the same to get this fix. I have verified the patch with required testing it works fine.
>
> Fairoz Matte has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update ArrayReferenceImpl.java
>  - Update ArrayTypeImpl.java

Hi Chris, thanks for the rreview.

> test/hotspot/jtreg/vmTestbase/nsk/jdb
> test/hotspot/jtreg/serviceability/jdwp
> test/hotspot/jtreg/vmTestbase/nsk/jdwp
> test/hotspot/jtreg/vmTestbase/nsk/jdi
> test/jdk/com/sun/jdi

I have verified tier1 to tier8 and didn't find any issues.
Could you please sponsor this push for me.

Thanks,

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

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

From github.com+7947546+tanghaoth90 at openjdk.java.net  Mon May  3 14:42:59 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Mon, 3 May 2021 14:42:59 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU
 load
Message-ID: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>

OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.

We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
"systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".

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

Commit messages:
 - 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load

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

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

From jlahoda at openjdk.java.net  Mon May  3 16:41:54 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 3 May 2021 16:41:54 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v6]
In-Reply-To: <Q1hazTs6avdgmK4wPDgVdT6Ki77SbjGfYOwCSz_8Yho=.7a7afb71-d34a-4fb0-a98e-3542a1e13949@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
 <Q1hazTs6avdgmK4wPDgVdT6Ki77SbjGfYOwCSz_8Yho=.7a7afb71-d34a-4fb0-a98e-3542a1e13949@github.com>
Message-ID: <WBi6bLOB01au08UiVs1yJKeh-V3E1Ll6n8XzgJPqUVM=.afbc01b3-be3d-4a80-a8ac-26288db464d1@github.com>

On Sun, 2 May 2021 02:10:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>> 
>> Thanks
>> 
>> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build

javac changes look good to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From mail.arghac at gmail.com  Mon May  3 17:14:07 2021
From: mail.arghac at gmail.com (Argha C)
Date: Mon, 3 May 2021 10:14:07 -0700
Subject: OperatingSystemImpl should factor cpu shares when calculating system
 load
Message-ID: <CAOz0wjGW=4dOhs6M0-S8nkntbZ0AODue8X8xrDx2Weds0b+LXQ@mail.gmail.com>

Hello,
I wanted to report an issue we're seeing with the load calculation, when
running with cpu shares > 1, in a container environment. Specifically, the
implementation of  *OperatingSystemImpl#getCpuLoad.*

*Problem*

When running with allocation of multiple cpu shares, ie. > 1 unit, the load
numbers do not comply with the expected range of 0-1. In the example
screenshot, it goes beyond 4.
This miscalculation throws off load based system heuristics, when running
in a container based environment.

*Proposed solution*

In a container aware environment, for load average calculation, the number
of cpu cycles, ie. *getCpuPeriod *must be multiplied by the number of
requested cpu shares by the process, ie. *getCpuShares.*
This would ensure that the load calculation uses the correct denominator
for elapsed time slice periods.

In the screenshot below, this would mean using *getCpuShares *as a
multiplier for *periodLength.*

Please consider validating this behavior. I'd be happy to submit a PR but
I'm not an openjdk author/contributor.
Thanks for your consideration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210503/fa5f158b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2021-05-03 at 10.02.27 AM.png
Type: image/png
Size: 479711 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210503/fa5f158b/ScreenShot2021-05-03at10.02.27AM-0001.png>

From david.holmes at oracle.com  Mon May  3 22:21:35 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 4 May 2021 08:21:35 +1000
Subject: OperatingSystemImpl should factor cpu shares when calculating
 system load
In-Reply-To: <CAOz0wjGW=4dOhs6M0-S8nkntbZ0AODue8X8xrDx2Weds0b+LXQ@mail.gmail.com>
References: <CAOz0wjGW=4dOhs6M0-S8nkntbZ0AODue8X8xrDx2Weds0b+LXQ@mail.gmail.com>
Message-ID: <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com>

Hi,

Is this related to the issue reported here:

https://bugs.openjdk.java.net/browse/JDK-8265836

Cheers,
David

On 4/05/2021 3:14 am, Argha C wrote:
> Hello,
> I wanted to report an issue we're seeing with the load calculation, when 
> running with cpu shares > 1, in a container environment. Specifically, 
> the implementation of /OperatingSystemImpl#getCpuLoad./
> /
> /
> /Problem/
> /
> /
> When running with allocation of multiple cpu shares, ie. > 1 unit, the 
> load numbers do not comply with the expected range of 0-1. In the 
> example screenshot, it goes beyond 4.
> This miscalculation throws off load based system heuristics, when 
> running in a container based environment.
> 
> /Proposed solution/
> /
> /
> In a container aware environment, for load average calculation, the 
> number of cpu cycles, ie. /getCpuPeriod /must be multiplied by the 
> number of requested cpu shares by the process, ie. /getCpuShares./
> This would ensure that the load calculation uses the correct denominator 
> for elapsed time slice periods.
> 
> In the screenshot below, this would mean using /getCpuShares /as a 
> multiplier for /periodLength./
> 
> Please consider validating this behavior. I'd be happy to submit a PR 
> but I'm not an openjdk author/contributor.
> Thanks for your consideration.

From mail.arghac at gmail.com  Mon May  3 23:07:06 2021
From: mail.arghac at gmail.com (Argha C)
Date: Mon, 3 May 2021 16:07:06 -0700
Subject: OperatingSystemImpl should factor cpu shares when calculating
 system load
In-Reply-To: <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com>
References: <CAOz0wjGW=4dOhs6M0-S8nkntbZ0AODue8X8xrDx2Weds0b+LXQ@mail.gmail.com>
 <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com>
Message-ID: <CAOz0wjH9qbrXx1qHinJoE7aJFxPJR_Z3hN23rK+g3Lbyoo=Dow@mail.gmail.com>

Hello David,
It does look quite similar.
The crux is factoring in the sum of cpu time across all shares, instead of
a single cpu share.
My proposal for implementing the fix is slightly different from the PR, but
happy to trust your advice on taking this forward.


On Mon, May 3, 2021 at 3:21 PM David Holmes <david.holmes at oracle.com> wrote:

> Hi,
>
> Is this related to the issue reported here:
>
> https://bugs.openjdk.java.net/browse/JDK-8265836
>
> Cheers,
> David
>
> On 4/05/2021 3:14 am, Argha C wrote:
> > Hello,
> > I wanted to report an issue we're seeing with the load calculation, when
> > running with cpu shares > 1, in a container environment. Specifically,
> > the implementation of /OperatingSystemImpl#getCpuLoad./
> > /
> > /
> > /Problem/
> > /
> > /
> > When running with allocation of multiple cpu shares, ie. > 1 unit, the
> > load numbers do not comply with the expected range of 0-1. In the
> > example screenshot, it goes beyond 4.
> > This miscalculation throws off load based system heuristics, when
> > running in a container based environment.
> >
> > /Proposed solution/
> > /
> > /
> > In a container aware environment, for load average calculation, the
> > number of cpu cycles, ie. /getCpuPeriod /must be multiplied by the
> > number of requested cpu shares by the process, ie. /getCpuShares./
> > This would ensure that the load calculation uses the correct denominator
> > for elapsed time slice periods.
> >
> > In the screenshot below, this would mean using /getCpuShares /as a
> > multiplier for /periodLength./
> >
> > Please consider validating this behavior. I'd be happy to submit a PR
> > but I'm not an openjdk author/contributor.
> > Thanks for your consideration.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210503/691b26a7/attachment.htm>

From david.holmes at oracle.com  Mon May  3 23:50:24 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 4 May 2021 09:50:24 +1000
Subject: OperatingSystemImpl should factor cpu shares when calculating
 system load
In-Reply-To: <CAOz0wjH9qbrXx1qHinJoE7aJFxPJR_Z3hN23rK+g3Lbyoo=Dow@mail.gmail.com>
References: <CAOz0wjGW=4dOhs6M0-S8nkntbZ0AODue8X8xrDx2Weds0b+LXQ@mail.gmail.com>
 <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com>
 <CAOz0wjH9qbrXx1qHinJoE7aJFxPJR_Z3hN23rK+g3Lbyoo=Dow@mail.gmail.com>
Message-ID: <6da4ac22-b109-6470-1145-a878cb6d235d@oracle.com>

On 4/05/2021 9:07 am, Argha C wrote:
> Hello David,
> It does look quite similar.
> The crux is factoring in the sum of cpu time across all shares, instead 
> of a single cpu share.
> My proposal for implementing the fix is slightly different from the PR, 
> but happy to trust your advice on taking this forward.

I would suggest liaising with the contributors of

https://github.com/openjdk/jdk/pull/3656

so see if all of the issues can be addressed together.

Cheers,
David

> 
> On Mon, May 3, 2021 at 3:21 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi,
> 
>     Is this related to the issue reported here:
> 
>     https://bugs.openjdk.java.net/browse/JDK-8265836
>     <https://bugs.openjdk.java.net/browse/JDK-8265836>
> 
>     Cheers,
>     David
> 
>     On 4/05/2021 3:14 am, Argha C wrote:
>      > Hello,
>      > I wanted to report an issue we're seeing with the load
>     calculation, when
>      > running with cpu shares > 1, in a container environment.
>     Specifically,
>      > the implementation of /OperatingSystemImpl#getCpuLoad./
>      > /
>      > /
>      > /Problem/
>      > /
>      > /
>      > When running with allocation of multiple cpu shares, ie. > 1
>     unit, the
>      > load numbers do not comply with the expected range of 0-1. In the
>      > example screenshot, it goes beyond 4.
>      > This miscalculation throws off load based system heuristics, when
>      > running in a container based environment.
>      >
>      > /Proposed solution/
>      > /
>      > /
>      > In a container aware environment, for load average calculation, the
>      > number of cpu cycles, ie. /getCpuPeriod /must be multiplied by the
>      > number of requested cpu shares by the process, ie. /getCpuShares./
>      > This would ensure that the load calculation uses the correct
>     denominator
>      > for elapsed time slice periods.
>      >
>      > In the screenshot below, this would mean using /getCpuShares /as a
>      > multiplier for /periodLength./
>      >
>      > Please consider validating this behavior. I'd be happy to submit
>     a PR
>      > but I'm not an openjdk author/contributor.
>      > Thanks for your consideration.
> 

From larry.cable at oracle.com  Tue May  4 00:57:16 2021
From: larry.cable at oracle.com (Laurence Cable)
Date: Mon, 3 May 2021 17:57:16 -0700
Subject: OperatingSystemImpl should factor cpu shares when calculating
 system load
In-Reply-To: <6da4ac22-b109-6470-1145-a878cb6d235d@oracle.com>
References: <CAOz0wjGW=4dOhs6M0-S8nkntbZ0AODue8X8xrDx2Weds0b+LXQ@mail.gmail.com>
 <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com>
 <CAOz0wjH9qbrXx1qHinJoE7aJFxPJR_Z3hN23rK+g3Lbyoo=Dow@mail.gmail.com>
 <6da4ac22-b109-6470-1145-a878cb6d235d@oracle.com>
Message-ID: <5aba1620-d10c-6586-8c3d-673ac58f6c4c@oracle.com>



On 5/3/21 4:50 PM, David Holmes wrote:
> On 4/05/2021 9:07 am, Argha C wrote:
>> Hello David,
>> It does look quite similar.
>> The crux is factoring in the sum of cpu time across all shares, 
>> instead of a single cpu share.
>> My proposal for implementing the fix is slightly different from the 
>> PR, but happy to trust your advice on taking this forward.
>
> I would suggest liaising with the contributors of
>
> https://github.com/openjdk/jdk/pull/3656
>
> so see if all of the issues can be addressed together.

+1!
>
> Cheers,
> David
>
>>
>> On Mon, May 3, 2021 at 3:21 PM David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> ??? Hi,
>>
>> ??? Is this related to the issue reported here:
>>
>> ??? https://bugs.openjdk.java.net/browse/JDK-8265836
>> ??? <https://bugs.openjdk.java.net/browse/JDK-8265836>
>>
>> ??? Cheers,
>> ??? David
>>
>> ??? On 4/05/2021 3:14 am, Argha C wrote:
>> ???? > Hello,
>> ???? > I wanted to report an issue we're seeing with the load
>> ??? calculation, when
>> ???? > running with cpu shares > 1, in a container environment.
>> ??? Specifically,
>> ???? > the implementation of /OperatingSystemImpl#getCpuLoad./
>> ???? > /
>> ???? > /
>> ???? > /Problem/
>> ???? > /
>> ???? > /
>> ???? > When running with allocation of multiple cpu shares, ie. > 1
>> ??? unit, the
>> ???? > load numbers do not comply with the expected range of 0-1. In the
>> ???? > example screenshot, it goes beyond 4.
>> ???? > This miscalculation throws off load based system heuristics, when
>> ???? > running in a container based environment.
>> ???? >
>> ???? > /Proposed solution/
>> ???? > /
>> ???? > /
>> ???? > In a container aware environment, for load average 
>> calculation, the
>> ???? > number of cpu cycles, ie. /getCpuPeriod /must be multiplied by 
>> the
>> ???? > number of requested cpu shares by the process, ie. 
>> /getCpuShares./
>> ???? > This would ensure that the load calculation uses the correct
>> ??? denominator
>> ???? > for elapsed time slice periods.
>> ???? >
>> ???? > In the screenshot below, this would mean using /getCpuShares 
>> /as a
>> ???? > multiplier for /periodLength./
>> ???? >
>> ???? > Please consider validating this behavior. I'd be happy to submit
>> ??? a PR
>> ???? > but I'm not an openjdk author/contributor.
>> ???? > Thanks for your consideration.
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: larry_cable.vcf
Type: text/x-vcard
Size: 217 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210503/03087b97/larry_cable.vcf>

From kevinw at openjdk.java.net  Tue May  4 09:37:54 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 4 May 2021 09:37:54 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation [v3]
In-Reply-To: <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>
Message-ID: <BPmcp5HiY6Q6NZvX-UiKsmmooLZNDQkjFkMTRcIGLyI=.4646c6f0-3a4e-43a9-a5af-35a1cd87e778@github.com>

On Sun, 2 May 2021 16:07:26 GMT, Mitsuru kariya <github.com+2217224+kariya-mitsuru at openjdk.org> wrote:

>> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
>> This PR changes to use `Long.hashCode` instead.
>
> Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some more SA's classes

Marked as reviewed by kevinw (Committer).

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

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

From kevinw at openjdk.java.net  Tue May  4 09:40:52 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 4 May 2021 09:40:52 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation [v3]
In-Reply-To: <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>
Message-ID: <cLRiJILDWOCuVBixyJR2JREwCjrCcXGlPg_49Lf8NXA=.241a4bf5-cb34-4cd1-a0a3-fba1bb1ffdb6@github.com>

On Sun, 2 May 2021 16:07:26 GMT, Mitsuru kariya <github.com+2217224+kariya-mitsuru at openjdk.org> wrote:

>> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
>> This PR changes to use `Long.hashCode` instead.
>
> Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some more SA's classes

No problem.  I updated the JBS title to match this.  I think the warning about title mismatch has gone.

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

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

From kevinw at openjdk.java.net  Tue May  4 09:53:01 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 4 May 2021 09:53:01 GMT
Subject: RFR: 8265505: findsym does not work on remote debug server [v2]
In-Reply-To: <MSNm6K4fp1_B11Y_TMktfs9Tita0O5V5ok4p7OPZN7E=.b67b3932-c084-4ba5-9ce5-90e1413b00d7@github.com>
References: <vYTOMCGRIq4iAeYyBrn8eX8qG7kFzNPOEi8FuMcjg2s=.c08a4b69-1112-479e-9e72-72494ee11009@github.com>
 <MSNm6K4fp1_B11Y_TMktfs9Tita0O5V5ok4p7OPZN7E=.b67b3932-c084-4ba5-9ce5-90e1413b00d7@github.com>
Message-ID: <I1tsdZ3uCSOaee077TtSUjtWNDMIZVoZtcc_9KAHJPA=.b89266a7-4a1c-48f1-a64f-0a4c8e80c006@github.com>

On Tue, 20 Apr 2021 23:18:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We can see following error when we run `findsym` on CLHSDB which connects to remote debug server.
>> 
>> 
>> hsdb> verbose true
>> hsdb> findsym gHotSpotVMTypes
>> 0x00007f913d4a45b0Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null
>> java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$7.doit(CommandProcessor.java:618)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2116)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2086)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1957)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:282)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493)
>> 
>> 
>> The cause of this NPE is that CDebugger is null.  It happens when the debugger is running on debugd server.
>> Command line debugger like CLHSDB can delegate the command to debugd, like `pmap` and `pstack`. `findsym` can also use this scheme.
>> 
>> This PR has passed serviceability/sa tests on Linux x64.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

Thanks - definitely good to have that Windows symbol logic out of CommandProcessor.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/Debugger.java line 114:

> 112:   /**
> 113:    * Find address and executable which contains symbol.
> 114:   */

Just a whitespace nit - the * doesn't align. 8-)

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

Marked as reviewed by kevinw (Committer).

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

From whuang at openjdk.java.net  Tue May  4 10:05:06 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Tue, 4 May 2021 10:05:06 GMT
Subject: Integrated: 8266187: Memory leak in appendBootClassPath()
In-Reply-To: <HvVBxde2QmtjzRLnVYe34CeZSHFEu9CGTnv5xj_dLf4=.99d24eb6-615b-445b-a9fe-1ab60fb92466@github.com>
References: <HvVBxde2QmtjzRLnVYe34CeZSHFEu9CGTnv5xj_dLf4=.99d24eb6-615b-445b-a9fe-1ab60fb92466@github.com>
Message-ID: <wdDSqydZe5hgQW8N2gxnbi4kTuHm71kGDq6J13_AUUY=.b8bfa5a2-6ba7-4214-baa9-975645d98028@github.com>

On Wed, 28 Apr 2021 06:38:57 GMT, Wang Huang <whuang at openjdk.org> wrote:

> Dear All, 
>     I find a memory leak in `appendBootClassPath()`
> https://github.com/openjdk/jdk/blob/75a2354dc276e107d64516d20fc72bc7ef3d5f86/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#L950
> * we malloc `resolved` from resolve(parent, path)
> * we use `resolved` in line 951 
> * we don't free() this memory after using.
> 
> I think we can fix this bug by adding a free() after line 951 as my commit.
> Thank you for your review. Any suggestion is welcome.
> 
> Yours , 
> Wang Huang

This pull request has now been integrated.

Changeset: aa90df6f
Author:    Wang Huang <whuang at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aa90df6f51940a73f9aa078a32768855c8568034
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8266187: Memory leak in appendBootClassPath()

Co-authored-by: Wang Huang <whuang at openjdk.org>
Co-authored-by: Sun Jianye <sunjianye at huawei.com>
Reviewed-by: kevinw, mli, alanb

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

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

From ysuenaga at openjdk.java.net  Tue May  4 11:47:22 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 4 May 2021 11:47:22 GMT
Subject: RFR: 8265505: findsym does not work on remote debug server [v3]
In-Reply-To: <vYTOMCGRIq4iAeYyBrn8eX8qG7kFzNPOEi8FuMcjg2s=.c08a4b69-1112-479e-9e72-72494ee11009@github.com>
References: <vYTOMCGRIq4iAeYyBrn8eX8qG7kFzNPOEi8FuMcjg2s=.c08a4b69-1112-479e-9e72-72494ee11009@github.com>
Message-ID: <13GKiD9JQOYJDJhrb5bpI8RzJNlMJlQvbrteqa-WGQg=.c07f9c9b-bd43-4520-b8cb-1ba26d6ad37a@github.com>

> We can see following error when we run `findsym` on CLHSDB which connects to remote debug server.
> 
> 
> hsdb> verbose true
> hsdb> findsym gHotSpotVMTypes
> 0x00007f913d4a45b0Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null
> java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null
>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$7.doit(CommandProcessor.java:618)
>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2116)
>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2086)
>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1957)
>         at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
>         at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:282)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493)
> 
> 
> The cause of this NPE is that CDebugger is null.  It happens when the debugger is running on debugd server.
> Command line debugger like CLHSDB can delegate the command to debugd, like `pmap` and `pstack`. `findsym` can also use this scheme.
> 
> This PR has passed serviceability/sa tests on Linux x64.

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

  Align whitespace

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3582/files
  - new: https://git.openjdk.java.net/jdk/pull/3582/files/6ef93d7d..b65c6fef

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

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

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

From ysuenaga at openjdk.java.net  Tue May  4 11:47:23 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 4 May 2021 11:47:23 GMT
Subject: RFR: 8265505: findsym does not work on remote debug server [v3]
In-Reply-To: <I1tsdZ3uCSOaee077TtSUjtWNDMIZVoZtcc_9KAHJPA=.b89266a7-4a1c-48f1-a64f-0a4c8e80c006@github.com>
References: <vYTOMCGRIq4iAeYyBrn8eX8qG7kFzNPOEi8FuMcjg2s=.c08a4b69-1112-479e-9e72-72494ee11009@github.com>
 <MSNm6K4fp1_B11Y_TMktfs9Tita0O5V5ok4p7OPZN7E=.b67b3932-c084-4ba5-9ce5-90e1413b00d7@github.com>
 <I1tsdZ3uCSOaee077TtSUjtWNDMIZVoZtcc_9KAHJPA=.b89266a7-4a1c-48f1-a64f-0a4c8e80c006@github.com>
Message-ID: <EKJ90AUmpZJBf0bvgpoIMLHdZejplEwK3iCRTeMlU30=.2b58820f-9eb0-4b5f-b502-1ecb3231f506@github.com>

On Tue, 4 May 2021 09:49:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Align whitespace
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/Debugger.java line 114:
> 
>> 112:   /**
>> 113:    * Find address and executable which contains symbol.
>> 114:   */
> 
> Just a whitespace nit - the * doesn't align. 8-)

Thanks! I aligned whitespace in new commit.

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

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

From ysuenaga at openjdk.java.net  Tue May  4 12:04:54 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 4 May 2021 12:04:54 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd
In-Reply-To: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
Message-ID: <AC4IF8pRCtEQbougGeJCB-59TlNBv58wU5_YPxbu4GA=.3f4fb7ba-6f51-452b-b72d-de1a5343d964@github.com>

On Sun, 25 Apr 2021 03:15:07 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA remote object. It is "SARemoteDebugger" by default.
> 
> As a result, remote name will be constructed as following:
> 
> 
> //host[:port]/<serverNamePrefix>['_'<id>]
> 
> 
> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. And also we should add the way to specify the prefix when we connect to debug server. I will add it like `--connect id at server:1234/prefix`.
> 
> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.

Ping: Could you review this PR and [CSR](https://bugs.openjdk.java.net/browse/JDK-8265897) ? Thanks!

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

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

From ysuenaga at openjdk.java.net  Tue May  4 12:05:59 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 4 May 2021 12:05:59 GMT
Subject: RFR: 8266038: Move newAddress() to JVMDebugger
In-Reply-To: <g2sxHFOtVfG39YsUw-zanYrLUXUe8YBFv87PJX3U09M=.60a35b2b-d976-4384-bc29-4b568ea333ae@github.com>
References: <g2sxHFOtVfG39YsUw-zanYrLUXUe8YBFv87PJX3U09M=.60a35b2b-d976-4384-bc29-4b568ea333ae@github.com>
Message-ID: <NE04u3lF5ht9Xm0Cl2-KL0Dqm70V4-LNnbmxu1qH8-M=.076aeda5-ac3e-4635-b0b5-232e5292a460@github.com>

On Tue, 27 Apr 2021 09:19:34 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> SA has `newAddress()` to create `Address` instance, however it is declared in each debugger classes (e.g. `LinuxDebugger`). So we can't access it directly from `VM` class.
> 
> Before SA improvement for ZGC in [JDK-8220624](https://bugs.openjdk.java.net/browse/JDK-8220624), we need to move `newAddress()` to super class (`JVMDebugger`).

Ping: Could you review this PR? I need Reviewer(s).

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

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

From coleenp at openjdk.java.net  Tue May  4 12:39:07 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 4 May 2021 12:39:07 GMT
Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication
Message-ID: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>

Marking running_emcp for Method* is unnecessary.  We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running.  See longer explanation in the CR.

Tested with tier1-6, tiers 7,8 are running and 98% passing.

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

Commit messages:
 - 8266497: Remove unnecessary EMCP liveness indication

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

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

From github.com+971473+argha-c at openjdk.java.net  Tue May  4 17:01:55 2021
From: github.com+971473+argha-c at openjdk.java.net (Argha C)
Date: Tue, 4 May 2021 17:01:55 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load
In-Reply-To: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
Message-ID: <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>

On Fri, 23 Apr 2021 13:33:42 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
> 
> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".

src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 142:

> 140:                 long usageNanos = containerMetrics.getCpuUsage();
> 141:                 if (numPeriods > 0 && usageNanos > 0) {
> 142:                     long quotaNanos = TimeUnit.MICROSECONDS.toNanos(quota * numPeriods);

We happened to hit an exactly similar problem when running on a container with openjdk15.

Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above. 
Is there a good reason `getCpuQuota` is a better alternative?

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

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

From iklam at openjdk.java.net  Tue May  4 18:17:52 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 4 May 2021 18:17:52 GMT
Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication
In-Reply-To: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
References: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
Message-ID: <nz3WwgBwHj_Djf4OMWzhk3hi2oZZntcNZopQpRB51t0=.b616f215-38e8-44ae-be27-716e26fe04a2@github.com>

On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Marking running_emcp for Method* is unnecessary.  We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running.  See longer explanation in the CR.
> 
> Tested with tier1-6, tiers 7,8 are running and 98% passing.

Looks reasonable to me.

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

Marked as reviewed by iklam (Reviewer).

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

From coleenp at openjdk.java.net  Tue May  4 19:24:56 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 4 May 2021 19:24:56 GMT
Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication
In-Reply-To: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
References: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
Message-ID: <Kfz5Xeu1FTWAvZGD7yhDoM3tCq7W26TzdMwJc93WqEI=.6461dc0a-1662-4880-a95f-1848b1814c5f@github.com>

On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Marking running_emcp for Method* is unnecessary.  We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running.  See longer explanation in the CR.
> 
> Tested with tier1-6, tiers 7,8 are running and 98% passing.

Thanks Ioi, and thanks for updating the description.

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

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

From amenkov at openjdk.java.net  Tue May  4 20:33:58 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 4 May 2021 20:33:58 GMT
Subject: RFR: 8266038: Move newAddress() to JVMDebugger
In-Reply-To: <g2sxHFOtVfG39YsUw-zanYrLUXUe8YBFv87PJX3U09M=.60a35b2b-d976-4384-bc29-4b568ea333ae@github.com>
References: <g2sxHFOtVfG39YsUw-zanYrLUXUe8YBFv87PJX3U09M=.60a35b2b-d976-4384-bc29-4b568ea333ae@github.com>
Message-ID: <Kzqjgud7AkEjgLkAUwbanPmJGozO9kCMvTOUtS6svxQ=.3ab6b773-443a-4ef4-80d0-600e2f2729ed@github.com>

On Tue, 27 Apr 2021 09:19:34 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> SA has `newAddress()` to create `Address` instance, however it is declared in each debugger classes (e.g. `LinuxDebugger`). So we can't access it directly from `VM` class.
> 
> Before SA improvement for ZGC in [JDK-8220624](https://bugs.openjdk.java.net/browse/JDK-8220624), we need to move `newAddress()` to super class (`JVMDebugger`).

Marked as reviewed by amenkov (Reviewer).

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

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

From dholmes at openjdk.java.net  Tue May  4 23:55:50 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 4 May 2021 23:55:50 GMT
Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log
In-Reply-To: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
References: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
Message-ID: <ePPUEpHlLvXDQuAjNNbhJWIgsMtG9sSRMG2NDCA3qPc=.34ec71c3-6d3d-41ef-8a78-9c2033ae01f3@github.com>

On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 4976 VM.log list
> Log output configuration:
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K
> 
> $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100"
> 4976:
> Output options for existing outputs are ignored.
> 
> $ jcmd 4976 VM.log output="#2" output_options="filecount=100"
> 4976:
> Command executed successfully
> 
> 
> It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases.
> 
> 
> $ jcmd 4976 VM.log list
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured)
> 
> This pull request enable to show the warning message when specifying the output index.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> $ jcmd 5054 VM.log output="#2" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> 
> ### gtest result
> 
> 
> $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.*
> Note: Google Test filter = LogConfigurationTest.*
> [==========] Running 15 tests from 1 test case.
> [----------] Global test environment set-up.
> [----------] 15 tests from LogConfigurationTest
> [ RUN      ] LogConfigurationTest.describe_vm
> [       OK ] LogConfigurationTest.describe_vm (1 ms)
> [ RUN      ] LogConfigurationTest.update_output_vm
> [       OK ] LogConfigurationTest.update_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.add_new_output_vm
> [       OK ] LogConfigurationTest.add_new_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.disable_logging_vm
> [       OK ] LogConfigurationTest.disable_logging_vm (1 ms)
> [ RUN      ] LogConfigurationTest.disable_output_vm
> [       OK ] LogConfigurationTest.disable_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.reconfigure_decorators_vm
> [       OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms)
> [ RUN      ] LogConfigurationTest.invalid_configure_options_vm
> [       OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_empty_command_line_arguments_vm
> [0.462s][warning][logging] Ignoring excess -Xlog options: ""
> [       OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_command_line_arguments_vm
> [       OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms)
> [ RUN      ] LogConfigurationTest.parse_log_arguments_vm
> [       OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms)
> [ RUN      ] LogConfigurationTest.configure_stdout_vm
> [       OK ] LogConfigurationTest.configure_stdout_vm (2 ms)
> [ RUN      ] LogConfigurationTest.subscribe_vm
> [       OK ] LogConfigurationTest.subscribe_vm (2 ms)
> [ RUN      ] LogConfigurationTest.parse_invalid_tagset_vm
> [       OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms)
> [ RUN      ] LogConfigurationTest.output_name_normalization_vm
> [       OK ] LogConfigurationTest.output_name_normalization_vm (1 ms)
> [ RUN      ] LogConfigurationTest.suggest_similar_selection_vm
> [       OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms)
> [----------] 15 tests from LogConfigurationTest (658 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 15 tests from 1 test case ran. (659 ms total)
> [  PASSED  ] 15 tests.

Sorry for the delay in noticing this PR!

Fix looks good. One nit on variable naming below.

Thanks,
David

src/hotspot/share/logging/logConfiguration.cpp line 430:

> 428:   ConfigurationLock cl;
> 429:   size_t idx;
> 430:   bool is_added = false;

Nit: `was_added` (or even just `added`)

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

Marked as reviewed by dholmes (Reviewer).

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

From dholmes at openjdk.java.net  Wed May  5 00:19:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 5 May 2021 00:19:49 GMT
Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication
In-Reply-To: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
References: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
Message-ID: <Dr6PXJYHH_dk0ajXy04ZSTYFS1IMGBn4NN1FA4x-0L8=.279d4244-f733-40ce-a371-6a29e08fe463@github.com>

On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Marking running_emcp for Method* is unnecessary.  We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running.  See longer explanation in the CR.
> 
> Tested with tier1-6, tiers 7,8 are running and 98% passing.

Hi Coleen,

Seems reasonable. Nice simplification too!

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From ysuenaga at openjdk.java.net  Wed May  5 00:26:52 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 5 May 2021 00:26:52 GMT
Subject: Integrated: 8266038: Move newAddress() to JVMDebugger
In-Reply-To: <g2sxHFOtVfG39YsUw-zanYrLUXUe8YBFv87PJX3U09M=.60a35b2b-d976-4384-bc29-4b568ea333ae@github.com>
References: <g2sxHFOtVfG39YsUw-zanYrLUXUe8YBFv87PJX3U09M=.60a35b2b-d976-4384-bc29-4b568ea333ae@github.com>
Message-ID: <Swtm28AW2N_KlBYijMRunTuJTzGliThD_SJHzG2Owps=.69d3d8b9-712b-4e68-b73e-21da1c8f9f82@github.com>

On Tue, 27 Apr 2021 09:19:34 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> SA has `newAddress()` to create `Address` instance, however it is declared in each debugger classes (e.g. `LinuxDebugger`). So we can't access it directly from `VM` class.
> 
> Before SA improvement for ZGC in [JDK-8220624](https://bugs.openjdk.java.net/browse/JDK-8220624), we need to move `newAddress()` to super class (`JVMDebugger`).

This pull request has now been integrated.

Changeset: b88785d2
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b88785d2c6945c3063ad264d27609980c359cd77
Stats:     10 lines in 5 files changed: 1 ins; 4 del; 5 mod

8266038: Move newAddress() to JVMDebugger

Reviewed-by: kevinw, amenkov

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

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

From ysuenaga at openjdk.java.net  Wed May  5 00:29:55 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 5 May 2021 00:29:55 GMT
Subject: Integrated: 8265505: findsym does not work on remote debug server
In-Reply-To: <vYTOMCGRIq4iAeYyBrn8eX8qG7kFzNPOEi8FuMcjg2s=.c08a4b69-1112-479e-9e72-72494ee11009@github.com>
References: <vYTOMCGRIq4iAeYyBrn8eX8qG7kFzNPOEi8FuMcjg2s=.c08a4b69-1112-479e-9e72-72494ee11009@github.com>
Message-ID: <R6BCp3ZJlsc7vvi6aJ1SkiZ0H028GmcIL_PyI_xPUpU=.e1544233-5a9b-4664-85be-8790dec6d94c@github.com>

On Tue, 20 Apr 2021 07:31:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We can see following error when we run `findsym` on CLHSDB which connects to remote debug server.
> 
> 
> hsdb> verbose true
> hsdb> findsym gHotSpotVMTypes
> 0x00007f913d4a45b0Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null
> java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null
>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$7.doit(CommandProcessor.java:618)
>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2116)
>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2086)
>         at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1957)
>         at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
>         at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:282)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493)
> 
> 
> The cause of this NPE is that CDebugger is null.  It happens when the debugger is running on debugd server.
> Command line debugger like CLHSDB can delegate the command to debugd, like `pmap` and `pstack`. `findsym` can also use this scheme.
> 
> This PR has passed serviceability/sa tests on Linux x64.

This pull request has now been integrated.

Changeset: 8bcebe73
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8bcebe73d283bd651a0e2d30133e40cca655f335
Stats:     94 lines in 6 files changed: 44 ins; 30 del; 20 mod

8265505: findsym does not work on remote debug server

Reviewed-by: cjplummer, kevinw

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

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

From sspitsyn at openjdk.java.net  Wed May  5 01:09:54 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 01:09:54 GMT
Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication
In-Reply-To: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
References: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
Message-ID: <9izvv99yDgbpyzYA4x_mh5GC36i04ltjSg2XtgRNUAI=.4f1450af-face-4e02-bd40-08df1c3d6723@github.com>

On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Marking running_emcp for Method* is unnecessary.  We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running.  See longer explanation in the CR.
> 
> Tested with tier1-6, tiers 7,8 are running and 98% passing.

Hi Coleen,

This looks good to me in general.
I'm a little bit puzzled why the check ` emcp_method_count != 0` is needed at the line:
`4005   if (emcp_method_count != 0 && obsolete_method_count != 0 &&`

Suppose, the emcp_method_count is equal to 0.
Then do we really want to skip marking all the methods of this InstanceKlass as obsolete?
Most likely, I'm missing something.

Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Wed May  5 02:08:49 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 02:08:49 GMT
Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails
 with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to
 double[][][] [v2]
In-Reply-To: <WDzJhktGgp7dKFMJ9ya1bsIIQtx1TVhcDvLACYB8GWE=.f83e8406-40d0-4ac4-86be-fbcd8674d6a0@github.com>
References: <CRhws_bAZAxKJwu_vUdY7mYDE91HClhs6VhmMwIJGvQ=.8686ea0c-2c3a-4d0e-99bf-8013b6574f53@github.com>
 <WDzJhktGgp7dKFMJ9ya1bsIIQtx1TVhcDvLACYB8GWE=.f83e8406-40d0-4ac4-86be-fbcd8674d6a0@github.com>
Message-ID: <uSn6XOFz7jc5MCYrddSnPlrlOLCcQvJMd9jEcUFAcK4=.44ef650c-6c9d-4106-9b0a-532d898e646e@github.com>

On Thu, 29 Apr 2021 07:58:26 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

>> findComponentType() logic is wrong. In findComponentType() method, We always get vm.classesByName() retruns empty list
>> list = vm.classesByName(parser.typeName());
>> We have "parser.typeName()" retruns " double[][]"
>> vm.classesByName("") is expecting the fully qualified name example "java.lang.Double"
>> This always returns empty list, resulting into ClassNotLoadedException as it assumes the Component class has not yet been loaded, hence the test case fails.
>> 
>> There was a suggested fix from Egor Ushakov from JetBrains, I am proposing the same to get this fix. I have verified the patch with required testing it works fine.
>
> Fairoz Matte has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update ArrayReferenceImpl.java
>  - Update ArrayTypeImpl.java

Hi Fairoz,
It looks good to me.
It is a good change to get rid of the `findComponentType`.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From fmatte at openjdk.java.net  Wed May  5 02:56:05 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Wed, 5 May 2021 02:56:05 GMT
Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails
 with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to
 double[][][] [v2]
In-Reply-To: <WDzJhktGgp7dKFMJ9ya1bsIIQtx1TVhcDvLACYB8GWE=.f83e8406-40d0-4ac4-86be-fbcd8674d6a0@github.com>
References: <CRhws_bAZAxKJwu_vUdY7mYDE91HClhs6VhmMwIJGvQ=.8686ea0c-2c3a-4d0e-99bf-8013b6574f53@github.com>
 <WDzJhktGgp7dKFMJ9ya1bsIIQtx1TVhcDvLACYB8GWE=.f83e8406-40d0-4ac4-86be-fbcd8674d6a0@github.com>
Message-ID: <evIQU_CupYdxcEo6npn4nHSOfUKWuI1QT5RjFt4CLT0=.e88d8e65-4b3f-41c6-bf81-46069318eb6b@github.com>

On Thu, 29 Apr 2021 07:58:26 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

>> findComponentType() logic is wrong. In findComponentType() method, We always get vm.classesByName() retruns empty list
>> list = vm.classesByName(parser.typeName());
>> We have "parser.typeName()" retruns " double[][]"
>> vm.classesByName("") is expecting the fully qualified name example "java.lang.Double"
>> This always returns empty list, resulting into ClassNotLoadedException as it assumes the Component class has not yet been loaded, hence the test case fails.
>> 
>> There was a suggested fix from Egor Ushakov from JetBrains, I am proposing the same to get this fix. I have verified the patch with required testing it works fine.
>
> Fairoz Matte has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update ArrayReferenceImpl.java
>  - Update ArrayTypeImpl.java

Hi Serguei, thanks for the review.

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

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

From github.com+7947546+tanghaoth90 at openjdk.java.net  Wed May  5 06:00:52 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Wed, 5 May 2021 06:00:52 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load
In-Reply-To: <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
Message-ID: <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>

On Tue, 4 May 2021 04:07:52 GMT, Argha C <github.com+971473+argha-c at openjdk.org> wrote:

>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
>> 
>> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
>> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".
>
> src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 142:
> 
>> 140:                 long usageNanos = containerMetrics.getCpuUsage();
>> 141:                 if (numPeriods > 0 && usageNanos > 0) {
>> 142:                     long quotaNanos = TimeUnit.MICROSECONDS.toNanos(quota * numPeriods);
> 
> We happened to hit an exactly similar problem when running on a container with openjdk15.
> 
> Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above. 
> Is there a good reason `getCpuQuota` is a better alternative?

Hi Argha, thanks a lot for your suggestion. I think both "quota" and "share" are worth considering. Let us look into the implementation of `CgroupSubsystem::active_processor_count()` in OpenJDK HotSpot (https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/cgroupSubsystem_linux.cpp).

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

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

From ysuenaga at openjdk.java.net  Wed May  5 06:37:14 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 5 May 2021 06:37:14 GMT
Subject: RFR: 8266531: ZAddress::address() should be removed from SA
Message-ID: <zWaxT0z3NQRICv2UGjLMxheBNd-L9RCkgQ2S1TniC5E=.c1c80a80-014a-4982-9aa5-7e517d3f3019@github.com>

`ZAddress::address()` has been removed since [JDK-8235748](https://bugs.openjdk.java.net/browse/JDK-8235748), however SA has not followed it. Thus some SA tests would fail with ZGC.
After this change, more than half of jtreg tests which are listed in ProblemList-zgc.txt pass on Linux x64 with -vmoption:-XX:+UseZGC. Please see the change of ProblemList-zgc.txt what test can be resolved.

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

Commit messages:
 - 8266531: ZAddress::address() should be removed from SA

Changes: https://git.openjdk.java.net/jdk/pull/3868/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3868&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266531
  Stats: 59 lines in 8 files changed: 13 ins; 34 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3868.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3868/head:pull/3868

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

From xliu at openjdk.java.net  Wed May  5 06:57:59 2021
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 5 May 2021 06:57:59 GMT
Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log
In-Reply-To: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
References: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
Message-ID: <eIWhrsN29atS9GaArZr3dDB699m3mCxY6DlehiEQfwc=.9966cda5-daf5-42c4-a15b-e06bc9efe2be@github.com>

On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 4976 VM.log list
> Log output configuration:
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K
> 
> $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100"
> 4976:
> Output options for existing outputs are ignored.
> 
> $ jcmd 4976 VM.log output="#2" output_options="filecount=100"
> 4976:
> Command executed successfully
> 
> 
> It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases.
> 
> 
> $ jcmd 4976 VM.log list
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured)
> 
> This pull request enable to show the warning message when specifying the output index.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> $ jcmd 5054 VM.log output="#2" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> 
> ### gtest result
> 
> 
> $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.*
> Note: Google Test filter = LogConfigurationTest.*
> [==========] Running 15 tests from 1 test case.
> [----------] Global test environment set-up.
> [----------] 15 tests from LogConfigurationTest
> [ RUN      ] LogConfigurationTest.describe_vm
> [       OK ] LogConfigurationTest.describe_vm (1 ms)
> [ RUN      ] LogConfigurationTest.update_output_vm
> [       OK ] LogConfigurationTest.update_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.add_new_output_vm
> [       OK ] LogConfigurationTest.add_new_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.disable_logging_vm
> [       OK ] LogConfigurationTest.disable_logging_vm (1 ms)
> [ RUN      ] LogConfigurationTest.disable_output_vm
> [       OK ] LogConfigurationTest.disable_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.reconfigure_decorators_vm
> [       OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms)
> [ RUN      ] LogConfigurationTest.invalid_configure_options_vm
> [       OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_empty_command_line_arguments_vm
> [0.462s][warning][logging] Ignoring excess -Xlog options: ""
> [       OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_command_line_arguments_vm
> [       OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms)
> [ RUN      ] LogConfigurationTest.parse_log_arguments_vm
> [       OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms)
> [ RUN      ] LogConfigurationTest.configure_stdout_vm
> [       OK ] LogConfigurationTest.configure_stdout_vm (2 ms)
> [ RUN      ] LogConfigurationTest.subscribe_vm
> [       OK ] LogConfigurationTest.subscribe_vm (2 ms)
> [ RUN      ] LogConfigurationTest.parse_invalid_tagset_vm
> [       OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms)
> [ RUN      ] LogConfigurationTest.output_name_normalization_vm
> [       OK ] LogConfigurationTest.output_name_normalization_vm (1 ms)
> [ RUN      ] LogConfigurationTest.suggest_similar_selection_vm
> [       OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms)
> [----------] 15 tests from LogConfigurationTest (658 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 15 tests from 1 test case ran. (659 ms total)
> [  PASSED  ] 15 tests.

Your bugfix looks good to me. 
I am not a reviewer. I just happen to work on this file recently.  You still need  reviewer's approval.

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

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

From fmatte at openjdk.java.net  Wed May  5 07:15:05 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Wed, 5 May 2021 07:15:05 GMT
Subject: Integrated: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java
 fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to
 double[][][]
In-Reply-To: <CRhws_bAZAxKJwu_vUdY7mYDE91HClhs6VhmMwIJGvQ=.8686ea0c-2c3a-4d0e-99bf-8013b6574f53@github.com>
References: <CRhws_bAZAxKJwu_vUdY7mYDE91HClhs6VhmMwIJGvQ=.8686ea0c-2c3a-4d0e-99bf-8013b6574f53@github.com>
Message-ID: <IUHmD1QCEK7VOQK5peqp2Crj1aVCrQHJxmxJH926GeA=.2383d756-bab7-41e3-b8ed-b4e47ea9ec88@github.com>

On Fri, 23 Apr 2021 15:03:42 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

> findComponentType() logic is wrong. In findComponentType() method, We always get vm.classesByName() retruns empty list
> list = vm.classesByName(parser.typeName());
> We have "parser.typeName()" retruns " double[][]"
> vm.classesByName("") is expecting the fully qualified name example "java.lang.Double"
> This always returns empty list, resulting into ClassNotLoadedException as it assumes the Component class has not yet been loaded, hence the test case fails.
> 
> There was a suggested fix from Egor Ushakov from JetBrains, I am proposing the same to get this fix. I have verified the patch with required testing it works fine.

This pull request has now been integrated.

Changeset: 82768d9a
Author:    Fairoz Matte <fmatte at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/82768d9a31edcfe5b27e75d681d3592c8f4a2ece
Stats:     41 lines in 3 files changed: 0 ins; 36 del; 5 mod

8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][]

Reviewed-by: cjplummer, sspitsyn

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

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

From sspitsyn at openjdk.java.net  Wed May  5 07:33:53 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 07:33:53 GMT
Subject: RFR: 8262002:
 java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with
 "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" [v2]
In-Reply-To: <goeRv9fMoeRUinXIn0aJomK4cebLlbVVlrzCCArDc7o=.f27926be-8feb-458b-8734-ef6ebfeb824c@github.com>
References: <zKkhC_I6U5M179m6g4pm2Aal447M11lt8FGrQ154i6c=.7028424c-7779-46bf-9eee-3f0b1b95d98d@github.com>
 <goeRv9fMoeRUinXIn0aJomK4cebLlbVVlrzCCArDc7o=.f27926be-8feb-458b-8734-ef6ebfeb824c@github.com>
Message-ID: <izu87qSKPSVsr2iZziU_It6Vi6ujHl4hMOkhKO4ALpU=.9b899b50-4051-454f-af78-6e8ef80d44a7@github.com>

On Wed, 21 Apr 2021 20:51:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution)
>> The fix:
>> - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does
>> - makes the test java instead of shell
>> - added workaround for JDK-8264667
>> - test code is ready to ignore order of attributes
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the fix accordingly feedback

Hi Alex,
Looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From stuefe at openjdk.java.net  Wed May  5 08:05:49 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 5 May 2021 08:05:49 GMT
Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log
In-Reply-To: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
References: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
Message-ID: <Vn3fxSKk4tE4481T3gkShswK6FRSFSHMTP9TNNc0x_4=.98a47c78-9d67-474e-86b5-d01adf461ccf@github.com>

On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 4976 VM.log list
> Log output configuration:
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K
> 
> $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100"
> 4976:
> Output options for existing outputs are ignored.
> 
> $ jcmd 4976 VM.log output="#2" output_options="filecount=100"
> 4976:
> Command executed successfully
> 
> 
> It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases.
> 
> 
> $ jcmd 4976 VM.log list
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured)
> 
> This pull request enable to show the warning message when specifying the output index.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> $ jcmd 5054 VM.log output="#2" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> 
> ### gtest result
> 
> 
> $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.*
> Note: Google Test filter = LogConfigurationTest.*
> [==========] Running 15 tests from 1 test case.
> [----------] Global test environment set-up.
> [----------] 15 tests from LogConfigurationTest
> [ RUN      ] LogConfigurationTest.describe_vm
> [       OK ] LogConfigurationTest.describe_vm (1 ms)
> [ RUN      ] LogConfigurationTest.update_output_vm
> [       OK ] LogConfigurationTest.update_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.add_new_output_vm
> [       OK ] LogConfigurationTest.add_new_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.disable_logging_vm
> [       OK ] LogConfigurationTest.disable_logging_vm (1 ms)
> [ RUN      ] LogConfigurationTest.disable_output_vm
> [       OK ] LogConfigurationTest.disable_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.reconfigure_decorators_vm
> [       OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms)
> [ RUN      ] LogConfigurationTest.invalid_configure_options_vm
> [       OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_empty_command_line_arguments_vm
> [0.462s][warning][logging] Ignoring excess -Xlog options: ""
> [       OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_command_line_arguments_vm
> [       OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms)
> [ RUN      ] LogConfigurationTest.parse_log_arguments_vm
> [       OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms)
> [ RUN      ] LogConfigurationTest.configure_stdout_vm
> [       OK ] LogConfigurationTest.configure_stdout_vm (2 ms)
> [ RUN      ] LogConfigurationTest.subscribe_vm
> [       OK ] LogConfigurationTest.subscribe_vm (2 ms)
> [ RUN      ] LogConfigurationTest.parse_invalid_tagset_vm
> [       OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms)
> [ RUN      ] LogConfigurationTest.output_name_normalization_vm
> [       OK ] LogConfigurationTest.output_name_normalization_vm (1 ms)
> [ RUN      ] LogConfigurationTest.suggest_similar_selection_vm
> [       OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms)
> [----------] 15 tests from LogConfigurationTest (658 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 15 tests from 1 test case ran. (659 ms total)
> [  PASSED  ] 15 tests.

Looks good.

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

Marked as reviewed by stuefe (Reviewer).

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

From sspitsyn at openjdk.java.net  Wed May  5 08:11:52 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 08:11:52 GMT
Subject: RFR: 8266002: vmTestbase/nsk/jvmti/ClassPrepare/classprep001
 should skip events for unexpected classes [v3]
In-Reply-To: <XETzpT3o5AyhG7CPAxRLzpomrTprckwmr4qPihWtKas=.8faaeaf2-c150-4e2b-936e-7fde2592280f@github.com>
References: <fqjBtpYtQINR4TjmMFMrQr5HoWKXUqGTlhqJt5ZSpck=.59a22e0a-5558-40d4-ae9f-3fcb51f5f1d2@github.com>
 <XETzpT3o5AyhG7CPAxRLzpomrTprckwmr4qPihWtKas=.8faaeaf2-c150-4e2b-936e-7fde2592280f@github.com>
Message-ID: <8HaujV32aMmFled5Fy9XWD8LLeIDw5YX7Is5j-_1JwY=.6f6ed414-42cf-41ee-8752-834667a2b472@github.com>

On Wed, 28 Apr 2021 21:48:15 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Class loading may cause loading of some other system/internal classes (for example loading of java.util.concurrent classes when an other thread loads some classes concurrently).
>> The fix updates ClassPrepare test so it skip events for "unexpected" classes.
>> Also it adds a testcase to verify that classes which are explicitly loaded on other thread do not generate ClassPrepare event on the test thread.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed type in otherThread variable name

Hi Alex,
The fix looks good to me. The logics is more clear now.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Wed May  5 08:19:54 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 08:19:54 GMT
Subject: RFR: 8265612: revise the help info for jmap histo command [v3]
In-Reply-To: <abgueqJn-Sd447YebtU90QKzA7DyRf6NMNnIw7c3O9w=.7dc4492d-df93-4c88-b5ce-7c2dd0dca43e@github.com>
References: <cfxcRzY79kUAvz0gmR7Br2NlSICV_MJZ1MD9Q5jl-9o=.19787a5d-8072-4341-9bfa-eef4f7329d83@github.com>
 <abgueqJn-Sd447YebtU90QKzA7DyRf6NMNnIw7c3O9w=.7dc4492d-df93-4c88-b5ce-7c2dd0dca43e@github.com>
Message-ID: <FfVpMogFWM0j68qPM9vs0gEMVt4ewiJyb4xR8W7URLI=.905ccf65-fd6d-4d4e-bf83-fd38f58ce33e@github.com>

On Thu, 22 Apr 2021 05:53:35 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR  revise the help message of the `parallel=[N]` option of command `jmap -histo`. It mainly comes from the discussion at  https://github.com/openjdk/jdk/pull/2379#issuecomment-782609582  and https://github.com/openjdk/jdk/pull/2261#issuecomment-823623186.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation issue

Hi Lin,
It looks good to me. Sorry for being late on this review.
Thanks,
serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Wed May  5 08:44:49 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 08:44:49 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd
In-Reply-To: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
Message-ID: <v6W6uMkFnKkbd-9iNYGWPISooUVzdI9RSXM3huBWyUM=.a65982e4-363b-472c-9176-8486dc7bd6ba@github.com>

On Sun, 25 Apr 2021 03:15:07 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA remote object. It is "SARemoteDebugger" by default.
> 
> As a result, remote name will be constructed as following:
> 
> 
> //host[:port]/<serverNamePrefix>['_'<id>]
> 
> 
> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. And also we should add the way to specify the prefix when we connect to debug server. I will add it like `--connect id at server:1234/prefix`.
> 
> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.

I've looked at the CSR and added a comment with a question.

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

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

From sspitsyn at openjdk.java.net  Wed May  5 08:55:59 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 08:55:59 GMT
Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste
 since it is never set [v3]
In-Reply-To: <HDkU6USAbeyYbhrr9hxPRG3Wci_V_KCaEVfYWJMPxHA=.2f4aca8b-b6b2-4a82-a1ac-78b4470a0baa@github.com>
References: <D8BYOrjHW_YzuZUuuHzfg8Ek38lFW2Dluhowqzq0QvA=.a22f3a9f-ee69-4454-a9f5-d2c6bd87239d@github.com>
 <HDkU6USAbeyYbhrr9hxPRG3Wci_V_KCaEVfYWJMPxHA=.2f4aca8b-b6b2-4a82-a1ac-78b4470a0baa@github.com>
Message-ID: <ahfXJzRGF9eSPn35pXxNDi1nVUvi74_WzXgiv_grhnI=.b70f9ec7-8444-4d1f-8b92-d3dfc79f54b0@github.com>

On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Hi Albert,
It looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Wed May  5 09:00:54 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 09:00:54 GMT
Subject: RFR: 8266193: BasicJMapTest should include testHistoParallel
 methods
In-Reply-To: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com>
References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com>
Message-ID: <5kkIscThLm820VsCd91EKWYPoYXXT20ZPbYNo5s2OLg=.ade64cda-f8a2-490e-b3aa-1ffdb7a3f95b@github.com>

On Fri, 30 Apr 2021 08:06:38 GMT, BuddyLiao <github.com+3094961+buddyliao at openjdk.org> wrote:

> The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included.

@buddyliao 
The test update looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Wed May  5 09:11:52 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 5 May 2021 09:11:52 GMT
Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log
In-Reply-To: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
References: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
Message-ID: <RD2CVrtt__OIhf9qXwDTYjUXczCrGaef9Je8rN_ah9g=.6098a284-a814-4529-a637-d855e90155f6@github.com>

On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 4976 VM.log list
> Log output configuration:
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K
> 
> $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100"
> 4976:
> Output options for existing outputs are ignored.
> 
> $ jcmd 4976 VM.log output="#2" output_options="filecount=100"
> 4976:
> Command executed successfully
> 
> 
> It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases.
> 
> 
> $ jcmd 4976 VM.log list
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured)
> 
> This pull request enable to show the warning message when specifying the output index.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> $ jcmd 5054 VM.log output="#2" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> 
> ### gtest result
> 
> 
> $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.*
> Note: Google Test filter = LogConfigurationTest.*
> [==========] Running 15 tests from 1 test case.
> [----------] Global test environment set-up.
> [----------] 15 tests from LogConfigurationTest
> [ RUN      ] LogConfigurationTest.describe_vm
> [       OK ] LogConfigurationTest.describe_vm (1 ms)
> [ RUN      ] LogConfigurationTest.update_output_vm
> [       OK ] LogConfigurationTest.update_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.add_new_output_vm
> [       OK ] LogConfigurationTest.add_new_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.disable_logging_vm
> [       OK ] LogConfigurationTest.disable_logging_vm (1 ms)
> [ RUN      ] LogConfigurationTest.disable_output_vm
> [       OK ] LogConfigurationTest.disable_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.reconfigure_decorators_vm
> [       OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms)
> [ RUN      ] LogConfigurationTest.invalid_configure_options_vm
> [       OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_empty_command_line_arguments_vm
> [0.462s][warning][logging] Ignoring excess -Xlog options: ""
> [       OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_command_line_arguments_vm
> [       OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms)
> [ RUN      ] LogConfigurationTest.parse_log_arguments_vm
> [       OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms)
> [ RUN      ] LogConfigurationTest.configure_stdout_vm
> [       OK ] LogConfigurationTest.configure_stdout_vm (2 ms)
> [ RUN      ] LogConfigurationTest.subscribe_vm
> [       OK ] LogConfigurationTest.subscribe_vm (2 ms)
> [ RUN      ] LogConfigurationTest.parse_invalid_tagset_vm
> [       OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms)
> [ RUN      ] LogConfigurationTest.output_name_normalization_vm
> [       OK ] LogConfigurationTest.output_name_normalization_vm (1 ms)
> [ RUN      ] LogConfigurationTest.suggest_similar_selection_vm
> [       OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms)
> [----------] 15 tests from LogConfigurationTest (658 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 15 tests from 1 test case ran. (659 ms total)
> [  PASSED  ] 15 tests.

Looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From mli at openjdk.java.net  Wed May  5 10:48:55 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 5 May 2021 10:48:55 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v7]
In-Reply-To: <xya5pLw2y95h8H4191fPxRii6_KSCwmPjY-geya5se4=.1e184d06-157a-4d99-b010-dfb7849dd73b@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
 <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>
 <MMfaRF7ay6_yVGOxC6SvO7-b7GwYkMG7r2uIkzfhSJ4=.f8d0457e-bc40-4025-8555-f3921fe9b6d3@github.com>
 <bNl-kdwPZVRfceE1bR2Lt3nYencF6XHmIJdDUAsjdL8=.da92bc6f-41df-486b-8e8d-f90d764c64aa@github.com>
 <lcOubi8bD8nfjs6CyZ_VVq__wlq1md0-kgKam76Ibwo=.6c10a867-9b3a-4c7b-b460-cdfd278a23f1@github.com>
 <xya5pLw2y95h8H4191fPxRii6_KSCwmPjY-geya5se4=.1e184d06-157a-4d99-b010-dfb7849dd73b@github.com>
Message-ID: <iim7Ckv1cAJokzcWUY2X32QYmvLxx4-Oeby2JeCuxJI=.c00609e3-cad1-41cc-bb1d-d89cd9c06a23@github.com>

On Sat, 20 Feb 2021 03:27:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve jcmd GC.class_histogram to support parallel
>
> For jmap -histo we have:
> 
>       parallel=<number>  parallel threads number for heap iteration:
>                                   parallel=0 default behavior, use predefined number of threads
>                                   parallel=1 disable parallel heap iteration
>                                   parallel=<N> use N threads for parallel heap iteration
> 
> It's a bit inconsistent here in that it says <number>, <N>, and N. I'd like to see that cleaned up at some point along with a few other things (as part of a separate PR). However, my point is that the value of the argument is given a name, <number> in this case, so it can be referenced in the help output. However, jmap help is done differently than jcmd help, which doesn't give names to the value of options. For example, GC.heap_dump has:
> 
> Options: (options must be specified using the <key> or <key>=<value> syntax)
> 	-all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false)
> 	-gz : [optional] If specified, the heap dump is written in gzipped format using the given compression level. 1 (recommended) is the fastest, 9 the strongest compression. (INT, 1)
> 
> The -gz option is much like -parallel in that a value is given for it, but there is no "name" for that value in the help output. So maybe we should avoid calling it "n" or <n>, or anything like that:
> 
> "Number of parallel threads to use for heap inspection."
> "0 (the default) means let the VM determine the number of threads to use. "
> "1 means use one thread (disable parallelism). "
> "For any other value the VM will try to use the specified number of threads, but might use fewer."
> 
> I think we can leave out "Must be positive." It should be obvious, and I assume an error is generated if negative number is given.

@plummercj @sspitsyn Kindly reminder. Thanks.

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

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

From rehn at openjdk.java.net  Wed May  5 11:54:06 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 5 May 2021 11:54:06 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked
Message-ID: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>

Please consider this change which removes the manual transitions to blocked.
This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.

The object monitor code could be straight forward changed to use this instead of manual transitions.

Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
That made it possible to careful use ThreadInVMfromNative in raw monitors.

I also remove the early CAS in raw_enter.
We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
(multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)

Passes t1-t7 and manual stressing relevant test groups.

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

Commit messages:
 - Removed manual transitions

Changes: https://git.openjdk.java.net/jdk/pull/3875/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265753
  Stats: 327 lines in 8 files changed: 122 ins; 155 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875

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

From coleenp at openjdk.java.net  Wed May  5 13:02:52 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 5 May 2021 13:02:52 GMT
Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication
In-Reply-To: <9izvv99yDgbpyzYA4x_mh5GC36i04ltjSg2XtgRNUAI=.4f1450af-face-4e02-bd40-08df1c3d6723@github.com>
References: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
 <9izvv99yDgbpyzYA4x_mh5GC36i04ltjSg2XtgRNUAI=.4f1450af-face-4e02-bd40-08df1c3d6723@github.com>
Message-ID: <WFRoFeVnI7i6H4cTf2fC7JcOqXLJfMaQtkVo4stR6AQ=.003baddc-869a-451c-bd6e-a8e467b8d12e@github.com>

On Wed, 5 May 2021 01:07:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Marking running_emcp for Method* is unnecessary.  We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running.  See longer explanation in the CR.
>> 
>> Tested with tier1-6, tiers 7,8 are running and 98% passing.
>
> Hi Coleen,
> 
> This looks good to me in general.
> I'm a little bit puzzled why the check ` emcp_method_count != 0` is needed at the line:
> `4005   if (emcp_method_count != 0 && obsolete_method_count != 0 &&`
> 
> Suppose, the emcp_method_count is equal to 0.
> Then do we really want to skip marking all the methods of this InstanceKlass as obsolete?
> Most likely, I'm missing something.
> 
> Thanks,
> Serguei

@sspitsyn  I think you're right here.  If all the newly old methods are obsolete, then we should mark all the methods in the previous versions as obsolete and not skip this.  I'll file an issue to investigate this because it's always been this way (and could use a test also).  It's too risky to change here.   Thanks for the code review!

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

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

From coleenp at openjdk.java.net  Wed May  5 13:02:53 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 5 May 2021 13:02:53 GMT
Subject: Integrated: 8266497: Remove unnecessary EMCP liveness indication
In-Reply-To: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
References: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
Message-ID: <DplRtKgMcn-rHf4FtQng9OLKNtJRQ6jDSWOQEo0N7iY=.5ec2cbff-c748-4140-827b-6f05dbf049d2@github.com>

On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Marking running_emcp for Method* is unnecessary.  We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running.  See longer explanation in the CR.
> 
> Tested with tier1-6, tiers 7,8 are running and 98% passing.

This pull request has now been integrated.

Changeset: a05e8e24
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a05e8e24224b047584c3a273fa7b4fef66798dd6
Stats:     78 lines in 4 files changed: 9 ins; 64 del; 5 mod

8266497: Remove unnecessary EMCP liveness indication

Reviewed-by: iklam, dholmes, sspitsyn

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

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

From coleenp at openjdk.java.net  Wed May  5 13:02:52 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 5 May 2021 13:02:52 GMT
Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication
In-Reply-To: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
References: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
Message-ID: <WLj-0aM-B6_BrnQ9joYqNrr2qDuTIWauHLvXtBy0kqs=.27bffe94-c7fa-4deb-a654-00ea7d605503@github.com>

On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Marking running_emcp for Method* is unnecessary.  We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running.  See longer explanation in the CR.
> 
> Tested with tier1-6, tiers 7,8 are running and 98% passing.

Thanks for the code review, David.

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

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

From prappo at openjdk.java.net  Wed May  5 16:05:59 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 5 May 2021 16:05:59 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap
Message-ID: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>

This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.

Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:

1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`

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

Commit messages:
 - Initial commit

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

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

From dfuchs at openjdk.java.net  Wed May  5 17:27:02 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 5 May 2021 17:27:02 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap
In-Reply-To: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
Message-ID: <DC-qvfS-7TIIabBwZY9750nRjrXufE8zzBsrGD33rQc=.05682212-9b8b-42fa-8289-c01ebbf4cc80@github.com>

On Wed, 5 May 2021 15:59:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.
> 
> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:
> 
> 1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`

LGTM. Thanks for fixing the various typos.

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

Marked as reviewed by dfuchs (Reviewer).

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

From prappo at openjdk.java.net  Wed May  5 18:39:14 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 5 May 2021 18:39:14 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap [v2]
In-Reply-To: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
Message-ID: <Lgl_vpHS83eytvWnxz91-wCg_Uh_JyfI4-K_uoF17os=.3375f1b0-097b-48b6-aa73-573ad2d3d6b8@github.com>

> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.
> 
> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:
> 
> 1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`

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

  Fixed more typos

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3885/files
  - new: https://git.openjdk.java.net/jdk/pull/3885/files/b8113178..6eea552e

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

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

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

From prappo at openjdk.java.net  Wed May  5 18:47:53 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 5 May 2021 18:47:53 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap [v2]
In-Reply-To: <Lgl_vpHS83eytvWnxz91-wCg_Uh_JyfI4-K_uoF17os=.3375f1b0-097b-48b6-aa73-573ad2d3d6b8@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
 <Lgl_vpHS83eytvWnxz91-wCg_Uh_JyfI4-K_uoF17os=.3375f1b0-097b-48b6-aa73-573ad2d3d6b8@github.com>
Message-ID: <b-g06VpsVISjpAr3MDuXsePClOd-I0Vf69GaBk7-RW0=.034d32cb-5b62-4520-82bb-dc0792d4c341@github.com>

On Wed, 5 May 2021 18:39:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.
>> 
>> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:
>> 
>> 1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
>> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed more typos

Daniel, would you kindly review the most recent commit, which fixes three more typos?

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

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

From dfuchs at openjdk.java.net  Wed May  5 19:24:52 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 5 May 2021 19:24:52 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap [v2]
In-Reply-To: <Lgl_vpHS83eytvWnxz91-wCg_Uh_JyfI4-K_uoF17os=.3375f1b0-097b-48b6-aa73-573ad2d3d6b8@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
 <Lgl_vpHS83eytvWnxz91-wCg_Uh_JyfI4-K_uoF17os=.3375f1b0-097b-48b6-aa73-573ad2d3d6b8@github.com>
Message-ID: <ErLYQE_w8pmCYf7offOx0TNxqqHkmClq-KbBiMfahtk=.f748d752-a47a-455a-bcfe-19478ac4723b@github.com>

On Wed, 5 May 2021 18:39:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.
>> 
>> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:
>> 
>> 1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
>> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed more typos

src/jdk.management.agent/share/classes/sun/management/jmxremote/ConnectorBootstrap.java line 308:

> 306:       public static synchronized JMXConnectorServer initialize() {
> 307: 
> 308:          // Load new management properties

Debatable. I guess what was meant here is:

// Loads a new management Properties instance

Otherwise LGTM.

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

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

From amenkov at openjdk.java.net  Wed May  5 20:33:06 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 5 May 2021 20:33:06 GMT
Subject: RFR: 8262092:
 vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java
 SIGSEGV in memmove_ssse3
Message-ID: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>

Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization.
The fix adds synchronization for ClassFileLoadHook.

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

Commit messages:
 - Added synchronization for ClassFileLoadHook callback

Changes: https://git.openjdk.java.net/jdk/pull/3889/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3889&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262092
  Stats: 35 lines in 1 file changed: 22 ins; 7 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3889.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3889/head:pull/3889

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

From lmesnik at openjdk.java.net  Wed May  5 21:05:52 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 5 May 2021 21:05:52 GMT
Subject: RFR: 8262092:
 vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java
 SIGSEGV in memmove_ssse3
In-Reply-To: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
References: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
Message-ID: <gxcc90G1LeLgipMv7AwFiotOQS15UGygEVW-EhxHZRU=.9d3aa926-22f6-48a5-a143-f5cc6576f22a@github.com>

On Wed, 5 May 2021 20:26:13 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization.
> The fix adds synchronization for ClassFileLoadHook.

Also, generic comment. There are other counters which might require synchronization, like CompiledMethodLoadEventsCount. Doesn't it makes sense to fix them also or file a new bug?

test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 71:

> 69: static int classCount = 0;
> 70: /* lock to access classCount */
> 71: static jrawMonitorID classLoadLock = NULL;

I think it would simpler to use an atomic counter rather than monitors for this fix.

test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 110:

> 108:         }
> 109:         // use while instead of if to exit the block on error
> 110:         while (classCount < max_classes) {

Could you please explain why this while is executed only once. It is not obvious.

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

Changes requested by lmesnik (Committer).

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

From github.com+971473+argha-c at openjdk.java.net  Wed May  5 21:18:52 2021
From: github.com+971473+argha-c at openjdk.java.net (Argha C)
Date: Wed, 5 May 2021 21:18:52 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load
In-Reply-To: <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
 <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>
Message-ID: <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>

On Wed, 5 May 2021 05:57:55 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 142:
>> 
>>> 140:                 long usageNanos = containerMetrics.getCpuUsage();
>>> 141:                 if (numPeriods > 0 && usageNanos > 0) {
>>> 142:                     long quotaNanos = TimeUnit.MICROSECONDS.toNanos(quota * numPeriods);
>> 
>> We happened to hit an exactly similar problem when running on a container with openjdk15.
>> 
>> Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above. 
>> Is there a good reason `getCpuQuota` is a better alternative?
>
> Hi Argha, thanks a lot for your suggestion. I think both "quota" and "share" are worth considering. Let us look into the implementation of `CgroupSubsystem::active_processor_count()` in OpenJDK HotSpot (https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/cgroupSubsystem_linux.cpp).

Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.

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

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

From amenkov at openjdk.java.net  Wed May  5 22:03:00 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 5 May 2021 22:03:00 GMT
Subject: RFR: 8262092:
 vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java
 SIGSEGV in memmove_ssse3
In-Reply-To: <gxcc90G1LeLgipMv7AwFiotOQS15UGygEVW-EhxHZRU=.9d3aa926-22f6-48a5-a143-f5cc6576f22a@github.com>
References: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
 <gxcc90G1LeLgipMv7AwFiotOQS15UGygEVW-EhxHZRU=.9d3aa926-22f6-48a5-a143-f5cc6576f22a@github.com>
Message-ID: <GTLuWsvlnqK3F9cTs6wApVNw4Qh1KZg_mlpVZnQ4k8c=.f8d9cb95-074b-46c0-95f6-eded609ed4ad@github.com>

On Wed, 5 May 2021 21:02:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Also, generic comment. There are other counters which might require synchronization, like CompiledMethodLoadEventsCount. Doesn't it makes sense to fix them also or file a new bug?

The problem with classCount is it's used as an index in the arrays.
CompiledMethodLoadEventsCount is only incremented (for formally it should be synchronized too).
And looks like CompiledMethodLoadEventsCount is actually not used (I mean the values is not checked)

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

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

From amenkov at openjdk.java.net  Wed May  5 22:11:50 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 5 May 2021 22:11:50 GMT
Subject: RFR: 8262092:
 vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java
 SIGSEGV in memmove_ssse3
In-Reply-To: <gxcc90G1LeLgipMv7AwFiotOQS15UGygEVW-EhxHZRU=.9d3aa926-22f6-48a5-a143-f5cc6576f22a@github.com>
References: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
 <gxcc90G1LeLgipMv7AwFiotOQS15UGygEVW-EhxHZRU=.9d3aa926-22f6-48a5-a143-f5cc6576f22a@github.com>
Message-ID: <eQwKiWu3kSMoKcm7hEFIj-2xRIbEPfdryVDhsbmw_gs=.04ee237a-f189-4c27-a4d3-28fac46daf68@github.com>

On Wed, 5 May 2021 20:59:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization.
>> The fix adds synchronization for ClassFileLoadHook.
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 71:
> 
>> 69: static int classCount = 0;
>> 70: /* lock to access classCount */
>> 71: static jrawMonitorID classLoadLock = NULL;
> 
> I think it would simpler to use an atomic counter rather than monitors for this fix.

Do you mean use <atomic> from STL?
I'm not sure it would be simpler as we need logic like "get the value, if the value is less than max_classes, increment it"

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

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

From amenkov at openjdk.java.net  Wed May  5 22:14:52 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 5 May 2021 22:14:52 GMT
Subject: RFR: 8262092:
 vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java
 SIGSEGV in memmove_ssse3
In-Reply-To: <gxcc90G1LeLgipMv7AwFiotOQS15UGygEVW-EhxHZRU=.9d3aa926-22f6-48a5-a143-f5cc6576f22a@github.com>
References: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
 <gxcc90G1LeLgipMv7AwFiotOQS15UGygEVW-EhxHZRU=.9d3aa926-22f6-48a5-a143-f5cc6576f22a@github.com>
Message-ID: <Q0k3SIW9m2ZZpKrec40vZn0S-uQFv6-Yiy6rRbjwLdA=.3abf731c-5bc5-4b99-aeb2-0ede7cdbc580@github.com>

On Wed, 5 May 2021 21:01:11 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization.
>> The fix adds synchronization for ClassFileLoadHook.
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 110:
> 
>> 108:         }
>> 109:         // use while instead of if to exit the block on error
>> 110:         while (classCount < max_classes) {
> 
> Could you please explain why this while is executed only once. It is not obvious.

I tried to explain it in the comment :)
it should be "if (classCount < max_classes)",
but inside the if we have return statements and we need to do cleanup (exit monitor).
So I used well-known pattern with 1-pass cycle (note that "return"s are replaced with "break"s)

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

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

From amenkov at openjdk.java.net  Wed May  5 22:46:51 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 5 May 2021 22:46:51 GMT
Subject: RFR: 8262092:
 vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java
 SIGSEGV in memmove_ssse3
In-Reply-To: <Q0k3SIW9m2ZZpKrec40vZn0S-uQFv6-Yiy6rRbjwLdA=.3abf731c-5bc5-4b99-aeb2-0ede7cdbc580@github.com>
References: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
 <gxcc90G1LeLgipMv7AwFiotOQS15UGygEVW-EhxHZRU=.9d3aa926-22f6-48a5-a143-f5cc6576f22a@github.com>
 <Q0k3SIW9m2ZZpKrec40vZn0S-uQFv6-Yiy6rRbjwLdA=.3abf731c-5bc5-4b99-aeb2-0ede7cdbc580@github.com>
Message-ID: <aw0vlhII3Nn3VBGT6svPrY6H2L0w7WGQi8reII4RqKc=.0108c056-7b6d-422d-b08b-f306b0bd6ace@github.com>

On Wed, 5 May 2021 22:12:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 110:
>> 
>>> 108:         }
>>> 109:         // use while instead of if to exit the block on error
>>> 110:         while (classCount < max_classes) {
>> 
>> Could you please explain why this while is executed only once. It is not obvious.
>
> I tried to explain it in the comment :)
> it should be "if (classCount < max_classes)",
> but inside the if we have return statements and we need to do cleanup (exit monitor).
> So I used well-known pattern with 1-pass cycle (note that "return"s are replaced with "break"s)

Offline discussion shown that I forgot to add break at the end of the cycle. Will fix

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

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

From sspitsyn at openjdk.java.net  Thu May  6 00:09:50 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 6 May 2021 00:09:50 GMT
Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication
In-Reply-To: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
References: <Taf4xBBQrpP-GXb-LC2_NDlg2JCT95DyluRjUjOn4Hk=.6f7d1fe3-71ee-4cf5-8f1a-e240d1611192@github.com>
Message-ID: <PS_mbp4YGdmhXTrOKAsGnRGtAEADM6RNWQq6rVuJ5FY=.e02157a4-980d-4b50-b3b1-1ca1d665e463@github.com>

On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Marking running_emcp for Method* is unnecessary.  We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running.  See longer explanation in the CR.
> 
> Tested with tier1-6, tiers 7,8 are running and 98% passing.

Thanks, Coleen! I agree, it is better to file a new bug.

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

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

From github.com+3094961+buddyliao at openjdk.java.net  Thu May  6 02:30:08 2021
From: github.com+3094961+buddyliao at openjdk.java.net (BuddyLiao)
Date: Thu, 6 May 2021 02:30:08 GMT
Subject: RFR: 8266193: BasicJMapTest should include testHistoParallel
 methods [v2]
In-Reply-To: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com>
References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com>
Message-ID: <uCjclqrhBQaKsY5-HvGqp2zRM3nsHulj2VV2C_pdrpo=.94a4e22b-362a-4a99-bfa1-51de71f35e2f@github.com>

> The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included.

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

  8266193: BasicJMapTest does not include testHistoParallel methods

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3810/files
  - new: https://git.openjdk.java.net/jdk/pull/3810/files/b922efee..d5edd157

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

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

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

From github.com+7947546+tanghaoth90 at openjdk.java.net  Thu May  6 02:36:54 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Thu, 6 May 2021 02:36:54 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load
In-Reply-To: <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
 <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>
 <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>
Message-ID: <HCdl5UDmZqeuYMbB8cnr0qesiFw1x-NH6F5tbrI0eMs=.c5ed84c9-9f23-4890-a0b5-ddb5c323a931@github.com>

On Wed, 5 May 2021 21:16:07 GMT, Argha C <github.com+971473+argha-c at openjdk.org> wrote:

> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.

Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation.

We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways.
1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` &  `share`);
2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number.

Looking forward to your suggestion.

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

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

From lzang at openjdk.java.net  Thu May  6 02:58:55 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 6 May 2021 02:58:55 GMT
Subject: RFR: 8265612: revise the help info for jmap histo command [v3]
In-Reply-To: <FfVpMogFWM0j68qPM9vs0gEMVt4ewiJyb4xR8W7URLI=.905ccf65-fd6d-4d4e-bf83-fd38f58ce33e@github.com>
References: <cfxcRzY79kUAvz0gmR7Br2NlSICV_MJZ1MD9Q5jl-9o=.19787a5d-8072-4341-9bfa-eef4f7329d83@github.com>
 <abgueqJn-Sd447YebtU90QKzA7DyRf6NMNnIw7c3O9w=.7dc4492d-df93-4c88-b5ce-7c2dd0dca43e@github.com>
 <FfVpMogFWM0j68qPM9vs0gEMVt4ewiJyb4xR8W7URLI=.905ccf65-fd6d-4d4e-bf83-fd38f58ce33e@github.com>
Message-ID: <MRhB2bUjsmqarRm5CfEyC96xDycfx8CtOQ3JKY2eu0g=.fdf8f1fd-c76e-4a3d-a7e3-bda6c841ac62@github.com>

On Wed, 5 May 2021 08:16:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix indentation issue
>
> Hi Lin,
> It looks good to me. Sorry for being late on this review.
> Thanks,
> serguei

Dear @sspitsyn @plummercj 
Thanks a lot for your help reviewing. May I ask your help to push it?

BRs,
Lin

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

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

From github.com+3094961+buddyliao at openjdk.java.net  Thu May  6 03:06:58 2021
From: github.com+3094961+buddyliao at openjdk.java.net (BuddyLiao)
Date: Thu, 6 May 2021 03:06:58 GMT
Subject: RFR: 8266193: BasicJMapTest should include testHistoParallel
 methods [v2]
In-Reply-To: <5kkIscThLm820VsCd91EKWYPoYXXT20ZPbYNo5s2OLg=.ade64cda-f8a2-490e-b3aa-1ffdb7a3f95b@github.com>
References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com>
 <5kkIscThLm820VsCd91EKWYPoYXXT20ZPbYNo5s2OLg=.ade64cda-f8a2-490e-b3aa-1ffdb7a3f95b@github.com>
Message-ID: <GxxfrFeDmpiIj76DKSQ_YWROalVxpK8h2zjTvvMmP_4=.d9e522f2-0ddc-4394-9e9f-2c505cea42b6@github.com>

On Wed, 5 May 2021 08:58:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> @buddyliao
> The test update looks good to me.
> Thanks,
> Serguei

@sspitsyn Thanks, I force update the title to match between PR and JBS.
Would you help me to push it?

Thanks,
Buddy

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

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

From ksakata at openjdk.java.net  Thu May  6 06:24:26 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Thu, 6 May 2021 06:24:26 GMT
Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log [v2]
In-Reply-To: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
References: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
Message-ID: <sMu5QO_SQ8d3u655ekVDz5CJZwpA1mWcwtzrjxwfMN0=.3e9f05c9-599b-4455-b021-cf837dea472b@github.com>

> When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 4976 VM.log list
> Log output configuration:
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K
> 
> $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100"
> 4976:
> Output options for existing outputs are ignored.
> 
> $ jcmd 4976 VM.log output="#2" output_options="filecount=100"
> 4976:
> Command executed successfully
> 
> 
> It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases.
> 
> 
> $ jcmd 4976 VM.log list
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured)
> 
> This pull request enable to show the warning message when specifying the output index.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> $ jcmd 5054 VM.log output="#2" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> 
> ### gtest result
> 
> 
> $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.*
> Note: Google Test filter = LogConfigurationTest.*
> [==========] Running 15 tests from 1 test case.
> [----------] Global test environment set-up.
> [----------] 15 tests from LogConfigurationTest
> [ RUN      ] LogConfigurationTest.describe_vm
> [       OK ] LogConfigurationTest.describe_vm (1 ms)
> [ RUN      ] LogConfigurationTest.update_output_vm
> [       OK ] LogConfigurationTest.update_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.add_new_output_vm
> [       OK ] LogConfigurationTest.add_new_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.disable_logging_vm
> [       OK ] LogConfigurationTest.disable_logging_vm (1 ms)
> [ RUN      ] LogConfigurationTest.disable_output_vm
> [       OK ] LogConfigurationTest.disable_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.reconfigure_decorators_vm
> [       OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms)
> [ RUN      ] LogConfigurationTest.invalid_configure_options_vm
> [       OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_empty_command_line_arguments_vm
> [0.462s][warning][logging] Ignoring excess -Xlog options: ""
> [       OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_command_line_arguments_vm
> [       OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms)
> [ RUN      ] LogConfigurationTest.parse_log_arguments_vm
> [       OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms)
> [ RUN      ] LogConfigurationTest.configure_stdout_vm
> [       OK ] LogConfigurationTest.configure_stdout_vm (2 ms)
> [ RUN      ] LogConfigurationTest.subscribe_vm
> [       OK ] LogConfigurationTest.subscribe_vm (2 ms)
> [ RUN      ] LogConfigurationTest.parse_invalid_tagset_vm
> [       OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms)
> [ RUN      ] LogConfigurationTest.output_name_normalization_vm
> [       OK ] LogConfigurationTest.output_name_normalization_vm (1 ms)
> [ RUN      ] LogConfigurationTest.suggest_similar_selection_vm
> [       OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms)
> [----------] 15 tests from LogConfigurationTest (658 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 15 tests from 1 test case ran. (659 ms total)
> [  PASSED  ] 15 tests.

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

  Change variable name to better one

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3448/files
  - new: https://git.openjdk.java.net/jdk/pull/3448/files/e37e8c50..d7b0627f

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

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

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

From ksakata at openjdk.java.net  Thu May  6 06:55:59 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Thu, 6 May 2021 06:55:59 GMT
Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log [v2]
In-Reply-To: <sMu5QO_SQ8d3u655ekVDz5CJZwpA1mWcwtzrjxwfMN0=.3e9f05c9-599b-4455-b021-cf837dea472b@github.com>
References: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
 <sMu5QO_SQ8d3u655ekVDz5CJZwpA1mWcwtzrjxwfMN0=.3e9f05c9-599b-4455-b021-cf837dea472b@github.com>
Message-ID: <J2fEYrm1QQP4f5mKkTJf-iLU4wxJ_i09RYja9FNTjB0=.a60400d8-e59b-4fff-ad15-0e7d2fc17277@github.com>

On Thu, 6 May 2021 06:24:26 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

>> When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown.
>> 
>> 
>> $ java -Xlog::sample.log:: Sample
>> $ jcmd 4976 VM.log list
>> Log output configuration:
>>  #0: stdout all=warning uptime,level,tags
>>  #1: stderr all=off uptime,level,tags
>>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K
>> 
>> $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100"
>> 4976:
>> Output options for existing outputs are ignored.
>> 
>> $ jcmd 4976 VM.log output="#2" output_options="filecount=100"
>> 4976:
>> Command executed successfully
>> 
>> 
>> It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases.
>> 
>> 
>> $ jcmd 4976 VM.log list
>>  #0: stdout all=warning uptime,level,tags
>>  #1: stderr all=off uptime,level,tags
>>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured)
>> 
>> This pull request enable to show the warning message when specifying the output index.
>> 
>> 
>> $ java -Xlog::sample.log:: Sample
>> $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100"
>> 5054:
>> Output options for existing outputs are ignored.
>> 
>> $ jcmd 5054 VM.log output="#2" output_options="filecount=100"
>> 5054:
>> Output options for existing outputs are ignored.
>> 
>> 
>> ### gtest result
>> 
>> 
>> $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.*
>> Note: Google Test filter = LogConfigurationTest.*
>> [==========] Running 15 tests from 1 test case.
>> [----------] Global test environment set-up.
>> [----------] 15 tests from LogConfigurationTest
>> [ RUN      ] LogConfigurationTest.describe_vm
>> [       OK ] LogConfigurationTest.describe_vm (1 ms)
>> [ RUN      ] LogConfigurationTest.update_output_vm
>> [       OK ] LogConfigurationTest.update_output_vm (0 ms)
>> [ RUN      ] LogConfigurationTest.add_new_output_vm
>> [       OK ] LogConfigurationTest.add_new_output_vm (0 ms)
>> [ RUN      ] LogConfigurationTest.disable_logging_vm
>> [       OK ] LogConfigurationTest.disable_logging_vm (1 ms)
>> [ RUN      ] LogConfigurationTest.disable_output_vm
>> [       OK ] LogConfigurationTest.disable_output_vm (0 ms)
>> [ RUN      ] LogConfigurationTest.reconfigure_decorators_vm
>> [       OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms)
>> [ RUN      ] LogConfigurationTest.invalid_configure_options_vm
>> [       OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms)
>> [ RUN      ] LogConfigurationTest.parse_empty_command_line_arguments_vm
>> [0.462s][warning][logging] Ignoring excess -Xlog options: ""
>> [       OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms)
>> [ RUN      ] LogConfigurationTest.parse_command_line_arguments_vm
>> [       OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms)
>> [ RUN      ] LogConfigurationTest.parse_log_arguments_vm
>> [       OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms)
>> [ RUN      ] LogConfigurationTest.configure_stdout_vm
>> [       OK ] LogConfigurationTest.configure_stdout_vm (2 ms)
>> [ RUN      ] LogConfigurationTest.subscribe_vm
>> [       OK ] LogConfigurationTest.subscribe_vm (2 ms)
>> [ RUN      ] LogConfigurationTest.parse_invalid_tagset_vm
>> [       OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms)
>> [ RUN      ] LogConfigurationTest.output_name_normalization_vm
>> [       OK ] LogConfigurationTest.output_name_normalization_vm (1 ms)
>> [ RUN      ] LogConfigurationTest.suggest_similar_selection_vm
>> [       OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms)
>> [----------] 15 tests from LogConfigurationTest (658 ms total)
>> 
>> [----------] Global test environment tear-down
>> [==========] 15 tests from 1 test case ran. (659 ms total)
>> [  PASSED  ] 15 tests.
>
> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change variable name to better one

Thank you for your reviews!

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

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

From ksakata at openjdk.java.net  Thu May  6 06:56:00 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Thu, 6 May 2021 06:56:00 GMT
Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log [v2]
In-Reply-To: <ePPUEpHlLvXDQuAjNNbhJWIgsMtG9sSRMG2NDCA3qPc=.34ec71c3-6d3d-41ef-8a78-9c2033ae01f3@github.com>
References: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
 <ePPUEpHlLvXDQuAjNNbhJWIgsMtG9sSRMG2NDCA3qPc=.34ec71c3-6d3d-41ef-8a78-9c2033ae01f3@github.com>
Message-ID: <f-4QuGWrQ88HzuB2MI-dJPhg6QRb24OP47I0wUEvohA=.47669d82-b456-4664-9ef1-71ae971744f0@github.com>

On Tue, 4 May 2021 23:50:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change variable name to better one
>
> src/hotspot/share/logging/logConfiguration.cpp line 430:
> 
>> 428:   ConfigurationLock cl;
>> 429:   size_t idx;
>> 430:   bool is_added = false;
> 
> Nit: `was_added` (or even just `added`)

Thank you, David. I changed `is_added` to `added`.

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

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

From lzang at openjdk.java.net  Thu May  6 08:45:45 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 6 May 2021 08:45:45 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <FEApmNXBv2avOTMxOmAGzZ02hT9AqwcSndvhr00yASk=.cfe79f07-f81c-4f5e-8581-7ac2281c28b5@github.com>

> 8252842: Extend jmap to support parallel heap dump

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

  code refine and typo fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/6d14790a..bf6d022e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=20-21

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

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

From ksakata at openjdk.java.net  Thu May  6 12:11:02 2021
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Thu, 6 May 2021 12:11:02 GMT
Subject: Integrated: 8265047: Inconsistent warning message in jcmd VM.log
In-Reply-To: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
References: <xJ4Sw-IxGI-Ya4shzzZnrm0oSi9yugVEmOKW_LSpPlM=.eff3b897-bcda-46ee-a945-fb5b77c9553d@github.com>
Message-ID: <ydjFrqeoE-lfjOvuNjqEh7ur_v4KjGK58999_KckUcE=.ad5d2a77-221d-4245-a614-476a2d370097@github.com>

On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 4976 VM.log list
> Log output configuration:
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K
> 
> $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100"
> 4976:
> Output options for existing outputs are ignored.
> 
> $ jcmd 4976 VM.log output="#2" output_options="filecount=100"
> 4976:
> Command executed successfully
> 
> 
> It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases.
> 
> 
> $ jcmd 4976 VM.log list
>  #0: stdout all=warning uptime,level,tags
>  #1: stderr all=off uptime,level,tags
>  #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured)
> 
> This pull request enable to show the warning message when specifying the output index.
> 
> 
> $ java -Xlog::sample.log:: Sample
> $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> $ jcmd 5054 VM.log output="#2" output_options="filecount=100"
> 5054:
> Output options for existing outputs are ignored.
> 
> 
> ### gtest result
> 
> 
> $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.*
> Note: Google Test filter = LogConfigurationTest.*
> [==========] Running 15 tests from 1 test case.
> [----------] Global test environment set-up.
> [----------] 15 tests from LogConfigurationTest
> [ RUN      ] LogConfigurationTest.describe_vm
> [       OK ] LogConfigurationTest.describe_vm (1 ms)
> [ RUN      ] LogConfigurationTest.update_output_vm
> [       OK ] LogConfigurationTest.update_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.add_new_output_vm
> [       OK ] LogConfigurationTest.add_new_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.disable_logging_vm
> [       OK ] LogConfigurationTest.disable_logging_vm (1 ms)
> [ RUN      ] LogConfigurationTest.disable_output_vm
> [       OK ] LogConfigurationTest.disable_output_vm (0 ms)
> [ RUN      ] LogConfigurationTest.reconfigure_decorators_vm
> [       OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms)
> [ RUN      ] LogConfigurationTest.invalid_configure_options_vm
> [       OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_empty_command_line_arguments_vm
> [0.462s][warning][logging] Ignoring excess -Xlog options: ""
> [       OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms)
> [ RUN      ] LogConfigurationTest.parse_command_line_arguments_vm
> [       OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms)
> [ RUN      ] LogConfigurationTest.parse_log_arguments_vm
> [       OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms)
> [ RUN      ] LogConfigurationTest.configure_stdout_vm
> [       OK ] LogConfigurationTest.configure_stdout_vm (2 ms)
> [ RUN      ] LogConfigurationTest.subscribe_vm
> [       OK ] LogConfigurationTest.subscribe_vm (2 ms)
> [ RUN      ] LogConfigurationTest.parse_invalid_tagset_vm
> [       OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms)
> [ RUN      ] LogConfigurationTest.output_name_normalization_vm
> [       OK ] LogConfigurationTest.output_name_normalization_vm (1 ms)
> [ RUN      ] LogConfigurationTest.suggest_similar_selection_vm
> [       OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms)
> [----------] 15 tests from LogConfigurationTest (658 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 15 tests from 1 test case ran. (659 ms total)
> [  PASSED  ] 15 tests.

This pull request has now been integrated.

Changeset: 51f5adfc
Author:    Koichi Sakata <ksakata at openjdk.org>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51f5adfca3854b1556bb73e08e0b3e733ab6161b
Stats:     7 lines in 1 file changed: 5 ins; 2 del; 0 mod

8265047: Inconsistent warning message in jcmd VM.log

Reviewed-by: dholmes, stuefe, sspitsyn

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

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

From sgehwolf at openjdk.java.net  Thu May  6 13:54:54 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 6 May 2021 13:54:54 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load
In-Reply-To: <HCdl5UDmZqeuYMbB8cnr0qesiFw1x-NH6F5tbrI0eMs=.c5ed84c9-9f23-4890-a0b5-ddb5c323a931@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
 <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>
 <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>
 <HCdl5UDmZqeuYMbB8cnr0qesiFw1x-NH6F5tbrI0eMs=.c5ed84c9-9f23-4890-a0b5-ddb5c323a931@github.com>
Message-ID: <21o75Tv0qUshuro02AKQGZHZCEnHw-zmOznWLKBXUVs=.c6463617-f075-4271-b035-7160b18d1196@github.com>

On Thu, 6 May 2021 02:34:01 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.
>
>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.
> 
> Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation.
> 
> We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways.
> 1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` &  `share`);
> 2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number.
> 
> Looking forward to your suggestion.

> We happened to hit an exactly similar problem when running on a container with openjdk15.
> 
> Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above.
> Is there a good reason `getCpuQuota` is a better alternative?

@argha-c  The proposed fix is within the `quota > 0` condition. I.e. this is code only run when CPU quotas, *not* shares are in effect. In docker/podman speach these are `--cpu-quota=...` and  `--cpu-period=....` switches. So no, in this case it wouldn't make sense to use cpu shares info in a branch which looks at cpu quotas ;-)

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

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

From sgehwolf at openjdk.java.net  Thu May  6 13:54:53 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 6 May 2021 13:54:53 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load
In-Reply-To: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
Message-ID: <fLdHuSX7hmGwY-pjvlk4lGCN0udEDXjqVzZ6cYQPKc4=.74d6f417-7191-451c-ba68-4861c9b2cc1d@github.com>

On Fri, 23 Apr 2021 13:33:42 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
> 
> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".

@tanghaoth90 There are a couple of ways how CPU restrictions can be enforced. It appears that the current patch fixes the cpuacct controller case (`--cpu-quota`), but doesn't yet address `--cpu-shares` case. I've made a note of that in the bug.

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

Changes requested by sgehwolf (Reviewer).

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

From sgehwolf at openjdk.java.net  Thu May  6 13:54:54 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 6 May 2021 13:54:54 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load
In-Reply-To: <21o75Tv0qUshuro02AKQGZHZCEnHw-zmOznWLKBXUVs=.c6463617-f075-4271-b035-7160b18d1196@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
 <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>
 <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>
 <HCdl5UDmZqeuYMbB8cnr0qesiFw1x-NH6F5tbrI0eMs=.c5ed84c9-9f23-4890-a0b5-ddb5c323a931@github.com>
 <21o75Tv0qUshuro02AKQGZHZCEnHw-zmOznWLKBXUVs=.c6463617-f075-4271-b035-7160b18d1196@github.com>
Message-ID: <zdd6f7UC8d3zWG_trQ6Sep2UNZ78NTp1JLJ80TTsSbc=.863d30fe-dd7b-4894-810f-9b7ba6ff7d50@github.com>

On Thu, 6 May 2021 12:36:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.
>> 
>> Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation.
>> 
>> We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways.
>> 1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` &  `share`);
>> 2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number.
>> 
>> Looking forward to your suggestion.
>
>> We happened to hit an exactly similar problem when running on a container with openjdk15.
>> 
>> Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above.
>> Is there a good reason `getCpuQuota` is a better alternative?
> 
> @argha-c  The proposed fix is within the `quota > 0` condition. I.e. this is code only run when CPU quotas, *not* shares are in effect. In docker/podman speach these are `--cpu-quota=...` and  `--cpu-period=....` switches. So no, in this case it wouldn't make sense to use cpu shares info in a branch which looks at cpu quotas ;-)

> Hi Argha, thanks a lot for your suggestion. I think both "quota" and "share" are worth considering.

@tanghaoth90 My local testing suggests that your fix addresses the issue of CPU quotas set via `--cpu-quota/--cpu-period`. When using `--cpu-shares` the CPU load calculation is wrong since it will (wrongly) report host values. Lets look at them individually, fix the quota and shares case individually (i.e. when not both are set). Once that's done, quota will be preferred in the OperatingSystemMXBean impl, which is reasonable. I don't think we need to account for the shares-preferred-over-quota at this point since that changed in HotSpot in JDK 11 time-frame (JDK-8197589) and OperatingSystemMXBean has only been made container aware in JDK 14 (yes, it got backported, but still).

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

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

From github.com+971473+argha-c at openjdk.java.net  Thu May  6 16:34:51 2021
From: github.com+971473+argha-c at openjdk.java.net (Argha C)
Date: Thu, 6 May 2021 16:34:51 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load
In-Reply-To: <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
 <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>
 <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>
Message-ID: <DYzBLFDBMsie1fb8GtbSw4xrbKzixbuer-ckYYn5O7E=.859ec2f7-7a8d-4aa5-9567-105a5410d113@github.com>

On Wed, 5 May 2021 21:16:07 GMT, Argha C <github.com+971473+argha-c at openjdk.org> wrote:

>> Hi Argha, thanks a lot for your suggestion. I think both "quota" and "share" are worth considering. Let us look into the implementation of `CgroupSubsystem::active_processor_count()` in OpenJDK HotSpot (https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/cgroupSubsystem_linux.cpp).
>
> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.

> @argha-c The proposed fix is within the `quota > 0` condition. I.e. this is code only run when CPU quotas, _not_ shares are in effect. In docker/podman speach these are `--cpu-quota=...` and `--cpu-period=....` switches. So no, in this case it wouldn't make sense to use cpu shares info in a branch which looks at cpu quotas ;-)

@jerboaa : Correct. My comment was less specific to the branch, and more to highlight that a fix here needs to consider the case for both `quota` and `shares`. I see the bug report has been updated to reflect that. Cheers.

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

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

From sgehwolf at openjdk.java.net  Thu May  6 16:42:53 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 6 May 2021 16:42:53 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load
In-Reply-To: <DYzBLFDBMsie1fb8GtbSw4xrbKzixbuer-ckYYn5O7E=.859ec2f7-7a8d-4aa5-9567-105a5410d113@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
 <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>
 <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>
 <DYzBLFDBMsie1fb8GtbSw4xrbKzixbuer-ckYYn5O7E=.859ec2f7-7a8d-4aa5-9567-105a5410d113@github.com>
Message-ID: <_ROoHGcoT4qAjecdgaTT7J-33EwEqfx62sBTZw8TBTw=.f33c4acc-8738-4b68-96d6-39c9191df103@github.com>

On Thu, 6 May 2021 16:31:57 GMT, Argha C <github.com+971473+argha-c at openjdk.org> wrote:

>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.
>
>> @argha-c The proposed fix is within the `quota > 0` condition. I.e. this is code only run when CPU quotas, _not_ shares are in effect. In docker/podman speach these are `--cpu-quota=...` and `--cpu-period=....` switches. So no, in this case it wouldn't make sense to use cpu shares info in a branch which looks at cpu quotas ;-)
> 
> @jerboaa : Correct. My comment was less specific to the branch, and more to highlight that a fix here needs to consider the case for both `quota` and `shares`. I see the bug report has been updated to reflect that. Cheers.

OK. Thanks for clarifying.

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

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

From amenkov at openjdk.java.net  Thu May  6 18:37:54 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 6 May 2021 18:37:54 GMT
Subject: Integrated: 8262002:
 java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with
 "TestCaseScaffoldException: DummyClassWithLVT did not match .class file"
In-Reply-To: <zKkhC_I6U5M179m6g4pm2Aal447M11lt8FGrQ154i6c=.7028424c-7779-46bf-9eee-3f0b1b95d98d@github.com>
References: <zKkhC_I6U5M179m6g4pm2Aal447M11lt8FGrQ154i6c=.7028424c-7779-46bf-9eee-3f0b1b95d98d@github.com>
Message-ID: <y4aj29pozhT4bBqSPdesdr6flTNj0T48zRLlyv3fLWE=.a56de1fc-8f6e-4b6d-9a2f-e8e1799fbc99@github.com>

On Sat, 10 Apr 2021 01:10:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution)
> The fix:
> - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does
> - makes the test java instead of shell
> - added workaround for JDK-8264667
> - test code is ready to ignore order of attributes

This pull request has now been integrated.

Changeset: 52f1db6b
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/52f1db6b6f7f5e5823ee84fc31edddf89ed21df4
Stats:     216 lines in 4 files changed: 109 ins; 97 del; 10 mod

8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file"

Reviewed-by: coleenp, sspitsyn

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

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

From amenkov at openjdk.java.net  Thu May  6 18:40:54 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 6 May 2021 18:40:54 GMT
Subject: Integrated: 8266002: vmTestbase/nsk/jvmti/ClassPrepare/classprep001
 should skip events for unexpected classes
In-Reply-To: <fqjBtpYtQINR4TjmMFMrQr5HoWKXUqGTlhqJt5ZSpck=.59a22e0a-5558-40d4-ae9f-3fcb51f5f1d2@github.com>
References: <fqjBtpYtQINR4TjmMFMrQr5HoWKXUqGTlhqJt5ZSpck=.59a22e0a-5558-40d4-ae9f-3fcb51f5f1d2@github.com>
Message-ID: <vqXslx78rS3l63XrsWbdCMD9V-8Kz-8BNFR4La4fDSk=.ee67e8fd-b5d5-4fb0-a9c3-363b0465bff3@github.com>

On Tue, 27 Apr 2021 21:30:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Class loading may cause loading of some other system/internal classes (for example loading of java.util.concurrent classes when an other thread loads some classes concurrently).
> The fix updates ClassPrepare test so it skip events for "unexpected" classes.
> Also it adds a testcase to verify that classes which are explicitly loaded on other thread do not generate ClassPrepare event on the test thread.

This pull request has now been integrated.

Changeset: 0ca86da0
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0ca86da0e3563a8328f6ff2a3bc4d4c5b8a82e69
Stats:     81 lines in 2 files changed: 47 ins; 16 del; 18 mod

8266002: vmTestbase/nsk/jvmti/ClassPrepare/classprep001 should skip events for unexpected classes

Reviewed-by: cjplummer, sspitsyn

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

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

From amenkov at openjdk.java.net  Thu May  6 18:45:20 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 6 May 2021 18:45:20 GMT
Subject: RFR: 8262092:
 vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java
 SIGSEGV in memmove_ssse3 [v2]
In-Reply-To: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
References: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
Message-ID: <EQW7wMGhMToOWYYaXhvPgGPYSWgGu2xSXUguEDpy5bU=.2de40aa1-7f0b-4631-bc34-4179f0a6fe44@github.com>

> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization.
> The fix adds synchronization for ClassFileLoadHook.

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

  added missed break; made all counters atomic

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3889/files
  - new: https://git.openjdk.java.net/jdk/pull/3889/files/63e85bc3..6606d89b

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

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

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

From vromero at openjdk.java.net  Thu May  6 19:06:41 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 6 May 2021 19:06:41 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v7]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <jNF-OSpoltX9uAQfIsPp1FUzxVoTGE22E6CShSLC0f8=.f3ac3333-64fa-420f-a123-47338d5b6058@github.com>

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

Vicente Romero 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' into JDK-8260517
 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - updating comment after review feedback
 - removing javax.lang.model changes
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - fixing failing regression tests
 - JVM related changes
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/10336a26...0208dcf0

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/304fd76a..0208dcf0

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

  Stats: 18908 lines in 391 files changed: 9887 ins; 4814 del; 4207 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526

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

From lmesnik at openjdk.java.net  Thu May  6 19:21:52 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 6 May 2021 19:21:52 GMT
Subject: RFR: 8262092:
 vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java
 SIGSEGV in memmove_ssse3 [v2]
In-Reply-To: <EQW7wMGhMToOWYYaXhvPgGPYSWgGu2xSXUguEDpy5bU=.2de40aa1-7f0b-4631-bc34-4179f0a6fe44@github.com>
References: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
 <EQW7wMGhMToOWYYaXhvPgGPYSWgGu2xSXUguEDpy5bU=.2de40aa1-7f0b-4631-bc34-4179f0a6fe44@github.com>
Message-ID: <okhOY-hXXxfxCa8m1c4JBVcFPRU-bC8OCG5sw8zKBzQ=.1c887363-a8b0-43bc-b132-09c0f22c3d8f@github.com>

On Thu, 6 May 2021 18:45:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization.
>> The fix adds synchronization for ClassFileLoadHook.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added missed break; made all counters atomic

Marked as reviewed by lmesnik (Committer).

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

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

From kevinw at openjdk.java.net  Thu May  6 20:48:00 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 6 May 2021 20:48:00 GMT
Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker
 container
Message-ID: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>

This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started.

jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file.  That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/.  But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers.  Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever.

Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go.  Running existing tests OK so far.

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

Commit messages:
 - 8196743: jstatd doesn't see new Java processes inside Docker container

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

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

From larry.cable at oracle.com  Thu May  6 21:50:51 2021
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 6 May 2021 14:50:51 -0700
Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker
 container
In-Reply-To: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
References: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
Message-ID: <a12d9bb9-79e5-c906-d59e-b33b717ec82f@oracle.com>

and sadly /proc does not support inotify()!!!!



On 5/6/21 1:48 PM, Kevin Walls wrote:
> This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started.
>
> jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file.  That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/.  But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers.  Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever.
>
> Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go.  Running existing tests OK so far.
>
> -------------
>
> Commit messages:
>   - 8196743: jstatd doesn't see new Java processes inside Docker container
>
> Changes: https://git.openjdk.java.net/jdk/pull/3908/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3908&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8196743
>    Stats: 10 lines in 1 file changed: 5 ins; 3 del; 2 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/3908.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/3908/head:pull/3908
>
> PR: https://git.openjdk.java.net/jdk/pull/3908

-------------- next part --------------
A non-text attachment was scrubbed...
Name: larry_cable.vcf
Type: text/x-vcard
Size: 217 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210506/2d0958e2/larry_cable.vcf>

From sspitsyn at openjdk.java.net  Thu May  6 23:57:22 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 6 May 2021 23:57:22 GMT
Subject: RFR: 8266193: BasicJMapTest does not include testHistoParallel
 methods [v2]
In-Reply-To: <GxxfrFeDmpiIj76DKSQ_YWROalVxpK8h2zjTvvMmP_4=.d9e522f2-0ddc-4394-9e9f-2c505cea42b6@github.com>
References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com>
 <5kkIscThLm820VsCd91EKWYPoYXXT20ZPbYNo5s2OLg=.ade64cda-f8a2-490e-b3aa-1ffdb7a3f95b@github.com>
 <GxxfrFeDmpiIj76DKSQ_YWROalVxpK8h2zjTvvMmP_4=.d9e522f2-0ddc-4394-9e9f-2c505cea42b6@github.com>
Message-ID: <O0ZNy0sCAqlhNlPVzpEQVWOEMkQhLQRDZHrU1CmSdrk=.b258da42-04ff-46f2-8898-850fa623b0e8@github.com>

On Thu, 6 May 2021 03:03:40 GMT, BuddyLiao <github.com+3094961+buddyliao at openjdk.org> wrote:

>> @buddyliao 
>> The test update looks good to me.
>> Thanks,
>> Serguei
>
>> @buddyliao
>> The test update looks good to me.
>> Thanks,
>> Serguei
> 
> @sspitsyn Thanks, I have forced update the title to match between PR and JBS.
> Would you help me to push it?
> 
> Thanks,
> Buddy

@buddyliao
Two reviews are required for serviceability fixes.
I'll sponsor it once you get another review.

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

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

From ysuenaga at openjdk.java.net  Thu May  6 23:57:51 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 6 May 2021 23:57:51 GMT
Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker
 container
In-Reply-To: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
References: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
Message-ID: <tuVqzopvlUcTl2In3Zvt2jUatKhA9YVT1e_Jlz2PY_M=.b1769f49-9ab5-4b07-be78-55e97e1ba9d3@github.com>

On Thu, 6 May 2021 20:41:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started.
> 
> jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file.  That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/.  But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers.  Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever.
> 
> Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go.  Running existing tests OK so far.

src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java line 79:

> 77:     public LocalVmManager(String user) {
> 78:         this.userName = user;
> 79:         setTempDirs();

Is this call necessary? It looks like we don't need to hold `tmpdirs` anymore. Can we remove `tmpdirs` from class member and can call `PerfDataFile.getTempDirectories()` directly at L138?

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

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

From sspitsyn at openjdk.java.net  Fri May  7 00:25:11 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 7 May 2021 00:25:11 GMT
Subject: RFR: 8262092:
 vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java
 SIGSEGV in memmove_ssse3 [v2]
In-Reply-To: <EQW7wMGhMToOWYYaXhvPgGPYSWgGu2xSXUguEDpy5bU=.2de40aa1-7f0b-4631-bc34-4179f0a6fe44@github.com>
References: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
 <EQW7wMGhMToOWYYaXhvPgGPYSWgGu2xSXUguEDpy5bU=.2de40aa1-7f0b-4631-bc34-4179f0a6fe44@github.com>
Message-ID: <JHlU47BlEHKc35OeF2P30RAuKPI-YyW_PQuudUD6gCA=.aaa14940-e922-4485-b3dd-b18ea8a0e23d@github.com>

On Thu, 6 May 2021 18:45:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization.
>> The fix adds synchronization for ClassFileLoadHook.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added missed break; made all counters atomic

This looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Fri May  7 00:33:59 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 7 May 2021 00:33:59 GMT
Subject: RFR: 8265612: revise the help info for jmap histo command [v3]
In-Reply-To: <abgueqJn-Sd447YebtU90QKzA7DyRf6NMNnIw7c3O9w=.7dc4492d-df93-4c88-b5ce-7c2dd0dca43e@github.com>
References: <cfxcRzY79kUAvz0gmR7Br2NlSICV_MJZ1MD9Q5jl-9o=.19787a5d-8072-4341-9bfa-eef4f7329d83@github.com>
 <abgueqJn-Sd447YebtU90QKzA7DyRf6NMNnIw7c3O9w=.7dc4492d-df93-4c88-b5ce-7c2dd0dca43e@github.com>
Message-ID: <yV70j-VKMJq0k2liW1O59_ddqsSF8yysapoHqE5MKnk=.fc55bbce-36a8-464c-bad3-55c9a75a90d1@github.com>

On Thu, 22 Apr 2021 05:53:35 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR  revise the help message of the `parallel=[N]` option of command `jmap -histo`. It mainly comes from the discussion at  https://github.com/openjdk/jdk/pull/2379#issuecomment-782609582  and https://github.com/openjdk/jdk/pull/2261#issuecomment-823623186.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation issue

Hi Lin,
I've added a comment with the /sponsor, so you can push it now.

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

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

From lzang at openjdk.java.net  Fri May  7 00:33:59 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 7 May 2021 00:33:59 GMT
Subject: RFR: 8265612: revise the help info for jmap histo command [v3]
In-Reply-To: <yV70j-VKMJq0k2liW1O59_ddqsSF8yysapoHqE5MKnk=.fc55bbce-36a8-464c-bad3-55c9a75a90d1@github.com>
References: <cfxcRzY79kUAvz0gmR7Br2NlSICV_MJZ1MD9Q5jl-9o=.19787a5d-8072-4341-9bfa-eef4f7329d83@github.com>
 <abgueqJn-Sd447YebtU90QKzA7DyRf6NMNnIw7c3O9w=.7dc4492d-df93-4c88-b5ce-7c2dd0dca43e@github.com>
 <yV70j-VKMJq0k2liW1O59_ddqsSF8yysapoHqE5MKnk=.fc55bbce-36a8-464c-bad3-55c9a75a90d1@github.com>
Message-ID: <tQNSj9fQ3kjXSMUDi9_EMr5YMUPAVPJQAenBYC91pts=.96a45026-7499-4d0a-8910-c764236e6b92@github.com>

On Fri, 7 May 2021 00:26:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix indentation issue
>
> Hi Lin,
> I've added a comment with the /sponsor, so you can push it now.

Hi @sspitsyn?Thanks a lot?

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

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

From sspitsyn at openjdk.java.net  Fri May  7 00:42:53 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 7 May 2021 00:42:53 GMT
Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker
 container
In-Reply-To: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
References: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
Message-ID: <BCPJqRH7beH9_BiI_55xQ6fKlvk-75Wu77UKBW_wTKo=.9f3d079a-d16d-4f41-b7e1-4672db051971@github.com>

On Thu, 6 May 2021 20:41:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started.
> 
> jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file.  That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/.  But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers.  Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever.
> 
> Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go.  Running existing tests OK so far.

Hi Kevin,
This looks okay to me modulo the question from Yasumasa.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From lzang at openjdk.java.net  Fri May  7 02:00:11 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 7 May 2021 02:00:11 GMT
Subject: RFR: 8265612: revise the help info for jmap histo command [v3]
In-Reply-To: <abgueqJn-Sd447YebtU90QKzA7DyRf6NMNnIw7c3O9w=.7dc4492d-df93-4c88-b5ce-7c2dd0dca43e@github.com>
References: <cfxcRzY79kUAvz0gmR7Br2NlSICV_MJZ1MD9Q5jl-9o=.19787a5d-8072-4341-9bfa-eef4f7329d83@github.com>
 <abgueqJn-Sd447YebtU90QKzA7DyRf6NMNnIw7c3O9w=.7dc4492d-df93-4c88-b5ce-7c2dd0dca43e@github.com>
Message-ID: <hjv7dUehVHJycZj9bzde_zJrFMh2I669PYiQGyUZG_U=.06aa4549-18b1-47b0-b0e9-c651d9276d9e@github.com>

On Thu, 22 Apr 2021 05:53:35 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR  revise the help message of the `parallel=[N]` option of command `jmap -histo`. It mainly comes from the discussion at  https://github.com/openjdk/jdk/pull/2379#issuecomment-782609582  and https://github.com/openjdk/jdk/pull/2261#issuecomment-823623186.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation issue

Hi Serguei, 
Sorry that I forgot to add /integrate tag before asking your help sponsor, it seems I need your help to mark this PR again with /sponsor tag, Would you like to help again. Thanks a lot!
Lin

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

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

From amenkov at openjdk.java.net  Fri May  7 02:03:50 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 7 May 2021 02:03:50 GMT
Subject: RFR: 8266193: BasicJMapTest does not include testHistoParallel
 methods [v2]
In-Reply-To: <uCjclqrhBQaKsY5-HvGqp2zRM3nsHulj2VV2C_pdrpo=.94a4e22b-362a-4a99-bfa1-51de71f35e2f@github.com>
References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com>
 <uCjclqrhBQaKsY5-HvGqp2zRM3nsHulj2VV2C_pdrpo=.94a4e22b-362a-4a99-bfa1-51de71f35e2f@github.com>
Message-ID: <GQFKVRwReaoUhNrNFp2ktRfY4xw7deU34u-sMsJ2zVw=.141c1a3d-05bf-4661-a631-a432411d9928@github.com>

On Thu, 6 May 2021 02:30:08 GMT, BuddyLiao <github.com+3094961+buddyliao at openjdk.org> wrote:

>> The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included.
>
> BuddyLiao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8266193: BasicJMapTest does not include testHistoParallel methods

Marked as reviewed by amenkov (Reviewer).

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

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

From github.com+3094961+buddyliao at openjdk.java.net  Fri May  7 03:00:56 2021
From: github.com+3094961+buddyliao at openjdk.java.net (BuddyLiao)
Date: Fri, 7 May 2021 03:00:56 GMT
Subject: Integrated: 8266193: BasicJMapTest does not include testHistoParallel
 methods
In-Reply-To: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com>
References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com>
Message-ID: <T_YKY7qQzJrQwp2gpAwKMZhJmTSWou48hNgm-wDDaTo=.eac1655c-b3fa-4d4a-b404-00cc5d78a346@github.com>

On Fri, 30 Apr 2021 08:06:38 GMT, BuddyLiao <github.com+3094961+buddyliao at openjdk.org> wrote:

> The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included.

This pull request has now been integrated.

Changeset: 66191ff4
Author:    buddyliao <buddyliao at tencent.com>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/66191ff4b04f03172e8b7b28184a7f39ce3804bd
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8266193: BasicJMapTest does not include testHistoParallel methods

Reviewed-by: sspitsyn, amenkov

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

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

From lzang at openjdk.java.net  Fri May  7 04:44:14 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 7 May 2021 04:44:14 GMT
Subject: Integrated: 8265612: revise the help info for jmap histo command
In-Reply-To: <cfxcRzY79kUAvz0gmR7Br2NlSICV_MJZ1MD9Q5jl-9o=.19787a5d-8072-4341-9bfa-eef4f7329d83@github.com>
References: <cfxcRzY79kUAvz0gmR7Br2NlSICV_MJZ1MD9Q5jl-9o=.19787a5d-8072-4341-9bfa-eef4f7329d83@github.com>
Message-ID: <CLMEJbwdzQTlmdDh8z9--pcOReRpfkHjDCqxCp3CYxc=.7d89dfd6-8839-4bbe-9e0e-5a9a7cf2dfd0@github.com>

On Wed, 21 Apr 2021 02:18:12 GMT, Lin Zang <lzang at openjdk.org> wrote:

> This PR  revise the help message of the `parallel=[N]` option of command `jmap -histo`. It mainly comes from the discussion at  https://github.com/openjdk/jdk/pull/2379#issuecomment-782609582  and https://github.com/openjdk/jdk/pull/2261#issuecomment-823623186.

This pull request has now been integrated.

Changeset: 3a474d95
Author:    Lin Zang <lzang at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3a474d953a608a0e4b40a4d0b53ec3e98d73f406
Stats:     10 lines in 1 file changed: 0 ins; 0 del; 10 mod

8265612: revise the help info for jmap histo command

Reviewed-by: cjplummer, sspitsyn

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

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

From kevinw at openjdk.java.net  Fri May  7 09:15:14 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 7 May 2021 09:15:14 GMT
Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker
 container [v2]
In-Reply-To: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
References: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
Message-ID: <ecpB7Q53QzPrxnJz5eM6Xp-sQS_E1Xzfh5W_Ml_5pp8=.5922c9b8-0d43-4ab4-92f2-2af84ed84494@github.com>

> This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started.
> 
> jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file.  That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/.  But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers.  Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever.
> 
> Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go.  Running existing tests OK so far.

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

  Remove tmpdirs member, call getTempDirectories() directly as needed.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3908/files
  - new: https://git.openjdk.java.net/jdk/pull/3908/files/658a9e27..3654447b

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

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

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

From kevinw at openjdk.java.net  Fri May  7 09:15:15 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 7 May 2021 09:15:15 GMT
Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker
 container [v2]
In-Reply-To: <tuVqzopvlUcTl2In3Zvt2jUatKhA9YVT1e_Jlz2PY_M=.b1769f49-9ab5-4b07-be78-55e97e1ba9d3@github.com>
References: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
 <tuVqzopvlUcTl2In3Zvt2jUatKhA9YVT1e_Jlz2PY_M=.b1769f49-9ab5-4b07-be78-55e97e1ba9d3@github.com>
Message-ID: <IqLSV-HSlEVIkAPRIVhVMtZ0o0aLgSWe8E66q6CsP6Y=.c2bf69d1-cb71-4bd9-9ffe-0bcf8cd8979d@github.com>

On Thu, 6 May 2021 23:54:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove tmpdirs member, call getTempDirectories() directly as needed.
>
> src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java line 79:
> 
>> 77:     public LocalVmManager(String user) {
>> 78:         this.userName = user;
>> 79:         setTempDirs();
> 
> Is this call necessary? It looks like we don't need to hold `tmpdirs` anymore. Can we remove `tmpdirs` from class member and can call `PerfDataFile.getTempDirectories()` directly at L138?

Hi - right, it's not necessary, I almost took it out, but had a minor concern about leaving tmpdirs unset.
But removing tmpdirs as a member is fine also.  That is testing well, will push an update shortly.

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

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

From ysuenaga at openjdk.java.net  Fri May  7 09:18:53 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 7 May 2021 09:18:53 GMT
Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker
 container [v2]
In-Reply-To: <ecpB7Q53QzPrxnJz5eM6Xp-sQS_E1Xzfh5W_Ml_5pp8=.5922c9b8-0d43-4ab4-92f2-2af84ed84494@github.com>
References: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
 <ecpB7Q53QzPrxnJz5eM6Xp-sQS_E1Xzfh5W_Ml_5pp8=.5922c9b8-0d43-4ab4-92f2-2af84ed84494@github.com>
Message-ID: <dMxPzjctK_00Z3_BMTL7d-oR7tV3KnqQzwuKqp-zwiw=.44ff1f8d-3c12-4693-9612-eda2cc53a1cf@github.com>

On Fri, 7 May 2021 09:15:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started.
>> 
>> jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file.  That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/.  But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers.  Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever.
>> 
>> Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go.  Running existing tests OK so far.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove tmpdirs member, call getTempDirectories() directly as needed.

Looks good! Thank you for fixing!

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

Marked as reviewed by ysuenaga (Reviewer).

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

From lzang at openjdk.java.net  Fri May  7 15:41:00 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 7 May 2021 15:41:00 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v8]
In-Reply-To: <szNcoxOky13tYdPwhiVITp8pAc1ok8H-4TKrcD48LwY=.d77792fb-3ce6-4082-8abf-95f32b5c4ec7@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <xZu6CoC0ZEYc3gFa7BHHCjnhZaMohpmpBcxm7t_Wu_E=.19e215c2-75aa-40ea-81da-38bdd2ffeb4a@github.com>
 <szNcoxOky13tYdPwhiVITp8pAc1ok8H-4TKrcD48LwY=.d77792fb-3ce6-4082-8abf-95f32b5c4ec7@github.com>
Message-ID: <M_GTRn658iQn4GJNyOseAbH_EpnuZjmlzTSjY0iR-jk=.57daedb1-ccb3-4397-884c-855ffe20b86c@github.com>

On Tue, 20 Apr 2021 21:55:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang 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'
>>  - Merge branch 'master' into sf
>>  - rename writeThrough to unbufferedMode and code refine
>>  - fix typo in comments
>>  - Merge branch 'master' into sf
>>  - Revert "reduce memory consumption"
>>    
>>    This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e.
>>  - reduce memory consumption
>>  - code refine
>>  - 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
>
> I think it's fine to fix this issue first with something simpler, and worry about the rewrite later.

Hi Chris (@plummercj )

After several tries, I think maybe the current patch is the better way to fix this issue. 
For detail, there are three issues that cause the problem. 
- The incorrect calculated array length when segmented heap dump is enabled, it can be fixed easily by modifying code in method `calculateArrayMaxLength()`. It is already in this PR.
- The internal segment buffer used for segmented heap dump. Plus the resize of this buffer can cause memory consumption by doing byte[] copy. 
- Also because the internal segment buffer is byte array, there is a limitation that the buffer length can not be larger than Integer.MAX_VALUE, which also cause the problem when dumping large array, as there can be integer overflow and also not align with the specification (as explained blow)

Here are the possible solutions I have tried to avoid using `unbufferedMode`:

- For segment heap dump, add limitation in `calculateArrayMaxLength()` to guarantee at most `Interger.MAX_VALUE` bytes can be filled into the internal byte array buffer. So there is no need to use unbufferedMode. But I found it can cause large memory usage with internal buffer resize to hold all array data, and also there is OOM thrown when I use `jhsdb jmap --binaryheap` command. Moreover it also changes the behavior of dumping large array:  The original limitation is  MAX_U4_VALUE, which follows the hprof spec that a segment in heap dump has a 32bit slot to hold the segment size.  But after the change , it becomes to `Integer.MAX_VALUE`, which is 2^31-1, just the half of MAX_U4_VALUE, the behavior doesn't follow the spec exactly. 
The change also introduce lots of overflow check when size of internal segment buffer is used, which IMHO is not clean.

- I also tried to avoid resize of internal segment buffer by using a linked list to hold all data to be flushed, this can avoid the overflow check. But it also cause OOM since the whole data are hold in the list. And it also introduce more codes for the linked list logic.

And the main reason for caching data in internal segment buffer is that the current implentation needs to update the `size slot` in the segment header, which must be done before the whole data flushed to file, otherwise it would cause problems when gzip heap dump is used. 

The way to avoid caching is to calculate the object size previously and then update the size slot at begining. But it would cause other changes in the code, which IMO is not suitable to introduce in this PR. That is why I mentioned to re-write the implementation of `HeapHprofBinWriter.java` in previous comments.

Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()`  and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file.

What do you think?

Thanks,
Lin

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

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

From kevinw at openjdk.java.net  Fri May  7 15:46:56 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 7 May 2021 15:46:56 GMT
Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker
 container [v2]
In-Reply-To: <ecpB7Q53QzPrxnJz5eM6Xp-sQS_E1Xzfh5W_Ml_5pp8=.5922c9b8-0d43-4ab4-92f2-2af84ed84494@github.com>
References: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
 <ecpB7Q53QzPrxnJz5eM6Xp-sQS_E1Xzfh5W_Ml_5pp8=.5922c9b8-0d43-4ab4-92f2-2af84ed84494@github.com>
Message-ID: <96hUWjwEDumCR3Q6TdrAWgmkOaUyZClG7bFkATZ2ABw=.dd86b32d-20cb-4497-ad3b-dc4c6400340b@github.com>

On Fri, 7 May 2021 09:15:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started.
>> 
>> jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file.  That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/.  But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers.  Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever.
>> 
>> Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go.  Running existing tests OK so far.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove tmpdirs member, call getTempDirectories() directly as needed.

(For the record, the tier1_serviceability tests run OK for me.)

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

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

From kevinw at openjdk.java.net  Fri May  7 15:46:56 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 7 May 2021 15:46:56 GMT
Subject: Integrated: 8196743: jstatd doesn't see new Java processes inside
 Docker container
In-Reply-To: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
References: <vLV5hO8BYh0jOMK5K1BDoOdqGrNFUi8TVrL1j-53utg=.e068256b-83b2-49a8-b6f0-d6e80f656dec@github.com>
Message-ID: <QCJjJo1ALbX1zw7yt8ucw2FzHVnqKPvcIUjmjjqyYzM=.033a16fc-eb6d-423e-ad87-abaed410799c@github.com>

On Thu, 6 May 2021 20:41:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started.
> 
> jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file.  That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/.  But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers.  Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever.
> 
> Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go.  Running existing tests OK so far.

This pull request has now been integrated.

Changeset: 0790e601
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0790e6016e153b4fa4df5d80737f90aa555c7ba9
Stats:     7 lines in 1 file changed: 1 ins; 5 del; 1 mod

8196743: jstatd doesn't see new Java processes inside Docker container

Reviewed-by: sspitsyn, ysuenaga

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

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

From coleenp at openjdk.java.net  Sun May  9 22:54:08 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Sun, 9 May 2021 22:54:08 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <Olj5jI71lCFEneQYGjUfWjhy-EhRX007ft8LZ6pcF2I=.5116187d-f6ab-4d77-9fe7-94f671ddff98@github.com>

On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

I started out thinking that this was too big and should be broken up but then the change is pretty simple to review and mostly mechanical.  So ignore my comments to break it up.  I think it's fine.  Hitting "approve" even though it's a draft.

src/hotspot/share/cds/archiveBuilder.cpp line 903:

> 901: 
> 902:   static void write_klass(Klass* k, address runtime_dest, const char* type_name, int bytes, Thread* THREAD) {
> 903:     ResourceMark rm(THREAD);

This change seems like it could be an independent check in because all you did was change the name of the parameter here, ie doesn't depend on on THREAD being a JavaThread.

src/hotspot/share/cds/dynamicArchive.cpp line 172:

> 170:   _header = mapinfo->dynamic_header();
> 171: 
> 172:   Thread* THREAD = Thread::current();

Unused?  Looks like you could also remove these in a trivial pre-commit.

src/hotspot/share/classfile/classLoader.cpp line 1077:

> 1075: 
> 1076: // Search either the patch-module or exploded build entries for class.
> 1077: ClassFileStream* ClassLoader::search_module_entries(JavaThread* current,

I wonder if these CDS and classLoader.hpp/cpp changes can be done first?  Just change the caller to pass ->as_Java_thread() until TRAPS is changed.

src/hotspot/share/runtime/sharedRuntime.cpp line 1197:

> 1195: 
> 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) {
> 1197:   JavaThread* current = THREAD;

I think these look strange, especially the ones
JavaThread* thread = THREAD;
but they can be fixed later to just use THREAD when THREAD is available. And it's not really important.

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

Marked as reviewed by coleenp (Reviewer).

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

From dholmes at openjdk.java.net  Sun May  9 22:54:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 9 May 2021 22:54:07 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
Message-ID: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>

Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done that
  pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:

- declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
- methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
- Manifestations of Thread::current() become JavaThread::current()
- THREAD->as_Java_thread() becomes just THREAD
- THREAD->is_Java_thread() is reworked so that THREAD is "current"

There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.

Testing:
 - tiers 1-8 on Linux-x64
 - all builds in tiers 1-4
 - tiers 1-3 on all platforms

Thanks,
David

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

Commit messages:
 - Merge
 - 8252685: APIs that require JavaThread should take JavaThread arguments

Changes: https://git.openjdk.java.net/jdk/pull/3877/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252685
  Stats: 537 lines in 121 files changed: 14 ins; 30 del; 493 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3877.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3877/head:pull/3877

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

From dholmes at openjdk.java.net  Sun May  9 22:54:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 9 May 2021 22:54:08 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <rdpjS7yRdsrtbdGEtOLGVp_EMojwCYqMzdyBtOqPAaE=.c874d813-d4bd-4e12-93f0-bf0ba8d88920@github.com>

On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

Thanks for the pre-review comments Coleen! I started responding to your various comments then realized they were the ones about breaking things up that you said I could now ignore :)

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

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

From dholmes at openjdk.java.net  Sun May  9 22:54:10 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 9 May 2021 22:54:10 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <Olj5jI71lCFEneQYGjUfWjhy-EhRX007ft8LZ6pcF2I=.5116187d-f6ab-4d77-9fe7-94f671ddff98@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <Olj5jI71lCFEneQYGjUfWjhy-EhRX007ft8LZ6pcF2I=.5116187d-f6ab-4d77-9fe7-94f671ddff98@github.com>
Message-ID: <r4U5VJq6BcO553mYLANBvfzyvvfPbbMIMyfe9xnWxpE=.b4ffb154-53ba-44d0-9cc8-1075bc469099@github.com>

On Sat, 8 May 2021 13:06:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t
 hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
>> 
>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
>> - Manifestations of Thread::current() become JavaThread::current()
>> - THREAD->as_Java_thread() becomes just THREAD
>> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
>> 
>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
>> 
>> Testing:
>>  - tiers 1-8 on Linux-x64
>>  - all builds in tiers 1-4
>>  - tiers 1-3 on all platforms
>> 
>> Thanks,
>> David
>
> src/hotspot/share/cds/archiveBuilder.cpp line 903:
> 
>> 901: 
>> 902:   static void write_klass(Klass* k, address runtime_dest, const char* type_name, int bytes, Thread* THREAD) {
>> 903:     ResourceMark rm(THREAD);
> 
> This change seems like it could be an independent check in because all you did was change the name of the parameter here, ie doesn't depend on on THREAD being a JavaThread.

Under these changes THREAD is always a JavaThread so I either need to change the type here (which would be wrong) or else change the name, because it doesn't actually relate to TRAPS/exceptions.  As this change touches a lot of files keeping it merged it time consuming so I'd prefer not to have to split out anything further at this stage. Thanks.

> src/hotspot/share/cds/dynamicArchive.cpp line 172:
> 
>> 170:   _header = mapinfo->dynamic_header();
>> 171: 
>> 172:   Thread* THREAD = Thread::current();
> 
> Unused?  Looks like you could also remove these in a trivial pre-commit.

Yes unused. Again trying to avoid further delays. Also I think this code just went through an undo and will soon be redone, in which case if it gets integrated first I'll try to get this cleaned up. Thanks.

> src/hotspot/share/runtime/sharedRuntime.cpp line 1197:
> 
>> 1195: 
>> 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) {
>> 1197:   JavaThread* current = THREAD;
> 
> I think these look strange, especially the ones
> JavaThread* thread = THREAD;
> but they can be fixed later to just use THREAD when THREAD is available. And it's not really important.

They are the inverse of the

JavaThread* THREAD = current; // For exception macro use.

due to the general trend to not use THREAD for non-exception related code except in some trivial cases.

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

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

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Mon May 10 06:27:12 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya)
Date: Mon, 10 May 2021 06:27:12 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation
In-Reply-To: <eguMK8JZKgHR3CYWJu5IqqSBWLwDGvDGEgZI7dOD3FQ=.e757c490-b4a6-47a2-91fe-03b663b2854a@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <eguMK8JZKgHR3CYWJu5IqqSBWLwDGvDGEgZI7dOD3FQ=.e757c490-b4a6-47a2-91fe-03b663b2854a@github.com>
Message-ID: <qr9EcwZiiCQXNe3qfbSFTrrta34O4UUEvqESc2iWysQ=.cbdf6860-8647-4020-b225-aa164bf92444@github.com>

On Thu, 29 Apr 2021 04:41:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
>> This PR changes to use `Long.hashCode` instead.
>
> @kariya-mitsuru Please enable github actions on your jdk personal fork to enable the pre-submit testing. Start with the following link:
> 
> https://github.com/kariya-mitsuru/jdk/actions
> 
> Click on "Settings" tab and then click on "Actions" from the list of settings (not the "Actions" tab). Then enable "Allow all Actions".

@plummercj Would you please check the changes again?
Also, should I issue the /contributor command?

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

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

From coleenp at openjdk.java.net  Mon May 10 12:35:52 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 10 May 2021 12:35:52 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <r4U5VJq6BcO553mYLANBvfzyvvfPbbMIMyfe9xnWxpE=.b4ffb154-53ba-44d0-9cc8-1075bc469099@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <Olj5jI71lCFEneQYGjUfWjhy-EhRX007ft8LZ6pcF2I=.5116187d-f6ab-4d77-9fe7-94f671ddff98@github.com>
 <r4U5VJq6BcO553mYLANBvfzyvvfPbbMIMyfe9xnWxpE=.b4ffb154-53ba-44d0-9cc8-1075bc469099@github.com>
Message-ID: <YMLMNWMtkqxjJrcjMlNMJ8dbVr28U9FHvpoJauZzy9M=.be2936ab-0535-4ea4-91c1-b337cb56f223@github.com>

On Sun, 9 May 2021 22:42:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/sharedRuntime.cpp line 1197:
>> 
>>> 1195: 
>>> 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) {
>>> 1197:   JavaThread* current = THREAD;
>> 
>> I think these look strange, especially the ones
>> JavaThread* thread = THREAD;
>> but they can be fixed later to just use THREAD when THREAD is available. And it's not really important.
>
> They are the inverse of the
> 
> JavaThread* THREAD = current; // For exception macro use.
> 
> due to the general trend to not use THREAD for non-exception related code except in some trivial cases.

I know what they are.  I think if we already have a THREAD then there's no point having another thread or current variable and it's noisy and confusing, ie. we *know* that THREAD is the current thread by definition and 'current' seems to suggest by name but no guarantee of that, and 'thread' is just generic and means nothing.  I don't think there should be another variable introduced for Handles and ResourceMarks.  Using another variable for last_frame and such might make some sense.  Anyway, my definition of "trivial" cases might be more broad than yours.
It's not for this change, though, this change is fine, even though I think these extra declarations should be removed at some later date if the code changes for some other reason.

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

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

From amenkov at openjdk.java.net  Mon May 10 22:51:32 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 10 May 2021 22:51:32 GMT
Subject: Integrated: 8262092:
 vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java
 SIGSEGV in memmove_ssse3
In-Reply-To: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
References: <Og0oNj5dyYTDCAR1p0lyhMXcCzt6J_AKyj7FNDy_bUc=.e9a99c10-7c23-473d-a301-aaee5cefbc35@github.com>
Message-ID: <kYQ36HebfEyplZS0FbqBQkIrJS0oWLsyNxFcxIMCbgE=.f9192018-a6d6-4a6c-b267-41b781640427@github.com>

On Wed, 5 May 2021 20:26:13 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization.
> The fix adds synchronization for ClassFileLoadHook.

This pull request has now been integrated.

Changeset: 9713152e
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9713152eae660f83b8a681c3168b7eb2285c05bc
Stats:     43 lines in 1 file changed: 24 ins; 7 del; 12 mod

8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3

Reviewed-by: lmesnik, sspitsyn

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

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

From sspitsyn at openjdk.java.net  Mon May 10 23:00:26 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 10 May 2021 23:00:26 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <wwW7kOkv6b7e9WIloNu1rWlOBsz3x-3db9YQQIDU7Ug=.704f8374-7f20-4a52-9306-ea823775c8a2@github.com>

On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp line 108:

> 106: 
> 107: // caller needs ResourceMark
> 108: const char* get_java_thread_name(const JavaThread* t) {

Nit: Better to rename it: t => jt

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

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

From sspitsyn at openjdk.java.net  Mon May 10 23:14:07 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 10 May 2021 23:14:07 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <wGuqyHU3dhONZD-0jCs3eBvrtpC5SduvoXAAjthK3gQ=.5a6f7543-8e13-42ca-9469-b990ec004b4e@github.com>

On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

David,
This looks pretty good. At least, I do not see real problems.
It is really nice to make it more consistent.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From cjplummer at openjdk.java.net  Mon May 10 23:18:03 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 10 May 2021 23:18:03 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation
In-Reply-To: <qr9EcwZiiCQXNe3qfbSFTrrta34O4UUEvqESc2iWysQ=.cbdf6860-8647-4020-b225-aa164bf92444@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <eguMK8JZKgHR3CYWJu5IqqSBWLwDGvDGEgZI7dOD3FQ=.e757c490-b4a6-47a2-91fe-03b663b2854a@github.com>
 <qr9EcwZiiCQXNe3qfbSFTrrta34O4UUEvqESc2iWysQ=.cbdf6860-8647-4020-b225-aa164bf92444@github.com>
Message-ID: <TaUUKhD_I1JPkWNKPIouE6qBe-i929_zCPd-HFxoMSM=.5cca0e92-38a7-47be-b75c-701787948e9f@github.com>

On Mon, 10 May 2021 06:24:23 GMT, Mitsuru kariya <github.com+2217224+kariya-mitsuru at openjdk.org> wrote:

>  Also, should I issue the /contributor command?

I don't think you need to. I tried using it to add you as a contributor because I thought it might be necessary since you don't have an openjdk username yet, but I was told that it is not necessary since you are the author of the PR.

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

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

From cjplummer at openjdk.java.net  Mon May 10 23:22:55 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 10 May 2021 23:22:55 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v8]
In-Reply-To: <M_GTRn658iQn4GJNyOseAbH_EpnuZjmlzTSjY0iR-jk=.57daedb1-ccb3-4397-884c-855ffe20b86c@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <xZu6CoC0ZEYc3gFa7BHHCjnhZaMohpmpBcxm7t_Wu_E=.19e215c2-75aa-40ea-81da-38bdd2ffeb4a@github.com>
 <szNcoxOky13tYdPwhiVITp8pAc1ok8H-4TKrcD48LwY=.d77792fb-3ce6-4082-8abf-95f32b5c4ec7@github.com>
 <M_GTRn658iQn4GJNyOseAbH_EpnuZjmlzTSjY0iR-jk=.57daedb1-ccb3-4397-884c-855ffe20b86c@github.com>
Message-ID: <Sd_6MyrjO-dbHFKPyPYjzwbpLeRIdA3-e65ZnBS2fvk=.226a0dcc-5c4b-400b-98e0-4a7cef7d3e47@github.com>

On Fri, 7 May 2021 15:37:34 GMT, Lin Zang <lzang at openjdk.org> wrote:

> Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()` and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file.

I think that makes sense. Is this now fully implemented in this PR and it is ready for a final review?

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

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

From cjplummer at openjdk.java.net  Mon May 10 23:33:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 10 May 2021 23:33:08 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22]
In-Reply-To: <FEApmNXBv2avOTMxOmAGzZ02hT9AqwcSndvhr00yASk=.cfe79f07-f81c-4f5e-8581-7ac2281c28b5@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <FEApmNXBv2avOTMxOmAGzZ02hT9AqwcSndvhr00yASk=.cfe79f07-f81c-4f5e-8581-7ac2281c28b5@github.com>
Message-ID: <qVInCa4LG5a2cNWA5ZEy2HzJSJG6rATPJQ78Vb3wtwo=.87a41d1e-e8b5-462e-a743-59c3e0640126@github.com>

On Thu, 6 May 2021 08:45:45 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code refine and typo fix

I think you still need to undo the JMap.java changes since they are now being handled by #3598

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

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

From cjplummer at openjdk.java.net  Mon May 10 23:41:59 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 10 May 2021 23:41:59 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation [v3]
In-Reply-To: <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <r2jalKVG9y9IRS5EH6K9O5-gbPdtXrUXLwzI8uKzD1U=.6675eccf-7781-4ce2-bd39-4c754f27f4fd@github.com>
Message-ID: <xJ785ZawIL2HTYjUGqID8tnSK7En6vLNiYqv-Tgf54A=.e894ce52-3e03-4b57-b40f-28bba72ff60b@github.com>

On Sun, 2 May 2021 16:07:26 GMT, Mitsuru kariya <github.com+2217224+kariya-mitsuru at openjdk.org> wrote:

>> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
>> This PR changes to use `Long.hashCode` instead.
>
> Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some more SA's classes

Some of the more recently changed files need updates to the Oracle copyrights. WindbgAARCH64Thread.java is a bit different in that it currently only has a 2020 date. It should be changed to the following:

` * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.`

Note I'm only requesting updates to the Oracle copyrights.

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

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

From cjplummer at openjdk.java.net  Mon May 10 23:46:24 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 10 May 2021 23:46:24 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v8]
In-Reply-To: <o7rRABwbyNuvVM-gWDBteMIfOdei-4sRhsCoX-B9joI=.64f60d89-022d-4d24-b747-fd3c380a195f@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <o7rRABwbyNuvVM-gWDBteMIfOdei-4sRhsCoX-B9joI=.64f60d89-022d-4d24-b747-fd3c380a195f@github.com>
Message-ID: <ZZ9yYMghqQvWHYerG9loIxjF0mYT9VADQH_-Kr1vL8s=.79430e9e-6c54-4712-a704-4dfdb68dbbae@github.com>

On Mon, 26 Apr 2021 02:22:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine help message.

Marked as reviewed by cjplummer (Reviewer).

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Tue May 11 00:03:54 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 11 May 2021 00:03:54 GMT
Subject: RFR: 8266531: ZAddress::address() should be removed from SA
In-Reply-To: <zWaxT0z3NQRICv2UGjLMxheBNd-L9RCkgQ2S1TniC5E=.c1c80a80-014a-4982-9aa5-7e517d3f3019@github.com>
References: <zWaxT0z3NQRICv2UGjLMxheBNd-L9RCkgQ2S1TniC5E=.c1c80a80-014a-4982-9aa5-7e517d3f3019@github.com>
Message-ID: <GtcRMYqC6QDlNLToQUwS7B03bGwrmzflX6K6rmVOsis=.13f36ff8-36eb-47c4-a5f9-03e68086e0db@github.com>

On Wed, 5 May 2021 01:35:11 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `ZAddress::address()` has been removed since [JDK-8235748](https://bugs.openjdk.java.net/browse/JDK-8235748), however SA has not followed it. Thus some SA tests would fail with ZGC.
> After this change, more than half of jtreg tests which are listed in ProblemList-zgc.txt pass on Linux x64 with -vmoption:-XX:+UseZGC. Please see the change of ProblemList-zgc.txt what test can be resolved.

The changes look good. I think it would be best if the 2nd review came from the GC team.

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

Marked as reviewed by cjplummer (Reviewer).

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

From ysuenaga at openjdk.java.net  Tue May 11 00:07:56 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 11 May 2021 00:07:56 GMT
Subject: RFR: 8266531: ZAddress::address() should be removed from SA
In-Reply-To: <GtcRMYqC6QDlNLToQUwS7B03bGwrmzflX6K6rmVOsis=.13f36ff8-36eb-47c4-a5f9-03e68086e0db@github.com>
References: <zWaxT0z3NQRICv2UGjLMxheBNd-L9RCkgQ2S1TniC5E=.c1c80a80-014a-4982-9aa5-7e517d3f3019@github.com>
 <GtcRMYqC6QDlNLToQUwS7B03bGwrmzflX6K6rmVOsis=.13f36ff8-36eb-47c4-a5f9-03e68086e0db@github.com>
Message-ID: <5-R87iV_MuMbTLp1IlDDw9r0sR8bjgXEMpHAqYikXwg=.45d0e616-60d2-4251-a5ea-807ec3f0dd34@github.com>

On Tue, 11 May 2021 00:00:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The changes look good.

Thanks!

> I think it would be best if the 2nd review came from the GC team.

I think so too, I'm waiting for the review from GC folks.

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

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

From ysuenaga at openjdk.java.net  Tue May 11 00:15:21 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 11 May 2021 00:15:21 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2]
In-Reply-To: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
Message-ID: <noWAINrOl6Nx3Hb3pBPPYa9ZXtlx45ohzGkiJk4x6Ww=.eaf2cf80-c1f6-4364-a4e4-8d01bb31902c@github.com>

> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA remote object. It is "SARemoteDebugger" by default.
> 
> As a result, remote name will be constructed as following:
> 
> 
> //host[:port]/<serverNamePrefix>['_'<id>]
> 
> 
> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. And also we should add the way to specify the prefix when we connect to debug server. I will add it like `--connect id at server:1234/prefix`.
> 
> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.

Yasumasa Suenaga 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:

 - Update jhsdb man page
 - Merge remote-tracking branch 'upstream/master' into JDK-8263635
 - Update help message
 - 8263635: Add --prefix option to jhsdb debugd

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3669/files
  - new: https://git.openjdk.java.net/jdk/pull/3669/files/90a9d014..af154a77

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

  Stats: 512695 lines in 4306 files changed: 25267 ins; 478859 del; 8569 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3669.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3669/head:pull/3669

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

From ysuenaga at openjdk.java.net  Tue May 11 00:15:22 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 11 May 2021 00:15:22 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd
In-Reply-To: <v6W6uMkFnKkbd-9iNYGWPISooUVzdI9RSXM3huBWyUM=.a65982e4-363b-472c-9176-8486dc7bd6ba@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <v6W6uMkFnKkbd-9iNYGWPISooUVzdI9RSXM3huBWyUM=.a65982e4-363b-472c-9176-8486dc7bd6ba@github.com>
Message-ID: <WIj_FsgauQaHjCY4zSVBRo8Yj6hxVAsJ464vmiow49U=.fc5fd0d3-9bea-4fd9-8f92-746a60611efb@github.com>

On Wed, 5 May 2021 08:41:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA remote object. It is "SARemoteDebugger" by default.
>> 
>> As a result, remote name will be constructed as following:
>> 
>> 
>> //host[:port]/<serverNamePrefix>['_'<id>]
>> 
>> 
>> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. And also we should add the way to specify the prefix when we connect to debug server. I will add it like `--connect id at server:1234/prefix`.
>> 
>> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
>> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.
>
> I've looked at the CSR and added a comment with a question.

@sspitsyn Thanks for your comment!
I updated the CSR, and pushed new commits to follow it. Could you review again?

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

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

From cjplummer at openjdk.java.net  Tue May 11 00:55:09 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 11 May 2021 00:55:09 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2]
In-Reply-To: <noWAINrOl6Nx3Hb3pBPPYa9ZXtlx45ohzGkiJk4x6Ww=.eaf2cf80-c1f6-4364-a4e4-8d01bb31902c@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <noWAINrOl6Nx3Hb3pBPPYa9ZXtlx45ohzGkiJk4x6Ww=.eaf2cf80-c1f6-4364-a4e4-8d01bb31902c@github.com>
Message-ID: <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com>

On Tue, 11 May 2021 00:15:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA remote object. It is "SARemoteDebugger" by default.
>> 
>> As a result, remote name will be constructed as following:
>> 
>> 
>> //host[:port]/<serverNamePrefix>['_'<id>]
>> 
>> 
>> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. And also we should add the way to specify the prefix when we connect to debug server. I will add it like `--connect id at server:1234/prefix`.
>> 
>> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
>> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.
>
> Yasumasa Suenaga 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:
> 
>  - Update jhsdb man page
>  - Merge remote-tracking branch 'upstream/master' into JDK-8263635
>  - Update help message
>  - 8263635: Add --prefix option to jhsdb debugd

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 93:

> 91: 
> 92:     public static Remote lookup(String debugServerID) throws DebuggerException {
> 93:         // debugServerID follows the pattern [unique_id@]host[:port][/prefix]

It's a bit unclear to me why we need both a "unique_id" and a "prefix". I understand that the SA already append the two, and that previously the prefix was a constant, but I don't see why the user would ever need to set the "prefix" when they can always specify a "unique_id" that is truly unique. What is the use case for this?

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

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

From ysuenaga at openjdk.java.net  Tue May 11 01:36:58 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 11 May 2021 01:36:58 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2]
In-Reply-To: <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <noWAINrOl6Nx3Hb3pBPPYa9ZXtlx45ohzGkiJk4x6Ww=.eaf2cf80-c1f6-4364-a4e4-8d01bb31902c@github.com>
 <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com>
Message-ID: <iU84ArHG5BfpTsA9qXufnCU8y9rVIjflPMTYY5Ctqyk=.e1f1d3ef-e93d-46d1-9446-5ea468e4dfff@github.com>

On Tue, 11 May 2021 00:52:12 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga 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:
>> 
>>  - Update jhsdb man page
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8263635
>>  - Update help message
>>  - 8263635: Add --prefix option to jhsdb debugd
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 93:
> 
>> 91: 
>> 92:     public static Remote lookup(String debugServerID) throws DebuggerException {
>> 93:         // debugServerID follows the pattern [unique_id@]host[:port][/prefix]
> 
> It's a bit unclear to me why we need both a "unique_id" and a "prefix". I understand that the SA already append the two, and that previously the prefix was a constant, but I don't see why the user would ever need to set the "prefix" when they can always specify a "unique_id" that is truly unique. What is the use case for this?

"prefix" is similar to "unique_id" as you said, but it is useful to group debugees.

For example, the host runs 2 container pods as following:

* Pod A
    * Container 1
    * Container 2
    * Container 3
* Pod B
    * Container 1
    * Container 2
    * Container 3

If we want to compare 2 pods with jhsdb, we can set ID like "A-1", "B-1".
However, if the prefix is supported on jhsdb, we can set ID and prefix like "1 at localhost/A", "1 at localhost/B". I think it is easy to understand.

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

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

From david.holmes at oracle.com  Tue May 11 01:55:58 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 May 2021 11:55:58 +1000
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <wGuqyHU3dhONZD-0jCs3eBvrtpC5SduvoXAAjthK3gQ=.5a6f7543-8e13-42ca-9469-b990ec004b4e@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <wGuqyHU3dhONZD-0jCs3eBvrtpC5SduvoXAAjthK3gQ=.5a6f7543-8e13-42ca-9469-b990ec004b4e@github.com>
Message-ID: <c8dbf267-d635-0846-e905-fa06e2cebd15@oracle.com>

On 11/05/2021 9:14 am, Serguei Spitsyn wrote:
> On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
> David,
> This looks pretty good. At least, I do not see real problems.
> It is really nice to make it more consistent.
> Thanks,
> Serguei

Thanks for the review Serguei!

David

> -------------
> 
> Marked as reviewed by sspitsyn (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/3877
> 

From dholmes at openjdk.java.net  Tue May 11 01:56:21 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 11 May 2021 01:56:21 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v2]
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

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

  Review feedback from Serguei

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3877/files
  - new: https://git.openjdk.java.net/jdk/pull/3877/files/3b74085a..b08c19cb

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

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

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

From david.holmes at oracle.com  Tue May 11 01:58:27 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 May 2021 11:58:27 +1000
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments
In-Reply-To: <wwW7kOkv6b7e9WIloNu1rWlOBsz3x-3db9YQQIDU7Ug=.704f8374-7f20-4a52-9306-ea823775c8a2@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <wwW7kOkv6b7e9WIloNu1rWlOBsz3x-3db9YQQIDU7Ug=.704f8374-7f20-4a52-9306-ea823775c8a2@github.com>
Message-ID: <49ecd1f6-fdde-99eb-ea7f-82240615b68f@oracle.com>

On 11/05/2021 9:00 am, Serguei Spitsyn wrote:
> On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
> src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp line 108:
> 
>> 106:
>> 107: // caller needs ResourceMark
>> 108: const char* get_java_thread_name(const JavaThread* t) {
> 
> Nit: Better to rename it: t => jt

Changed.

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3877
> 

From lzang at openjdk.java.net  Tue May 11 03:19:05 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 11 May 2021 03:19:05 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v23]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <BYpxDQpMHSZ7DUggko-Y8HbDMYSa9DCoeMSyXaHb0n4=.dd5065b9-7141-4a4f-9c17-f4b38334bfe3@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - Merge branch 'master' into par-dump
 - undo JMap.java
 - code refine and typo fix
 - Merge branch 'master' into par-dump
 - refine with several fix
 - Merge branch 'master' into par-dump
 - Merge branch 'master' into par-dump
 - Typo fix
 - remove parallel option and dumpheapext command
 - Revert "hide the dumpheapext error message"
   
   This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4.
 - ... and 20 more: https://git.openjdk.java.net/jdk/compare/9713152e...5c0863ad

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

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=22
  Stats: 840 lines in 5 files changed: 653 ins; 61 del; 126 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

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

From lzang at openjdk.java.net  Tue May 11 03:26:07 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 11 May 2021 03:26:07 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22]
In-Reply-To: <qVInCa4LG5a2cNWA5ZEy2HzJSJG6rATPJQ78Vb3wtwo=.87a41d1e-e8b5-462e-a743-59c3e0640126@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <FEApmNXBv2avOTMxOmAGzZ02hT9AqwcSndvhr00yASk=.cfe79f07-f81c-4f5e-8581-7ac2281c28b5@github.com>
 <qVInCa4LG5a2cNWA5ZEy2HzJSJG6rATPJQ78Vb3wtwo=.87a41d1e-e8b5-462e-a743-59c3e0640126@github.com>
Message-ID: <Hbvtzxr_K1Q1-Cq_g_48gcueWsCtrol0jqi_92kQF78=.0ad21732-1851-44ae-b49e-7d8e0d35025d@github.com>

On Mon, 10 May 2021 23:29:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code refine and typo fix
>
> I think you still need to undo the JMap.java changes since they are now being handled by #3598

Hi @plummercj ,
Thanks for your patience reviewing it over and over again! I have undo the JMap.java and sync with latest master.

BRs,
LIn

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

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

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Tue May 11 06:35:43 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya)
Date: Tue, 11 May 2021 06:35:43 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation [v4]
In-Reply-To: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
Message-ID: <gcZNzL97V9ENQzFqo9gVTn9KkaId0eKSeVlOpGRgHqE=.bfe39e40-657e-4701-91ff-4f5862e8bf2d@github.com>

> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
> This PR changes to use `Long.hashCode` instead.

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

  Update copyright

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3522/files
  - new: https://git.openjdk.java.net/jdk/pull/3522/files/ac5c2660..71b663cd

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

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

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

From stefank at openjdk.java.net  Tue May 11 06:37:52 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 11 May 2021 06:37:52 GMT
Subject: RFR: 8266531: ZAddress::address() should be removed from SA
In-Reply-To: <zWaxT0z3NQRICv2UGjLMxheBNd-L9RCkgQ2S1TniC5E=.c1c80a80-014a-4982-9aa5-7e517d3f3019@github.com>
References: <zWaxT0z3NQRICv2UGjLMxheBNd-L9RCkgQ2S1TniC5E=.c1c80a80-014a-4982-9aa5-7e517d3f3019@github.com>
Message-ID: <QaZ_-9wctNT7lSI9l6lm7T7FVmBwOESba7xcnpmKxFQ=.f6a88b0b-5dee-4ac7-a1a1-ba36da2f3149@github.com>

On Wed, 5 May 2021 01:35:11 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `ZAddress::address()` has been removed since [JDK-8235748](https://bugs.openjdk.java.net/browse/JDK-8235748), however SA has not followed it. Thus some SA tests would fail with ZGC.
> After this change, more than half of jtreg tests which are listed in ProblemList-zgc.txt pass on Linux x64 with -vmoption:-XX:+UseZGC. Please see the change of ProblemList-zgc.txt what test can be resolved.

The HotSpot changes look good.

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

Marked as reviewed by stefank (Reviewer).

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

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Tue May 11 07:09:54 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya)
Date: Tue, 11 May 2021 07:09:54 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation
In-Reply-To: <TaUUKhD_I1JPkWNKPIouE6qBe-i929_zCPd-HFxoMSM=.5cca0e92-38a7-47be-b75c-701787948e9f@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <eguMK8JZKgHR3CYWJu5IqqSBWLwDGvDGEgZI7dOD3FQ=.e757c490-b4a6-47a2-91fe-03b663b2854a@github.com>
 <qr9EcwZiiCQXNe3qfbSFTrrta34O4UUEvqESc2iWysQ=.cbdf6860-8647-4020-b225-aa164bf92444@github.com>
 <TaUUKhD_I1JPkWNKPIouE6qBe-i929_zCPd-HFxoMSM=.5cca0e92-38a7-47be-b75c-701787948e9f@github.com>
Message-ID: <vPz6dzb_I_Qwp29oDDbZLhv7E9tT1cQ_EJsmNjX6QOA=.043613cc-f84f-47e1-8284-5b060395d158@github.com>

On Mon, 10 May 2021 23:15:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I don't think you need to.

Sure.


> Some of the more recently changed files need updates to the Oracle copyrights.

I'm sorry for the stupid mistake.
I just updated the copyright.


> Note I'm only requesting updates to the Oracle copyrights.

I made no change to ShenandoahHeapRegion.java since it has no Oracle copyright line.
If the line need to be added, could you please let me know?

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

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

From lzang at openjdk.java.net  Tue May 11 08:35:37 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 11 May 2021 08:35:37 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v8]
In-Reply-To: <Sd_6MyrjO-dbHFKPyPYjzwbpLeRIdA3-e65ZnBS2fvk=.226a0dcc-5c4b-400b-98e0-4a7cef7d3e47@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <xZu6CoC0ZEYc3gFa7BHHCjnhZaMohpmpBcxm7t_Wu_E=.19e215c2-75aa-40ea-81da-38bdd2ffeb4a@github.com>
 <szNcoxOky13tYdPwhiVITp8pAc1ok8H-4TKrcD48LwY=.d77792fb-3ce6-4082-8abf-95f32b5c4ec7@github.com>
 <M_GTRn658iQn4GJNyOseAbH_EpnuZjmlzTSjY0iR-jk=.57daedb1-ccb3-4397-884c-855ffe20b86c@github.com>
 <Sd_6MyrjO-dbHFKPyPYjzwbpLeRIdA3-e65ZnBS2fvk=.226a0dcc-5c4b-400b-98e0-4a7cef7d3e47@github.com>
Message-ID: <5vKXRileYX5AYzaEn2RoG0ZATMI14tov2QkdufS12Do=.b1fc3088-d00b-4ac5-85ad-00c812448d79@github.com>

On Mon, 10 May 2021 23:19:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi Chris (@plummercj )
>> 
>> After several tries, I think maybe the current patch is the better way to fix this issue. 
>> For detail, there are three issues that cause the problem. 
>> - The incorrect calculated array length when segmented heap dump is enabled, it can be fixed easily by modifying code in method `calculateArrayMaxLength()`. It is already in this PR.
>> - The internal segment buffer used for segmented heap dump. Plus the resize of this buffer can cause memory consumption by doing byte[] copy. 
>> - Also because the internal segment buffer is byte array, there is a limitation that the buffer length can not be larger than Integer.MAX_VALUE, which also cause the problem when dumping large array, as there can be integer overflow and also not align with the specification (as explained blow)
>> 
>> Here are the possible solutions I have tried to avoid using `unbufferedMode`:
>> 
>> - For segment heap dump, add limitation in `calculateArrayMaxLength()` to guarantee at most `Interger.MAX_VALUE` bytes can be filled into the internal byte array buffer. So there is no need to use unbufferedMode. But I found it can cause large memory usage with internal buffer resize to hold all array data, and also there is OOM thrown when I use `jhsdb jmap --binaryheap` command. Moreover it also changes the behavior of dumping large array:  The original limitation is  MAX_U4_VALUE, which follows the hprof spec that a segment in heap dump has a 32bit slot to hold the segment size.  But after the change , it becomes to `Integer.MAX_VALUE`, which is 2^31-1, just the half of MAX_U4_VALUE, the behavior doesn't follow the spec exactly. 
>> The change also introduce lots of overflow check when size of internal segment buffer is used, which IMHO is not clean.
>> 
>> - I also tried to avoid resize of internal segment buffer by using a linked list to hold all data to be flushed, this can avoid the overflow check. But it also cause OOM since the whole data are hold in the list. And it also introduce more codes for the linked list logic.
>> 
>> And the main reason for caching data in internal segment buffer is that the current implentation needs to update the `size slot` in the segment header, which must be done before the whole data flushed to file, otherwise it would cause problems when gzip heap dump is used. 
>> 
>> The way to avoid caching is to calculate the object size previously and then update the size slot at begining. But it would cause other changes in the code, which IMO is not suitable to introduce in this PR. That is why I mentioned to re-write the implementation of `HeapHprofBinWriter.java` in previous comments.
>> 
>> Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()`  and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file.
>> 
>> What do you think?
>> 
>> Thanks,
>> Lin
>
>> Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()` and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file.
> 
> I think that makes sense. Is this now fully implemented in this PR and it is ready for a final review?

Hi @plummercj, 
I think it is now ready for final review. Thanks a lot!
-Lin

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

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

From lzang at openjdk.java.net  Tue May 11 08:35:36 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 11 May 2021 08:35:36 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v9]
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <36Z_jPBtZtFp33jBw41uFpVJFFDb-b8sLts_uvWtbLg=.8d9ad6ee-38a9-4544-a3c2-ae1064a0264d@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

Lin Zang 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:

 - fix typo in comments
 - Merge branch 'master' into s-fix
 - Merge branch 'master'
 - Merge branch 'master' into sf
 - rename writeThrough to unbufferedMode and code refine
 - fix typo in comments
 - Merge branch 'master' into sf
 - Revert "reduce memory consumption"
   
   This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e.
 - reduce memory consumption
 - code refine
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/0504cf2b...67f6d985

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/70dbbfea..67f6d985

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=07-08

  Stats: 597367 lines in 5749 files changed: 64391 ins; 518662 del; 14314 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

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

From rehn at openjdk.java.net  Tue May 11 12:13:33 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 11 May 2021 12:13:33 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2]
In-Reply-To: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
Message-ID: <lbaH3ck6InZu4fukbaTHqWxCDMMOGU58P2hMEo3EEqA=.8acc2813-c146-4d05-84fd-fd5b02b2c5ab@github.com>

> Please consider this change which removes the manual transitions to blocked.
> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
> 
> The object monitor code could be straight forward changed to use this instead of manual transitions.
> 
> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
> That made it possible to careful use ThreadInVMfromNative in raw monitors.
> 
> I also remove the early CAS in raw_enter.
> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
> 
> Passes t1-t7 and manual stressing relevant test groups.

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

 - Merge branch 'master' into 8265753
 - Removed manual transitions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3875/files
  - new: https://git.openjdk.java.net/jdk/pull/3875/files/e16e2c30..07ddf393

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

  Stats: 15745 lines in 431 files changed: 9555 ins; 3584 del; 2606 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875

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

From hseigel at openjdk.java.net  Tue May 11 12:58:07 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 12:58:07 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
Message-ID: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>

Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.

This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.

Thanks, Harold

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

Commit messages:
 - 8243287: Removal of Unsafe::defineAnonymousClass

Changes: https://git.openjdk.java.net/jdk/pull/3974/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
  Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974

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

From brian.goetz at oracle.com  Tue May 11 13:20:27 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 11 May 2021 13:20:27 +0000
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>

There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?

Sent from my iPad

> On May 11, 2021, at 8:59 AM, Harold Seigel <hseigel at openjdk.java.net> wrote:
> 
> ?Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold
> 
> -------------
> 
> Commit messages:
> - 8243287: Removal of Unsafe::defineAnonymousClass
> 
> Changes: https://git.openjdk.java.net/jdk/pull/3974/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
>  Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974
> 
> PR: https://git.openjdk.java.net/jdk/pull/3974

From alanb at openjdk.java.net  Tue May 11 13:40:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 11 May 2021 13:40:54 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <jv8lcM9GVgefV6lzgRdh-bIQrxN91pkOusleqo2JdpM=.08f401a7-96cd-4ffd-9d92-acb7c740b65d@github.com>

On Tue, 11 May 2021 12:50:31 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

test/jdk/java/lang/Class/GetModuleTest.java line 42:

> 40: import static org.testng.Assert.*;
> 41: 
> 42: public class GetModuleTest {

testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal.

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

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

From alanb at openjdk.java.net  Tue May 11 13:45:01 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 11 May 2021 13:45:01 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <jv8lcM9GVgefV6lzgRdh-bIQrxN91pkOusleqo2JdpM=.08f401a7-96cd-4ffd-9d92-acb7c740b65d@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <jv8lcM9GVgefV6lzgRdh-bIQrxN91pkOusleqo2JdpM=.08f401a7-96cd-4ffd-9d92-acb7c740b65d@github.com>
Message-ID: <B6FMrKGRolpl0SMX867JWddnPwqK5_ixIOBg3zr6Og0=.50b0e57d-d8e9-427b-afc3-311bb080afc9@github.com>

On Tue, 11 May 2021 13:37:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> test/jdk/java/lang/Class/GetModuleTest.java line 42:
> 
>> 40: import static org.testng.Assert.*;
>> 41: 
>> 42: public class GetModuleTest {
> 
> testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal.

Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk.

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

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

From hseigel at openjdk.java.net  Tue May 11 14:10:42 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 14:10:42 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v2]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <LbwuOkUqTA3ZEXoxdHChL_TtrtrlnYOPpgOY_0-4Sjg=.29528c34-6554-4452-82c1-c636c677e4be@github.com>

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

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

  test fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/233a4725..35c6634c

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

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

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

From hseigel at openjdk.java.net  Tue May 11 14:13:49 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 14:13:49 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

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

  fix GetModuleTest.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/35c6634c..874a1603

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

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

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

From hseigel at openjdk.java.net  Tue May 11 14:13:51 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 11 May 2021 14:13:51 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <B6FMrKGRolpl0SMX867JWddnPwqK5_ixIOBg3zr6Og0=.50b0e57d-d8e9-427b-afc3-311bb080afc9@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <jv8lcM9GVgefV6lzgRdh-bIQrxN91pkOusleqo2JdpM=.08f401a7-96cd-4ffd-9d92-acb7c740b65d@github.com>
 <B6FMrKGRolpl0SMX867JWddnPwqK5_ixIOBg3zr6Og0=.50b0e57d-d8e9-427b-afc3-311bb080afc9@github.com>
Message-ID: <D3MaVYi6Rdq6cEhXousz4fIcsEZsYj7D-MJyxP7dqKs=.221945b9-53c8-4339-9f6e-ec36dc625abe@github.com>

On Tue, 11 May 2021 13:41:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/Class/GetModuleTest.java line 42:
>> 
>>> 40: import static org.testng.Assert.*;
>>> 41: 
>>> 42: public class GetModuleTest {
>> 
>> testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal.
>
> Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk.

Hi Alan,
Thanks for find this.  I removed the unneeded imports and @modules from GetModulesTest.java and updated the comment in ClassAttributesTest.java.
Thanks, Harold

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

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

From harold.seigel at oracle.com  Tue May 11 14:15:10 2021
From: harold.seigel at oracle.com (Harold Seigel)
Date: Tue, 11 May 2021 10:15:10 -0400
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
Message-ID: <8013d5ad-b06f-29c1-9287-e3408ec86413@oracle.com>

Hi Brian,

Thanks for looking at this.

The JDK no longer creates unsafe anon classes.? So, those tests could 
only find an unsafe anonymous class if they explicitly created one.? In 
which case, the tests would need to call Unsafe.defineAnonymousClass().? 
And, hopefully, those tests have been handled in this webrev.

If there are dead tests then they probably died when the JDK stopped 
creating unsafe anon classes.? Note that none of them showed up as 
failures during regression testing.

Harold

On 5/11/2021 9:20 AM, Brian Goetz wrote:
> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>
> Sent from my iPad
>
>> On May 11, 2021, at 8:59 AM, Harold Seigel <hseigel at openjdk.java.net> wrote:
>>
>> ?Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>
>> Thanks, Harold
>>
>> -------------
>>
>> Commit messages:
>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/3974/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3974

From github.com+7947546+tanghaoth90 at openjdk.java.net  Tue May 11 14:57:32 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Tue, 11 May 2021 14:57:32 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v2]
In-Reply-To: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
Message-ID: <9VBZqwiHrAzT_UHPsv2gIiGsSq9csV8cFOfjmgmhEwg=.50ae512b-5705-4c63-85ea-01f861e78024@github.com>

> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
> 
> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".

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

  cpu.shares for OperatingSystemImpl.getCpuLoad()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3656/files
  - new: https://git.openjdk.java.net/jdk/pull/3656/files/b052b624..81867f21

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

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

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

From github.com+7947546+tanghaoth90 at openjdk.java.net  Tue May 11 15:52:01 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Tue, 11 May 2021 15:52:01 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v2]
In-Reply-To: <HCdl5UDmZqeuYMbB8cnr0qesiFw1x-NH6F5tbrI0eMs=.c5ed84c9-9f23-4890-a0b5-ddb5c323a931@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
 <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>
 <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>
 <HCdl5UDmZqeuYMbB8cnr0qesiFw1x-NH6F5tbrI0eMs=.c5ed84c9-9f23-4890-a0b5-ddb5c323a931@github.com>
Message-ID: <GfXN3AoHt5Yi55L5vVJWEGV5lUZeUO62foe5zn_B234=.522648e8-0c17-4263-92e3-be575260e1d1@github.com>

On Thu, 6 May 2021 02:34:01 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.
>
>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.
> 
> Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation.
> 
> We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways.
> 1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` &  `share`);
> 2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number.
> 
> Looking forward to your suggestion.

> @tanghaoth90 My local testing suggests that your fix addresses the issue of CPU quotas set via `--cpu-quota/--cpu-period`. When using `--cpu-shares` the CPU load calculation is wrong since it will (wrongly) report host values. Lets look at them individually, fix the quota and shares case individually (i.e. when not both are set). Once that's done, quota will be preferred in the OperatingSystemMXBean impl, which is reasonable. I don't think we need to account for the shares-preferred-over-quota at this point since that changed in HotSpot in JDK 11 time-frame (JDK-8197589) and OperatingSystemMXBean has only been made container aware in JDK 14 (yes, it got backported, but still).

@jerboaa I have updated my fix by inserting a new branch for `--cpu-shares`. By setting up containers with different restrictions based on your suggestion, I noticed two problems for the CPU load calculation. Take [TestLoad.java](https://bugs.openjdk.java.net/secure/attachment/94530/TestLoad.java) as the example.

1. `--cpu-quota=700000 --cpu-period=100000` as the restriction: the result is getting close to `6/7` slowly as time goes by, which indicates that the result of 

long usageNanos = containerMetrics.getCpuUsage();

is an accumulated CPU usage rather than a real-time CPU usage.
According to the javadoc, `getCpuLoad()` _returns the "recent cpu usage"_. The current fix obviously does not address this issue.

2. `--cpu-shares=2048` as the restriction: the "cpu-share" branch only returns `-1` since `containerMetrics.getCpuNumPeriods()` returns `0` (`nr_periods` of `cpu.stat` stays `0` when only `--cpu-shares` is set). By now, I have no idea to compute the elapsed time or the total available CPU time with the help of the methods of `jdk.internal.platform.CgroupMetrics`.

Any suggestion is appreciated. @jerboaa @argha-c

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

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

From iklam at openjdk.java.net  Tue May 11 17:12:23 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 11 May 2021 17:12:23 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: <sJyvFHU5KhmFEbzS8UO7tPFY0Koxct_h6PUKvx38hqg=.0de94f46-7bf2-4500-8a26-30fdc83a8cc8@github.com>

On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

The CDS VM and test changes look OK to me.

src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 65:

> 63:         // so when handling the java mirror for the class we need to make sure its class
> 64:         // loader data is claimed, this is done by calling do_cld explicitly.
> 65:         // For non-string hidden classes the call to do_cld is made when the class

Typo: non-strong

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

Marked as reviewed by iklam (Reviewer).

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

From dcubed at openjdk.java.net  Tue May 11 19:12:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 11 May 2021 19:12:01 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2]
In-Reply-To: <lbaH3ck6InZu4fukbaTHqWxCDMMOGU58P2hMEo3EEqA=.8acc2813-c146-4d05-84fd-fd5b02b2c5ab@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <lbaH3ck6InZu4fukbaTHqWxCDMMOGU58P2hMEo3EEqA=.8acc2813-c146-4d05-84fd-fd5b02b2c5ab@github.com>
Message-ID: <JfNNkm0845PZujgZ94Bh5UuwQ0ztgO1GUQeFYDmZeQk=.15459b66-f979-49db-b83f-b297f1bab78d@github.com>

On Tue, 11 May 2021 12:13:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8265753
>  - Removed manual transitions

Thumbs up on the over all logic. I only have minor nits and suggestions.

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 242:

> 240:   if (self->is_Java_thread()) {
> 241:     JavaThread* jt = self->as_Java_thread();
> 242:     guarantee(jt->thread_state() == _thread_in_native, "invariant");

Thanks for making this a guarantee()!

There is an existing assert() about this in:
ThreadInVMfromNative -> trans() -> transition_from_native()
so it doesn't have to be there for forever.

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 320:

> 318: // JavaThreads will enter here with state _thread_in_native.
> 319: void JvmtiRawMonitor::raw_enter(Thread* self) {
> 320:   // TODO Atomic::load on _owner field

Why is this still a TODO?

src/hotspot/share/prims/jvmtiRawMonitor.hpp line 42:

> 40: // Important note:
> 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM
> 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint

nit typo: s/e.g./e.g.,/
nit typo: s/tranisition/transition/

src/hotspot/share/prims/jvmtiRawMonitor.hpp line 43:

> 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM
> 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint
> 43: // poll in many cases, else the agent JavaThread can deadlock with VM thread,

nit typo: s/VM thread/the VM thread/

src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48:

> 46: // The rules are:
> 47: // - We must never safepoint poll if raw monitor is owned.
> 48: // - We may safepoint poll before it is owned and after it have been released.

nit typo: s/have been/has been/

src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52:

> 50: // native for all operations. However we need to honor suspend request, not
> 51: // entering a monitor if suspended, and check for interrupts. Honoring suspened
> 52: // and reading interrupt flag must be done from VM state (a safepoint unsafe

nit typo: s/suspend request/a suspend request/
nit typo: s/Honoring suspened/Honoring a suspend request/
nit typo: s/interrupt flag/the interrupt flag/
(You'll probably want to reformat the changed lines a bit.)

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 206:

> 204:   ~ThreadInVMfromNative() {
> 205:     assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition");
> 206:     _thread->set_thread_state(_thread_in_native);

You're losing the assertion that we're transitioning from
`_thread_in_vm` to `_thread_in_native` here. Although,
the constructor did verify that we were in `_thread_in_native`
when we transitioned to `_thread_in_vm` so at least the
first half is still verified.

Can you an assertion that we're in `_thread_in_vm` here?

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 230:

> 228: };
> 229: 
> 230: template <typename PRE_PROC>

When you mentioned doing this with templates, I was having
nightmares, but this one is not bad at all...

src/hotspot/share/runtime/objectMonitor.cpp line 313:

> 311:   if (current->is_suspended()) {
> 312:     _om->_recursions = 0;
> 313:     _om->_succ = NULL;

Please add a comment after this line:
// Don't need a full fence after clearing successor here because of the call to exit().

src/hotspot/share/runtime/objectMonitor.cpp line 325:

> 323:       OrderAccess::fence(); // always do a full fence when successor is cleared
> 324:     }
> 325:     _om_exit = true;

Hmmm... `_om_exit` flag is misnamed here since you're "only" clearing the successor.

Update: Now I see that the ClearSuccOnSuspend class is subclassed from
the ExitOnSuspend, but I still find that flag a bit confusing.

src/hotspot/share/runtime/objectMonitor.hpp line 309:

> 307:    protected:
> 308:     ObjectMonitor* _om;
> 309:     bool _om_exit;

Instead of `_om_exit` maybe this should be more generic?
Perhaps `_om_op_done` or something like that?

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

Marked as reviewed by dcubed (Reviewer).

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

From cjplummer at openjdk.java.net  Tue May 11 19:31:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 11 May 2021 19:31:56 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation [v4]
In-Reply-To: <gcZNzL97V9ENQzFqo9gVTn9KkaId0eKSeVlOpGRgHqE=.bfe39e40-657e-4701-91ff-4f5862e8bf2d@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <gcZNzL97V9ENQzFqo9gVTn9KkaId0eKSeVlOpGRgHqE=.bfe39e40-657e-4701-91ff-4f5862e8bf2d@github.com>
Message-ID: <JETNbt8T2DiEobQ99S3SHukIZgxseAIv2rDfbny9cx0=.57b433e6-3c4b-4311-814f-edcbe4b5dbf4@github.com>

On Tue, 11 May 2021 06:35:43 GMT, Mitsuru kariya <github.com+2217224+kariya-mitsuru at openjdk.org> wrote:

>> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
>> This PR changes to use `Long.hashCode` instead.
>
> Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

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

From cjplummer at openjdk.java.net  Tue May 11 19:38:04 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 11 May 2021 19:38:04 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v23]
In-Reply-To: <BYpxDQpMHSZ7DUggko-Y8HbDMYSa9DCoeMSyXaHb0n4=.dd5065b9-7141-4a4f-9c17-f4b38334bfe3@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <BYpxDQpMHSZ7DUggko-Y8HbDMYSa9DCoeMSyXaHb0n4=.dd5065b9-7141-4a4f-9c17-f4b38334bfe3@github.com>
Message-ID: <2T6LlZ9PbwPuy5f1_WfMmboNDcHimJ2-dhPvRMH_qlw=.107aa7b8-5d03-47b0-9687-e307f90d30d5@github.com>

On Tue, 11 May 2021 03:19:05 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - Merge branch 'master' into par-dump
>  - undo JMap.java
>  - code refine and typo fix
>  - Merge branch 'master' into par-dump
>  - refine with several fix
>  - Merge branch 'master' into par-dump
>  - Merge branch 'master' into par-dump
>  - Typo fix
>  - remove parallel option and dumpheapext command
>  - Revert "hide the dumpheapext error message"
>    
>    This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4.
>  - ... and 20 more: https://git.openjdk.java.net/jdk/compare/9713152e...5c0863ad

heapDumper.hpp needs a copyright update. Otherwise the changes look good.

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

Changes requested by cjplummer (Reviewer).

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

From sspitsyn at openjdk.java.net  Tue May 11 20:27:54 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 11 May 2021 20:27:54 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v2]
In-Reply-To: <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
Message-ID: <KDMGAil9kPgYeIGnOeXvG-t_4d7NW2ijw8D-0-I6PrM=.6794313e-501e-408f-80c0-a2ed92e1c3c2@github.com>

On Tue, 11 May 2021 01:56:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t
 hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
>> 
>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
>> - Manifestations of Thread::current() become JavaThread::current()
>> - THREAD->as_Java_thread() becomes just THREAD
>> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
>> 
>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
>> 
>> Testing:
>>  - tiers 1-8 on Linux-x64
>>  - all builds in tiers 1-4
>>  - tiers 1-3 on all platforms
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback from Serguei

Marked as reviewed by sspitsyn (Reviewer).

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

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

From mchung at openjdk.java.net  Tue May 11 20:52:59 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 11 May 2021 20:52:59 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com>

On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java line 53:

> 51:             return simpleName;
> 52:         }
> 53:         // Must be a local class

This file should not be changed.  It refers to the Java language anonymous class (not VM anonymous class).

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

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

From sspitsyn at openjdk.java.net  Tue May 11 21:03:56 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 11 May 2021 21:03:56 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v8]
In-Reply-To: <o7rRABwbyNuvVM-gWDBteMIfOdei-4sRhsCoX-B9joI=.64f60d89-022d-4d24-b747-fd3c380a195f@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <o7rRABwbyNuvVM-gWDBteMIfOdei-4sRhsCoX-B9joI=.64f60d89-022d-4d24-b747-fd3c380a195f@github.com>
Message-ID: <Y0ROoXk8ukvMxHzmU3qPhM9LbUF8tkJZPmfmVe7jTQY=.b2e393ad-0ece-41bd-964a-be9f5399d89d@github.com>

On Mon, 26 Apr 2021 02:22:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine help message.

The fix looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From prappo at openjdk.java.net  Tue May 11 22:57:24 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 11 May 2021 22:57:24 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap [v3]
In-Reply-To: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
Message-ID: <-vEUXKnK4Hx08RxoJZ6znhlblhrIgoslG7odDTh27Ns=.7eb65699-6068-4f09-8d14-5a9455b5a854@github.com>

> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.
> 
> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:
> 
> 1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`

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

  Reverted a previously fixed typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3885/files
  - new: https://git.openjdk.java.net/jdk/pull/3885/files/6eea552e..c8d2c04f

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

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

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

From prappo at openjdk.java.net  Tue May 11 23:00:55 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 11 May 2021 23:00:55 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap [v2]
In-Reply-To: <ErLYQE_w8pmCYf7offOx0TNxqqHkmClq-KbBiMfahtk=.f748d752-a47a-455a-bcfe-19478ac4723b@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
 <Lgl_vpHS83eytvWnxz91-wCg_Uh_JyfI4-K_uoF17os=.3375f1b0-097b-48b6-aa73-573ad2d3d6b8@github.com>
 <ErLYQE_w8pmCYf7offOx0TNxqqHkmClq-KbBiMfahtk=.f748d752-a47a-455a-bcfe-19478ac4723b@github.com>
Message-ID: <70URtsH2FCbxLxOfDCVPGXgZN3bMWvC2jeE7AnI6Y3E=.63c0df50-f199-43b2-b36d-29152be9e7c1@github.com>

On Wed, 5 May 2021 19:22:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed more typos
>
> src/jdk.management.agent/share/classes/sun/management/jmxremote/ConnectorBootstrap.java line 308:
> 
>> 306:       public static synchronized JMXConnectorServer initialize() {
>> 307: 
>> 308:          // Load new management properties
> 
> Debatable. I guess what was meant here is:
> 
> // Loads a new management Properties instance
> 
> Or maybe a better comment text would be:
> 
> Load and snapshot management properties
> 
> Otherwise LGTM.

I've reverted that particular line.

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

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

From dcubed at openjdk.java.net  Tue May 11 23:24:53 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 11 May 2021 23:24:53 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v4]
In-Reply-To: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com>
Message-ID: <BEJUTyIPOLXDHUUvBxJNAQT4j0PF8n69-ZxWbt3Nh-I=.07d3a9b4-d4d0-437a-bf4d-7caa947624fe@github.com>

On Wed, 28 Apr 2021 13:03:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary "@library /test/lib".
>
> HI Dan,
> 
> Some minor comments, but to be frank I have no idea what this test is actually doing - sorry.
> 
> Cheers,
> David

@dholmes-ora - Sorry I missed this comment:

> Some minor comments, but to be frank I have no idea what this test is actually doing - sorry.

This test stresses getThreadInfo() and ThreadInfo.getLockOwnerName() as a
JavaThread is exiting. Similar to other stress tests that I wrote for M&M in the
Thread-SMR project, but this one is targeting getting the lock owner name as
the lock owner thread is exiting.

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

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

From dcubed at openjdk.java.net  Tue May 11 23:28:53 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 11 May 2021 23:28:53 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v4]
In-Reply-To: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com>
Message-ID: <7n0D4JR-B2bxToSWtJ361mu3b_xT5Zfmo9JDsmRISao=.4b15a470-2dd3-460b-884b-3e16925acb87@github.com>

On Wed, 28 Apr 2021 13:03:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary "@library /test/lib".
>
> HI Dan,
> 
> Some minor comments, but to be frank I have no idea what this test is actually doing - sorry.
> 
> Cheers,
> David

@dholmes-ora also sent the comment in email but it didn't seem to
show up in this PR:

> Hmmm... this is a legacy style/approach that is not necessary any more.
> If the test fails it should throw an exception from the main thread and
> that will produce a non-zero exit value. I think seeing this legacy style in
> new tests will just confuse people. 

I agree. In particular this legacy style approach with exit_delta == 95 is
for VMTestbase tests and this new test is not part of the VMTestbase
test suite. I'm fixing this.

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

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

From dcubed at openjdk.java.net  Tue May 11 23:34:29 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 11 May 2021 23:34:29 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5]
In-Reply-To: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
Message-ID: <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>

> The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
> 
> Currently running the new test thru Mach5 Tier[1-7].
> I've run the test thru several 12 hour runs on my MBP13 and
> on my Linux-X64 server.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Drop exit_delta and the VMTestbase style of exiting on test failure.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3478/files
  - new: https://git.openjdk.java.net/jdk/pull/3478/files/bac63a79..771dafee

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

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

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

From sspitsyn at openjdk.java.net  Wed May 12 00:46:55 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 12 May 2021 00:46:55 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap [v3]
In-Reply-To: <-vEUXKnK4Hx08RxoJZ6znhlblhrIgoslG7odDTh27Ns=.7eb65699-6068-4f09-8d14-5a9455b5a854@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
 <-vEUXKnK4Hx08RxoJZ6znhlblhrIgoslG7odDTh27Ns=.7eb65699-6068-4f09-8d14-5a9455b5a854@github.com>
Message-ID: <QllQj153tfGKXjv68Eb396T0ZEbQXfMqfQEvIowOXiE=.41476607-1003-4d61-a6b4-6c46d6b2058e@github.com>

On Tue, 11 May 2021 22:57:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.
>> 
>> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:
>> 
>> 1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
>> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted a previously fixed typo

Hi Pavel,
 It looks good.
 Just one nit is to add a dot at the end of this comment:
 280    // time. It's OK for now as logic in Agent.java forbids multiple agents
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From mli at openjdk.java.net  Wed May 12 01:21:01 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 12 May 2021 01:21:01 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v7]
In-Reply-To: <xya5pLw2y95h8H4191fPxRii6_KSCwmPjY-geya5se4=.1e184d06-157a-4d99-b010-dfb7849dd73b@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
 <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>
 <MMfaRF7ay6_yVGOxC6SvO7-b7GwYkMG7r2uIkzfhSJ4=.f8d0457e-bc40-4025-8555-f3921fe9b6d3@github.com>
 <bNl-kdwPZVRfceE1bR2Lt3nYencF6XHmIJdDUAsjdL8=.da92bc6f-41df-486b-8e8d-f90d764c64aa@github.com>
 <lcOubi8bD8nfjs6CyZ_VVq__wlq1md0-kgKam76Ibwo=.6c10a867-9b3a-4c7b-b460-cdfd278a23f1@github.com>
 <xya5pLw2y95h8H4191fPxRii6_KSCwmPjY-geya5se4=.1e184d06-157a-4d99-b010-dfb7849dd73b@github.com>
Message-ID: <j73eNG_-MAUHR1QlQJXj-kQvPJ1Gnvulum7QwuGOvpY=.b5f1e192-973b-4107-807a-e904280f1941@github.com>

On Sat, 20 Feb 2021 03:27:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve jcmd GC.class_histogram to support parallel
>
> For jmap -histo we have:
> 
>       parallel=<number>  parallel threads number for heap iteration:
>                                   parallel=0 default behavior, use predefined number of threads
>                                   parallel=1 disable parallel heap iteration
>                                   parallel=<N> use N threads for parallel heap iteration
> 
> It's a bit inconsistent here in that it says <number>, <N>, and N. I'd like to see that cleaned up at some point along with a few other things (as part of a separate PR). However, my point is that the value of the argument is given a name, <number> in this case, so it can be referenced in the help output. However, jmap help is done differently than jcmd help, which doesn't give names to the value of options. For example, GC.heap_dump has:
> 
> Options: (options must be specified using the <key> or <key>=<value> syntax)
> 	-all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false)
> 	-gz : [optional] If specified, the heap dump is written in gzipped format using the given compression level. 1 (recommended) is the fastest, 9 the strongest compression. (INT, 1)
> 
> The -gz option is much like -parallel in that a value is given for it, but there is no "name" for that value in the help output. So maybe we should avoid calling it "n" or <n>, or anything like that:
> 
> "Number of parallel threads to use for heap inspection."
> "0 (the default) means let the VM determine the number of threads to use. "
> "1 means use one thread (disable parallelism). "
> "For any other value the VM will try to use the specified number of threads, but might use fewer."
> 
> I think we can leave out "Must be positive." It should be obvious, and I assume an error is generated if negative number is given.

Thanks @plummercj @sspitsyn for your review.

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

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

From mli at openjdk.java.net  Wed May 12 01:21:01 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 12 May 2021 01:21:01 GMT
Subject: Integrated: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <dq2gcgO6MijvdLf2cLriwt1ncXYsqLL4AuJad6C3fG0=.edecbc9e-e871-499c-9a57-75052cb4100f@github.com>

On Wed, 3 Feb 2021 12:44:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

This pull request has now been integrated.

Changeset: 3c47cab6
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3c47cab6db949b19cfd300139cbdbf81fb521e68
Stats:     98 lines in 4 files changed: 49 ins; 42 del; 7 mod

8261034: improve jcmd GC.class_histogram to support parallel

Reviewed-by: cjplummer, sspitsyn

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

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

From mchung at openjdk.java.net  Wed May 12 02:50:58 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 12 May 2021 02:50:58 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: <SzNTQC13ELzcwsos7x8FHf3u4RkXOGIah31lAUR4sdM=.5e8e2ff4-aa75-42c4-9639-b2e4fba86789@github.com>

On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

I reviewed java.base and took a pass on the test changes.  Here are some comments:
 
test/hotspot/jtreg/runtime/HiddenClasses/TestHiddenClassUnloading.java has this comment:


+// This is based on test compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java


This comment can be removed as this test will be removed.   A few tests under  test/hotspot/jtreg/runtime/HiddenClasses also have similar comment that should be removed.

test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/castToGrandparent/Test.java
test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/classNameInStackTrace/Test.java
- I think these tests are already well covered by test/hotspot/jtreg/runtime/HiddenClasses/CastToParentTest.java
and test/hotspot/jtreg/runtime/HiddenClasses/HiddenClassStack.java 
- I suggest to copy the description from the anonloader tests to these hidden class tests

test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/share/StressClassLoadingTest.java
   - test/hotspot/jtreg/runtime/HiddenClasses/StressClassLoadingTest.java is a subset of this test.  Should we remove test/hotspot/jtreg/runtime/HiddenClasses/StressClassLoadingTest.java?
   
test/jdk/java/lang/invoke/VMAnonymousClass.java
- FYI.  I have added a new test to verify hidden class (see JDK-8266925)

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

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

From ysuenaga at openjdk.java.net  Wed May 12 05:29:54 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 12 May 2021 05:29:54 GMT
Subject: Integrated: 8266531: ZAddress::address() should be removed from SA
In-Reply-To: <zWaxT0z3NQRICv2UGjLMxheBNd-L9RCkgQ2S1TniC5E=.c1c80a80-014a-4982-9aa5-7e517d3f3019@github.com>
References: <zWaxT0z3NQRICv2UGjLMxheBNd-L9RCkgQ2S1TniC5E=.c1c80a80-014a-4982-9aa5-7e517d3f3019@github.com>
Message-ID: <9gabfsfUZib1omZurYMFMnwvU8AJTEYA6xFqXwmvzuM=.7d9fcc35-03cc-41b7-9518-b308a5e6ba01@github.com>

On Wed, 5 May 2021 01:35:11 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `ZAddress::address()` has been removed since [JDK-8235748](https://bugs.openjdk.java.net/browse/JDK-8235748), however SA has not followed it. Thus some SA tests would fail with ZGC.
> After this change, more than half of jtreg tests which are listed in ProblemList-zgc.txt pass on Linux x64 with -vmoption:-XX:+UseZGC. Please see the change of ProblemList-zgc.txt what test can be resolved.

This pull request has now been integrated.

Changeset: 476994aa
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/476994aa373ac95e73e672b7cc463c95e96509dc
Stats:     59 lines in 8 files changed: 13 ins; 34 del; 12 mod

8266531: ZAddress::address() should be removed from SA

Reviewed-by: cjplummer, stefank

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

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

From rehn at openjdk.java.net  Wed May 12 06:06:01 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 12 May 2021 06:06:01 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2]
In-Reply-To: <JfNNkm0845PZujgZ94Bh5UuwQ0ztgO1GUQeFYDmZeQk=.15459b66-f979-49db-b83f-b297f1bab78d@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <lbaH3ck6InZu4fukbaTHqWxCDMMOGU58P2hMEo3EEqA=.8acc2813-c146-4d05-84fd-fd5b02b2c5ab@github.com>
 <JfNNkm0845PZujgZ94Bh5UuwQ0ztgO1GUQeFYDmZeQk=.15459b66-f979-49db-b83f-b297f1bab78d@github.com>
Message-ID: <Rw_cTIqJNDsTueWF2atPmowPnFqkO48GfcTT8s0PnwM=.eb3672fa-0f48-4679-bd3e-daeb702f22a0@github.com>

On Tue, 11 May 2021 17:02:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8265753
>>  - Removed manual transitions
>
> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 320:
> 
>> 318: // JavaThreads will enter here with state _thread_in_native.
>> 319: void JvmtiRawMonitor::raw_enter(Thread* self) {
>> 320:   // TODO Atomic::load on _owner field
> 
> Why is this still a TODO?

We have ~15 plain loads of _owner, I thought it would be nice to fix all at the same time and I did not want to clobber this with that also.
I can do a follow-up and change them.

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

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

From rehn at openjdk.java.net  Wed May 12 08:04:55 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 12 May 2021 08:04:55 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2]
In-Reply-To: <JfNNkm0845PZujgZ94Bh5UuwQ0ztgO1GUQeFYDmZeQk=.15459b66-f979-49db-b83f-b297f1bab78d@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <lbaH3ck6InZu4fukbaTHqWxCDMMOGU58P2hMEo3EEqA=.8acc2813-c146-4d05-84fd-fd5b02b2c5ab@github.com>
 <JfNNkm0845PZujgZ94Bh5UuwQ0ztgO1GUQeFYDmZeQk=.15459b66-f979-49db-b83f-b297f1bab78d@github.com>
Message-ID: <W0U8XH9uPVJkJZMVJXnDqxV4gdxs9jF8Ko3lkCycy48=.18a0bbb1-be19-4364-afb6-6396f50ad2b7@github.com>

On Tue, 11 May 2021 17:08:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8265753
>>  - Removed manual transitions
>
> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 42:
> 
>> 40: // Important note:
>> 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM
>> 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint
> 
> nit typo: s/e.g./e.g.,/
> nit typo: s/tranisition/transition/

Fixed

> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 43:
> 
>> 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM
>> 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint
>> 43: // poll in many cases, else the agent JavaThread can deadlock with VM thread,
> 
> nit typo: s/VM thread/the VM thread/

Fixed

> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52:
> 
>> 50: // native for all operations. However we need to honor suspend request, not
>> 51: // entering a monitor if suspended, and check for interrupts. Honoring suspened
>> 52: // and reading interrupt flag must be done from VM state (a safepoint unsafe
> 
> nit typo: s/suspend request/a suspend request/
> nit typo: s/Honoring suspened/Honoring a suspend request/
> nit typo: s/interrupt flag/the interrupt flag/
> (You'll probably want to reformat the changed lines a bit.)

Fixed

> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 206:
> 
>> 204:   ~ThreadInVMfromNative() {
>> 205:     assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition");
>> 206:     _thread->set_thread_state(_thread_in_native);
> 
> You're losing the assertion that we're transitioning from
> `_thread_in_vm` to `_thread_in_native` here. Although,
> the constructor did verify that we were in `_thread_in_native`
> when we transitioned to `_thread_in_vm` so at least the
> first half is still verified.
> 
> Can you an assertion that we're in `_thread_in_vm` here?

Fixed

> src/hotspot/share/runtime/objectMonitor.hpp line 309:
> 
>> 307:    protected:
>> 308:     ObjectMonitor* _om;
>> 309:     bool _om_exit;
> 
> Instead of `_om_exit` maybe this should be more generic?
> Perhaps `_om_op_done` or something like that?

Fixed

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

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

From rehn at openjdk.java.net  Wed May 12 08:04:47 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 12 May 2021 08:04:47 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
Message-ID: <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>

> Please consider this change which removes the manual transitions to blocked.
> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
> 
> The object monitor code could be straight forward changed to use this instead of manual transitions.
> 
> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
> That made it possible to careful use ThreadInVMfromNative in raw monitors.
> 
> I also remove the early CAS in raw_enter.
> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
> 
> Passes t1-t7 and manual stressing relevant test groups.

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

  Fixes for Dan

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3875/files
  - new: https://git.openjdk.java.net/jdk/pull/3875/files/07ddf393..1c6448e3

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

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

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

From rehn at openjdk.java.net  Wed May 12 08:08:55 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 12 May 2021 08:08:55 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2]
In-Reply-To: <JfNNkm0845PZujgZ94Bh5UuwQ0ztgO1GUQeFYDmZeQk=.15459b66-f979-49db-b83f-b297f1bab78d@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <lbaH3ck6InZu4fukbaTHqWxCDMMOGU58P2hMEo3EEqA=.8acc2813-c146-4d05-84fd-fd5b02b2c5ab@github.com>
 <JfNNkm0845PZujgZ94Bh5UuwQ0ztgO1GUQeFYDmZeQk=.15459b66-f979-49db-b83f-b297f1bab78d@github.com>
Message-ID: <hJARhUKFQmyZ0KfFkk7QgmpuV4OAvvaiOVtaHkIqBtM=.3f597225-7e8e-4754-a278-5e2834fa5c13@github.com>

On Tue, 11 May 2021 19:08:46 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up on the over all logic. I only have minor nits and suggestions.

Thank you!

> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48:
> 
>> 46: // The rules are:
>> 47: // - We must never safepoint poll if raw monitor is owned.
>> 48: // - We may safepoint poll before it is owned and after it have been released.
> 
> nit typo: s/have been/has been/

Fixed

> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 230:
> 
>> 228: };
>> 229: 
>> 230: template <typename PRE_PROC>
> 
> When you mentioned doing this with templates, I was having
> nightmares, but this one is not bad at all...

:)

> src/hotspot/share/runtime/objectMonitor.cpp line 313:
> 
>> 311:   if (current->is_suspended()) {
>> 312:     _om->_recursions = 0;
>> 313:     _om->_succ = NULL;
> 
> Please add a comment after this line:
> // Don't need a full fence after clearing successor here because of the call to exit().

Fixed

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

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

From rrich at openjdk.java.net  Wed May 12 08:31:13 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 12 May 2021 08:31:13 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
Message-ID: <EYHQ8DQn-doISd6HatOklej326frnOZn2HjF9MDY4yI=.72d9e057-a6f6-40af-99a8-77e93f85d25a@github.com>

On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes for Dan

Hi Robbin,

I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed.

Thanks, Richard.

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

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

From rrich at openjdk.java.net  Wed May 12 08:31:13 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 12 May 2021 08:31:13 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2]
In-Reply-To: <hJARhUKFQmyZ0KfFkk7QgmpuV4OAvvaiOVtaHkIqBtM=.3f597225-7e8e-4754-a278-5e2834fa5c13@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <lbaH3ck6InZu4fukbaTHqWxCDMMOGU58P2hMEo3EEqA=.8acc2813-c146-4d05-84fd-fd5b02b2c5ab@github.com>
 <JfNNkm0845PZujgZ94Bh5UuwQ0ztgO1GUQeFYDmZeQk=.15459b66-f979-49db-b83f-b297f1bab78d@github.com>
 <hJARhUKFQmyZ0KfFkk7QgmpuV4OAvvaiOVtaHkIqBtM=.3f597225-7e8e-4754-a278-5e2834fa5c13@github.com>
Message-ID: <MWq-8HC4ttqPDxNFcWOqlqpIa-pvmIj1UhgfKlt5wHQ=.e78ac2d7-1afa-4a79-9e75-ad1bc1ee9b2b@github.com>

On Wed, 12 May 2021 08:04:24 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 230:
>> 
>>> 228: };
>>> 229: 
>>> 230: template <typename PRE_PROC>
>> 
>> When you mentioned doing this with templates, I was having
>> nightmares, but this one is not bad at all...
>
> :)

Any reason why you don't use a ThreadClosure instead of the template parameter. I reckon it cannot be performance since it is only used on the slow path.

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

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

From prappo at openjdk.java.net  Wed May 12 09:14:53 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 12 May 2021 09:14:53 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap [v4]
In-Reply-To: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
Message-ID: <oSB4DsN_tz3gMg3OGA6kPDedEbRusuYMoAjVsaoqJXs=.96a7f892-c8c6-444f-aa13-ea31731cbcd2@github.com>

> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.
> 
> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:
> 
> 1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`

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

  Added missing full stops

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3885/files
  - new: https://git.openjdk.java.net/jdk/pull/3885/files/c8d2c04f..7a834b3e

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

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

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

From prappo at openjdk.java.net  Wed May 12 09:18:54 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 12 May 2021 09:18:54 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap [v3]
In-Reply-To: <QllQj153tfGKXjv68Eb396T0ZEbQXfMqfQEvIowOXiE=.41476607-1003-4d61-a6b4-6c46d6b2058e@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
 <-vEUXKnK4Hx08RxoJZ6znhlblhrIgoslG7odDTh27Ns=.7eb65699-6068-4f09-8d14-5a9455b5a854@github.com>
 <QllQj153tfGKXjv68Eb396T0ZEbQXfMqfQEvIowOXiE=.41476607-1003-4d61-a6b4-6c46d6b2058e@github.com>
Message-ID: <nXBeaHdDOMF-XUDxN_gB01PKEvWevOWo8Q1hxJqmVQc=.f352e084-6585-46ad-91fd-c9b1b0fe53f1@github.com>

On Wed, 12 May 2021 00:43:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Just one nit is to add a dot at the end of this comment:
> 280 // time. It's OK for now as logic in Agent.java forbids multiple agents

I added two full stops: one for each unterminated sentence in that inline comment.

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

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

From sspitsyn at openjdk.java.net  Wed May 12 09:33:52 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 12 May 2021 09:33:52 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap [v4]
In-Reply-To: <oSB4DsN_tz3gMg3OGA6kPDedEbRusuYMoAjVsaoqJXs=.96a7f892-c8c6-444f-aa13-ea31731cbcd2@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
 <oSB4DsN_tz3gMg3OGA6kPDedEbRusuYMoAjVsaoqJXs=.96a7f892-c8c6-444f-aa13-ea31731cbcd2@github.com>
Message-ID: <tuvNQzuwGhTvL6BpJRE0kkkDKXzVpSmkcBSfz7iK-qI=.e7d50dce-626c-4a4d-b7f4-06f0b02fd455@github.com>

On Wed, 12 May 2021 09:14:53 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.
>> 
>> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:
>> 
>> 1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
>> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing full stops

Marked as reviewed by sspitsyn (Reviewer).

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

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

From dfuchs at openjdk.java.net  Wed May 12 09:33:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 12 May 2021 09:33:53 GMT
Subject: RFR: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap [v4]
In-Reply-To: <oSB4DsN_tz3gMg3OGA6kPDedEbRusuYMoAjVsaoqJXs=.96a7f892-c8c6-444f-aa13-ea31731cbcd2@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
 <oSB4DsN_tz3gMg3OGA6kPDedEbRusuYMoAjVsaoqJXs=.96a7f892-c8c6-444f-aa13-ea31731cbcd2@github.com>
Message-ID: <ywYq2jp8998lKPb1gLf66he3GrVhbt_BPAexZtIwWUE=.e82cfb0c-d167-4d96-b2c9-86191611d2bb@github.com>

On Wed, 12 May 2021 09:14:53 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.
>> 
>> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:
>> 
>> 1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
>> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing full stops

Marked as reviewed by dfuchs (Reviewer).

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

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

From rehn at openjdk.java.net  Wed May 12 10:56:15 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 12 May 2021 10:56:15 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <EYHQ8DQn-doISd6HatOklej326frnOZn2HjF9MDY4yI=.72d9e057-a6f6-40af-99a8-77e93f85d25a@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <EYHQ8DQn-doISd6HatOklej326frnOZn2HjF9MDY4yI=.72d9e057-a6f6-40af-99a8-77e93f85d25a@github.com>
Message-ID: <EMf6NHVahTw88DzTR0HiOqn-6S5CoO6YLMpppRpVxJs=.8587a35d-06c9-4685-ac59-b01fb99f0bcd@github.com>

On Wed, 12 May 2021 08:27:33 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Hi Robbin,
> 
> I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed.
> 
> Thanks, Richard.

Hi Richard,
I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function.
 
Regarding ThreadClosure, we could use it, maybe that is preferable?!

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

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

From prappo at openjdk.java.net  Wed May 12 11:01:16 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 12 May 2021 11:01:16 GMT
Subject: Integrated: 8266567: Fix javadoc tag references in
 sun.management.jmxremote.ConnectorBootstrap
In-Reply-To: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
References: <YqGx5eOLnv7zYRbj0DXF5gJ3toWKnyt88Y873_PHeig=.cf942443-335f-4110-a4bf-ac454bc37e0c@github.com>
Message-ID: <pojg9q9frehclG6yJzGHtKOElVwJgWeVR8OWlfPJkTo=.da1cd565-b359-45f1-976d-a823ac525d65@github.com>

On Wed, 5 May 2021 15:59:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label.
> 
> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example:
> 
> 1. Numerous instances of `Boolean.valueOf( <var> ).booleanValue()` could be changed to `Boolean.parseBoolean( <var> )`
> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);`

This pull request has now been integrated.

Changeset: 4727187f
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4727187f86d18d34bd79cf93a74ff4a6515c662e
Stats:     12 lines in 1 file changed: 0 ins; 1 del; 11 mod

8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap

Reviewed-by: dfuchs, sspitsyn

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

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

From lzang at openjdk.java.net  Wed May 12 11:10:37 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 12 May 2021 11:10:37 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v24]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into pd
 - update copyright info
 - Merge branch 'master' into par-dump
 - undo JMap.java
 - code refine and typo fix
 - Merge branch 'master' into par-dump
 - refine with several fix
 - Merge branch 'master' into par-dump
 - Merge branch 'master' into par-dump
 - Typo fix
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/4727187f...6d8e944f

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

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=23
  Stats: 841 lines in 5 files changed: 653 ins; 61 del; 127 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

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

From lzang at openjdk.java.net  Wed May 12 11:11:39 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 12 May 2021 11:11:39 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v10]
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <XeqgnwWZzfkUaWorIXUVS4J33oGOfKBm6BjYAVLNRE4=.47c5bafb-e0ee-44d1-8c52-ed5304d24475@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

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

 - Merge branch 'master' into s-fix
 - fix typo in comments
 - Merge branch 'master' into s-fix
 - Merge branch 'master'
 - Merge branch 'master' into sf
 - rename writeThrough to unbufferedMode and code refine
 - fix typo in comments
 - Merge branch 'master' into sf
 - Revert "reduce memory consumption"
   
   This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e.
 - reduce memory consumption
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/8db72dde...6fde07bd

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/67f6d985..6fde07bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=08-09

  Stats: 4888 lines in 218 files changed: 1525 ins; 782 del; 2581 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

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

From lzang at openjdk.java.net  Wed May 12 11:14:55 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 12 May 2021 11:14:55 GMT
Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with
 EOFException
In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
Message-ID: <fZYfj-aQylAZir63t2J6D0Ju7lMpx5HKNp9zftnhjH8=.b3a1e522-984d-46bb-beba-ae2348e08a78@github.com>

On Thu, 22 Apr 2021 14:16:21 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> This fixes a race condition in the CompressionBackend class of the heap dump code.
> 
> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself.
> 
> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen.
> 
> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking.

Dear Ralf(@schmelter-sap), 
I am not a reviewer, just want to state that this change looks good to me and also helpful.
I have encountered an issue that happened 2 times among 100 times try when testing #2261.  And after applied this change, it works normally for another 100 times test.  Just FYI.

BRs,
Lin

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

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

From lzang at openjdk.java.net  Wed May 12 11:17:57 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 12 May 2021 11:17:57 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v24]
In-Reply-To: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com>
Message-ID: <_zH7zhSHNVXccz-n8ejwCp-_QIxvB5ICu_ieahs7ui4=.b732dbcb-aaaf-40c3-aa09-f3fe8fe720ef@github.com>

On Wed, 12 May 2021 11:10:37 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - Merge branch 'master' into pd
>  - update copyright info
>  - Merge branch 'master' into par-dump
>  - undo JMap.java
>  - code refine and typo fix
>  - Merge branch 'master' into par-dump
>  - refine with several fix
>  - Merge branch 'master' into par-dump
>  - Merge branch 'master' into par-dump
>  - Typo fix
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/4727187f...6d8e944f

Dear Chris,
Thanks a lot for reviewing.
I did more stress tests recently and found an issue that seems could be fixed by #3628, I am still verifying it. Will update when I confirm it.
Just FYI. Thanks!
Lin

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

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

From rrich at openjdk.java.net  Wed May 12 12:35:27 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 12 May 2021 12:35:27 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <EMf6NHVahTw88DzTR0HiOqn-6S5CoO6YLMpppRpVxJs=.8587a35d-06c9-4685-ac59-b01fb99f0bcd@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <EYHQ8DQn-doISd6HatOklej326frnOZn2HjF9MDY4yI=.72d9e057-a6f6-40af-99a8-77e93f85d25a@github.com>
 <EMf6NHVahTw88DzTR0HiOqn-6S5CoO6YLMpppRpVxJs=.8587a35d-06c9-4685-ac59-b01fb99f0bcd@github.com>
Message-ID: <909VtnsgD4R5wqUITLJD9R_4jDxnhLSLL7DyBaah4Ug=.bff780ad-86d9-4d99-8a98-3314d806212d@github.com>

On Wed, 12 May 2021 10:53:21 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> 
> 
> > Hi Robbin,
> > I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed.
> > Thanks, Richard.
> 
> Hi Richard,
> I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function.

Yes, I'd think so too.

> Regarding ThreadClosure, we could use it, maybe that is preferable?!

Personally I'd prefer it but I'm fine with the current version too.

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

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

From david.holmes at oracle.com  Wed May 12 13:00:03 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 May 2021 23:00:03 +1000
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <EMf6NHVahTw88DzTR0HiOqn-6S5CoO6YLMpppRpVxJs=.8587a35d-06c9-4685-ac59-b01fb99f0bcd@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <EYHQ8DQn-doISd6HatOklej326frnOZn2HjF9MDY4yI=.72d9e057-a6f6-40af-99a8-77e93f85d25a@github.com>
 <EMf6NHVahTw88DzTR0HiOqn-6S5CoO6YLMpppRpVxJs=.8587a35d-06c9-4685-ac59-b01fb99f0bcd@github.com>
Message-ID: <6d44b14a-875f-3658-970d-2604c0ebf1a5@oracle.com>

On 12/05/2021 8:56 pm, Robbin Ehn wrote:
> On Wed, 12 May 2021 08:27:33 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
> 
>> Hi Robbin,
>>
>> I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed.
>>
>> Thanks, Richard.
> 
> Hi Richard,
> I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function.
>   
> Regarding ThreadClosure, we could use it, maybe that is preferable?!

Isn't a ThreadClosure for applying an operation to a set of threads? 
That is not what we are doing here.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3875
> 

From rrich at openjdk.java.net  Wed May 12 15:31:11 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 12 May 2021 15:31:11 GMT
Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with
 EOFException
In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
Message-ID: <JqjOTJrfnONvy2mM547IB-xmNvMXAY1_KxQ_ymiuvb8=.1d847302-f5d1-4c34-adab-abcddbb3a837@github.com>

On Thu, 22 Apr 2021 14:16:21 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> This fixes a race condition in the CompressionBackend class of the heap dump code.
> 
> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself.
> 
> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen.
> 
> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking.

Hi Ralf,

your change looks good to me.

Thanks for fixing,
Richard.

src/hotspot/share/services/heapDumperCompression.cpp line 262:

> 260: }
> 261: 
> 262: void CompressionBackend::thread_loop() {

You could simplify `CompressionBackend::thread_loop()` further:


void CompressionBackend::thread_loop() {
  {
    MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag);
    _nr_of_threads++;
  }

  WriteWork* work = get_work();
  while (work != NULL) {
      do_compress(work);
      finish_work(work);
      work = get_work();
  }

  MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag);
  _nr_of_threads--;
  assert(_nr_of_threads >= 0, "Too many threads finished");
  ml.notify_all();
}

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

Marked as reviewed by rrich (Reviewer).

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

From rrich at openjdk.java.net  Wed May 12 15:31:12 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 12 May 2021 15:31:12 GMT
Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with
 EOFException
In-Reply-To: <JqjOTJrfnONvy2mM547IB-xmNvMXAY1_KxQ_ymiuvb8=.1d847302-f5d1-4c34-adab-abcddbb3a837@github.com>
References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
 <JqjOTJrfnONvy2mM547IB-xmNvMXAY1_KxQ_ymiuvb8=.1d847302-f5d1-4c34-adab-abcddbb3a837@github.com>
Message-ID: <5CPIAlmMc6p7oVHAaUlLz7_0CZQesWLFs0T0hXWZ81o=.a2fcf555-1d56-4339-bfba-a6a1268c789f@github.com>

On Wed, 12 May 2021 14:37:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This fixes a race condition in the CompressionBackend class of the heap dump code.
>> 
>> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself.
>> 
>> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen.
>> 
>> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking.
>
> src/hotspot/share/services/heapDumperCompression.cpp line 262:
> 
>> 260: }
>> 261: 
>> 262: void CompressionBackend::thread_loop() {
> 
> You could simplify `CompressionBackend::thread_loop()` further:
> 
> 
> void CompressionBackend::thread_loop() {
>   {
>     MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag);
>     _nr_of_threads++;
>   }
> 
>   WriteWork* work = get_work();
>   while (work != NULL) {
>       do_compress(work);
>       finish_work(work);
>       work = get_work();
>   }
> 
>   MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag);
>   _nr_of_threads--;
>   assert(_nr_of_threads >= 0, "Too many threads finished");
>   ml.notify_all();
> }

BTW: why is `ml.notify_all()` in line 275 needed at all?

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

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

From hseigel at openjdk.java.net  Wed May 12 16:10:25 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:25 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
Message-ID: <CaV6MEL82hBZVDl3y7mx3R7jTViXiOwZbNANa6_MK0Y=.91800e73-844d-4d5a-819e-b125cd77ebda@github.com>

On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix GetModuleTest.java

Thanks Alan, Ioi, and Mandy for looking at this.  The latest changes should address the issues that you found.
Harold

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

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

From hseigel at openjdk.java.net  Wed May 12 16:10:24 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:24 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

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

  test changes and small fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/874a1603..5246dd76

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

  Stats: 286 lines in 10 files changed: 22 ins; 256 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974

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

From hseigel at openjdk.java.net  Wed May 12 16:10:27 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:27 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
 <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com>
Message-ID: <ltY7CzN_ay0uBhRGthL1ZavkQkycONKJ4LbzYas7T5I=.8a4fbbf2-8b7b-40f8-a19c-b4856c3c5e63@github.com>

On Tue, 11 May 2021 20:49:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix GetModuleTest.java
>
> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java line 53:
> 
>> 51:             return simpleName;
>> 52:         }
>> 53:         // Must be a local class
> 
> This file should not be changed.  It refers to the Java language anonymous class (not VM anonymous class).

Changes have been restored.

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

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

From hseigel at openjdk.java.net  Wed May 12 16:10:26 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 12 May 2021 16:10:26 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3]
In-Reply-To: <sJyvFHU5KhmFEbzS8UO7tPFY0Koxct_h6PUKvx38hqg=.0de94f46-7bf2-4500-8a26-30fdc83a8cc8@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com>
 <sJyvFHU5KhmFEbzS8UO7tPFY0Koxct_h6PUKvx38hqg=.0de94f46-7bf2-4500-8a26-30fdc83a8cc8@github.com>
Message-ID: <6vXfHjNzHSk46muMlntg2ZqE1OSmHx0eg08V-3AqIvc=.2dbd90d5-453a-4447-abfd-9aebfff9143d@github.com>

On Tue, 11 May 2021 17:07:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix GetModuleTest.java
>
> src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 65:
> 
>> 63:         // so when handling the java mirror for the class we need to make sure its class
>> 64:         // loader data is claimed, this is done by calling do_cld explicitly.
>> 65:         // For non-string hidden classes the call to do_cld is made when the class
> 
> Typo: non-strong

fixed, thanks for finding this.

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

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

From rschmelter at openjdk.java.net  Wed May 12 17:55:57 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Wed, 12 May 2021 17:55:57 GMT
Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with
 EOFException
In-Reply-To: <5CPIAlmMc6p7oVHAaUlLz7_0CZQesWLFs0T0hXWZ81o=.a2fcf555-1d56-4339-bfba-a6a1268c789f@github.com>
References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
 <JqjOTJrfnONvy2mM547IB-xmNvMXAY1_KxQ_ymiuvb8=.1d847302-f5d1-4c34-adab-abcddbb3a837@github.com>
 <5CPIAlmMc6p7oVHAaUlLz7_0CZQesWLFs0T0hXWZ81o=.a2fcf555-1d56-4339-bfba-a6a1268c789f@github.com>
Message-ID: <PbD89Y93Jwfl1HK0N_5Zfd6yKscXb9SAN3w29rLo170=.08c79d63-ac62-4dfe-9e63-a6395c71b8d2@github.com>

On Wed, 12 May 2021 15:22:52 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/share/services/heapDumperCompression.cpp line 262:
>> 
>>> 260: }
>>> 261: 
>>> 262: void CompressionBackend::thread_loop() {
>> 
>> You could simplify `CompressionBackend::thread_loop()` further:
>> 
>> 
>> void CompressionBackend::thread_loop() {
>>   {
>>     MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag);
>>     _nr_of_threads++;
>>   }
>> 
>>   WriteWork* work = get_work();
>>   while (work != NULL) {
>>       do_compress(work);
>>       finish_work(work);
>>       work = get_work();
>>   }
>> 
>>   MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag);
>>   _nr_of_threads--;
>>   assert(_nr_of_threads >= 0, "Too many threads finished");
>>   ml.notify_all();
>> }
>
> BTW: why is `ml.notify_all()` in line 275 needed at all?

Hi,

thanks for the review Lin and Richard. 

The notify_all() is indeed not needed anymore. It was originally needed when the worker threads were newly created threads and we had to wait for them to finish at the end of the dump operation. But since we now use the GC work gang, this can be removed.

I will update the PR with your suggestions.

Best regards,
Ralf

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

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

From cjplummer at openjdk.java.net  Wed May 12 18:07:57 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 12 May 2021 18:07:57 GMT
Subject: RFR: 8267047: Put serviceability/sa/TestJmapCoreMetaspace.java back
 on ZGC problem list due to JDK-8267045
Message-ID: <E9fk3WpIGEEoFWn48Zn44zmw86518Bbj_uOCA6Qvkj4=.87968b20-2aeb-4039-ade2-c1731dac43e3@github.com>

[JDK-8267045](https://bugs.openjdk.java.net/browse/JDK)-8267045 removed this test from the ZGC problem list, but it still fails, so it needs to be re-added.

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

Commit messages:
 - ProblemList serviceability/sa/TestJmapCoreMetaspace.java

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

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

From dcubed at openjdk.java.net  Wed May 12 18:51:56 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 12 May 2021 18:51:56 GMT
Subject: RFR: 8267047: Put serviceability/sa/TestJmapCoreMetaspace.java
 back on ZGC problem list due to JDK-8267045
In-Reply-To: <E9fk3WpIGEEoFWn48Zn44zmw86518Bbj_uOCA6Qvkj4=.87968b20-2aeb-4039-ade2-c1731dac43e3@github.com>
References: <E9fk3WpIGEEoFWn48Zn44zmw86518Bbj_uOCA6Qvkj4=.87968b20-2aeb-4039-ade2-c1731dac43e3@github.com>
Message-ID: <zKNsmsfJRs-WwpEzrzBLQZR_akFUPWIH20Yo_5WkAWA=.6ddc8b43-6717-4adb-bfda-e56a38f38268@github.com>

On Wed, 12 May 2021 18:00:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8267045](https://bugs.openjdk.java.net/browse/JDK)-8267045 removed this test from the ZGC problem list, but it still fails, so it needs to be re-added.

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

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

From cjplummer at openjdk.java.net  Wed May 12 21:05:11 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 12 May 2021 21:05:11 GMT
Subject: Integrated: 8267047: Put serviceability/sa/TestJmapCoreMetaspace.java
 back on ZGC problem list due to JDK-8267045
In-Reply-To: <E9fk3WpIGEEoFWn48Zn44zmw86518Bbj_uOCA6Qvkj4=.87968b20-2aeb-4039-ade2-c1731dac43e3@github.com>
References: <E9fk3WpIGEEoFWn48Zn44zmw86518Bbj_uOCA6Qvkj4=.87968b20-2aeb-4039-ade2-c1731dac43e3@github.com>
Message-ID: <wGRB90_NdhoXaL6r7hnerUGAYvAVKuGpgWj95fx3ZfM=.ec123b16-a6e9-4655-a3bf-3ed1f539f060@github.com>

On Wed, 12 May 2021 18:00:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8267045](https://bugs.openjdk.java.net/browse/JDK)-8267045 removed this test from the ZGC problem list, but it still fails, so it needs to be re-added.

This pull request has now been integrated.

Changeset: 2568d181
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2568d181a778add4837bb0eada8c5f4a137d4560
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8267047: Put serviceability/sa/TestJmapCoreMetaspace.java back on ZGC problem list due to JDK-8267045

Reviewed-by: dcubed

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

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

From mchung at openjdk.java.net  Wed May 12 22:34:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 12 May 2021 22:34:55 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
Message-ID: <gs5wpPzMnPR1L_si6beJUuRxKkv8pF-zWiuA1IljRRc=.d5a528e8-620a-49ec-9aad-e3246f437b00@github.com>

On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes and small fixes

Overall looks good to me.

src/hotspot/share/classfile/classLoaderData.cpp line 299:

> 297: }
> 298: 
> 299: // Weak hidden classes have their own ClassLoaderData that is marked to keep alive

`s/Weak/Non-strong/`

test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java line 39:

> 37: import jdk.test.lib.compiler.InMemoryJavaCompiler;
> 38: 
> 39: public class StressHiddenClasses {

Since `StressClassLoadingTest` is revised to test hidden class, this test is a subset of it.
I think this can be removed as JDK-8265694 suggests.

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

Marked as reviewed by mchung (Reviewer).

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

From cjplummer at openjdk.java.net  Wed May 12 22:44:59 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 12 May 2021 22:44:59 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v24]
In-Reply-To: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com>
Message-ID: <h3ahLnZ40qxxHMfTikqA123eT0JB8lJo8uswFkG-P2Y=.15641131-1770-4b21-8056-ed7c390d8bb7@github.com>

On Wed, 12 May 2021 11:10:37 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - Merge branch 'master' into pd
>  - update copyright info
>  - Merge branch 'master' into par-dump
>  - undo JMap.java
>  - code refine and typo fix
>  - Merge branch 'master' into par-dump
>  - refine with several fix
>  - Merge branch 'master' into par-dump
>  - Merge branch 'master' into par-dump
>  - Typo fix
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/4727187f...6d8e944f

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Wed May 12 23:05:52 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 12 May 2021 23:05:52 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2]
In-Reply-To: <iU84ArHG5BfpTsA9qXufnCU8y9rVIjflPMTYY5Ctqyk=.e1f1d3ef-e93d-46d1-9446-5ea468e4dfff@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <noWAINrOl6Nx3Hb3pBPPYa9ZXtlx45ohzGkiJk4x6Ww=.eaf2cf80-c1f6-4364-a4e4-8d01bb31902c@github.com>
 <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com>
 <iU84ArHG5BfpTsA9qXufnCU8y9rVIjflPMTYY5Ctqyk=.e1f1d3ef-e93d-46d1-9446-5ea468e4dfff@github.com>
Message-ID: <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com>

On Tue, 11 May 2021 01:34:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 93:
>> 
>>> 91: 
>>> 92:     public static Remote lookup(String debugServerID) throws DebuggerException {
>>> 93:         // debugServerID follows the pattern [unique_id@]host[:port][/prefix]
>> 
>> It's a bit unclear to me why we need both a "unique_id" and a "prefix". I understand that the SA already append the two, and that previously the prefix was a constant, but I don't see why the user would ever need to set the "prefix" when they can always specify a "unique_id" that is truly unique. What is the use case for this?
>
> "prefix" is similar to "unique_id" as you said, but it is useful to group debugees.
> 
> For example, the host runs 2 container pods as following:
> 
> * Pod A
>     * Container 1
>     * Container 2
>     * Container 3
> * Pod B
>     * Container 1
>     * Container 2
>     * Container 3
> 
> If we want to compare 2 pods with jhsdb, we can set ID like "A-1", "B-1".
> However, if the prefix is supported on jhsdb, we can set ID and prefix like "1 at localhost/A", "1 at localhost/B". I think it is easy to understand.

Ok, this explanation seems reasonable, but is not something that is really conveyed with the the name `--prefix` or with the help "Sets the prefix to distinguish SA debugee". We are at the same giving too much and too little info. Too much in that we are saying that it is a prefix of some sort, which then leads to that fact that we don't explain how it is used in the RMI URL.

I'm not saying that we need to explain how  the `--connect [<id>@]<host>[:registryport][/prefix]` option is converted into an RMI URL (although perhaps we should), but it seems we at least need to describe the relation between `<id>` and `/prefix`. Otherwise no one is really going to understand how/why to use it.

Also, having the prefix at the end of the "serverID" string seems odd. Maybe it should be:

   [[prefix/]unique_id@]host[:port]

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

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

From kvn at openjdk.java.net  Thu May 13 03:29:57 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 13 May 2021 03:29:57 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v2]
In-Reply-To: <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
Message-ID: <Nyq7U_Z1Ke7dlNhEcOvcj_aAtZC2UY26qNYnpkRe3pg=.ac3e3a4a-837b-4d89-bfe9-25972f5d60a9@github.com>

On Tue, 11 May 2021 01:56:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t
 hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
>> 
>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
>> - Manifestations of Thread::current() become JavaThread::current()
>> - THREAD->as_Java_thread() becomes just THREAD
>> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
>> 
>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
>> 
>> Testing:
>>  - tiers 1-8 on Linux-x64
>>  - all builds in tiers 1-4
>>  - tiers 1-3 on all platforms
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback from Serguei

Compiler related changes seems fine.
@dougxc,  note that jvmci is affected. It looks reasonable for me but you may need to check if it is correct from libgraal POV.

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

Marked as reviewed by kvn (Reviewer).

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

From david.holmes at oracle.com  Thu May 13 03:59:50 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 May 2021 13:59:50 +1000
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v2]
In-Reply-To: <Nyq7U_Z1Ke7dlNhEcOvcj_aAtZC2UY26qNYnpkRe3pg=.ac3e3a4a-837b-4d89-bfe9-25972f5d60a9@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
 <Nyq7U_Z1Ke7dlNhEcOvcj_aAtZC2UY26qNYnpkRe3pg=.ac3e3a4a-837b-4d89-bfe9-25972f5d60a9@github.com>
Message-ID: <3a458466-6e48-309b-e78d-146ab4edd9d5@oracle.com>

On 13/05/2021 1:29 pm, Vladimir Kozlov wrote:
> On Tue, 11 May 2021 01:56:21 GMT, David Holmes <dholmes at openjdk.org> wrote:
>>
>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Review feedback from Serguei
> 
> Compiler related changes seems fine.
> @dougxc,  note that jvmci is affected. It looks reasonable for me but you may need to check if it is correct from libgraal POV.

Thanks for the review Vladimir!

cc'ing Doug in case the @-notification doesn't work.

David

> -------------
> 
> Marked as reviewed by kvn (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/3877
> 

From dholmes at openjdk.java.net  Thu May 13 04:59:11 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 13 May 2021 04:59:11 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v3]
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com>

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Update after merge with master
 - Merge branch 'master' into 8252685-JavaThread
 - Review feedback from Serguei
 - Merge
 - 8252685: APIs that require JavaThread should take JavaThread arguments

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

Changes: https://git.openjdk.java.net/jdk/pull/3877/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=02
  Stats: 537 lines in 121 files changed: 14 ins; 30 del; 493 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3877.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3877/head:pull/3877

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

From ysuenaga at openjdk.java.net  Thu May 13 05:59:51 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 13 May 2021 05:59:51 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2]
In-Reply-To: <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <noWAINrOl6Nx3Hb3pBPPYa9ZXtlx45ohzGkiJk4x6Ww=.eaf2cf80-c1f6-4364-a4e4-8d01bb31902c@github.com>
 <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com>
 <iU84ArHG5BfpTsA9qXufnCU8y9rVIjflPMTYY5Ctqyk=.e1f1d3ef-e93d-46d1-9446-5ea468e4dfff@github.com>
 <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com>
Message-ID: <R7XeiE2Y_Kc0SfAYw2SH8z9fNtGPVFzJxQ_MHm9qei4=.3a09da67-54e5-4bc3-9217-02fb173aeffa@github.com>

On Wed, 12 May 2021 23:03:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> "prefix" is similar to "unique_id" as you said, but it is useful to group debugees.
>> 
>> For example, the host runs 2 container pods as following:
>> 
>> * Pod A
>>     * Container 1
>>     * Container 2
>>     * Container 3
>> * Pod B
>>     * Container 1
>>     * Container 2
>>     * Container 3
>> 
>> If we want to compare 2 pods with jhsdb, we can set ID like "A-1", "B-1".
>> However, if the prefix is supported on jhsdb, we can set ID and prefix like "1 at localhost/A", "1 at localhost/B". I think it is easy to understand.
>
> Ok, this explanation seems reasonable, but is not something that is really conveyed with the the name `--prefix` or with the help "Sets the prefix to distinguish SA debugee". We are at the same giving too much and too little info. Too much in that we are saying that it is a prefix of some sort, which then leads to that fact that we don't explain how it is used in the RMI URL.
> 
> I'm not saying that we need to explain how  the `--connect [<id>@]<host>[:registryport][/prefix]` option is converted into an RMI URL (although perhaps we should), but it seems we at least need to describe the relation between `<id>` and `/prefix`. Otherwise no one is really going to understand how/why to use it.
> 
> Also, having the prefix at the end of the "serverID" string seems odd. Maybe it should be:
> 
>    [[prefix/]unique_id@]host[:port]

Finally, all parameters will be transformed to `//host[:port]/<serverNamePrefix>['_'<unique_id>]`.
`--prefix` and `id` affect to RMI object name to be precise. So ID is object name, then the prefix will be added to it.

Based on them, how about this?


--prefix <url prefix> Set the prefix to add to debug server instance name.


I understand is is odd the value is added to the tail even if it is named "prefix".
Both `prefix` and `id` are optional, so we can specify `prefix` only, then `prefix/@host` is strange for me.

How about this pattern? Use ":" instead of "/" like a URL.


[prefix:][unique_id@]host[:port]


I thought to give new name instead of "prefix", but I give up because I have not good idea and would be inconsistent system property. (`sun.jvm.hotspot.rmi.serverNamePrefix`)

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

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

From dholmes at openjdk.java.net  Thu May 13 06:07:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 13 May 2021 06:07:00 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
Message-ID: <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>

On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes for Dan

Hi Robbin,

Sorry for the delay in getting through this.

Overall approach looks good. I have a few queries below and some requested naming changes to make things clearer.

Thanks,
David

src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48:

> 46: // The rules are:
> 47: // - We must never safepoint poll if raw monitor is owned.
> 48: // - We may safepoint poll before it is owned and after it has been released.

I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course.

src/hotspot/share/prims/jvmtiRawMonitor.hpp line 96:

> 94:    protected:
> 95:     JvmtiRawMonitor* _rm;
> 96:     bool _rm_exit;

If this signifies the monitor exited then please name it `_rm_exited`.

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 207:

> 205:     assert(_thread->thread_state() == _thread_in_vm, "coming from wrong thread state");
> 206:     assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition");
> 207:     _thread->set_thread_state(_thread_in_native);

After doing a heavyweight transition for many many years I find it somewhat disconcerting to suddenly be told it is not necessary. If we are _thread_in_vm and so unsafe, then no handshake/safepoint can have been processed, so there is nothing to check. Makes sense. But how long has that been true? Could we have simplified this years ago or it is a result of other changes?

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 277:

> 275: class ThreadBlockInVM {
> 276:   InFlightMutexRelease _ifmr;
> 277:   ThreadBlockInVMPreprocess<InFlightMutexRelease> _tbivmpp;

Why delegate to the TBIVMPP instead of extending it?

src/hotspot/share/runtime/objectMonitor.cpp line 435:

> 433:         EnterI(current);
> 434:       }
> 435:       if (!eos.om_op_done()) {

I find this API too generic. I'd much rather see:

if (!eos.exited()) {
  assert ...
  break;
}

src/hotspot/share/runtime/objectMonitor.hpp line 309:

> 307:    protected:
> 308:     ObjectMonitor* _om;
> 309:     bool _om_op_done;

Please rename to _exited - we know what the "op" is so no need to use generic terminology.

src/hotspot/share/runtime/objectMonitor.hpp line 313:

> 311:     ExitOnSuspend(ObjectMonitor* om) : _om(om), _om_op_done(false) {}
> 312:     void operator()(JavaThread* current);
> 313:     bool om_op_done() { return _om_op_done; }

please rename to exited()

src/hotspot/share/runtime/objectMonitor.hpp line 315:

> 313:     bool om_op_done() { return _om_op_done; }
> 314:   };
> 315:   class ClearSuccOnSuspend : public ExitOnSuspend {

I don't see why there is any relationship between these two. You don't clear-succ and exit.

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

Changes requested by dholmes (Reviewer).

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

From alanb at openjdk.java.net  Thu May 13 06:24:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 13 May 2021 06:24:54 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <D3MaVYi6Rdq6cEhXousz4fIcsEZsYj7D-MJyxP7dqKs=.221945b9-53c8-4339-9f6e-ec36dc625abe@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <jv8lcM9GVgefV6lzgRdh-bIQrxN91pkOusleqo2JdpM=.08f401a7-96cd-4ffd-9d92-acb7c740b65d@github.com>
 <B6FMrKGRolpl0SMX867JWddnPwqK5_ixIOBg3zr6Og0=.50b0e57d-d8e9-427b-afc3-311bb080afc9@github.com>
 <D3MaVYi6Rdq6cEhXousz4fIcsEZsYj7D-MJyxP7dqKs=.221945b9-53c8-4339-9f6e-ec36dc625abe@github.com>
Message-ID: <26yxlZkGUBDT2wTKQUS9koA7PZPYojY23wJvl7aTAWE=.6ac4247e-b13f-4ed1-b603-6ff1b09f526b@github.com>

On Tue, 11 May 2021 14:11:22 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk.
>
> Hi Alan,
> Thanks for find this.  I removed the unneeded imports and @modules from GetModulesTest.java and updated the comment in ClassAttributesTest.java.
> Thanks, Harold

Thanks for fixing up these tests, I didn't spot any more in the test/jdk tree.

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

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

From alanb at openjdk.java.net  Thu May 13 06:24:54 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 13 May 2021 06:24:54 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
Message-ID: <xnnGBiJp_v-hOfPj6PH5hpwyh_CKDxekdiWfXVQ_dIQ=.500477c6-50ec-4a69-a71e-1f48b579b37f@github.com>

On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes and small fixes

Marked as reviewed by alanb (Reviewer).

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

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

From dholmes at openjdk.java.net  Thu May 13 07:27:56 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 13 May 2021 07:27:56 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
Message-ID: <qsWyA88_CjTCQjwxawPf7eTMgUySALN7_jHLi04Nz1A=.c6935617-90df-4f49-bbe4-2f4ecb756d0d@github.com>

On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes and small fixes

Hi Harold,

Big change! :) This looks good. All the removals of references to unsafe_anonymous were easy enough  to follow.

I didn't realize that cp patching and psuedo-strings were only related to VM anonymous. It is good to see all that code go as well (but hard to see if you got it all :) ). But as per comment below are we sure psuedo-strings can't be used elsewhere?

Thanks,
David

src/hotspot/share/oops/constantPool.hpp line 493:

> 491:   // object into a CONSTANT_String entry of an unsafe anonymous class.
> 492:   // Methods internally created for method handles may also
> 493:   // use pseudo-strings to link themselves to related metaobjects.

Is this comment wrong? Are psuedo-strings not used by anything now?

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

Marked as reviewed by dholmes (Reviewer).

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

From dholmes at openjdk.java.net  Thu May 13 08:14:55 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 13 May 2021 08:14:55 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5]
In-Reply-To: <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>
Message-ID: <ybmxMSsR_v-bmdrlWcYlVWIzSG-Y2hrh1sRM-W0unS8=.d92d33ac-3652-4e59-ac9b-88c68d1152a8@github.com>

On Tue, 11 May 2021 23:34:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
>> 
>> Currently running the new test thru Mach5 Tier[1-7].
>> I've run the test thru several 12 hour runs on my MBP13 and
>> on my Linux-X64 server.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop exit_delta and the VMTestbase style of exiting on test failure.

Hi Dan,

Seems fine. Thanks for the updates.

The proof of a test is in its execution :)

David

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

Marked as reviewed by dholmes (Reviewer).

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

From hseigel at openjdk.java.net  Thu May 13 12:31:44 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:31:44 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com>

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

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

  fix Weak hidden comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3974/files
  - new: https://git.openjdk.java.net/jdk/pull/3974/files/5246dd76..38675761

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

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

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

From hseigel at openjdk.java.net  Thu May 13 12:31:48 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:31:48 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]
In-Reply-To: <gs5wpPzMnPR1L_si6beJUuRxKkv8pF-zWiuA1IljRRc=.d5a528e8-620a-49ec-9aad-e3246f437b00@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
 <gs5wpPzMnPR1L_si6beJUuRxKkv8pF-zWiuA1IljRRc=.d5a528e8-620a-49ec-9aad-e3246f437b00@github.com>
Message-ID: <PCK4GpTKgvSX-oiVLF3dDbEVK2REvBRO8Qi29QSd2DY=.2ba33cf9-1137-4e67-8e1a-4f9af63d98e7@github.com>

On Wed, 12 May 2021 22:30:30 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test changes and small fixes
>
> src/hotspot/share/classfile/classLoaderData.cpp line 299:
> 
>> 297: }
>> 298: 
>> 299: // Weak hidden classes have their own ClassLoaderData that is marked to keep alive
> 
> `s/Weak/Non-strong/`

fixed.  thanks for finding it.

> test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java line 39:
> 
>> 37: import jdk.test.lib.compiler.InMemoryJavaCompiler;
>> 38: 
>> 39: public class StressHiddenClasses {
> 
> Since `StressClassLoadingTest` is revised to test hidden class, this test is a subset of it.
> I think this can be removed as JDK-8265694 suggests.

Thanks Mandy. I will remove the test as the fix for JDK-8265694 after this change is pushed.

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

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

From hseigel at openjdk.java.net  Thu May 13 12:38:01 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:38:01 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]
In-Reply-To: <qsWyA88_CjTCQjwxawPf7eTMgUySALN7_jHLi04Nz1A=.c6935617-90df-4f49-bbe4-2f4ecb756d0d@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <AU6XZet4yXNMRdEfixnPDvMX0HF31NsBWQuNcSThoiw=.504fc152-fb81-445e-a542-ab16d26d8908@github.com>
 <qsWyA88_CjTCQjwxawPf7eTMgUySALN7_jHLi04Nz1A=.c6935617-90df-4f49-bbe4-2f4ecb756d0d@github.com>
Message-ID: <UW4SilKIKYWhjZyoRr4hj9C2u1LEozCpkijqVSA9HsA=.36d7b26a-6513-4571-84c8-5320d4e93f74@github.com>

On Thu, 13 May 2021 07:19:03 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 Weak hidden comment
>
> src/hotspot/share/oops/constantPool.hpp line 493:
> 
>> 491:   // object into a CONSTANT_String entry of an unsafe anonymous class.
>> 492:   // Methods internally created for method handles may also
>> 493:   // use pseudo-strings to link themselves to related metaobjects.
> 
> Is this comment wrong? Are psuedo-strings not used by anything now?

Thanks for looking at this.  I discussed pseudo strings with Coleen and we didn't find any use of them besides unsafe.DefineAnonymousClass.

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

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

From hseigel at openjdk.java.net  Thu May 13 12:50:40 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:50:40 GMT
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5]
In-Reply-To: <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com>
Message-ID: <sNlFAC93FzLaMQHBPf6mxME_yCgSPpP3V4MThLZ9Roo=.5d317499-eb93-4d2b-8068-7289dcc0f1f4@github.com>

On Thu, 13 May 2021 12:31:44 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>> 
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Weak hidden comment

Thanks Ioi, Alan, Mandy, and David for reviewing this big change!

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

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

From hseigel at openjdk.java.net  Thu May 13 12:50:41 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 13 May 2021 12:50:41 GMT
Subject: Integrated: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
Message-ID: <tfKcVuLeaIw0b7aQE9GDf_t4vMbAl66stRcEe6ko-Qs=.052cdc2b-7634-429e-861b-671f0bc41d80@github.com>

On Tue, 11 May 2021 12:50:31 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
> 
> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: e14b0268
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e14b0268411bba8eb01bf6c477cc8743a53ffd1c
Stats:     3754 lines in 122 files changed: 75 ins; 3426 del; 253 mod

8243287: Removal of Unsafe::defineAnonymousClass

Reviewed-by: iklam, mchung, alanb, dholmes

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

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

From dnsimon at openjdk.java.net  Thu May 13 13:20:55 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 13 May 2021 13:20:55 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v2]
In-Reply-To: <Nyq7U_Z1Ke7dlNhEcOvcj_aAtZC2UY26qNYnpkRe3pg=.ac3e3a4a-837b-4d89-bfe9-25972f5d60a9@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <CAKFLZGwXI0arDJhfLwVap-MB9R3lSRvnhpOL2CzIfA=.0b0d5cf4-3917-413c-98ad-c9d738f543ea@github.com>
 <Nyq7U_Z1Ke7dlNhEcOvcj_aAtZC2UY26qNYnpkRe3pg=.ac3e3a4a-837b-4d89-bfe9-25972f5d60a9@github.com>
Message-ID: <JM9zx8Q6rf1h-yjum1-ji-9ygGQF_cjNCRaRWmqfB7M=.bed3ed24-409c-4277-ad9c-45e5659ba2e2@github.com>

On Thu, 13 May 2021 03:26:50 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Compiler related changes seems fine.
> @dougxc, note that jvmci is affected. It looks reasonable for me but you may need to check if it is correct from libgraal POV.

I tried to test this patch against GraalVM but am blocked due to `jdk.internal.vm.compiler` [no longer being upgradeable](https://bugs.openjdk.java.net/browse/JDK-8265091?focusedCommentId=14417587&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14417587).

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

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

From dcubed at openjdk.java.net  Thu May 13 15:40:55 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 13 May 2021 15:40:55 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5]
In-Reply-To: <ybmxMSsR_v-bmdrlWcYlVWIzSG-Y2hrh1sRM-W0unS8=.d92d33ac-3652-4e59-ac9b-88c68d1152a8@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>
 <ybmxMSsR_v-bmdrlWcYlVWIzSG-Y2hrh1sRM-W0unS8=.d92d33ac-3652-4e59-ac9b-88c68d1152a8@github.com>
Message-ID: <igOY4zVW88xolobwujv_5H5Hhu27zVDPrloAdmp2n74=.26cc168a-5836-4637-90ae-a28f0b3ca7a0@github.com>

On Thu, 13 May 2021 08:12:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop exit_delta and the VMTestbase style of exiting on test failure.
>
> Hi Dan,
> 
> Seems fine. Thanks for the updates.
> 
> The proof of a test is in its execution :)
> 
> David

@dholmes-ora - Thanks for the re-review. My Mach5 Tier[1-7] testing for an
earlier version of the test is documented in the bug report.

@plummercj - Are you still planning to review this new test?

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

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

From iklam at openjdk.java.net  Thu May 13 17:03:08 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 13 May 2021 17:03:08 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v3]
In-Reply-To: <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com>
Message-ID: <9DWWaiSiiVwftGvwmLgOMMB_EMXByhnYed1Ykqs41kk=.91f30a36-9789-4b93-882c-d9876c9dca38@github.com>

On Thu, 13 May 2021 04:59:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t
 hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
>> 
>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
>> - Manifestations of Thread::current() become JavaThread::current()
>> - THREAD->as_Java_thread() becomes just THREAD
>> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
>> 
>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
>> 
>> Testing:
>>  - tiers 1-8 on Linux-x64
>>  - all builds in tiers 1-4
>>  - tiers 1-3 on all platforms
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Update after merge with master
>  - Merge branch 'master' into 8252685-JavaThread
>  - Review feedback from Serguei
>  - Merge
>  - 8252685: APIs that require JavaThread should take JavaThread arguments

LGTM

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

Marked as reviewed by iklam (Reviewer).

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

From cjplummer at openjdk.java.net  Thu May 13 18:03:59 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 13 May 2021 18:03:59 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
In-Reply-To: <SCpNgoRbJtP_tyRfdvlkQVnE8r5_8Wa_t-8XdN3t4os=.023130cc-355f-485a-a72b-9567d30cfb77@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <SCpNgoRbJtP_tyRfdvlkQVnE8r5_8Wa_t-8XdN3t4os=.023130cc-355f-485a-a72b-9567d30cfb77@github.com>
Message-ID: <HeB_Rmg3k5H2K-xgCylYikJXO4-toR4Uaa-Q89KuvDY=.3e70686d-8b8b-4b68-a81b-25ea3ec87549@github.com>

On Tue, 27 Apr 2021 23:21:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
>> 
>> Currently running the new test thru Mach5 Tier[1-7].
>> I've run the test thru several 12 hour runs on my MBP13 and
>> on my Linux-X64 server.
>
> When reviewing this new test, is it worth comparing it with counter based tests that it was based on, or is it best just to view it as a completely new test.

> @plummercj - Are you still planning to review this new test?

Yes

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

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

From cjplummer at openjdk.java.net  Thu May 13 18:30:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 13 May 2021 18:30:56 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2]
In-Reply-To: <R7XeiE2Y_Kc0SfAYw2SH8z9fNtGPVFzJxQ_MHm9qei4=.3a09da67-54e5-4bc3-9217-02fb173aeffa@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <noWAINrOl6Nx3Hb3pBPPYa9ZXtlx45ohzGkiJk4x6Ww=.eaf2cf80-c1f6-4364-a4e4-8d01bb31902c@github.com>
 <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com>
 <iU84ArHG5BfpTsA9qXufnCU8y9rVIjflPMTYY5Ctqyk=.e1f1d3ef-e93d-46d1-9446-5ea468e4dfff@github.com>
 <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com>
 <R7XeiE2Y_Kc0SfAYw2SH8z9fNtGPVFzJxQ_MHm9qei4=.3a09da67-54e5-4bc3-9217-02fb173aeffa@github.com>
Message-ID: <yFXzSEB4su5QNw-13giZ1pXujz1XNxu8V4gGoWvik-A=.7e67d968-f8e7-4708-ae65-caecce4ec8fc@github.com>

On Thu, 13 May 2021 05:56:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Ok, this explanation seems reasonable, but is not something that is really conveyed with the the name `--prefix` or with the help "Sets the prefix to distinguish SA debugee". We are at the same giving too much and too little info. Too much in that we are saying that it is a prefix of some sort, which then leads to that fact that we don't explain how it is used in the RMI URL.
>> 
>> I'm not saying that we need to explain how  the `--connect [<id>@]<host>[:registryport][/prefix]` option is converted into an RMI URL (although perhaps we should), but it seems we at least need to describe the relation between `<id>` and `/prefix`. Otherwise no one is really going to understand how/why to use it.
>> 
>> Also, having the prefix at the end of the "serverID" string seems odd. Maybe it should be:
>> 
>>    [[prefix/]unique_id@]host[:port]
>
> Finally, all parameters will be transformed to `//host[:port]/<serverNamePrefix>['_'<unique_id>]`.
> `--prefix` and `id` affect to RMI object name to be precise. So ID is object name, then the prefix will be added to it.
> 
> Based on them, how about this?
> 
> 
> --prefix <url prefix> Set the prefix to add to debug server instance name.
> 
> 
> I understand is is odd the value is added to the tail even if it is named "prefix".
> Both `prefix` and `id` are optional, so we can specify `prefix` only, then `prefix/@host` is strange for me.
> 
> How about this pattern? Use ":" instead of "/" like a URL.
> 
> 
> [prefix:][unique_id@]host[:port]
> 
> 
> I thought to give new name instead of "prefix", but I give up because I have not good idea and would be inconsistent system property. (`sun.jvm.hotspot.rmi.serverNamePrefix`)

I think this is better, but I think better help output is needed. `prefix` has a default and `unique_id` does not. I think both of these need to be mentioned in the help output. Also, if `unique_id` is not specified, then the value of `prefix` is the name of the RMI object, which seems a bit odd because it is suppose to be a prefix to a name, not the entire name.

I think maybe the property name of `sun.jvm.hotspot.rmi.serverNamePrefix` was not a good choice, and is making it harder to come up with good argument names and syntax. If designing this from scratch, I would have called it `sun.jvm.hotspot.rmi.serverName`, and then appending an optional `unique_id` to it would make more sense.

What if instead of `prefix` you used `servername` and possibly also rename `sun.jvm.hotspot.rmi.serverNamePrefix` to `sun.jvm.hotspot.rmi.serverName`, but also keep legacy support in case someone is already using `sun.jvm.hotspot.rmi.serverNamePrefix` and decides to set it?

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

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

From mandy.chung at oracle.com  Thu May 13 18:50:22 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 13 May 2021 11:50:22 -0700
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
Message-ID: <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>

I did a search on java.base and the tests on `String::indexOf` and 
`String::contains` of a slash and don't spot any such test.? The JDK has 
no use of VM anonymous class.?? If the test is trying to determine if 
it's lambda proxy class, it should be converted to call 
`Class::isHidden` but testing of the class name containing a slash is 
still valid (I haven't found any of such test though).

Mandy

On 5/11/21 6:20 AM, Brian Goetz wrote:
> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>
> Sent from my iPad
>
>> On May 11, 2021, at 8:59 AM, Harold Seigel <hseigel at openjdk.java.net> wrote:
>>
>> ?Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>
>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>
>> Thanks, Harold
>>
>> -------------
>>
>> Commit messages:
>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/3974/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8243287
>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/3974.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3974

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210513/53a41c15/attachment-0001.htm>

From brian.goetz at oracle.com  Thu May 13 19:03:09 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 13 May 2021 15:03:09 -0400
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
 <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>
Message-ID: <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com>

Thanks for checking.? I thought I remembered something like this 
somewhere, but it may be that you already fixed such tests when you did 
hidden classes?? In any case, seems like we're all good now.

Cheers,
-Brian

On 5/13/2021 2:50 PM, Mandy Chung wrote:
> I did a search on java.base and the tests on `String::indexOf` and 
> `String::contains` of a slash and don't spot any such test.? The JDK 
> has no use of VM anonymous class. If the test is trying to determine 
> if it's lambda proxy class, it should be converted to call 
> `Class::isHidden` but testing of the class name containing a slash is 
> still valid (I haven't found any of such test though).
>
> Mandy
>
> On 5/11/21 6:20 AM, Brian Goetz wrote:
>> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>>
>> Sent from my iPad
>>
>>> On May 11, 2021, at 8:59 AM, Harold Seigel<hseigel at openjdk.java.net>  wrote:
>>>
>>> ?Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>>
>>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>>
>>> Thanks, Harold
>>>
>>> -------------
>>>
>>> Commit messages:
>>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>>
>>> Changes:https://git.openjdk.java.net/jdk/pull/3974/files
>>> Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>>   Issue:https://bugs.openjdk.java.net/browse/JDK-8243287
>>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>>   Patch:https://git.openjdk.java.net/jdk/pull/3974.diff
>>>   Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/3974/head:pull/3974
>>>
>>> PR:https://git.openjdk.java.net/jdk/pull/3974
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210513/17ba471e/attachment.htm>

From cjplummer at openjdk.java.net  Thu May 13 20:34:44 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 13 May 2021 20:34:44 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v10]
In-Reply-To: <XeqgnwWZzfkUaWorIXUVS4J33oGOfKBm6BjYAVLNRE4=.47c5bafb-e0ee-44d1-8c52-ed5304d24475@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <XeqgnwWZzfkUaWorIXUVS4J33oGOfKBm6BjYAVLNRE4=.47c5bafb-e0ee-44d1-8c52-ed5304d24475@github.com>
Message-ID: <E5n2jDHXDO-MrStBTr__jwFZzywVxlBpFxE6aNfybLw=.87f341a8-1ecc-4561-9be4-8a1ad0a36668@github.com>

On Wed, 12 May 2021 11:11:39 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into s-fix
>  - fix typo in comments
>  - Merge branch 'master' into s-fix
>  - Merge branch 'master'
>  - Merge branch 'master' into sf
>  - rename writeThrough to unbufferedMode and code refine
>  - fix typo in comments
>  - Merge branch 'master' into sf
>  - Revert "reduce memory consumption"
>    
>    This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e.
>  - reduce memory consumption
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/7dae89e1...6fde07bd

Overall looks good. I just have one question and a couple minor comment suggestions.

Also, can you do the same extra testing that you did for #2261

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1510:

> 1508:          */
> 1509:         private boolean shouldFlush() {
> 1510:             // unbuffered mode always flush data.

"flushes data"

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1528:

> 1526:             }
> 1527:             writeInteger(0);
> 1528:             writeInteger(size);

You've added `writeInteger(size)` here, but I'm not sure where this used to be done.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1577:

> 1575:         private boolean segmentMode;
> 1576:         private boolean allowSegmented;
> 1577:         // Writes data directly to underlying stream, don't use internal buffer.

It should be "Write data". I noticed you recently changed it to "Writes", but I'm not sure why. Also, make this two sentences rather than using a comma.

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

Changes requested by cjplummer (Reviewer).

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

From mandy.chung at oracle.com  Thu May 13 20:37:34 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 13 May 2021 13:37:34 -0700
Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass
In-Reply-To: <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com>
References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com>
 <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com>
 <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com>
 <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com>
Message-ID: <b8c0d26b-6994-2f72-66e8-390e78cae7a5@oracle.com>

Maybe you were thinking 
`jdk.internal.reflect.ReflectUtil::isVMAnonymousClass` that is now 
removed by this patch [1].

[1] 
https://github.com/openjdk/jdk/pull/3974/files#diff-1af3026a3b4942af3ebe6a4df02f8952fb9d51bf93336a2f7f93ce175d047574

On 5/13/21 12:03 PM, Brian Goetz wrote:
> Thanks for checking.? I thought I remembered something like this 
> somewhere, but it may be that you already fixed such tests when you 
> did hidden classes?? In any case, seems like we're all good now.
>
> Cheers,
> -Brian
>
> On 5/13/2021 2:50 PM, Mandy Chung wrote:
>> I did a search on java.base and the tests on `String::indexOf` and 
>> `String::contains` of a slash and don't spot any such test.? The JDK 
>> has no use of VM anonymous class.?? If the test is trying to 
>> determine if it's lambda proxy class, it should be converted to call 
>> `Class::isHidden` but testing of the class name containing a slash is 
>> still valid (I haven't found any of such test though).
>>
>> Mandy
>>
>> On 5/11/21 6:20 AM, Brian Goetz wrote:
>>> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?.  Did you do a search for these idioms too, which are now dead tests?
>>>
>>> Sent from my iPad
>>>
>>>> On May 11, 2021, at 8:59 AM, Harold Seigel<hseigel at openjdk.java.net>  wrote:
>>>>
>>>> ?Please review this large change to remove Unsafe::defineAnonymousClass().  The change removes dAC relevant code and changes a lot of tests.  Many of the changed tests need renaming.  I hope to do this in a follow up RFE.  Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes.
>>>>
>>>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64.
>>>>
>>>> Thanks, Harold
>>>>
>>>> -------------
>>>>
>>>> Commit messages:
>>>> - 8243287: Removal of Unsafe::defineAnonymousClass
>>>>
>>>> Changes:https://git.openjdk.java.net/jdk/pull/3974/files
>>>> Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00
>>>>   Issue:https://bugs.openjdk.java.net/browse/JDK-8243287
>>>>   Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod
>>>>   Patch:https://git.openjdk.java.net/jdk/pull/3974.diff
>>>>   Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/3974/head:pull/3974
>>>>
>>>> PR:https://git.openjdk.java.net/jdk/pull/3974
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210513/71fc6fd4/attachment-0001.htm>

From david.holmes at oracle.com  Fri May 14 00:06:59 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 14 May 2021 10:06:59 +1000
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v3]
In-Reply-To: <9DWWaiSiiVwftGvwmLgOMMB_EMXByhnYed1Ykqs41kk=.91f30a36-9789-4b93-882c-d9876c9dca38@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
 <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com>
 <9DWWaiSiiVwftGvwmLgOMMB_EMXByhnYed1Ykqs41kk=.91f30a36-9789-4b93-882c-d9876c9dca38@github.com>
Message-ID: <a2b55b3c-38b0-87d0-05dc-600528b7c9e0@oracle.com>

Thanks for the review Ioi!

David

On 14/05/2021 3:03 am, Ioi Lam wrote:
> On Thu, 13 May 2021 04:59:11 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t
>   hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
>>>
>>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
>>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
>>> - Manifestations of Thread::current() become JavaThread::current()
>>> - THREAD->as_Java_thread() becomes just THREAD
>>> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
>>>
>>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
>>>
>>> Testing:
>>>   - tiers 1-8 on Linux-x64
>>>   - all builds in tiers 1-4
>>>   - tiers 1-3 on all platforms
>>>
>>> Thanks,
>>> David
>>
>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>>
>>   - Update after merge with master
>>   - Merge branch 'master' into 8252685-JavaThread
>>   - Review feedback from Serguei
>>   - Merge
>>   - 8252685: APIs that require JavaThread should take JavaThread arguments
> 
> LGTM
> 
> -------------
> 
> Marked as reviewed by iklam (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/3877
> 

From ysuenaga at openjdk.java.net  Fri May 14 00:53:37 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 14 May 2021 00:53:37 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2]
In-Reply-To: <yFXzSEB4su5QNw-13giZ1pXujz1XNxu8V4gGoWvik-A=.7e67d968-f8e7-4708-ae65-caecce4ec8fc@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <noWAINrOl6Nx3Hb3pBPPYa9ZXtlx45ohzGkiJk4x6Ww=.eaf2cf80-c1f6-4364-a4e4-8d01bb31902c@github.com>
 <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com>
 <iU84ArHG5BfpTsA9qXufnCU8y9rVIjflPMTYY5Ctqyk=.e1f1d3ef-e93d-46d1-9446-5ea468e4dfff@github.com>
 <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com>
 <R7XeiE2Y_Kc0SfAYw2SH8z9fNtGPVFzJxQ_MHm9qei4=.3a09da67-54e5-4bc3-9217-02fb173aeffa@github.com>
 <yFXzSEB4su5QNw-13giZ1pXujz1XNxu8V4gGoWvik-A=.7e67d968-f8e7-4708-ae65-caecce4ec8fc@github.com>
Message-ID: <lJ-cHcD4XwU6KbDEOVYtQSIe7_bOCxv8qbNY71dGKXw=.b34c5a68-a7b9-43d4-ad98-45a5fdbc5b23@github.com>

On Thu, 13 May 2021 18:28:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I think maybe the property name of sun.jvm.hotspot.rmi.serverNamePrefix was not a good choice, and is making it harder to come up with good argument names and syntax. If designing this from scratch, I would have called it sun.jvm.hotspot.rmi.serverName, and then appending an optional unique_id to it would make more sense.

Agree.

> What if instead of prefix you used servername and possibly also rename sun.jvm.hotspot.rmi.serverNamePrefix to sun.jvm.hotspot.rmi.serverName, but also keep legacy support in case someone is already using sun.jvm.hotspot.rmi.serverNamePrefix and decides to set it?

Sounds good if we can do so! Indeed we need to send CSR for this issue, so we can do it.
We do not need to think to pass parameters via system properties because we have SALauncher. So I think against this issue as following. Is it ok?

* Add `--servername` option to debugd
    * debugd help describes about this as "instance name of debugd server"
    * man page of jhsdb describes that it is used for RMI object name, and describes "SARemoteDebugger" is set by default.
* Connection string is `[unique_id@]host[:port][/servername]`
* Change the description for `--serverid` in man page to "This is required if multiple debug servers are run on the same server instance. It would be added to RMI object name for server instance."
    * Will not change the help message because it seems to be enough to describe abstraction (A unique identifier for this debug server)
* Declare that `sun.jvm.hotspot.rmi.serverNamePrefix` will be deprecated in the CSR, and show the warning if it is set

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

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

From lzang at openjdk.java.net  Fri May 14 02:10:55 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 14 May 2021 02:10:55 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v10]
In-Reply-To: <E5n2jDHXDO-MrStBTr__jwFZzywVxlBpFxE6aNfybLw=.87f341a8-1ecc-4561-9be4-8a1ad0a36668@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <XeqgnwWZzfkUaWorIXUVS4J33oGOfKBm6BjYAVLNRE4=.47c5bafb-e0ee-44d1-8c52-ed5304d24475@github.com>
 <E5n2jDHXDO-MrStBTr__jwFZzywVxlBpFxE6aNfybLw=.87f341a8-1ecc-4561-9be4-8a1ad0a36668@github.com>
Message-ID: <P2uu3g9vn4QRnxsltfL0RGHqmfMEYwUynlJ1PxuVr7A=.e839185c-25c8-40f9-9d9a-4ae7232bfce7@github.com>

On Thu, 13 May 2021 20:23:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into s-fix
>>  - fix typo in comments
>>  - Merge branch 'master' into s-fix
>>  - Merge branch 'master'
>>  - Merge branch 'master' into sf
>>  - rename writeThrough to unbufferedMode and code refine
>>  - fix typo in comments
>>  - Merge branch 'master' into sf
>>  - Revert "reduce memory consumption"
>>    
>>    This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e.
>>  - reduce memory consumption
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/a02b1f29...6fde07bd
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1528:
> 
>> 1526:             }
>> 1527:             writeInteger(0);
>> 1528:             writeInteger(size);
> 
> You've added `writeInteger(size)` here, but I'm not sure where this used to be done.

There used to be 2 writeInterger(0), and the second one is write the segment size with dummy value 0. I will add a comment here. Thanks

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

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

From lzang at openjdk.java.net  Fri May 14 02:28:17 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 14 May 2021 02:28:17 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v11]
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <9waTwJ5eaX-nWBADd5H-yF3FPrpF_eA0pre3xnBFB24=.a25bddf7-5a2c-426f-877f-8faf312406f7@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

Lin Zang 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 14 additional commits since the last revision:

 - Merge branch 'master' into s-fix
 - Fix typo and add comment
 - Merge branch 'master' into s-fix
 - fix typo in comments
 - Merge branch 'master' into s-fix
 - Merge branch 'master'
 - Merge branch 'master' into sf
 - rename writeThrough to unbufferedMode and code refine
 - fix typo in comments
 - Merge branch 'master' into sf
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a0a8462d...01e1a107

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/6fde07bd..01e1a107

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=09-10

  Stats: 6272 lines in 202 files changed: 1865 ins; 3846 del; 561 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

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

From lzang at openjdk.java.net  Fri May 14 02:31:48 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 14 May 2021 02:31:48 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v11]
In-Reply-To: <9waTwJ5eaX-nWBADd5H-yF3FPrpF_eA0pre3xnBFB24=.a25bddf7-5a2c-426f-877f-8faf312406f7@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <9waTwJ5eaX-nWBADd5H-yF3FPrpF_eA0pre3xnBFB24=.a25bddf7-5a2c-426f-877f-8faf312406f7@github.com>
Message-ID: <VdUG06f4wS-_NezxA3TtNrtE_AEsE3lzC9QoHDA9LnY=.fd2eb82e-0ab0-4e52-a6c7-497fef4423a1@github.com>

On Fri, 14 May 2021 02:28:17 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
>
> Lin Zang 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 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into s-fix
>  - Fix typo and add comment
>  - Merge branch 'master' into s-fix
>  - fix typo in comments
>  - Merge branch 'master' into s-fix
>  - Merge branch 'master'
>  - Merge branch 'master' into sf
>  - rename writeThrough to unbufferedMode and code refine
>  - fix typo in comments
>  - Merge branch 'master' into sf
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/2204d556...01e1a107

Thanks Chris for suggestion. I will conduct the tests today and update asap.

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

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

From cjplummer at openjdk.java.net  Fri May 14 03:56:46 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 14 May 2021 03:56:46 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v10]
In-Reply-To: <P2uu3g9vn4QRnxsltfL0RGHqmfMEYwUynlJ1PxuVr7A=.e839185c-25c8-40f9-9d9a-4ae7232bfce7@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <XeqgnwWZzfkUaWorIXUVS4J33oGOfKBm6BjYAVLNRE4=.47c5bafb-e0ee-44d1-8c52-ed5304d24475@github.com>
 <E5n2jDHXDO-MrStBTr__jwFZzywVxlBpFxE6aNfybLw=.87f341a8-1ecc-4561-9be4-8a1ad0a36668@github.com>
 <P2uu3g9vn4QRnxsltfL0RGHqmfMEYwUynlJ1PxuVr7A=.e839185c-25c8-40f9-9d9a-4ae7232bfce7@github.com>
Message-ID: <8oyXWVSuwtRYsbfodxnK0uyl0mh2Xit0Ixg5JOM4XzE=.99e943e5-fde5-476f-8428-ba86dec0a53c@github.com>

On Fri, 14 May 2021 02:08:13 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1528:
>> 
>>> 1526:             }
>>> 1527:             writeInteger(0);
>>> 1528:             writeInteger(size);
>> 
>> You've added `writeInteger(size)` here, but I'm not sure where this used to be done.
>
> There used to be 2 writeInterger(0), and the second one is write the segment size with dummy value 0. I will add a comment here. Thanks

Ok, I missed that. I think where a comment is needed is with the first `writerInteger(0)`. It's not clear to me what that one is for.

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

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

From cjplummer at openjdk.java.net  Fri May 14 04:10:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 14 May 2021 04:10:43 GMT
Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2]
In-Reply-To: <lJ-cHcD4XwU6KbDEOVYtQSIe7_bOCxv8qbNY71dGKXw=.b34c5a68-a7b9-43d4-ad98-45a5fdbc5b23@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <noWAINrOl6Nx3Hb3pBPPYa9ZXtlx45ohzGkiJk4x6Ww=.eaf2cf80-c1f6-4364-a4e4-8d01bb31902c@github.com>
 <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com>
 <iU84ArHG5BfpTsA9qXufnCU8y9rVIjflPMTYY5Ctqyk=.e1f1d3ef-e93d-46d1-9446-5ea468e4dfff@github.com>
 <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com>
 <R7XeiE2Y_Kc0SfAYw2SH8z9fNtGPVFzJxQ_MHm9qei4=.3a09da67-54e5-4bc3-9217-02fb173aeffa@github.com>
 <yFXzSEB4su5QNw-13giZ1pXujz1XNxu8V4gGoWvik-A=.7e67d968-f8e7-4708-ae65-caecce4ec8fc@github.com>
 <lJ-cHcD4XwU6KbDEOVYtQSIe7_bOCxv8qbNY71dGKXw=.b34c5a68-a7b9-43d4-ad98-45a5fdbc5b23@github.com>
Message-ID: <EnbcGZd1YOTVod5XefMMW0W9abp1vfNn6TBsQGy4pzc=.ad5662dd-7a4e-4183-95ca-7d778eb94d4c@github.com>

On Fri, 14 May 2021 00:51:12 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I think this is better, but I think better help output is needed. `prefix` has a default and `unique_id` does not. I think both of these need to be mentioned in the help output. Also, if `unique_id` is not specified, then the value of `prefix` is the name of the RMI object, which seems a bit odd because it is suppose to be a prefix to a name, not the entire name.
>> 
>> I think maybe the property name of `sun.jvm.hotspot.rmi.serverNamePrefix` was not a good choice, and is making it harder to come up with good argument names and syntax. If designing this from scratch, I would have called it `sun.jvm.hotspot.rmi.serverName`, and then appending an optional `unique_id` to it would make more sense.
>> 
>> What if instead of `prefix` you used `servername` and possibly also rename `sun.jvm.hotspot.rmi.serverNamePrefix` to `sun.jvm.hotspot.rmi.serverName`, but also keep legacy support in case someone is already using `sun.jvm.hotspot.rmi.serverNamePrefix` and decides to set it?
>
>> I think maybe the property name of sun.jvm.hotspot.rmi.serverNamePrefix was not a good choice, and is making it harder to come up with good argument names and syntax. If designing this from scratch, I would have called it sun.jvm.hotspot.rmi.serverName, and then appending an optional unique_id to it would make more sense.
> 
> Agree.
> 
>> What if instead of prefix you used servername and possibly also rename sun.jvm.hotspot.rmi.serverNamePrefix to sun.jvm.hotspot.rmi.serverName, but also keep legacy support in case someone is already using sun.jvm.hotspot.rmi.serverNamePrefix and decides to set it?
> 
> Sounds good if we can do so! Indeed we need to send CSR for this issue, so we can do it.
> We do not need to think to pass parameters via system properties because we have SALauncher. So I think against this issue as following. Is it ok?
> 
> * Add `--servername` option to debugd
>     * debugd help describes about this as "instance name of debugd server"
>     * man page of jhsdb describes that it is used for RMI object name, and describes "SARemoteDebugger" is set by default.
> * Connection string is `[unique_id@]host[:port][/servername]`
> * Change the description for `--serverid` in man page to "This is required if multiple debug servers are run on the same server instance. It would be added to RMI object name for server instance."
>     * Will not change the help message because it seems to be enough to describe abstraction (A unique identifier for this debug server)
> * Declare that `sun.jvm.hotspot.rmi.serverNamePrefix` will be deprecated in the CSR, and show the warning if it is set

We already have a CSR. I think it can cover both the addition of `--servername` and the rename of `serverNamePrefix`.

We need to be more consistent with the use of `serverid`. Between the man page, help output, and code we call use `serverid`, `<id>` and `uniqueID`. We should use `serverid` in all cases.

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

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

From cjplummer at openjdk.java.net  Fri May 14 04:48:35 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 14 May 2021 04:48:35 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5]
In-Reply-To: <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>
Message-ID: <gAgdgxMoCwVO004MxpPuH1WcNpc0u8rgKktQR3g7y4M=.b11fba84-8d9e-4556-90c4-4ca03abe6d20@github.com>

On Tue, 11 May 2021 23:34:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
>> 
>> Currently running the new test thru Mach5 Tier[1-7].
>> I've run the test thru several 12 hour runs on my MBP13 and
>> on my Linux-X64 server.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop exit_delta and the VMTestbase style of exiting on test failure.

Overall it looks good. Some minor suggestions, most of which can be ignored if you wish.

Is there a reason these tests were not placed under `test/jdk/java/lang/management`?

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 70:

> 68: //
> 69: 
> 70: public class getLockOwnerName {

Shouldn't this be called GetLockOwnerName? We don't usually use lower case for a class name.

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 150:

> 148:         System.err.println("where:");
> 149:         System.err.println("    -p       ::= print debug info");
> 150:         System.err.println("    time_max ::= max looping time in seconds");

`::=` doesn't seem to be a convention we use in help output other than in the other recent tests you've added.

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 324:

> 322: 
> 323:         //
> 324:         // Launch the blocker thread:

The comment says "Launch the blocker thread", but this thread is already launched. Maybe drop "Launch" in favor of "Run", or just say "The block thread". Same comment for the other two threads.

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 329:

> 327:         // - releases threadLock
> 328:         //
> 329:         if (getName().equals("blocker")) {

Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda.

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

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

From lzang at openjdk.java.net  Fri May 14 07:09:45 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 14 May 2021 07:09:45 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v10]
In-Reply-To: <8oyXWVSuwtRYsbfodxnK0uyl0mh2Xit0Ixg5JOM4XzE=.99e943e5-fde5-476f-8428-ba86dec0a53c@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <XeqgnwWZzfkUaWorIXUVS4J33oGOfKBm6BjYAVLNRE4=.47c5bafb-e0ee-44d1-8c52-ed5304d24475@github.com>
 <E5n2jDHXDO-MrStBTr__jwFZzywVxlBpFxE6aNfybLw=.87f341a8-1ecc-4561-9be4-8a1ad0a36668@github.com>
 <P2uu3g9vn4QRnxsltfL0RGHqmfMEYwUynlJ1PxuVr7A=.e839185c-25c8-40f9-9d9a-4ae7232bfce7@github.com>
 <8oyXWVSuwtRYsbfodxnK0uyl0mh2Xit0Ixg5JOM4XzE=.99e943e5-fde5-476f-8428-ba86dec0a53c@github.com>
Message-ID: <8goAagr_Vyc741-zWx4_IiIQ-VCjsK7aaC5xP7JG2bg=.34640245-1158-44a4-b5f8-0af6a84b46b2@github.com>

On Fri, 14 May 2021 03:53:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> There used to be 2 writeInterger(0), and the second one is write the segment size with dummy value 0. I will add a comment here. Thanks
>
> Ok, I missed that. I think where a comment is needed is with the first `writerInteger(0)`. It's not clear to me what that one is for.

OK, I will add it.  it is a dummy value for `timestamp` slot.And seems it is never fill with real time stamp in current implementation.

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

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

From rschmelter at openjdk.java.net  Fri May 14 07:14:07 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Fri, 14 May 2021 07:14:07 GMT
Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with
 EOFException [v2]
In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
Message-ID: <BKktAXQZwjk11F7-iPduZ0Az_z8mAZiybCB89cB6sUk=.fb3b17c7-a5ea-4a87-84ca-9c969d12d8c6@github.com>

> This fixes a race condition in the CompressionBackend class of the heap dump code.
> 
> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself.
> 
> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen.
> 
> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking.

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

 - Simplify thread_loop()
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661
 - Fix punctuation
 - Simplify code
 - Fix race in heap dump compression backend

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3628/files
  - new: https://git.openjdk.java.net/jdk/pull/3628/files/fb17cab8..1891197a

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

  Stats: 555249 lines in 4988 files changed: 44477 ins; 497699 del; 13073 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3628.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3628/head:pull/3628

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

From rrich at openjdk.java.net  Fri May 14 07:28:49 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 14 May 2021 07:28:49 GMT
Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with
 EOFException [v2]
In-Reply-To: <BKktAXQZwjk11F7-iPduZ0Az_z8mAZiybCB89cB6sUk=.fb3b17c7-a5ea-4a87-84ca-9c969d12d8c6@github.com>
References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
 <BKktAXQZwjk11F7-iPduZ0Az_z8mAZiybCB89cB6sUk=.fb3b17c7-a5ea-4a87-84ca-9c969d12d8c6@github.com>
Message-ID: <MDwkhBvofX-P07BSCzmfoVNpK0HSnQUYXnm2FVyp2cs=.8628bb13-23b2-4773-8377-3afc3e4aa18a@github.com>

On Fri, 14 May 2021 07:14:07 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> This fixes a race condition in the CompressionBackend class of the heap dump code.
>> 
>> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself.
>> 
>> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen.
>> 
>> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking.
>
> Ralf Schmelter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Simplify thread_loop()
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661
>  - Fix punctuation
>  - Simplify code
>  - Fix race in heap dump compression backend

LGTM ??

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

Marked as reviewed by rrich (Reviewer).

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

From lzang at openjdk.java.net  Fri May 14 09:41:08 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 14 May 2021 09:41:08 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v12]
In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
Message-ID: <tbI8LyCELD0Ht4-wFAP1fvMBBOySU-RA4DDWItXvtIM=.918d3165-bfc1-4700-b2b0-9686bd11c9a4@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

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

 - Merge branch 'master' into s-fix
 - add comment for the timestamp value
 - Merge branch 'master' into s-fix
 - Fix typo and add comment
 - Merge branch 'master' into s-fix
 - fix typo in comments
 - Merge branch 'master' into s-fix
 - Merge branch 'master'
 - Merge branch 'master' into sf
 - rename writeThrough to unbufferedMode and code refine
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/aac1e78c...c80a10e0

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/01e1a107..c80a10e0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=10-11

  Stats: 84 lines in 12 files changed: 16 ins; 39 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

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

From lzang at openjdk.java.net  Fri May 14 09:41:18 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 14 May 2021 09:41:18 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v11]
In-Reply-To: <9waTwJ5eaX-nWBADd5H-yF3FPrpF_eA0pre3xnBFB24=.a25bddf7-5a2c-426f-877f-8faf312406f7@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <9waTwJ5eaX-nWBADd5H-yF3FPrpF_eA0pre3xnBFB24=.a25bddf7-5a2c-426f-877f-8faf312406f7@github.com>
Message-ID: <IKwn9uMa7GmcPlI0f2tyu3Rmqscp5-QPZpOzr09ytLo=.850065f8-6a1c-417e-a3e5-55e0f09b5630@github.com>

On Fri, 14 May 2021 02:28:17 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
>
> Lin Zang 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 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into s-fix
>  - Fix typo and add comment
>  - Merge branch 'master' into s-fix
>  - fix typo in comments
>  - Merge branch 'master' into s-fix
>  - Merge branch 'master'
>  - Merge branch 'master' into sf
>  - rename writeThrough to unbufferedMode and code refine
>  - fix typo in comments
>  - Merge branch 'master' into sf
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/45b46a08...01e1a107

Here are the tests I have conducted:
1. Passed test tier1 and tier2 (tier3 not executed)
2. Tested to dump netbeans with heap size at ~500MB, ~700MB and 1GB,  and tested w/o `-gz` option from 1-9. all passed.
3. A workload that generate different object to fill heap, I have tested with heap usage from 1GB to 8GB with different `gz` options. All passed.

Thanks !
Lin

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

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

From rrich at openjdk.java.net  Fri May 14 18:04:39 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 14 May 2021 18:04:39 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
Message-ID: <X46Kp3Cy0BXs9HtgCGe_HRWEu-aPsNToCJFY6nH83Dw=.68a30070-3b54-42f2-9672-da28a94a5b10@github.com>

On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes for Dan

Hi Robbin,

there seem to be issues in the jvmtiRawMonitor part of the change. Besides that it looks good.

Cheers, Richard.

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 47:

> 45:   JavaThread* current_java_thread = JavaThread::current();
> 46:   assert(current_java_thread->thread_state() == _thread_in_vm, "Must be in vm");
> 47:   {

Looks like the assertion in L46 is redundant now. ThreadToNativeFromVM asserts as well.

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 386:

> 384:     _waiters++;
> 385:     ret = simple_wait(self, millis);
> 386:     _waiters--;

We don't own the monitor yet so you cannot modify `_waiters` here.
Any reason you moved and duplicated this block?

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 410:

> 408:     ret = simple_wait(self, millis);
> 409:     _waiters--;
> 410:     _recursions = save;

The values of `_waiters` and `_recursions` should be adjusted after the monitor is owned again.

src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52:

> 50: // native for all operations. However we need to honor a suspend request, not
> 51: // entering a monitor if suspended, and check for interrupts. Honoring a suspend
> 52: // request// and reading the interrupt flag must be done from VM state

`s/request///request/` ??

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

Changes requested by rrich (Reviewer).

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

From cjplummer at openjdk.java.net  Fri May 14 18:07:47 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 14 May 2021 18:07:47 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v12]
In-Reply-To: <tbI8LyCELD0Ht4-wFAP1fvMBBOySU-RA4DDWItXvtIM=.918d3165-bfc1-4700-b2b0-9686bd11c9a4@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <tbI8LyCELD0Ht4-wFAP1fvMBBOySU-RA4DDWItXvtIM=.918d3165-bfc1-4700-b2b0-9686bd11c9a4@github.com>
Message-ID: <R-YzAICad4UxNlkoPdeQzrQa0rGSMxMiIdNR-i2FQbk=.38d0722d-14ec-4a23-98e4-cdddb50983f4@github.com>

On Fri, 14 May 2021 09:41:08 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'master' into s-fix
>  - add comment for the timestamp value
>  - Merge branch 'master' into s-fix
>  - Fix typo and add comment
>  - Merge branch 'master' into s-fix
>  - fix typo in comments
>  - Merge branch 'master' into s-fix
>  - Merge branch 'master'
>  - Merge branch 'master' into sf
>  - rename writeThrough to unbufferedMode and code refine
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/1672cc1a...c80a10e0

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Fri May 14 18:28:51 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 14 May 2021 18:28:51 GMT
Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with
 EOFException [v2]
In-Reply-To: <BKktAXQZwjk11F7-iPduZ0Az_z8mAZiybCB89cB6sUk=.fb3b17c7-a5ea-4a87-84ca-9c969d12d8c6@github.com>
References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
 <BKktAXQZwjk11F7-iPduZ0Az_z8mAZiybCB89cB6sUk=.fb3b17c7-a5ea-4a87-84ca-9c969d12d8c6@github.com>
Message-ID: <tBlDapILVmOrh6fAEOGK8Z48gRqUNWJGubPxkN-Z2Jk=.f454e0b5-8036-461e-965d-017665e2d961@github.com>

On Fri, 14 May 2021 07:14:07 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> This fixes a race condition in the CompressionBackend class of the heap dump code.
>> 
>> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself.
>> 
>> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen.
>> 
>> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking.
>
> Ralf Schmelter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Simplify thread_loop()
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661
>  - Fix punctuation
>  - Simplify code
>  - Fix race in heap dump compression backend

Changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

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

From rrich at openjdk.java.net  Fri May 14 19:45:11 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 14 May 2021 19:45:11 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
Message-ID: <sL2ks0f0hV_KHAVEbxWI0pxdnoabwDRdP2NZfG4IDiY=.3b6fce14-795c-4168-94bb-550839007b26@github.com>

On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes for Dan

> 
> 
> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 12/05/2021 8:56 pm, Robbin Ehn wrote:
> 
> > On Wed, 12 May 2021 08:27:33 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
> > > Hi Robbin,
> > > I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed.
> > > Thanks, Richard.
> > 
> > 
> > Hi Richard,
> > I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function.
> > Regarding ThreadClosure, we could use it, maybe that is preferable?!
> 
> Isn't a ThreadClosure for applying an operation to a set of threads?
> That is not what we are doing here.

No it isn't. A closure is just a set of variable bindings and a function that can be executed. And yes we're doing just that.

A ThreadClosure is just an instance of this general concept. E.g. an AsyncHandshakeClosure (subclass of ThreadClosure) is a function (plus variable bindings) that is passed by a requesting thread to a target thread to be executed by it.

Thanks,
Richard.

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

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

From dcubed at openjdk.java.net  Fri May 14 22:14:56 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 14 May 2021 22:14:56 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5]
In-Reply-To: <gAgdgxMoCwVO004MxpPuH1WcNpc0u8rgKktQR3g7y4M=.b11fba84-8d9e-4556-90c4-4ca03abe6d20@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>
 <gAgdgxMoCwVO004MxpPuH1WcNpc0u8rgKktQR3g7y4M=.b11fba84-8d9e-4556-90c4-4ca03abe6d20@github.com>
Message-ID: <sTst2nzOG3PC_x7hFI_EBYyBSFCewaip-ekTx_vHzhA=.e2910a84-24ff-49f1-8ec6-4d61fb2ea853@github.com>

On Fri, 14 May 2021 04:45:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Overall it looks good. Some minor suggestions, most of which can be ignored if you wish.

Thanks for the review. I made some of the changes, but not all of them.


> Is there a reason these tests were not placed under test/jdk/java/lang/management?

These tests are for stressing particular HotSpot implementation pieces that are used
by the M&M APIs. In particular, they are stressing the use of ThreadsListHandles
in both the safepoint and non-safepoint code paths traveled by getThreadInfo():


                // maxDepth == 0 requires no safepoint so alternate.
                int maxDepth = ((count % 1) == 1) ? Integer.MAX_VALUE : 0;
                info = mbean.getThreadInfo(id, maxDepth);
                if (info == null) {
                    // the contender has exited
                    break;
                }
                name = info.getLockOwnerName();


And we're stressing getLockOwnerName() because we had a non-reproducible
bug that crashed in that particular function after the getThreadInfo() call.

So I think this stress test (along with others that I've written in this family) belong
in the test/hotspot collection of tests.

> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 70:
> 
>> 68: //
>> 69: 
>> 70: public class getLockOwnerName {
> 
> Shouldn't this be called GetLockOwnerName? We don't usually use lower case for a class name.

Looks like I did that because the API is called:
ThreadInfo.getLockOwnerName()
Will fix the filenames and the classname.

> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 150:
> 
>> 148:         System.err.println("where:");
>> 149:         System.err.println("    -p       ::= print debug info");
>> 150:         System.err.println("    time_max ::= max looping time in seconds");
> 
> `::=` doesn't seem to be a convention we use in help output other than in the other recent tests you've added.

It's a grammar notational style from my compiler theory days.
I've used '::=' and ':=' for years. What would you like it changed to?
Or can I just leave it and try to use '-' in the future?

> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 324:
> 
>> 322: 
>> 323:         //
>> 324:         // Launch the blocker thread:
> 
> The comment says "Launch the blocker thread", but this thread is already launched. Maybe drop "Launch" in favor of "Run", or just say "The block thread". Same comment for the other two threads.

Fixed.

> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 329:
> 
>> 327:         // - releases threadLock
>> 328:         //
>> 329:         if (getName().equals("blocker")) {
> 
> Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda.

This new test is a variation of a 20 year old test that I recently ported to JVM/TI
and integrated. 20 years ago, it was much simpler to write the test this way.
I could create a separate Thread subclass for each "role", but I'd rather not
do that since it will no longer be easy to compare this test to its siblings.

As for lambdas, I know absolutely zero about writing lambda code.

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

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

From dcubed at openjdk.java.net  Fri May 14 22:20:31 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 14 May 2021 22:20:31 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v6]
In-Reply-To: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
Message-ID: <fCEwBPavzPXZu2sQN1lu7FkDiGU8XqjGxUfsJmerGKY=.a4c71913-0f9c-43f1-8226-385cb16a7e3d@github.com>

> The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
> 
> Currently running the new test thru Mach5 Tier[1-7].
> I've run the test thru several 12 hour runs on my MBP13 and
> on my Linux-X64 server.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  plummercj CR changes.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3478/files
  - new: https://git.openjdk.java.net/jdk/pull/3478/files/771dafee..6a8e5e37

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

  Stats: 831 lines in 3 files changed: 415 ins; 415 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3478.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478

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

From cjplummer at openjdk.java.net  Fri May 14 22:44:54 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 14 May 2021 22:44:54 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5]
In-Reply-To: <sTst2nzOG3PC_x7hFI_EBYyBSFCewaip-ekTx_vHzhA=.e2910a84-24ff-49f1-8ec6-4d61fb2ea853@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>
 <gAgdgxMoCwVO004MxpPuH1WcNpc0u8rgKktQR3g7y4M=.b11fba84-8d9e-4556-90c4-4ca03abe6d20@github.com>
 <sTst2nzOG3PC_x7hFI_EBYyBSFCewaip-ekTx_vHzhA=.e2910a84-24ff-49f1-8ec6-4d61fb2ea853@github.com>
Message-ID: <UvogTwA5b5AXKPlfa5SA4EdsQh3jxg3sW2X84ng7mPI=.abf66a65-d7a0-4a87-9bcd-7627b74f7668@github.com>

On Fri, 14 May 2021 21:54:46 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 150:
>> 
>>> 148:         System.err.println("where:");
>>> 149:         System.err.println("    -p       ::= print debug info");
>>> 150:         System.err.println("    time_max ::= max looping time in seconds");
>> 
>> `::=` doesn't seem to be a convention we use in help output other than in the other recent tests you've added.
>
> It's a grammar notational style from my compiler theory days.
> I've used '::=' and ':=' for years. What would you like it changed to?
> Or can I just leave it and try to use '-' in the future?

The convention for java tools seems to be to just use tabs to align the start of the argument descriptions:


   -p          print debug info
   time_max    max looping time in seconds

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

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

From cjplummer at openjdk.java.net  Fri May 14 22:57:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 14 May 2021 22:57:39 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5]
In-Reply-To: <sTst2nzOG3PC_x7hFI_EBYyBSFCewaip-ekTx_vHzhA=.e2910a84-24ff-49f1-8ec6-4d61fb2ea853@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>
 <gAgdgxMoCwVO004MxpPuH1WcNpc0u8rgKktQR3g7y4M=.b11fba84-8d9e-4556-90c4-4ca03abe6d20@github.com>
 <sTst2nzOG3PC_x7hFI_EBYyBSFCewaip-ekTx_vHzhA=.e2910a84-24ff-49f1-8ec6-4d61fb2ea853@github.com>
Message-ID: <e6s9i95DZgIXxCzKhyMv8wDAyHu_YtUxLWcFQBnmOhc=.fd5dc23f-a270-4cd0-b1fa-e904f1115acd@github.com>

On Fri, 14 May 2021 22:04:05 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 329:
>> 
>>> 327:         // - releases threadLock
>>> 328:         //
>>> 329:         if (getName().equals("blocker")) {
>> 
>> Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda.
>
> This new test is a variation of a 20 year old test that I recently ported to JVM/TI
> and integrated. 20 years ago, it was much simpler to write the test this way.
> I could create a separate Thread subclass for each "role", but I'd rather not
> do that since it will no longer be easy to compare this test to its siblings.
> 
> As for lambdas, I know absolutely zero about writing lambda code.

Ok. I get it about lambdas, but they can be useful for simplifying thread tasks without creating a subclass. Here are a few examples, but no need for you to replicate any them:


    // create thread with specified method as the "run" method
    Thread t = new Thread(this::testMethod);
    t.start();



    // create thread with the specified code block as the "run" method
    Thread t1 = new Thread(() -> {
        synchronized (lock1) {
            System.out.println("Thread in sync section 1: "
                    + Thread.currentThread().getName());
            test1();
        }



    // create a static Runnable object using a lambda and use it as the Runnable for a new Thread
    static final Runnable CONSUMER = () -> {
        remove(QUEUE);
    };
    ...
    Thread t = new Thread(CONSUMER);

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

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

From dcubed at openjdk.java.net  Fri May 14 23:58:03 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 14 May 2021 23:58:03 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
In-Reply-To: <HeB_Rmg3k5H2K-xgCylYikJXO4-toR4Uaa-Q89KuvDY=.3e70686d-8b8b-4b68-a81b-25ea3ec87549@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <SCpNgoRbJtP_tyRfdvlkQVnE8r5_8Wa_t-8XdN3t4os=.023130cc-355f-485a-a72b-9567d30cfb77@github.com>
 <HeB_Rmg3k5H2K-xgCylYikJXO4-toR4Uaa-Q89KuvDY=.3e70686d-8b8b-4b68-a81b-25ea3ec87549@github.com>
Message-ID: <GN8Ik7P9YGziDcnYNCtXhWGeHLt8egb4ew3lhFZva0k=.0a35d742-ae6f-4726-a457-765bcb26bd91@github.com>

On Thu, 13 May 2021 18:01:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> When reviewing this new test, is it worth comparing it with counter based tests that it was based on, or is it best just to view it as a completely new test.
>
>> @plummercj - Are you still planning to review this new test?
> 
> Yes

@plummercj - please mark this as 'Reviewed' if this latest version is acceptable. Thanks.

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

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

From dcubed at openjdk.java.net  Fri May 14 23:58:03 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 14 May 2021 23:58:03 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v7]
In-Reply-To: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
Message-ID: <BW-umVx-kt-b-sfKys8W55b-g44UpoZuXrSPJ0VCKNs=.49225d8f-03b1-49fc-9976-f0c59a7a914c@github.com>

> The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
> 
> Currently running the new test thru Mach5 Tier[1-7].
> I've run the test thru several 12 hour runs on my MBP13 and
> on my Linux-X64 server.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  plummercj CR - drop '::=' from the usage() output.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3478/files
  - new: https://git.openjdk.java.net/jdk/pull/3478/files/6a8e5e37..185ee0f5

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

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

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

From dcubed at openjdk.java.net  Fri May 14 23:58:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 14 May 2021 23:58:04 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5]
In-Reply-To: <UvogTwA5b5AXKPlfa5SA4EdsQh3jxg3sW2X84ng7mPI=.abf66a65-d7a0-4a87-9bcd-7627b74f7668@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>
 <gAgdgxMoCwVO004MxpPuH1WcNpc0u8rgKktQR3g7y4M=.b11fba84-8d9e-4556-90c4-4ca03abe6d20@github.com>
 <sTst2nzOG3PC_x7hFI_EBYyBSFCewaip-ekTx_vHzhA=.e2910a84-24ff-49f1-8ec6-4d61fb2ea853@github.com>
 <UvogTwA5b5AXKPlfa5SA4EdsQh3jxg3sW2X84ng7mPI=.abf66a65-d7a0-4a87-9bcd-7627b74f7668@github.com>
Message-ID: <KUrpacrKPvDZtIyJD3UOHQn_5hcwjfvhlbcvM3MSkVU=.c74bcf1b-db0d-4e11-9b59-2f9423b58963@github.com>

On Fri, 14 May 2021 22:41:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It's a grammar notational style from my compiler theory days.
>> I've used '::=' and ':=' for years. What would you like it changed to?
>> Or can I just leave it and try to use '-' in the future?
>
> The convention for java tools seems to be to just use tabs to align the start of the argument descriptions:
> 
> 
>    -p          print debug info
>    time_max    max looping time in seconds

Fixed.

>> This new test is a variation of a 20 year old test that I recently ported to JVM/TI
>> and integrated. 20 years ago, it was much simpler to write the test this way.
>> I could create a separate Thread subclass for each "role", but I'd rather not
>> do that since it will no longer be easy to compare this test to its siblings.
>> 
>> As for lambdas, I know absolutely zero about writing lambda code.
>
> Ok. I get it about lambdas, but they can be useful for simplifying thread tasks without creating a subclass. Here are a few examples, but no need for you to replicate any them:
> 
> 
>     // create thread with specified method as the "run" method
>     Thread t = new Thread(this::testMethod);
>     t.start();
> 
> 
> 
>     // create thread with the specified code block as the "run" method
>     Thread t1 = new Thread(() -> {
>         synchronized (lock1) {
>             System.out.println("Thread in sync section 1: "
>                     + Thread.currentThread().getName());
>             test1();
>         }
> 
> 
> 
>     // create a static Runnable object using a lambda and use it as the Runnable for a new Thread
>     static final Runnable CONSUMER = () -> {
>         remove(QUEUE);
>     };
>     ...
>     Thread t = new Thread(CONSUMER);

I'll pass on the lambdas.

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

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

From ysuenaga at openjdk.java.net  Sat May 15 02:00:15 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 15 May 2021 02:00:15 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v3]
In-Reply-To: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
Message-ID: <TraaQakfH6DYbgnie89jGZzQMEk36HCNOVwnmPej1Vg=.ef619ac6-8767-4221-b278-88272e8834f7@github.com>

> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
> 
> As a result, remote name will be constructed as following:
> 
> 
> //host[:port]/<serverNamePrefix>['_'<id>]
> 
> 
> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
> 
> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
> 
> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.

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

  8263635: Add --servername option to jhsdb debugd

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3669/files
  - new: https://git.openjdk.java.net/jdk/pull/3669/files/af154a77..03ed5d19

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

  Stats: 131 lines in 12 files changed: 26 ins; 12 del; 93 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3669.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3669/head:pull/3669

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

From ysuenaga at openjdk.java.net  Sat May 15 02:03:37 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 15 May 2021 02:03:37 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v3]
In-Reply-To: <TraaQakfH6DYbgnie89jGZzQMEk36HCNOVwnmPej1Vg=.ef619ac6-8767-4221-b278-88272e8834f7@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <TraaQakfH6DYbgnie89jGZzQMEk36HCNOVwnmPej1Vg=.ef619ac6-8767-4221-b278-88272e8834f7@github.com>
Message-ID: <hjRQaC5Pudp0gFDHg92YBXBeGgo-3vNiVCr8ufmnkgc=.c6609739-17dd-4a72-bc13-74fb260402c7@github.com>

On Sat, 15 May 2021 02:00:15 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
>> 
>> As a result, remote name will be constructed as following:
>> 
>> 
>> //host[:port]/<serverNamePrefix>['_'<id>]
>> 
>> 
>> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>> 
>> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
>> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
>> 
>> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
>> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263635: Add --servername option to jhsdb debugd

@plummercj I updated the CSR and JBS issue to rename to `--servername`, and also I pushed new commit to follow them. It includes the update for help message, man page, and variable names.

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

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

From cjplummer at openjdk.java.net  Sat May 15 03:00:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 15 May 2021 03:00:40 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v7]
In-Reply-To: <BW-umVx-kt-b-sfKys8W55b-g44UpoZuXrSPJ0VCKNs=.49225d8f-03b1-49fc-9976-f0c59a7a914c@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <BW-umVx-kt-b-sfKys8W55b-g44UpoZuXrSPJ0VCKNs=.49225d8f-03b1-49fc-9976-f0c59a7a914c@github.com>
Message-ID: <vQn9MSFt6eJ2BICQrkgG-ad3KRsNmF6zqSf6USQ7uhI=.c2708125-72ea-42ef-9546-55b47005fda4@github.com>

On Fri, 14 May 2021 23:58:03 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
>> 
>> Currently running the new test thru Mach5 Tier[1-7].
>> I've run the test thru several 12 hour runs on my MBP13 and
>> on my Linux-X64 server.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   plummercj CR - drop '::=' from the usage() output.

Marked as reviewed by cjplummer (Reviewer).

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

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

From dcubed at openjdk.java.net  Sat May 15 13:17:42 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 15 May 2021 13:17:42 GMT
Subject: RFR: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5]
In-Reply-To: <ybmxMSsR_v-bmdrlWcYlVWIzSG-Y2hrh1sRM-W0unS8=.d92d33ac-3652-4e59-ac9b-88c68d1152a8@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
 <PyN9Iix6AxeV4b7LY1PZK4O8bk0-ePZeL5n1c_pzddA=.a2256de6-df92-41cb-9a11-e0f77adce3bc@github.com>
 <ybmxMSsR_v-bmdrlWcYlVWIzSG-Y2hrh1sRM-W0unS8=.d92d33ac-3652-4e59-ac9b-88c68d1152a8@github.com>
Message-ID: <k3KkaBbzkmUp5_F86cKY0b4eyT5TXl3qk4aroqWtdBQ=.fa3110cf-1c8a-447f-bd74-674b1789c678@github.com>

On Thu, 13 May 2021 08:12:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop exit_delta and the VMTestbase style of exiting on test failure.
>
> Hi Dan,
> 
> Seems fine. Thanks for the updates.
> 
> The proof of a test is in its execution :)
> 
> David

@dholmes-ora and @plummercj - Thanks for the reviews.

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

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

From dcubed at openjdk.java.net  Sat May 15 13:17:45 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 15 May 2021 13:17:45 GMT
Subject: Integrated: 8265153: add time based test for
 ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
In-Reply-To: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
References: <tqJNAfq_xQUHB4yCEE00uFI14nY0CPUCzngpVILXaVo=.856c54fb-6fc1-41e9-8e84-44f37a8ae54b@github.com>
Message-ID: <Uf-W1UQZOWAQv6fLNitm3uX1wr-KcwNmm3Ga05vsLuw=.b87b5dc7-95aa-47a0-b238-69bb2dcb52e5@github.com>

On Wed, 14 Apr 2021 00:08:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
> 
> Currently running the new test thru Mach5 Tier[1-7].
> I've run the test thru several 12 hour runs on my MBP13 and
> on my Linux-X64 server.

This pull request has now been integrated.

Changeset: 8c71144a
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8c71144a2392b8d2ce47074c819d56e523b50145
Stats:     503 lines in 2 files changed: 503 ins; 0 del; 0 mod

8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()

Reviewed-by: dholmes, cjplummer

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

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

From lzang at openjdk.java.net  Mon May 17 01:37:47 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 17 May 2021 01:37:47 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v8]
In-Reply-To: <Sd_6MyrjO-dbHFKPyPYjzwbpLeRIdA3-e65ZnBS2fvk=.226a0dcc-5c4b-400b-98e0-4a7cef7d3e47@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <xZu6CoC0ZEYc3gFa7BHHCjnhZaMohpmpBcxm7t_Wu_E=.19e215c2-75aa-40ea-81da-38bdd2ffeb4a@github.com>
 <szNcoxOky13tYdPwhiVITp8pAc1ok8H-4TKrcD48LwY=.d77792fb-3ce6-4082-8abf-95f32b5c4ec7@github.com>
 <M_GTRn658iQn4GJNyOseAbH_EpnuZjmlzTSjY0iR-jk=.57daedb1-ccb3-4397-884c-855ffe20b86c@github.com>
 <Sd_6MyrjO-dbHFKPyPYjzwbpLeRIdA3-e65ZnBS2fvk=.226a0dcc-5c4b-400b-98e0-4a7cef7d3e47@github.com>
Message-ID: <t4abV6idbamdR1OB-QyU2pumHQgqqrxrsTCa0zherXQ=.bc84968f-a71f-4151-8dbf-7e9e629b8fa9@github.com>

On Mon, 10 May 2021 23:19:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi Chris (@plummercj )
>> 
>> After several tries, I think maybe the current patch is the better way to fix this issue. 
>> For detail, there are three issues that cause the problem. 
>> - The incorrect calculated array length when segmented heap dump is enabled, it can be fixed easily by modifying code in method `calculateArrayMaxLength()`. It is already in this PR.
>> - The internal segment buffer used for segmented heap dump. Plus the resize of this buffer can cause memory consumption by doing byte[] copy. 
>> - Also because the internal segment buffer is byte array, there is a limitation that the buffer length can not be larger than Integer.MAX_VALUE, which also cause the problem when dumping large array, as there can be integer overflow and also not align with the specification (as explained blow)
>> 
>> Here are the possible solutions I have tried to avoid using `unbufferedMode`:
>> 
>> - For segment heap dump, add limitation in `calculateArrayMaxLength()` to guarantee at most `Interger.MAX_VALUE` bytes can be filled into the internal byte array buffer. So there is no need to use unbufferedMode. But I found it can cause large memory usage with internal buffer resize to hold all array data, and also there is OOM thrown when I use `jhsdb jmap --binaryheap` command. Moreover it also changes the behavior of dumping large array:  The original limitation is  MAX_U4_VALUE, which follows the hprof spec that a segment in heap dump has a 32bit slot to hold the segment size.  But after the change , it becomes to `Integer.MAX_VALUE`, which is 2^31-1, just the half of MAX_U4_VALUE, the behavior doesn't follow the spec exactly. 
>> The change also introduce lots of overflow check when size of internal segment buffer is used, which IMHO is not clean.
>> 
>> - I also tried to avoid resize of internal segment buffer by using a linked list to hold all data to be flushed, this can avoid the overflow check. But it also cause OOM since the whole data are hold in the list. And it also introduce more codes for the linked list logic.
>> 
>> And the main reason for caching data in internal segment buffer is that the current implentation needs to update the `size slot` in the segment header, which must be done before the whole data flushed to file, otherwise it would cause problems when gzip heap dump is used. 
>> 
>> The way to avoid caching is to calculate the object size previously and then update the size slot at begining. But it would cause other changes in the code, which IMO is not suitable to introduce in this PR. That is why I mentioned to re-write the implementation of `HeapHprofBinWriter.java` in previous comments.
>> 
>> Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()`  and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file.
>> 
>> What do you think?
>> 
>> Thanks,
>> Lin
>
>> Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()` and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file.
> 
> I think that makes sense. Is this now fully implemented in this PR and it is ready for a final review?

Thanks @plummercj for review and approve this PR.
Dear All, May I get more review? Thanks!

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

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

From dholmes at openjdk.java.net  Mon May 17 01:38:47 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 17 May 2021 01:38:47 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <X46Kp3Cy0BXs9HtgCGe_HRWEu-aPsNToCJFY6nH83Dw=.68a30070-3b54-42f2-9672-da28a94a5b10@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <X46Kp3Cy0BXs9HtgCGe_HRWEu-aPsNToCJFY6nH83Dw=.68a30070-3b54-42f2-9672-da28a94a5b10@github.com>
Message-ID: <zogidrSXhtBy6dBQCTe_f8vVup6pBJ3EQP1yfS7zOC0=.abc508d5-2da5-4fca-bda0-f24874c89341@github.com>

On Fri, 14 May 2021 17:53:15 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes for Dan
>
> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 386:
> 
>> 384:     _waiters++;
>> 385:     ret = simple_wait(self, millis);
>> 386:     _waiters--;
> 
> We don't own the monitor yet so you cannot modify `_waiters` here.
> Any reason you moved and duplicated this block?

Good catch! Even if the block wasn't moved we still no longer own the monitor after simple_wait.

This is going to be tricky to fix in a clear/clean way as the waiters count has to be maintained properly.

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

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

From dholmes at openjdk.java.net  Mon May 17 04:07:44 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 17 May 2021 04:07:44 GMT
Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread
 arguments [v4]
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <Z9zBbwDOMlO2tfJnmcwKfELlNz7mj3m1Kt-OLLHfvfo=.c99111cf-bb28-4d45-8067-7766efd623a0@github.com>

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into 8252685-JavaThread
 - Update after merge with master
 - Merge branch 'master' into 8252685-JavaThread
 - Review feedback from Serguei
 - Merge
 - 8252685: APIs that require JavaThread should take JavaThread arguments

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

Changes: https://git.openjdk.java.net/jdk/pull/3877/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=03
  Stats: 535 lines in 120 files changed: 14 ins; 28 del; 493 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3877.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3877/head:pull/3877

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

From dholmes at openjdk.java.net  Mon May 17 04:08:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 17 May 2021 04:08:28 GMT
Subject: Integrated: 8252685: APIs that require JavaThread should take
 JavaThread arguments
In-Reply-To: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
References: <UnHomVbP7qOoMkwV8PB_by3upNytN-XB0BN2SZf9Pvs=.61bfaf98-6e57-4230-8477-5eded47b7e83@github.com>
Message-ID: <U9jEpgB76_M4HyJQ8-X6vB5VW6o3qQUbWC6CWqEOPkw=.03842586-29ff-4780-af83-6e56f4a58888@github.com>

On Wed, 5 May 2021 10:16:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th
 at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical:
> 
> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current)
> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param
> - Manifestations of Thread::current() become JavaThread::current()
> - THREAD->as_Java_thread() becomes just THREAD
> - THREAD->is_Java_thread() is reworked so that THREAD is "current"
> 
> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths.
> 
> Testing:
>  - tiers 1-8 on Linux-x64
>  - all builds in tiers 1-4
>  - tiers 1-3 on all platforms
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 02f895c5
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/02f895c5f6f6de38549337d45ed8ba4c446e9677
Stats:     535 lines in 120 files changed: 14 ins; 28 del; 493 mod

8252685: APIs that require JavaThread should take JavaThread arguments

Reviewed-by: coleenp, sspitsyn, kvn, iklam

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

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

From rehn at openjdk.java.net  Mon May 17 07:05:41 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 17 May 2021 07:05:41 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
Message-ID: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com>

On Thu, 13 May 2021 05:22:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes for Dan
>
> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48:
> 
>> 46: // The rules are:
>> 47: // - We must never safepoint poll if raw monitor is owned.
>> 48: // - We may safepoint poll before it is owned and after it has been released.
> 
> I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course.

This comment applies to the RawMonitor code, where the typical use-case that otherwise can deadlock is:
JavaThread:
-lock RM
LOOP { 
 -wait RM
 -do stufff with data from VM thread
}
-unlock RM

The user do not call into the VM/Java.

VM Thread:
-safepoint
  -lock RM
  -notify RM
  -unlock RM

If we in this case safepoint between the lock and the unlock in wait() we deadlock with VM thread.

If the user would call into the VM/Java while holding the RM he obviously could deadlock with VM thread.
But he would also deadlock if he used a pthread mutex because that code would be buggy.

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

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

From david.holmes at oracle.com  Mon May 17 07:23:26 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 17 May 2021 17:23:26 +1000
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
 <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com>
Message-ID: <87e79d33-1c7f-3d0f-edfb-3376d3c267d9@oracle.com>

On 17/05/2021 5:05 pm, Robbin Ehn wrote:
> On Thu, 13 May 2021 05:22:51 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Fixes for Dan
>>
>> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48:
>>
>>> 46: // The rules are:
>>> 47: // - We must never safepoint poll if raw monitor is owned.
>>> 48: // - We may safepoint poll before it is owned and after it has been released.
>>
>> I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course.
> 
> This comment applies to the RawMonitor code, where the typical use-case that otherwise can deadlock is:
> JavaThread:
> -lock RM
> LOOP {
>   -wait RM
>   -do stufff with data from VM thread
> }
> -unlock RM
> 
> The user do not call into the VM/Java.
> 
> VM Thread:
> -safepoint
>    -lock RM
>    -notify RM
>    -unlock RM
> 
> If we in this case safepoint between the lock and the unlock in wait() we deadlock with VM thread.
> 
> If the user would call into the VM/Java while holding the RM he obviously could deadlock with VM thread.

Only if the VMThread executes code that uses the same RM - which should 
be a rare occurrence.

David
-----

> But he would also deadlock if he used a pthread mutex because that code would be buggy.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3875
> 

From rehn at openjdk.java.net  Mon May 17 07:24:40 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 17 May 2021 07:24:40 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
Message-ID: <PHTjzOKIqYGrnyc7VVHJrD3CM1EHi2dotgHn3iTylQE=.bc6085e0-5206-4c39-92f2-45536de9d514@github.com>

On Thu, 13 May 2021 05:24:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes for Dan
>
> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 96:
> 
>> 94:    protected:
>> 95:     JvmtiRawMonitor* _rm;
>> 96:     bool _rm_exit;
> 
> If this signifies the monitor exited then please name it `_rm_exited`.

Fixed

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

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

From rehn at openjdk.java.net  Mon May 17 07:45:39 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 17 May 2021 07:45:39 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
Message-ID: <mBOAhpOonAVk-a2VuEkm9KgcSArh9uDxDwmepNvqERI=.f99faad9-ccc5-4977-8533-e64754dc0d84@github.com>

On Thu, 13 May 2021 05:46:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes for Dan
>
> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 277:
> 
>> 275: class ThreadBlockInVM {
>> 276:   InFlightMutexRelease _ifmr;
>> 277:   ThreadBlockInVMPreprocess<InFlightMutexRelease> _tbivmpp;
> 
> Why delegate to the TBIVMPP instead of extending it?

I need to run the InFlightMutexRelease constructor before I can run the ThreadBlockInVMPreprocess constructor.

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

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

From rehn at openjdk.java.net  Mon May 17 07:58:23 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 17 May 2021 07:58:23 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <X46Kp3Cy0BXs9HtgCGe_HRWEu-aPsNToCJFY6nH83Dw=.68a30070-3b54-42f2-9672-da28a94a5b10@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <X46Kp3Cy0BXs9HtgCGe_HRWEu-aPsNToCJFY6nH83Dw=.68a30070-3b54-42f2-9672-da28a94a5b10@github.com>
Message-ID: <ZcFpvl43wGM0HChC5U1IVw-L1AViDVgRupMjwM2cNNQ=.4d376df2-a1cc-4b05-ad85-84794cce7b08@github.com>

On Fri, 14 May 2021 09:50:56 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes for Dan
>
> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 47:
> 
>> 45:   JavaThread* current_java_thread = JavaThread::current();
>> 46:   assert(current_java_thread->thread_state() == _thread_in_vm, "Must be in vm");
>> 47:   {
> 
> Looks like the assertion in L46 is redundant now. ThreadToNativeFromVM asserts as well.

Fixed

> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 410:
> 
>> 408:     ret = simple_wait(self, millis);
>> 409:     _waiters--;
>> 410:     _recursions = save;
> 
> The values of `_waiters` and `_recursions` should be adjusted after the monitor is owned again.

Fixed

> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52:
> 
>> 50: // native for all operations. However we need to honor a suspend request, not
>> 51: // entering a monitor if suspended, and check for interrupts. Honoring a suspend
>> 52: // request// and reading the interrupt flag must be done from VM state
> 
> `s/request///request/` ??

Fixed

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

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

From rehn at openjdk.java.net  Mon May 17 07:58:24 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 17 May 2021 07:58:24 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <zogidrSXhtBy6dBQCTe_f8vVup6pBJ3EQP1yfS7zOC0=.abc508d5-2da5-4fca-bda0-f24874c89341@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <X46Kp3Cy0BXs9HtgCGe_HRWEu-aPsNToCJFY6nH83Dw=.68a30070-3b54-42f2-9672-da28a94a5b10@github.com>
 <zogidrSXhtBy6dBQCTe_f8vVup6pBJ3EQP1yfS7zOC0=.abc508d5-2da5-4fca-bda0-f24874c89341@github.com>
Message-ID: <165oJPFEipZ7u6iG0buImc-eTxwyPf-EOkKn3GpzlJg=.13f86155-ddf6-4ccb-aee9-9df674081520@github.com>

On Mon, 17 May 2021 01:36:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 386:
>> 
>>> 384:     _waiters++;
>>> 385:     ret = simple_wait(self, millis);
>>> 386:     _waiters--;
>> 
>> We don't own the monitor yet so you cannot modify `_waiters` here.
>> Any reason you moved and duplicated this block?
>
> Good catch! Even if the block wasn't moved we still no longer own the monitor after simple_wait.
> 
> This is going to be tricky to fix in a clear/clean way as the waiters count has to be maintained properly.

Actually the field is unused.
The _entry_list is the list of waiters, which is the only thing we really care about.
If there was a reader of _waiter reading it without lock can only be used as some kind of hint.
If you have lock you can just check _entry_list.

I duplicated it because otherwise I would need two branchse on if (self->is_Java_thread()) which creates more complicated code.

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

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

From rehn at openjdk.java.net  Mon May 17 08:09:09 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 17 May 2021 08:09:09 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
Message-ID: <3j6Egl0cd7pkHjWQfOTr65Kpk_7OmNLfo8xYK_AfWjM=.a97f7d87-06b6-46bc-b30d-75f12391f96f@github.com>

On Thu, 13 May 2021 05:57:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes for Dan
>
> src/hotspot/share/runtime/objectMonitor.cpp line 435:
> 
>> 433:         EnterI(current);
>> 434:       }
>> 435:       if (!eos.om_op_done()) {
> 
> I find this API too generic. I'd much rather see:
> 
> if (!eos.exited()) {
>   assert ...
>   break;
> }

Fixed

> src/hotspot/share/runtime/objectMonitor.hpp line 309:
> 
>> 307:    protected:
>> 308:     ObjectMonitor* _om;
>> 309:     bool _om_op_done;
> 
> Please rename to _exited - we know what the "op" is so no need to use generic terminology.

Fixed

> src/hotspot/share/runtime/objectMonitor.hpp line 313:
> 
>> 311:     ExitOnSuspend(ObjectMonitor* om) : _om(om), _om_op_done(false) {}
>> 312:     void operator()(JavaThread* current);
>> 313:     bool om_op_done() { return _om_op_done; }
> 
> please rename to exited()

Fixed

> src/hotspot/share/runtime/objectMonitor.hpp line 315:
> 
>> 313:     bool om_op_done() { return _om_op_done; }
>> 314:   };
>> 315:   class ClearSuccOnSuspend : public ExitOnSuspend {
> 
> I don't see why there is any relationship between these two. You don't clear-succ and exit.

Fixed

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

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

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Mon May 17 08:10:45 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya)
Date: Mon, 17 May 2021 08:10:45 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation [v4]
In-Reply-To: <gcZNzL97V9ENQzFqo9gVTn9KkaId0eKSeVlOpGRgHqE=.bfe39e40-657e-4701-91ff-4f5862e8bf2d@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <gcZNzL97V9ENQzFqo9gVTn9KkaId0eKSeVlOpGRgHqE=.bfe39e40-657e-4701-91ff-4f5862e8bf2d@github.com>
Message-ID: <du-CPhSuPA3m31nzdbGVO0ZYUuv7L-2Urx4qKn54ZWU=.e244ebee-cd27-4a81-9c67-5fa76c49e786@github.com>

On Tue, 11 May 2021 06:35:43 GMT, Mitsuru Kariya <github.com+2217224+kariya-mitsuru at openjdk.org> wrote:

>> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
>> This PR changes to use `Long.hashCode` instead.
>
> Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Hi,

Would anyone sponsor it?

Best regards,
Mitsuru

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

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

From rehn at openjdk.java.net  Mon May 17 08:29:41 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 17 May 2021 08:29:41 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
Message-ID: <5z8gIP9ALINo5U1RdyqJiZQFb1BlYA69zR-8PUQsa0Q=.76c28c76-7eda-4acd-b744-cb39c018bec0@github.com>

On Thu, 13 May 2021 05:27:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes for Dan
>
> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 207:
> 
>> 205:     assert(_thread->thread_state() == _thread_in_vm, "coming from wrong thread state");
>> 206:     assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition");
>> 207:     _thread->set_thread_state(_thread_in_native);
> 
> After doing a heavyweight transition for many many years I find it somewhat disconcerting to suddenly be told it is not necessary. If we are _thread_in_vm and so unsafe, then no handshake/safepoint can have been processed, so there is nothing to check. Makes sense. But how long has that been true? Could we have simplified this years ago or it is a result of other changes?

I looked over the transitions this fall, I don't know but there are some of these oddities.
One problem is the some of the generic named transitions RAII are actually supposed to be used only at certain places and some optimizations have been added.
E.g. in this case someone have figured out that we can remove make_walkable(), but as a generic rule when going to a safe state (blocked/native)  you should call make_walkable. My guess is that calling make_walkable on every JNI/JVM TI call was expensive on Solaris, so someone optimized that.
Now I'm unsure if that is actually true (I my feeling is no, because we could accidentally call Java if we hit e.g. class loading or something). And the optimization is no longer valid, make_walkable() is light weight on current hardware AFAIK.

I updated to what I see as a correct transition to an safe state without any short cuts.
I also notice I missed an assert from the previous code.

Re-running all test, since these kinds of changes should not be taken lightly.

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

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

From rrich at openjdk.java.net  Mon May 17 09:35:46 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 17 May 2021 09:35:46 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
Message-ID: <r77QtdXbVoAxFSK_T5Lp77EAJRuaSLWBSJdj8mkv_K8=.0178fc2d-8e34-4cda-a143-8d659444460d@github.com>

On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes for Dan

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 395:

> 393:           ThreadBlockInVMPreprocess<ExitOnSuspend> tbivmp(jt, eos);
> 394:           simple_enter(jt);
> 395:           _recursions = save;

I think you should restore `_recursions` only when finally leaving the loop because if you do it here and exit the monitor again because of a suspend then another thread could hit the `guarantee(_recursions == 0, "invariant")` at L349. This is a preexisting issue but since you're modifying this I reckon it makes sense to correct it.

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

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

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Mon May 17 09:54:10 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya)
Date: Mon, 17 May 2021 09:54:10 GMT
Subject: Integrated: 8264734: Some SA classes could use better hashCode()
 implementation
In-Reply-To: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
Message-ID: <6wpLFPjMzqSlUYxZ4g-OImbXZXNVLm0J8yj-e7mYiXI=.af64f451-598d-4690-824a-12e4f6715003@github.com>

On Thu, 15 Apr 2021 15:44:15 GMT, Mitsuru Kariya <github.com+2217224+kariya-mitsuru at openjdk.org> wrote:

> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
> This PR changes to use `Long.hashCode` instead.

This pull request has now been integrated.

Changeset: a555fd89
Author:    Mitsuru Kariya <Mitsuru.Kariya at oss.nttdata.com>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a555fd89d040792d4de73ab67d86b171a38cfde6
Stats:     26 lines in 11 files changed: 0 ins; 6 del; 20 mod

8264734: Some SA classes could use better hashCode() implementation

Reviewed-by: cjplummer, kevinw

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

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

From rehn at openjdk.java.net  Mon May 17 11:24:42 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 17 May 2021 11:24:42 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <r77QtdXbVoAxFSK_T5Lp77EAJRuaSLWBSJdj8mkv_K8=.0178fc2d-8e34-4cda-a143-8d659444460d@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <r77QtdXbVoAxFSK_T5Lp77EAJRuaSLWBSJdj8mkv_K8=.0178fc2d-8e34-4cda-a143-8d659444460d@github.com>
Message-ID: <qk5EuLqyIaCujGHR0xbvtlNbnAYJejO2bPD5zqlf3BM=.812291a9-70e1-4e41-8bb0-387eeb12b484@github.com>

On Mon, 17 May 2021 09:32:23 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes for Dan
>
> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 395:
> 
>> 393:           ThreadBlockInVMPreprocess<ExitOnSuspend> tbivmp(jt, eos);
>> 394:           simple_enter(jt);
>> 395:           _recursions = save;
> 
> I think you should restore `_recursions` only when finally leaving the loop because if you do it here and exit the monitor again because of a suspend then another thread could hit the `guarantee(_recursions == 0, "invariant")` at L349. This is a preexisting issue but since you're modifying this I reckon it makes sense to correct it.

Fixed

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

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

From rschmelter at openjdk.java.net  Mon May 17 11:50:43 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Mon, 17 May 2021 11:50:43 GMT
Subject: Integrated: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with
 EOFException
In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com>
Message-ID: <RTaGrtHbh6ZyfnUpXaxRoS68wH5JQdkqtkhgnMNN_-M=.0fe7a6b7-2f7b-45d2-a8af-eecda1ca48d4@github.com>

On Thu, 22 Apr 2021 14:16:21 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> This fixes a race condition in the CompressionBackend class of the heap dump code.
> 
> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself.
> 
> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen.
> 
> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking.

This pull request has now been integrated.

Changeset: a29612ea
Author:    Ralf Schmelter <rschmelter at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a29612ea9998a8e45f25add7ae30bfbc62ce3756
Stats:     51 lines in 3 files changed: 15 ins; 24 del; 12 mod

8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException

Reviewed-by: rrich, cjplummer

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

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

From ysuenaga at openjdk.java.net  Mon May 17 12:15:01 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 17 May 2021 12:15:01 GMT
Subject: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965
Message-ID: <SEstazl5HPdp9XNAaPGKtXNhdhq4eGocYHFpS7GHuZA=.926a304e-f0b9-43c7-b05c-01b0dd944bcf@github.com>

Following jtreg tests for SA would fail because SA has not followed [JDK-8220587](https://bugs.openjdk.java.net/browse/JDK-8220587) and [JDK-8224965](https://bugs.openjdk.java.net/browse/JDK-8224965).

* serviceability/sa/ClhsdbDumpheap.java
* serviceability/sa/ClhsdbFindPC.java
* serviceability/sa/ClhsdbInspect.java
* serviceability/sa/ClhsdbSymbol.java
* serviceability/sa/TestHeapDumpForInvokeDynamic.java
* serviceability/sa/TestJmapCore.java
* serviceability/sa/TestJmapCoreMetaspace.java

They need to handle relocated objects and/or live regions (pages). SA should handle them.

This change passes serviceability/sa jtreg tests on Linux x64 with -vmoption:-XX:+UseZGC, but I want to know this change works fine on testbed for ZGC in Oracle. Could you help?

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

Commit messages:
 - Improve relocation handling
 - Merge remote-tracking branch 'upstream/master' into JDK-8266957
 - 8266957: SA has not followed JDK-8220587 and JDK-8224965

Changes: https://git.openjdk.java.net/jdk/pull/4057/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4057&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266957
  Stats: 799 lines in 23 files changed: 558 ins; 191 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4057.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4057/head:pull/4057

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

From github.com+2217224+kariya-mitsuru at openjdk.java.net  Mon May 17 12:40:47 2021
From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya)
Date: Mon, 17 May 2021 12:40:47 GMT
Subject: RFR: 8264734: Some SA classes could use better hashCode()
 implementation [v4]
In-Reply-To: <gcZNzL97V9ENQzFqo9gVTn9KkaId0eKSeVlOpGRgHqE=.bfe39e40-657e-4701-91ff-4f5862e8bf2d@github.com>
References: <IpS3qAOqJEBhGuAXWcMo4ig49r6TaOH1g_Y2EcavSzM=.60b62763-077c-47ec-a411-5ce6417b318d@github.com>
 <gcZNzL97V9ENQzFqo9gVTn9KkaId0eKSeVlOpGRgHqE=.bfe39e40-657e-4701-91ff-4f5862e8bf2d@github.com>
Message-ID: <gfvCIiWnl9MND1pfLF4ICI8cREgi3TzGo1NTseZzUEc=.d871d653-e5a4-4e7f-9818-168c002ec0d4@github.com>

On Tue, 11 May 2021 06:35:43 GMT, Mitsuru Kariya <github.com+2217224+kariya-mitsuru at openjdk.org> wrote:

>> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value.
>> This PR changes to use `Long.hashCode` instead.
>
> Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Thanks a lot!

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

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

From weijun at openjdk.java.net  Mon May 17 22:01:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:49 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
Message-ID: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>

Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).

With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).

To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:

1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.

Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.

Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.

Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.

There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).

3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).

2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:

rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
 ```

The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

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

Commit messages:
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - test for nio
 - test for hotspot-runtime
 - test for security
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0

Changes: https://git.openjdk.java.net/jdk/pull/4071/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267184
  Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

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

From weijun at openjdk.java.net  Mon May 17 22:01:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:52 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for
 Removal
Message-ID: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>

Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).

The code change is divided into 3 commits. Please review them one by one.

1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal

The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.

Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.

Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

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

Commit messages:
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266459
  Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

From weijun at openjdk.java.net  Mon May 17 22:01:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <jYnPM3TGZaiZyNdO1TqYy5zWEHeqaEJH6dbp1xhiIHI=.213bd236-b2df-44d8-8f34-a963a3ffdfb6@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The 3rd commit is the biggest one but it's all generated programmatically. All changes are simply adding `@SupressWarnings("removal")` to a declaration.

Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 

+ @SuppressWarnings("removal")


There are also 7 cases where an existing annotation is updated

================= 2 ====================
- @SuppressWarnings("deprecation")
+ @SuppressWarnings({"removal","deprecation"})
================= 1 ====================
- @SuppressWarnings("Convert2Lambda")
+ @SuppressWarnings({"removal","Convert2Lambda"})
================= 1 ====================
- @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"})
+ @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"})
================= 1 ====================
- @SuppressWarnings("deprecation") // Use of RMISecurityManager
+ @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager
================= 1 ====================
- @SuppressWarnings("unchecked")     /*To suppress warning from line 1374*/
+ @SuppressWarnings({"removal","unchecked"})     /*To suppress warning from line 1374*/
================= 1 ====================
- @SuppressWarnings("fallthrough")
+ @SuppressWarnings({"removal","fallthrough"})


All other cases are new annotation embedded inline:

================= 7 ====================
- AccessControlContext acc) {
+ @SuppressWarnings("removal") AccessControlContext acc) {
================= 4 ====================
- AccessControlContext acc,
+ @SuppressWarnings("removal") AccessControlContext acc,
================= 3 ====================
- AccessControlContext context,
+ @SuppressWarnings("removal") AccessControlContext context,
================= 3 ====================
- AccessControlContext acc)
+ @SuppressWarnings("removal") AccessControlContext acc)
================= 2 ====================
- try (InputStream stream = AccessController.doPrivileged(pa)) {
+ try (@SuppressWarnings("removal") InputStream stream = AccessController.doPrivileged(pa)) {
================= 2 ====================
- AccessControlContext context, Permission... perms) {
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
================= 2 ====================
- } catch (java.security.AccessControlException e) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException e) {
================= 2 ====================
- } catch (AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") AccessControlException ace) {
================= 2 ====================
- AccessControlContext context)
+ @SuppressWarnings("removal") AccessControlContext context)
================= 2 ====================
- AccessControlContext acc) throws LoginException {
+ @SuppressWarnings("removal") AccessControlContext acc) throws LoginException {
================= 2 ====================
- } catch (AccessControlException e) {
+ } catch (@SuppressWarnings("removal") AccessControlException e) {
================= 1 ====================
- public static void addHook(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ public static void addHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- DomainCombiner combiner,
+ @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- } catch (java.security.AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException ace) {
================= 1 ====================
- private static File checkFile(File f, SecurityManager sm) {
+ private static File checkFile(File f, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static File checkFile(File file, SecurityManager sm) {
+ private static File checkFile(File file, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm,
+ private static void checkPackageAccessForPermittedSubclasses(@SuppressWarnings("removal") SecurityManager sm,
================= 1 ====================
- ProtectionDomain[] getProtectDomains(AccessControlContext context);
+ ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- SecureCallbackHandler(java.security.AccessControlContext acc,
+ SecureCallbackHandler(@SuppressWarnings("removal") java.security.AccessControlContext acc,
================= 1 ====================
- private static void addHookInternal(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ private static void addHookInternal(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- private void checkMemberAccess(SecurityManager sm, int which,
+ private void checkMemberAccess(@SuppressWarnings("removal") SecurityManager sm, int which,
================= 1 ====================
- private static File[] checkFiles(Stream<File> filesStream, SecurityManager sm) {
+ private static File[] checkFiles(Stream<File> filesStream, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- Thread(Runnable target, AccessControlContext acc) {
+ Thread(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public ProtectionDomain[] getProtectDomains(AccessControlContext context) {
+ public ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext stack,
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext stack,
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext(ProtectionDomain caller, DomainCombiner combiner,
+ AccessControlContext(ProtectionDomain caller, @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- public URLClassPath(URL[] urls, AccessControlContext acc) {
+ public URLClassPath(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- URLClassLoader(URL[] urls, AccessControlContext acc) {
+ URLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public static void setSecurityManager(SecurityManager sm) {
+ public static void setSecurityManager(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- try (DataInputStream dis = new DataInputStream(new InflaterInputStream(
+ try (@SuppressWarnings("removal") DataInputStream dis = new DataInputStream(new InflaterInputStream(
================= 1 ====================
- try (FileInputStream fis = AccessController.doPrivileged(
+ try (@SuppressWarnings("removal") FileInputStream fis = AccessController.doPrivileged(
================= 1 ====================
- FactoryURLClassLoader(URL[] urls, AccessControlContext acc) {
+ FactoryURLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- Thread newThreadWithAcc(Runnable target, AccessControlContext acc);
+ Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc);
================= 1 ====================
- SecureRecorderListener(AccessControlContext context, FlightRecorderListener changeListener) {
+ SecureRecorderListener(@SuppressWarnings("removal") AccessControlContext context, FlightRecorderListener changeListener) {
================= 1 ====================
- private PolicyDelegate(PolicySpi spi, Provider p,
+ private PolicyDelegate(@SuppressWarnings("removal") PolicySpi spi, Provider p,
================= 1 ====================
- DomainCombiner combiner) {
+ @SuppressWarnings("removal") DomainCombiner combiner) {
================= 1 ====================
- PrivilegedRunnable(Runnable r, AccessControlContext acc) {
+ PrivilegedRunnable(Runnable r, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private static File[] checkFiles(Stream<File> fs, SecurityManager sm) {
+ private static File[] checkFiles(Stream<File> fs, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private void checkSpecifyHandler(SecurityManager sm) {
+ private void checkSpecifyHandler(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- String serverPrincipal, AccessControlContext acc)
+ String serverPrincipal, @SuppressWarnings("removal") AccessControlContext acc)
================= 1 ====================
- public Thread newThreadWithAcc(Runnable target, AccessControlContext acc) {
+ public Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- try (InputStream is = AccessController.doPrivileged(new PrivilegedAction<InputStream>() {
+ try (@SuppressWarnings("removal") InputStream is = AccessController.doPrivileged(new PrivilegedAction<InputStream>() {
================= 1 ====================
- public EventFileStream(AccessControlContext acc, Path path) throws IOException {
+ public EventFileStream(@SuppressWarnings("removal") AccessControlContext acc, Path path) throws IOException {
================= 1 ====================
- AccessControlContext context, Permission... perms)
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
================= 1 ====================
- private static void privateCheckPackageAccess(SecurityManager s, Class<?> clazz) {
+ private static void privateCheckPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class<?> clazz) {
================= 1 ====================
- AbstractEventStream(AccessControlContext acc, PlatformRecording recording, List<Configuration> configurations) throws IOException {
+ AbstractEventStream(@SuppressWarnings("removal") AccessControlContext acc, PlatformRecording recording, List<Configuration> configurations) throws IOException {
================= 1 ====================
- private void checkPackageAccess(SecurityManager sm, final ClassLoader ccl,
+ private void checkPackageAccess(@SuppressWarnings("removal") SecurityManager sm, final ClassLoader ccl,
================= 1 ====================
- AccessControlContext context) {
+ @SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- public PrivilegedExecutor(Executor executor, AccessControlContext acc) {
+ public PrivilegedExecutor(Executor executor, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private RequestHook(AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
+ private RequestHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
================= 1 ====================
- try (BufferedReader bufferedReader =
+ try (@SuppressWarnings("removal") BufferedReader bufferedReader =
================= 1 ====================
- private static void privateCheckProxyPackageAccess(SecurityManager s, Class<?> clazz) {
+ private static void privateCheckProxyPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class<?> clazz) {


**That's all**.

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

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

From cjplummer at openjdk.java.net  Mon May 17 22:15:22 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 17 May 2021 22:15:22 GMT
Subject: RFR: 8263242: serviceability/sa/ClhsdbFindPC.java cannot find
 MaxJNILocalCapacity with ASLR
Message-ID: <XosrK5FRTzslyLKhe77RDSMIulCAi6AyO5fvfBaGn1k=.4570eb3f-4bdb-43b1-a0e5-ff6727557848@github.com>

The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail.

The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best:

https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953

There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change.

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

Commit messages:
 - Use p_memsz instead of p_filesz to correctly compute segment size.

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

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

From erikj at openjdk.java.net  Mon May 17 22:30:56 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 17 May 2021 22:30:56 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <wihzX2vMKBxcpu3CE2BaQNZ1jyXj8e2Fbps1z0CJMlU=.e234b050-b1b0-4280-b764-9a409d5cf428@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Makefile change looks ok.

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

Marked as reviewed by erikj (Reviewer).

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

From dholmes at openjdk.java.net  Tue May 18 05:01:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 18 May 2021 05:01:46 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <JhTe209ZxiIMoOvppz7-1xRxGS2Rb-YiyJnD7OzZDp0=.73ed4efc-2751-4746-b5d2-1bfd327574a6@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Changes to hotspot-* and serviceability look good.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From alanb at openjdk.java.net  Tue May 18 05:51:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 05:51:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Marked as reviewed by alanb (Reviewer).

The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.

test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.

test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.

For uses using ProcessTools then it seems to be very random.

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

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

From alanb at openjdk.java.net  Tue May 18 06:33:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 06:33:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

src/java.base/share/classes/java/lang/SecurityManager.java line 315:

> 313:  *
> 314:  * @since   1.0
> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a

Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

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

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

From kevinw at openjdk.java.net  Tue May 18 08:52:42 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 18 May 2021 08:52:42 GMT
Subject: RFR: 8263242: serviceability/sa/ClhsdbFindPC.java cannot find
 MaxJNILocalCapacity with ASLR
In-Reply-To: <XosrK5FRTzslyLKhe77RDSMIulCAi6AyO5fvfBaGn1k=.4570eb3f-4bdb-43b1-a0e5-ff6727557848@github.com>
References: <XosrK5FRTzslyLKhe77RDSMIulCAi6AyO5fvfBaGn1k=.4570eb3f-4bdb-43b1-a0e5-ff6727557848@github.com>
Message-ID: <HrQSxljULpO105J0UO6QLMFQCIfgl8aiTziGpzXtwlo=.360e209f-78e6-42e5-a674-e613f2159ffd@github.com>

On Mon, 17 May 2021 22:05:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail.
> 
> The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best:
> 
> https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953
> 
> There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change.

Marked as reviewed by kevinw (Committer).

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

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

From ysuenaga at openjdk.java.net  Tue May 18 09:00:41 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 18 May 2021 09:00:41 GMT
Subject: RFR: 8263242: serviceability/sa/ClhsdbFindPC.java cannot find
 MaxJNILocalCapacity with ASLR
In-Reply-To: <XosrK5FRTzslyLKhe77RDSMIulCAi6AyO5fvfBaGn1k=.4570eb3f-4bdb-43b1-a0e5-ff6727557848@github.com>
References: <XosrK5FRTzslyLKhe77RDSMIulCAi6AyO5fvfBaGn1k=.4570eb3f-4bdb-43b1-a0e5-ff6727557848@github.com>
Message-ID: <LPD1RpyEFR9G00saWJgBXHg6L6PmN9GuxMkauGutpVk=.baa8a73b-8941-4e28-bff6-8aa591318e7e@github.com>

On Mon, 17 May 2021 22:05:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail.
> 
> The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best:
> 
> https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953
> 
> There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change.

Marked as reviewed by ysuenaga (Reviewer).

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

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

From dfuchs at openjdk.java.net  Tue May 18 11:33:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 18 May 2021 11:33:44 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I looked at serviceability, net, and corelibs. The changes look good to me - though I have one question about the NotificationEmissionTest. I believe that regardless of whether the new property is needed, test case 1 should be run in /othervm too.

test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:

> 32:  * @run clean NotificationEmissionTest
> 33:  * @run build NotificationEmissionTest
> 34:  * @run main NotificationEmissionTest 1

This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

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

Marked as reviewed by dfuchs (Reviewer).

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

From mullan at openjdk.java.net  Tue May 18 12:44:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 12:44:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
Message-ID: <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>

On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
> 
>> 313:  *
>> 314:  * @since   1.0
>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
> 
> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

It includes both:
![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

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

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

From weijun at openjdk.java.net  Tue May 18 14:01:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:01:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>
Message-ID: <LP-JXhyiYZ4-yfHkeHX7Rqt-1AnCPesIf4uK5ycC8B4=.4459bddf-cc61-4c92-9b5e-4e046ede8a90@github.com>

On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:
> 
>> 32:  * @run clean NotificationEmissionTest
>> 33:  * @run build NotificationEmissionTest
>> 34:  * @run main NotificationEmissionTest 1
> 
> This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

Or maybe the policy setting line should only be called when a security manager is set? IIRC jtreg is able to restore system properties even in agentvm mode. So maybe this really doesn't matter. We just want to modify as little as possible in this PR.

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

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

From weijun at openjdk.java.net  Tue May 18 14:07:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:07:38 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>
Message-ID: <z9kXH2Zm9AgECH3iihoXcgKisBj7HQMYB7SBmr98Hek=.c0ba0d9d-f3ea-427c-97a1-8de5843c0698@github.com>

On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.
> 
> test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.
> 
> test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.
> 
> For uses using ProcessTools then it seems to be very random.

I've updated the 3 cases you mentioned and will go through more. Yes it looks good to group system property settings together. Thanks.

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

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

From alanb at openjdk.java.net  Tue May 18 15:22:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 15:22:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
 <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
Message-ID: <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>

On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
>> 
>>> 313:  *
>>> 314:  * @since   1.0
>>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
>> 
>> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?
>
> It includes both:
> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

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

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

From mullan at openjdk.java.net  Tue May 18 15:49:38 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 15:49:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
 <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
 <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>
Message-ID: <0_9OMaDXfGSSqm5VdlusV4KRWnHxD2KFD5ifyV1hVFI=.1ba2b000-954e-4b23-a869-7d3aa1a909d6@github.com>

On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It includes both:
>> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)
>
> Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

My feeling is that it is better to be more specific than the generic removal text as this is the most significant class that is being deprecated for removal. Also, this says "the Security Manager" (note the space between) which really encompasses more than the `java.lang.SecurityManager` API and which is explained more completely in the JEP.

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

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

From darcy at openjdk.java.net  Tue May 18 16:29:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 18 May 2021 16:29:47 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <UN8g8sgK7nXvYjtZiSBUhCaU-0qEb8b7Y2OzhxgtOzY=.08a47c9a-a7a5-4a0e-8919-19d71fc19a4f@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by darcy (Reviewer).

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

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

From chegar at openjdk.java.net  Tue May 18 16:38:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 18 May 2021 16:38:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <LgbU-sI0tWPZUqtoQA3U69H6-_YB1kKmqgTckkVcrlo=.0d7b35c2-aec5-41be-ab62-459a9ae8c7dd@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The changes in the net area look fine.

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

Marked as reviewed by chegar (Reviewer).

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

From naoto at openjdk.java.net  Tue May 18 16:45:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 18 May 2021 16:45:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <NQ4IhVZC8LudCe-a1JsSFd95dtttKo46bw2iK0DkiQA=.1139a6e3-8acc-4099-b9ab-c599fdca20d2@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Reviewed i18n/java.time/charset. They all look good.

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

Marked as reviewed by naoto (Reviewer).

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

From joehw at openjdk.java.net  Tue May 18 17:30:39 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 18 May 2021 17:30:39 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <Ep1azxH_vnemjxbvBu6HprCKjwMcG1nzTozdYIA1RtU=.e8be0928-e09f-483e-a775-06bbcce8be8c@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

java.xml changes look good. Thanks.

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

Marked as reviewed by joehw (Reviewer).

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

From alanb at openjdk.java.net  Tue May 18 17:39:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 17:39:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/security/AccessController.java line 877:

> 875:     @CallerSensitive
> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

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

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

From mchung at openjdk.java.net  Tue May 18 17:43:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:43:39 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <L_strZt1H9X1vdJh8AYRIWExhJMfmODbsj-N8xQkvYw=.1e46863a-db33-4d33-bbe4-645f0c52b349@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I reviewed non-client areas.  Looks okay.

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

Marked as reviewed by mchung (Reviewer).

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

From mchung at openjdk.java.net  Tue May 18 17:53:51 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:53:51 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <jVoctx_UzYbZpnzVpQJ-kVkDSiW8wpixKMGGDicrAfk=.e36178c6-303c-489c-813b-37842a110503@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by mchung (Reviewer).

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

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

From weijun at openjdk.java.net  Tue May 18 18:42:26 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 18:42:26 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
Message-ID: <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>

On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/security/AccessController.java line 877:
> 
>> 875:     @CallerSensitive
>> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
> 
> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

My rule is that a new line is added if there's only whitespaces before the insert position and the previous line does not end with a comma. In this case, unless I move `Permission... perms` onto a new line that an annotation on a new line looks like covering both `context` and `perms`.

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

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

From weijun at openjdk.java.net  Tue May 18 21:13:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:13:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
 <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>
Message-ID: <NsAoXUFxz2QHQKrDb3O1Ls1jKyXBkfbmB9AubjXUDus=.6a87197e-b3bf-4971-a48e-6e7f008c9135@github.com>

On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AccessController.java line 877:
>> 
>>> 875:     @CallerSensitive
>>> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
>>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
>> 
>> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.
>
> I'll try to update my auto-annotating program.

Turns out this only happens in this class:

$ rg '^\s*@SuppressWarnings("removal").*?,.'
src/java.base/share/classes/java/security/AccessController.java:449:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:514:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:877:                                     @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

I'll fix them manually.

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

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

From cjplummer at openjdk.java.net  Tue May 18 21:21:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 18 May 2021 21:21:38 GMT
Subject: RFR: 8263242: serviceability/sa/ClhsdbFindPC.java cannot find
 MaxJNILocalCapacity with ASLR
In-Reply-To: <XosrK5FRTzslyLKhe77RDSMIulCAi6AyO5fvfBaGn1k=.4570eb3f-4bdb-43b1-a0e5-ff6727557848@github.com>
References: <XosrK5FRTzslyLKhe77RDSMIulCAi6AyO5fvfBaGn1k=.4570eb3f-4bdb-43b1-a0e5-ff6727557848@github.com>
Message-ID: <Bz4NWXueZE5lG9hgMxGNAdHmBkDystQMPNG5YFnKl24=.66f0efb3-4a35-4609-ad80-353cccf0f58b@github.com>

On Mon, 17 May 2021 22:05:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail.
> 
> The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best:
> 
> https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953
> 
> There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change.

Thanks for the reviews!

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

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

From weijun at openjdk.java.net  Tue May 18 21:21:45 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:21:45 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

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

  feedback from Sean, Phil and Alan

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a

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

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

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

From cjplummer at openjdk.java.net  Tue May 18 21:29:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 18 May 2021 21:29:41 GMT
Subject: Integrated: 8263242: serviceability/sa/ClhsdbFindPC.java cannot find
 MaxJNILocalCapacity with ASLR
In-Reply-To: <XosrK5FRTzslyLKhe77RDSMIulCAi6AyO5fvfBaGn1k=.4570eb3f-4bdb-43b1-a0e5-ff6727557848@github.com>
References: <XosrK5FRTzslyLKhe77RDSMIulCAi6AyO5fvfBaGn1k=.4570eb3f-4bdb-43b1-a0e5-ff6727557848@github.com>
Message-ID: <uYSDYqB5L-M1IaVnMQsrZ4kHXpv_2WiNmEUCjrjibwY=.8707351b-122f-4f6f-9fe6-82755d244359@github.com>

On Mon, 17 May 2021 22:05:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail.
> 
> The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best:
> 
> https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953
> 
> There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change.

This pull request has now been integrated.

Changeset: 10236e7a
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/10236e7a52a2dd117c3639d020cfe294797f57af
Stats:     4 lines in 1 file changed: 1 ins; 1 del; 2 mod

8263242: serviceability/sa/ClhsdbFindPC.java cannot find MaxJNILocalCapacity with ASLR

Reviewed-by: kevinw, ysuenaga

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

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

From weijun at openjdk.java.net  Tue May 18 21:44:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:44:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

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

  adjust order of VM options

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad

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

  Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

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

From rehn at openjdk.java.net  Wed May 19 07:26:14 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 19 May 2021 07:26:14 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4]
In-Reply-To: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
Message-ID: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>

> Please consider this change which removes the manual transitions to blocked.
> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
> 
> The object monitor code could be straight forward changed to use this instead of manual transitions.
> 
> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
> That made it possible to careful use ThreadInVMfromNative in raw monitors.
> 
> I also remove the early CAS in raw_enter.
> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
> 
> Passes t1-t7 and manual stressing relevant test groups.

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

 - Review fixes
 - Merge branch 'master' into 8265753
 - Fixes for Dan
 - Merge branch 'master' into 8265753
 - Removed manual transitions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3875/files
  - new: https://git.openjdk.java.net/jdk/pull/3875/files/1c6448e3..a8b8469c

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

  Stats: 23290 lines in 735 files changed: 8980 ins; 9379 del; 4931 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875

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

From rehn at openjdk.java.net  Wed May 19 07:26:17 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 19 May 2021 07:26:17 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
Message-ID: <q14NUPq1DYukEgQDfgoUANCQqiKALVEknglrPljf2jk=.d7cf571a-ef69-43da-bc4c-f9667175d184@github.com>

On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes for Dan

Updated, passed t1-t7 och local stress-testing.

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

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

From rehn at openjdk.java.net  Wed May 19 07:26:19 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 19 May 2021 07:26:19 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
Message-ID: <CuptVnldT0QO2ECUlq4sIo4PEdqgK7D6bR6-ysNNQnI=.870f7ef5-831a-43a1-a0b7-6334018b1b18@github.com>

On Thu, 13 May 2021 06:04:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Robbin,
> 
> Sorry for the delay in getting through this.
> 
> Overall approach looks good. I have a few queries below and some requested naming changes to make things clearer.
> 
> Thanks,
> David

Thanks for looking at, update after comments.

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

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

From rehn at openjdk.java.net  Wed May 19 07:26:20 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 19 May 2021 07:26:20 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <X46Kp3Cy0BXs9HtgCGe_HRWEu-aPsNToCJFY6nH83Dw=.68a30070-3b54-42f2-9672-da28a94a5b10@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <X46Kp3Cy0BXs9HtgCGe_HRWEu-aPsNToCJFY6nH83Dw=.68a30070-3b54-42f2-9672-da28a94a5b10@github.com>
Message-ID: <RSZ2eL-T18HHp0TTX8ZKJ_xJ15xDTsggr9oConSClNk=.8294b34d-88ae-4ce7-affa-59a90a3c865b@github.com>

On Fri, 14 May 2021 18:02:12 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Hi Robbin,
> 
> there seem to be issues in the jvmtiRawMonitor part of the change. Besides that it looks good.
> 
> Cheers, Richard.

Thanks and thanks for finding the two issues, updated!

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

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

From lzang at openjdk.java.net  Wed May 19 11:55:12 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 19 May 2021 11:55:12 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v25]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <pOvflcfxV8E2kfZ0gQR0UCWDfgYSiRDOCuuoOeiKYeU=.563fc116-6a94-4e77-a066-599b1142843d@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - fix build issue after rebase and fix one issue
 - Merge branch 'master'
 - Merge branch 'master' into pd
 - update copyright info
 - Merge branch 'master' into par-dump
 - undo JMap.java
 - code refine and typo fix
 - Merge branch 'master' into par-dump
 - refine with several fix
 - Merge branch 'master' into par-dump
 - ... and 24 more: https://git.openjdk.java.net/jdk/compare/6ef46ce3...d03e994b

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

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=24
  Stats: 835 lines in 5 files changed: 648 ins; 57 del; 130 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

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

From lzang at openjdk.java.net  Wed May 19 12:02:00 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 19 May 2021 12:02:00 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22]
In-Reply-To: <qVInCa4LG5a2cNWA5ZEy2HzJSJG6rATPJQ78Vb3wtwo=.87a41d1e-e8b5-462e-a743-59c3e0640126@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <FEApmNXBv2avOTMxOmAGzZ02hT9AqwcSndvhr00yASk=.cfe79f07-f81c-4f5e-8581-7ac2281c28b5@github.com>
 <qVInCa4LG5a2cNWA5ZEy2HzJSJG6rATPJQ78Vb3wtwo=.87a41d1e-e8b5-462e-a743-59c3e0640126@github.com>
Message-ID: <9yxlJK34rPBqiP47CNcvVmr_zdd3wMNUZblx2EQWVA4=.437cb8bf-7dd8-47e0-9351-51478fd8c0bd@github.com>

On Mon, 10 May 2021 23:29:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code refine and typo fix
>
> I think you still need to undo the JMap.java changes since they are now being handled by #3598

Hi Chris (@plummercj),
May I ask your help to remove the `csr` label? As we discussed before, there is no need for this PR to have CSR.

Thanks!
Lin

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

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

From weijun at openjdk.java.net  Wed May 19 13:47:54 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:54 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>
Message-ID: <8mVaKSBeyfyVBHsp67PuOC1G7--flmHQzygrQTyrgGE=.ed4f6dd9-e0af-4058-97f5-cf5ab3651aa4@github.com>

On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from Sean, Phil and Alan

A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` test in tier4. The test compares stderr output with a known value but we have a new warning written to stderr now. It's now using stdout instead. @prrace, Please confirm this is acceptable. Thanks.

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

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

From weijun at openjdk.java.net  Wed May 19 13:47:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

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

  fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f

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

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

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

From rrich at openjdk.java.net  Wed May 19 14:28:48 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 19 May 2021 14:28:48 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4]
In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
Message-ID: <uH2EyRSAjnIv02tXdS63blAcEq_ovkCy20vWVNi6URA=.64753b68-430b-42f6-b0c8-4ec9954b36fb@github.com>

On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Review fixes
>  - Merge branch 'master' into 8265753
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Removed manual transitions

Just one more, rather unimportant comment...

Either way: LGTM!

Thanks, Richard.

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382:

> 380: 
> 381:     _recursions = 0;
> 382:     ret = simple_wait(self, millis);

IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240.

In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement.

    _recursions = 0;
    ret = simple_wait(self, millis);
    _recursions = save;

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

Marked as reviewed by rrich (Reviewer).

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

From ayang at openjdk.java.net  Wed May 19 17:05:49 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 19 May 2021 17:05:49 GMT
Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste
 since it is never set [v3]
In-Reply-To: <HDkU6USAbeyYbhrr9hxPRG3Wci_V_KCaEVfYWJMPxHA=.2f4aca8b-b6b2-4a82-a1ac-78b4470a0baa@github.com>
References: <D8BYOrjHW_YzuZUuuHzfg8Ek38lFW2Dluhowqzq0QvA=.a22f3a9f-ee69-4454-a9f5-d2c6bd87239d@github.com>
 <HDkU6USAbeyYbhrr9hxPRG3Wci_V_KCaEVfYWJMPxHA=.2f4aca8b-b6b2-4a82-a1ac-78b4470a0baa@github.com>
Message-ID: <KYam5IifLN-j6_-XKjoCBCjIGqVI4jHZAyGvKGV33R8=.555e32ff-ac46-4103-8806-a21fea9be082@github.com>

On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

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

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

From ayang at openjdk.java.net  Wed May 19 17:05:50 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 19 May 2021 17:05:50 GMT
Subject: Integrated: 8234532: Remove
 ThreadLocalAllocBuffer::_fast_refill_waste since it is never set
In-Reply-To: <D8BYOrjHW_YzuZUuuHzfg8Ek38lFW2Dluhowqzq0QvA=.a22f3a9f-ee69-4454-a9f5-d2c6bd87239d@github.com>
References: <D8BYOrjHW_YzuZUuuHzfg8Ek38lFW2Dluhowqzq0QvA=.a22f3a9f-ee69-4454-a9f5-d2c6bd87239d@github.com>
Message-ID: <M72WI6jOeqH2yUGrdPeM-wlI9In56bl3a-MW5K8GIZk=.ae40016d-f67c-4b61-9b88-cba21ed77749@github.com>

On Wed, 28 Apr 2021 09:23:31 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also.

This pull request has now been integrated.

Changeset: 99fcc410
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/99fcc410a774e7b830856aa9c8e18e8a3b0567de
Stats:     43 lines in 5 files changed: 0 ins; 36 del; 7 mod

8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set

Reviewed-by: tschatzl, sjohanss, pliden, sspitsyn

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

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

From prr at openjdk.java.net  Wed May 19 18:16:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:16:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <fiq_yIbqC9QRDEcRvYChJl6aWrZvnOxZM4uuDdwYDek=.bbe622b3-b90a-4441-bb0c-ead59bca50d2@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

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

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

From prr at openjdk.java.net  Wed May 19 18:19:49 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:19:49 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <hfPqSTPSSpxjLndppmuJovqQVW7q2UXmBhzI8sIGDJg=.bdef2a7d-72bd-49ac-b7f6-9ca56ce3cd1e@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This change is so large that github won't even display the list of files so I can't jump to where I want to go !
And when I try to scroll I get just a blank page.

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

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

From prr at openjdk.java.net  Wed May 19 18:29:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:29:41 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.desktop/share/classes/java/awt/Component.java line 217:

> 215:  * @author      Sami Shaio
> 216:  */
> 217: @SuppressWarnings("removal")

Why is this placed on the *entire class* ??
This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

src/java.desktop/share/classes/java/awt/Container.java line 97:

> 95:  * @since     1.0
> 96:  */
> 97: @SuppressWarnings("removal")

Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.

Where else are you adding this to entire classes instead of the specific site ?

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

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

From weijun at openjdk.java.net  Wed May 19 18:41:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:41:44 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
Message-ID: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>

On Wed, 19 May 2021 18:26:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 217:
> 
>> 215:  * @author      Sami Shaio
>> 216:  */
>> 217: @SuppressWarnings("removal")
> 
> Why is this placed on the *entire class* ??
> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is

        s = java.security.AccessController.doPrivileged(
                                                        new GetPropertyAction("awt.image.redrawrate"));

> src/java.desktop/share/classes/java/awt/Container.java line 97:
> 
>> 95:  * @since     1.0
>> 96:  */
>> 97: @SuppressWarnings("removal")
> 
> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
> 
> Where else are you adding this to entire classes instead of the specific site ?

Similar as the one above, it's because of

    static {
        // Don't lazy-read because every app uses invalidate()
        isJavaAwtSmartInvalidate = AccessController.doPrivileged(
                new GetBooleanAction("java.awt.smartInvalidate"));
    }

> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
>> 57:                 ProcessCommunicator
>> 58:                         .executeChildProcess(Consumer.class, new String[0]);
>> 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

The child process is started with `-Djava.security.manager=allow` (after the other PR) and a warning will be printed to stderr. Therefore I move the message to stdout.

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

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

From weijun at openjdk.java.net  Wed May 19 18:46:46 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:46:46 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
Message-ID: <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>

On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Container.java line 97:
>> 
>>> 95:  * @since     1.0
>>> 96:  */
>>> 97: @SuppressWarnings("removal")
>> 
>> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
>> 
>> Where else are you adding this to entire classes instead of the specific site ?
>
> Similar as the one above, it's because of
> 
>     static {
>         // Don't lazy-read because every app uses invalidate()
>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>                 new GetBooleanAction("java.awt.smartInvalidate"));
>     }

We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

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

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

From weijun at openjdk.java.net  Wed May 19 18:51:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:51:43 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>
Message-ID: <P1n8uhHy1IqLsvr2AH5wQb1wuBkGPofCg2TFvelA4sQ=.1cbb03a5-084d-4548-be7c-fa66b9968f87@github.com>

On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Similar as the one above, it's because of
>> 
>>     static {
>>         // Don't lazy-read because every app uses invalidate()
>>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>>                 new GetBooleanAction("java.awt.smartInvalidate"));
>>     }
>
> We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

I know it's not easy to read the commit and that's why I make the 3rd commit totally automatic. Hopefully you have more confidence on the program than my hand. All annotations are added to the nearest declarations.

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

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

From prr at openjdk.java.net  Wed May 19 19:34:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 19:34:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
Message-ID: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>

On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>> 
>>> 215:  * @author      Sami Shaio
>>> 216:  */
>>> 217: @SuppressWarnings("removal")
>> 
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.
>
> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
> 
>         s = java.security.AccessController.doPrivileged(
>                                                         new GetPropertyAction("awt.image.redrawrate"));

That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
You can define a static private method to contain this and call it from the static initializer block.
Much better than applying the annotation to an entire class.

--- a/src/java.desktop/share/classes/java/awt/Component.java
+++ b/src/java.desktop/share/classes/java/awt/Component.java
@@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
      */
     static boolean isInc;
     static int incRate;
+
+    private static void initIncRate() {
+        String s = java.security.AccessController.doPrivileged(
+                                 new GetPropertyAction("awt.image.incrementaldraw"));
+        isInc = (s == null || s.equals("true"));
+
+        s = java.security.AccessController.doPrivileged(
+                          new GetPropertyAction("awt.image.redrawrate"));
+        incRate = (s != null) ? Integer.parseInt(s) : 100;
+    }
+
     static {
         /* ensure that the necessary native libraries are loaded */
         Toolkit.loadLibraries();
@@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
         if (!GraphicsEnvironment.isHeadless()) {
             initIDs();
         }
-
-        String s = java.security.AccessController.doPrivileged(
-                                                               new GetPropertyAction("awt.image.incrementaldraw"));
-        isInc = (s == null || s.equals("true"));
-
-        s = java.security.AccessController.doPrivileged(
-                                                        new GetPropertyAction("awt.image.redrawrate"));
-        incRate = (s != null) ? Integer.parseInt(s) : 100;
+        initIncRate();
     }

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

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

From snazarkin at azul.com  Wed May 19 20:28:10 2021
From: snazarkin at azul.com (Sergey Nazarkin)
Date: Wed, 19 May 2021 20:28:10 +0000
Subject: [8u] RFR: 8267426 MonitorVmStartTerminate test timed out on
 Embedded VM
In-Reply-To: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com>
References: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com>
Message-ID: <B7847F0C-D7BD-44FE-AA96-54DE47CBDFD7@azul.com>

Correct serviceability list address


> On May 19, 2021, at 22:19, Sergey Nazarkin <snazarkin at azul.com> wrote:
> 
> Hi!
> 
> Please review small patch for the test that fails [1] on jdk8 built with JAVASE_EMBEDDED option.
> 
> Embedded VM build disables [2] jvmstat instrumentation that prevent launched instance be detected by test agent. The fix [3] enables instrumentation for launched VM swarm and agent is able to detect them.
> 
> The bug affects jdk8 only [4].
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8267426
> [2] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/8c40ddd927ce/src/share/vm/runtime/globals.hpp#l3782
> [3]  http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8267426/
> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/bce3c3659531/src/hotspot/share/runtime/globals.hpp#l2413
> 
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210519/e5d3ad0a/signature-0001.asc>

From mullan at openjdk.java.net  Wed May 19 20:33:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 19 May 2021 20:33:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
Message-ID: <faOe6m8bn6J0ZmXT2mXeQnXapiwOqEixCz4qYhAXRSk=.ec7435aa-b851-4be2-88d2-f122f3fea099@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The changes to the security tests look good.

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

Marked as reviewed by mullan (Reviewer).

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

From vromero at openjdk.java.net  Wed May 19 20:46:23 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 19 May 2021 20:46:23 GMT
Subject: RFR: 8260517: implement Sealed Classes as a standard feature in
 Java [v8]
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <gn205vZkb8GgZvBHBAvwtFDaSYM4R0DW7Azx_FZPEJQ=.8f160a78-48ee-4241-bc56-7d59d5dec735@github.com>

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

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

 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - updating comment after review feedback
 - removing javax.lang.model changes
 - Merge branch 'master' into JDK-8260517
 - Merge branch 'master' into JDK-8260517
 - fixing failing regression tests
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/cc4f43fb...d220bc20

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3526/files
  - new: https://git.openjdk.java.net/jdk/pull/3526/files/0208dcf0..d220bc20

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=06-07

  Stats: 40144 lines in 1123 files changed: 19391 ins; 13080 del; 7673 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526

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

From weijun at openjdk.java.net  Wed May 19 21:56:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 21:56:30 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
Message-ID: <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>

On Wed, 19 May 2021 19:31:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
>> 
>>         s = java.security.AccessController.doPrivileged(
>>                                                         new GetPropertyAction("awt.image.redrawrate"));
>
> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
> You can define a static private method to contain this and call it from the static initializer block.
> Much better than applying the annotation to an entire class.
> 
> --- a/src/java.desktop/share/classes/java/awt/Component.java
> +++ b/src/java.desktop/share/classes/java/awt/Component.java
> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>       */
>      static boolean isInc;
>      static int incRate;
> +
> +    private static void initIncRate() {
> +        String s = java.security.AccessController.doPrivileged(
> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
> +        isInc = (s == null || s.equals("true"));
> +
> +        s = java.security.AccessController.doPrivileged(
> +                          new GetPropertyAction("awt.image.redrawrate"));
> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +    }
> +
>      static {
>          /* ensure that the necessary native libraries are loaded */
>          Toolkit.loadLibraries();
> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>          if (!GraphicsEnvironment.isHeadless()) {
>              initIDs();
>          }
> -
> -        String s = java.security.AccessController.doPrivileged(
> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
> -        isInc = (s == null || s.equals("true"));
> -
> -        s = java.security.AccessController.doPrivileged(
> -                                                        new GetPropertyAction("awt.image.redrawrate"));
> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +        initIncRate();
>      }

Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

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

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

From prr at openjdk.java.net  Wed May 19 22:07:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 22:07:36 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
Message-ID: <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>

On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
>> You can define a static private method to contain this and call it from the static initializer block.
>> Much better than applying the annotation to an entire class.
>> 
>> --- a/src/java.desktop/share/classes/java/awt/Component.java
>> +++ b/src/java.desktop/share/classes/java/awt/Component.java
>> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>       */
>>      static boolean isInc;
>>      static int incRate;
>> +
>> +    private static void initIncRate() {
>> +        String s = java.security.AccessController.doPrivileged(
>> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
>> +        isInc = (s == null || s.equals("true"));
>> +
>> +        s = java.security.AccessController.doPrivileged(
>> +                          new GetPropertyAction("awt.image.redrawrate"));
>> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +    }
>> +
>>      static {
>>          /* ensure that the necessary native libraries are loaded */
>>          Toolkit.loadLibraries();
>> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>          if (!GraphicsEnvironment.isHeadless()) {
>>              initIDs();
>>          }
>> -
>> -        String s = java.security.AccessController.doPrivileged(
>> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
>> -        isInc = (s == null || s.equals("true"));
>> -
>> -        s = java.security.AccessController.doPrivileged(
>> -                                                        new GetPropertyAction("awt.image.redrawrate"));
>> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +        initIncRate();
>>      }
>
> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
I think it should all be taken care of as part of this proposed change.

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

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

From weijun at openjdk.java.net  Wed May 19 22:17:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 22:17:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
Message-ID: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>

On Wed, 19 May 2021 22:04:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.
>
> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
> I think it should all be taken care of as part of this proposed change.

I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

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

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

From prr at openjdk.java.net  Wed May 19 23:53:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 23:53:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
Message-ID: <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>

On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
I already pasted the patch for Component.java and it took about 60 seconds to do that.
Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.

I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

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

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

From david.holmes at oracle.com  Thu May 20 00:50:16 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 May 2021 10:50:16 +1000
Subject: [8u] RFR: 8267426 MonitorVmStartTerminate test timed out on
 Embedded VM
In-Reply-To: <B7847F0C-D7BD-44FE-AA96-54DE47CBDFD7@azul.com>
References: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com>
 <B7847F0C-D7BD-44FE-AA96-54DE47CBDFD7@azul.com>
Message-ID: <cb69d603-c5bd-b47d-1de7-4cb8d753f8ef@oracle.com>

Hi Sergey,

Fix looks fine. I'm a little surprised we have any SE Embedded test 
issues arising - is this a new test?

Cheers,
David


On 20/05/2021 6:28 am, Sergey Nazarkin wrote:
> Correct serviceability list address
> 
> 
>> On May 19, 2021, at 22:19, Sergey Nazarkin <snazarkin at azul.com> wrote:
>>
>> Hi!
>>
>> Please review small patch for the test that fails [1] on jdk8 built with JAVASE_EMBEDDED option.
>>
>> Embedded VM build disables [2] jvmstat instrumentation that prevent launched instance be detected by test agent. The fix [3] enables instrumentation for launched VM swarm and agent is able to detect them.
>>
>> The bug affects jdk8 only [4].
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8267426
>> [2] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/8c40ddd927ce/src/share/vm/runtime/globals.hpp#l3782
>> [3]  http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8267426/
>> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/bce3c3659531/src/hotspot/share/runtime/globals.hpp#l2413
>>
>>
>>
>>
> 

From cjplummer at openjdk.java.net  Thu May 20 01:12:32 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 20 May 2021 01:12:32 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v3]
In-Reply-To: <TraaQakfH6DYbgnie89jGZzQMEk36HCNOVwnmPej1Vg=.ef619ac6-8767-4221-b278-88272e8834f7@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <TraaQakfH6DYbgnie89jGZzQMEk36HCNOVwnmPej1Vg=.ef619ac6-8767-4221-b278-88272e8834f7@github.com>
Message-ID: <i4TQQ70WtsArt6QBqt2dSlj_XmedqO8ejiNN3z0cF5c=.4bf23df2-7a76-4f3f-a014-52d8ae341b70@github.com>

On Sat, 15 May 2021 02:00:15 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
>> 
>> As a result, remote name will be constructed as following:
>> 
>> 
>> //host[:port]/<serverNamePrefix>['_'<id>]
>> 
>> 
>> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>> 
>> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
>> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
>> 
>> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
>> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263635: Add --servername option to jhsdb debugd

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 101:

> 99:         if (serverNamePrefix != null) {
> 100:             System.err.println("WARNING: sun.jvm.hotspot.rmi.serverNamePrefix is deprecated. Please specify it in --connect.");
> 101:             rmiObjectName = serverNamePrefix;

If the servername was already specified with `--connect`, I would think that we would not want to override it with the property if it is also set. Maybe if both are set then fail with an error. Same in `getName()` below.

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

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

From cjplummer at openjdk.java.net  Thu May 20 01:25:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 20 May 2021 01:25:40 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v3]
In-Reply-To: <TraaQakfH6DYbgnie89jGZzQMEk36HCNOVwnmPej1Vg=.ef619ac6-8767-4221-b278-88272e8834f7@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <TraaQakfH6DYbgnie89jGZzQMEk36HCNOVwnmPej1Vg=.ef619ac6-8767-4221-b278-88272e8834f7@github.com>
Message-ID: <vY8Fx6vuETl7LtcIZ1EIi0wJH6T-0ZP0VNTjNXtab5M=.edb98dd1-4ffa-4eb1-a254-2c8450127f20@github.com>

On Sat, 15 May 2021 02:00:15 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
>> 
>> As a result, remote name will be constructed as following:
>> 
>> 
>> //host[:port]/<serverNamePrefix>['_'<id>]
>> 
>> 
>> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>> 
>> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
>> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
>> 
>> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
>> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263635: Add --servername option to jhsdb debugd

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 94:

> 92: 
> 93:     private static boolean debugdHelp() {
> 94:         System.out.println("    --serverid <id>         A unique identifier for this debug server.");

"debugd server" instead of "debug server"

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 105:

> 103:                 " 'java.rmi.server.hostname'. If not specified, the system property is used. If the system" +
> 104:                 " property is not set, a system hostname is used.");
> 105:         System.out.println("    --servername <name>     Instance name of debugd server.");

I think this should go right below `--serverid` above

src/jdk.hotspot.agent/share/man/jhsdb.1 line 206:

> 204: Sets the instance name of debugd server to distinguish SA debugee.
> 205: It is used for RMI object name for server instance.
> 206: If not specified, "SARemoteDebugger" will be set.

"will be used"

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

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

From weijun at openjdk.java.net  Thu May 20 02:09:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:09:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
Message-ID: <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>

On Wed, 19 May 2021 23:50:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.
>
> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
> I already pasted the patch for Component.java and it took about 60 seconds to do that.
> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
> 
> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

I can make it a bug.

I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.

And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.

Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

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

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

From weijun at openjdk.java.net  Thu May 20 02:12:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:12:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
Message-ID: <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD_jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>

On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
>> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
>> I already pasted the patch for Component.java and it took about 60 seconds to do that.
>> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
>> 
>> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?
>
> I can make it a bug.
> 
> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
> 
> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
> 
> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

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

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

From ysuenaga at openjdk.java.net  Thu May 20 03:03:09 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 20 May 2021 03:03:09 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v4]
In-Reply-To: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
Message-ID: <muAtxC9s7FVOy27tGFfZ0J9qrkc-sNt7qkFuNVf60js=.8b96a1b9-ce36-462e-88c2-33adb4041ae3@github.com>

> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
> 
> As a result, remote name will be constructed as following:
> 
> 
> //host[:port]/<serverNamePrefix>['_'<id>]
> 
> 
> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
> 
> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
> 
> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.

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

  Fix comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3669/files
  - new: https://git.openjdk.java.net/jdk/pull/3669/files/03ed5d19..1315dc56

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

  Stats: 27 lines in 3 files changed: 16 ins; 4 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3669.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3669/head:pull/3669

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

From ysuenaga at openjdk.java.net  Thu May 20 03:05:31 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 20 May 2021 03:05:31 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v3]
In-Reply-To: <TraaQakfH6DYbgnie89jGZzQMEk36HCNOVwnmPej1Vg=.ef619ac6-8767-4221-b278-88272e8834f7@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <TraaQakfH6DYbgnie89jGZzQMEk36HCNOVwnmPej1Vg=.ef619ac6-8767-4221-b278-88272e8834f7@github.com>
Message-ID: <9MhCTkA7i5VNb7WhTixLtxzN0cWBe6dkyB1F1PqYgpU=.b08c7ad1-ff72-4c19-8af7-205efa53a63e@github.com>

On Sat, 15 May 2021 02:00:15 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
>> 
>> As a result, remote name will be constructed as following:
>> 
>> 
>> //host[:port]/<serverNamePrefix>['_'<id>]
>> 
>> 
>> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>> 
>> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
>> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
>> 
>> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
>> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263635: Add --servername option to jhsdb debugd

@plummercj Thanks for your review! I pushed new commit to fix them. And also I updated debugd help message in CSR.

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

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

From prr at openjdk.java.net  Thu May 20 04:08:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:08:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD_jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
Message-ID: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>

On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I can make it a bug.
>> 
>> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
>> 
>> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
>> 
>> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.
>
> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

That is unfortunate, but nonetheless I think required to be done.
We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>From my point of view it is a blocker.

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

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

From prr at openjdk.java.net  Thu May 20 04:25:29 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:25:29 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
Message-ID: <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>

On Thu, 20 May 2021 04:05:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
> From my point of view it is a blocker.

The JEP isn't PTT for 17 so there's plenty of time isn't there ?

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

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

From dholmes at openjdk.java.net  Thu May 20 04:43:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 20 May 2021 04:43:41 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4]
In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
Message-ID: <qgBrWEuEnfRPIDHSK0k0WDYONjeSeroAcKYUrzHlVTE=.e8d6d5d4-2052-4c16-bacc-3b0b885ff001@github.com>

On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Review fixes
>  - Merge branch 'master' into 8265753
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Removed manual transitions

Updates seem fine. Lucky _waiters was unused :)

Will take another full pass over the changes.

Thanks,
David

src/hotspot/share/runtime/objectMonitor.hpp line 309:

> 307:    protected:
> 308:     ObjectMonitor* _om;
> 309:     bool _exited;

For consistency with raw monitor code this would _om_exited

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

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

From lzang at openjdk.java.net  Thu May 20 05:10:46 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 20 May 2021 05:10:46 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v25]
In-Reply-To: <pOvflcfxV8E2kfZ0gQR0UCWDfgYSiRDOCuuoOeiKYeU=.563fc116-6a94-4e77-a066-599b1142843d@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <pOvflcfxV8E2kfZ0gQR0UCWDfgYSiRDOCuuoOeiKYeU=.563fc116-6a94-4e77-a066-599b1142843d@github.com>
Message-ID: <iY9n2q-ieooNSQptNW3Og8g8oUevBAlXd9mb8p02QAs=.c597844b-55d8-4e62-bee5-70532bd09812@github.com>

On Wed, 19 May 2021 11:55:12 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - fix build issue after rebase and fix one issue
>  - Merge branch 'master'
>  - Merge branch 'master' into pd
>  - update copyright info
>  - Merge branch 'master' into par-dump
>  - undo JMap.java
>  - code refine and typo fix
>  - Merge branch 'master' into par-dump
>  - refine with several fix
>  - Merge branch 'master' into par-dump
>  - ... and 24 more: https://git.openjdk.java.net/jdk/compare/6ef46ce3...d03e994b

Dear All, 
    May I get more review about the PR? Thanks!

BRs,
Lin

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

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

From dholmes at openjdk.java.net  Thu May 20 07:03:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 20 May 2021 07:03:42 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4]
In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
Message-ID: <e7Whlu5IMq2BVQnP47ZRi9bI-G1vPVPZBhYyxEkDRiQ=.22f71f15-bb20-4ad6-bf01-bb701dc77438@github.com>

On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Review fixes
>  - Merge branch 'master' into 8265753
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Removed manual transitions

Hi Robbin,

Overall this looks good to me, but there is one issue that needs fixing (partially pre-existing but now also affecting ObjectMonitor::enter).

Other minor comments below.

Thanks,
David

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 236:

> 234: 
> 235: template <typename PRE_PROC>
> 236: class ThreadBlockInVMPreprocess : public ThreadStateTransition {

Can we add a comment before this template definition please:

// Perform a transition to _thread_blocked and take a call-back to be executed before 
// SafepointMechanism::process_if_requested when returning to the VM. This allows us
// to perform an "undo" action if we might block processing a safepoint/handshake operation
// (such as thread suspension).

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 245:

> 243:     // Once we are blocked vm expects stack to be walkable
> 244:     thread->frame_anchor()->make_walkable(thread);
> 245:     thread->set_thread_state(_thread_blocked);

This is a pre-existing issue. Everywhere we call make_walkable and then call plain set_thread_state (other than on PPC/Aarch64 which do a release_store) we are at risk of the thread_state update being reordered with stores related to making the stack walkable. Potentially allowing the VMThread (or other thread) to walk a stack that is not yet walkable! The original ObjectMonitor::enter code was aware of this:
`current->frame_anchor()->make_walkable(current);`
`// Thread must be walkable before it is blocked.`
`// Read in reverse order.`
`OrderAccess::storestore();`
`for (;;) {`
`  current->set_thread_state(_thread_blocked);`

src/hotspot/share/runtime/objectMonitor.cpp line 448:

> 446:     // Completed the tranisition.
> 447:     SafepointMechanism::process_if_requested(current);
> 448:     current->set_thread_state(_thread_in_vm);

The comment block above this code is no longer accurate as there is no longer an opportunity to go to a safepoint at the end of the block. I'm not sure what a thread dump would show with the new code.

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

Changes requested by dholmes (Reviewer).

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

From dholmes at openjdk.java.net  Thu May 20 07:03:43 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 20 May 2021 07:03:43 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
 <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com>
Message-ID: <sf7L7wEY2u9oT-jH5pyP8Nnm5MkwBwspvVL3rBX2iAk=.ee663553-2ac0-432c-8231-a11385d3136d@github.com>

On Mon, 17 May 2021 07:02:30 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48:
>> 
>>> 46: // The rules are:
>>> 47: // - We must never safepoint poll if raw monitor is owned.
>>> 48: // - We may safepoint poll before it is owned and after it has been released.
>> 
>> I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course.
>
> This comment applies to the RawMonitor code, where the typical use-case that otherwise can deadlock is:
> JavaThread:
> -lock RM
> LOOP { 
>  -wait RM
>  -do stufff with data from VM thread
> }
> -unlock RM
> 
> The user do not call into the VM/Java.
> 
> VM Thread:
> -safepoint
>   -lock RM
>   -notify RM
>   -unlock RM
> 
> If we in this case safepoint between the lock and the unlock in wait() we deadlock with VM thread.
> 
> If the user would call into the VM/Java while holding the RM he obviously could deadlock with VM thread.
> But he would also deadlock if he used a pthread mutex because that code would be buggy.

Okay I understand what you are referring to now - thanks. It is a bit concerning that Raw Monitor wait is specified to be callback safe as that means we can legitimately block the VMThread indefinitely!

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

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

From alanb at openjdk.java.net  Thu May 20 07:08:35 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 20 May 2021 07:08:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
Message-ID: <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>

On Thu, 20 May 2021 04:22:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> That is unfortunate, but nonetheless I think required to be done.
>> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>> From my point of view it is a blocker.
>
> The JEP isn't PTT for 17 so there's plenty of time isn't there ?

There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

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

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

From rehn at openjdk.java.net  Thu May 20 07:10:34 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 20 May 2021 07:10:34 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4]
In-Reply-To: <uH2EyRSAjnIv02tXdS63blAcEq_ovkCy20vWVNi6URA=.64753b68-430b-42f6-b0c8-4ec9954b36fb@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
 <uH2EyRSAjnIv02tXdS63blAcEq_ovkCy20vWVNi6URA=.64753b68-430b-42f6-b0c8-4ec9954b36fb@github.com>
Message-ID: <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com>

On Wed, 19 May 2021 14:25:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Just one more, rather unimportant comment...
> 
> Either way: LGTM!
> 
> Thanks, Richard.

Thanks!

> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382:
> 
>> 380: 
>> 381:     _recursions = 0;
>> 382:     ret = simple_wait(self, millis);
> 
> IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240.
> 
> In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement.
> 
>     _recursions = 0;
>     ret = simple_wait(self, millis);
>     _recursions = save;

Yes, it can be re-written as something below, but is this more readable?


  _recursions = 0;                                                                                               
  ret = simple_wait(self, millis);                                                                                   
  
  if (self->is_Java_thread()) { // JavaThread re-enter                                                                                        
    JavaThread* jt = self->as_Java_thread();                                                                           
    {                                                                                                                  
      ThreadInVMfromNative tivmfn(jt);                                                                                 
      for (;;) {                                                                                                       
        ExitOnSuspend eos(this);                                                                                       
        {                                                                                                              
          ThreadBlockInVMPreprocess<ExitOnSuspend> tbivmp(jt, eos);                                                    
          simple_enter(jt);                                                                                            
        }                                                                                                              
        if (!eos.monitor_exited()) {                                                                                   
          break;                                                                                                       
        }                                                                                                              
      }                                                                                                                
      if (jt->is_interrupted(true)) {                                                                                  
        ret = M_INTERRUPTED;                                                                                           
      }                                                                                                                
    }                                                                                                                  
  } else { // Non-JavaThread re-enter                                                                 
    assert(ret != M_INTERRUPTED, "Only JavaThreads can be interrupted");                                               
    simple_enter(self);                                                                                            
  }
  _recursions = save;

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

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

From david.holmes at oracle.com  Thu May 20 07:19:03 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 May 2021 17:19:03 +1000
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4]
In-Reply-To: <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
 <uH2EyRSAjnIv02tXdS63blAcEq_ovkCy20vWVNi6URA=.64753b68-430b-42f6-b0c8-4ec9954b36fb@github.com>
 <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com>
Message-ID: <892486cc-4564-81e1-b3d8-2922859c78e8@oracle.com>

On 20/05/2021 5:10 pm, Robbin Ehn wrote:
> On Wed, 19 May 2021 14:25:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
> 
>> Just one more, rather unimportant comment...
>>
>> Either way: LGTM!
>>
>> Thanks, Richard.
> 
> Thanks!
> 
>> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382:
>>
>>> 380:
>>> 381:     _recursions = 0;
>>> 382:     ret = simple_wait(self, millis);
>>
>> IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240.
>>
>> In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement.
>>
>>      _recursions = 0;
>>      ret = simple_wait(self, millis);
>>      _recursions = save;
> 
> Yes, it can be re-written as something below, but is this more readable?

I'd say yes with two minor modifications:

> 
>    _recursions = 0;
>    ret = simple_wait(self, millis);

+ // Now we need to re-enter the monitor. For JavaThread's
+ // we need to manage suspend requests.

>    if (self->is_Java_thread()) { // JavaThread re-enter
>      JavaThread* jt = self->as_Java_thread();
>      {

I think this extra block scope can also go.

Cheers,
David
-----

>        ThreadInVMfromNative tivmfn(jt);
>        for (;;) {
>          ExitOnSuspend eos(this);
>          {
>            ThreadBlockInVMPreprocess<ExitOnSuspend> tbivmp(jt, eos);
>            simple_enter(jt);
>          }
>          if (!eos.monitor_exited()) {
>            break;
>          }
>        }
>        if (jt->is_interrupted(true)) {
>          ret = M_INTERRUPTED;
>        }
>      }
>    } else { // Non-JavaThread re-enter
>      assert(ret != M_INTERRUPTED, "Only JavaThreads can be interrupted");
>      simple_enter(self);
>    }
>    _recursions = save;
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3875
> 

From rehn at openjdk.java.net  Thu May 20 07:19:35 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 20 May 2021 07:19:35 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4]
In-Reply-To: <e7Whlu5IMq2BVQnP47ZRi9bI-G1vPVPZBhYyxEkDRiQ=.22f71f15-bb20-4ad6-bf01-bb701dc77438@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
 <e7Whlu5IMq2BVQnP47ZRi9bI-G1vPVPZBhYyxEkDRiQ=.22f71f15-bb20-4ad6-bf01-bb701dc77438@github.com>
Message-ID: <Ne1VeVYc6tyIKXl5tbEQBtuaMgaqVk200Dv7EJ4x96c=.0677c9e9-a981-46a2-9b8a-da28a67d5179@github.com>

On Thu, 20 May 2021 05:14:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Review fixes
>>  - Merge branch 'master' into 8265753
>>  - Fixes for Dan
>>  - Merge branch 'master' into 8265753
>>  - Removed manual transitions
>
> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 236:
> 
>> 234: 
>> 235: template <typename PRE_PROC>
>> 236: class ThreadBlockInVMPreprocess : public ThreadStateTransition {
> 
> Can we add a comment before this template definition please:
> 
> // Perform a transition to _thread_blocked and take a call-back to be executed before 
> // SafepointMechanism::process_if_requested when returning to the VM. This allows us
> // to perform an "undo" action if we might block processing a safepoint/handshake operation
> // (such as thread suspension).

Fixed

> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 245:
> 
>> 243:     // Once we are blocked vm expects stack to be walkable
>> 244:     thread->frame_anchor()->make_walkable(thread);
>> 245:     thread->set_thread_state(_thread_blocked);
> 
> This is a pre-existing issue. Everywhere we call make_walkable and then call plain set_thread_state (other than on PPC/Aarch64 which do a release_store) we are at risk of the thread_state update being reordered with stores related to making the stack walkable. Potentially allowing the VMThread (or other thread) to walk a stack that is not yet walkable! The original ObjectMonitor::enter code was aware of this:
> `current->frame_anchor()->make_walkable(current);`
> `// Thread must be walkable before it is blocked.`
> `// Read in reverse order.`
> `OrderAccess::storestore();`
> `for (;;) {`
> `  current->set_thread_state(_thread_blocked);`

Good catch, fixed.

> src/hotspot/share/runtime/objectMonitor.hpp line 309:
> 
>> 307:    protected:
>> 308:     ObjectMonitor* _om;
>> 309:     bool _exited;
> 
> For consistency with raw monitor code this would be _om_exited

Fixed

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

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

From rehn at openjdk.java.net  Thu May 20 07:31:38 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 20 May 2021 07:31:38 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <CuptVnldT0QO2ECUlq4sIo4PEdqgK7D6bR6-ysNNQnI=.870f7ef5-831a-43a1-a0b7-6334018b1b18@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
 <CuptVnldT0QO2ECUlq4sIo4PEdqgK7D6bR6-ysNNQnI=.870f7ef5-831a-43a1-a0b7-6334018b1b18@github.com>
Message-ID: <f_NeErv7EkDdLW91_lIaIxNLdzOLJAygBAelEKuyqRY=.a044edf8-5989-4642-b87c-1f2453c31dc4@github.com>

On Wed, 19 May 2021 07:22:06 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi Robbin,
> 
> Sorry for the delay in getting through this.
> 
> Overall approach looks good. I have a few queries below and some requested naming changes to make things clearer.
> 
> Thanks,
> David

Thanks!

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

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

From rehn at openjdk.java.net  Thu May 20 07:31:41 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 20 May 2021 07:31:41 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4]
In-Reply-To: <e7Whlu5IMq2BVQnP47ZRi9bI-G1vPVPZBhYyxEkDRiQ=.22f71f15-bb20-4ad6-bf01-bb701dc77438@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
 <e7Whlu5IMq2BVQnP47ZRi9bI-G1vPVPZBhYyxEkDRiQ=.22f71f15-bb20-4ad6-bf01-bb701dc77438@github.com>
Message-ID: <Gx2E9Yyvg37gZsI4g0moir3XlliW1HGFLu1BG47H1lE=.d9e0a921-7a66-47a6-85c1-7b664f23d0eb@github.com>

On Thu, 20 May 2021 06:03:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Review fixes
>>  - Merge branch 'master' into 8265753
>>  - Fixes for Dan
>>  - Merge branch 'master' into 8265753
>>  - Removed manual transitions
>
> src/hotspot/share/runtime/objectMonitor.cpp line 448:
> 
>> 446:     // Completed the tranisition.
>> 447:     SafepointMechanism::process_if_requested(current);
>> 448:     current->set_thread_state(_thread_in_vm);
> 
> The comment block above this code is no longer accurate as there is no longer an opportunity to go to a safepoint at the end of the block. I'm not sure what a thread dump would show with the new code.

I moved comment and current->set_current_pending_monitor(NULL); into loop.
And I set current->set_current_pending_monitor(om);  to OM again in ExitOnSuspend if we exit the OM.
The thread dump is then identical to what we have today if ~ThreadBlockInVMPreprocess safepoints.

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

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

From vromero at openjdk.java.net  Thu May 20 09:14:33 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 20 May 2021 09:14:33 GMT
Subject: Integrated: 8260517: implement Sealed Classes as a standard feature
 in Java
In-Reply-To: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
References: <vycn6jqrkgxTXx1pG6-h0Z7djt1GV3Tmf7Y9jJo0SxY=.1b02dfc8-27b8-4b5f-940a-433dbb1902cc@github.com>
Message-ID: <sTNVHO4rsk9be3QkZ4EDY2Rw9GtH9X_tUqQOyRNb_L8=.8e8fd575-510d-4312-85ab-51379f9d685d@github.com>

On Fri, 16 Apr 2021 01:08:57 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
> 
> Thanks
> 
> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it.

This pull request has now been integrated.

Changeset: 0fa9223f
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0fa9223f34bc33635079763362f42f0a5c53759b
Stats:     444 lines in 54 files changed: 51 ins; 275 del; 118 mod

8260517: implement Sealed Classes as a standard feature in Java

Co-authored-by: Harold Seigel <hseigel at openjdk.org>
Co-authored-by: Vicente Romero <vromero at openjdk.org>
Reviewed-by: dholmes, mcimadamore, jlahoda

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

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

From snazarkin at azul.com  Thu May 20 10:27:21 2021
From: snazarkin at azul.com (Sergey Nazarkin)
Date: Thu, 20 May 2021 10:27:21 +0000
Subject: [8u] RFR: 8267426 MonitorVmStartTerminate test timed out on
 Embedded VM
In-Reply-To: <cb69d603-c5bd-b47d-1de7-4cb8d753f8ef@oracle.com>
References: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com>
 <B7847F0C-D7BD-44FE-AA96-54DE47CBDFD7@azul.com>
 <cb69d603-c5bd-b47d-1de7-4cb8d753f8ef@oracle.com>
Message-ID: <19732680-A7C4-41CA-87C9-02CA29BDEB92@azul.com>

Thanks David, I?ve tagged the bug

The test is not new, I tracked it down to jdk7. But EmbeddedVM build is quite tricky and it seems nobody care about it nowadays. 


/Sergey

> On May 20, 2021, at 03:50, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Sergey,
> 
> Fix looks fine. I'm a little surprised we have any SE Embedded test issues arising - is this a new test?
> 
> Cheers,
> David
> 
> 
> On 20/05/2021 6:28 am, Sergey Nazarkin wrote:
>> Correct serviceability list address
>>> On May 19, 2021, at 22:19, Sergey Nazarkin <snazarkin at azul.com> wrote:
>>> 
>>> Hi!
>>> 
>>> Please review small patch for the test that fails [1] on jdk8 built with JAVASE_EMBEDDED option.
>>> 
>>> Embedded VM build disables [2] jvmstat instrumentation that prevent launched instance be detected by test agent. The fix [3] enables instrumentation for launched VM swarm and agent is able to detect them.
>>> 
>>> The bug affects jdk8 only [4].
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8267426
>>> [2] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/8c40ddd927ce/src/share/vm/runtime/globals.hpp#l3782
>>> [3]  http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8267426/
>>> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/bce3c3659531/src/hotspot/share/runtime/globals.hpp#l2413
>>> 
>>> 
>>> 
>>> 


From rehn at openjdk.java.net  Thu May 20 11:37:35 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 20 May 2021 11:37:35 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4]
In-Reply-To: <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
 <uH2EyRSAjnIv02tXdS63blAcEq_ovkCy20vWVNi6URA=.64753b68-430b-42f6-b0c8-4ec9954b36fb@github.com>
 <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com>
Message-ID: <evFDdWoa_fdJKs4nKcN-556xcYAPgTO-TSshGq4k3xc=.b1514fba-4a9f-478f-b11b-58589724f3d5@github.com>

On Thu, 20 May 2021 07:07:20 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382:
>> 
>>> 380: 
>>> 381:     _recursions = 0;
>>> 382:     ret = simple_wait(self, millis);
>> 
>> IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240.
>> 
>> In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement.
>> 
>>     _recursions = 0;
>>     ret = simple_wait(self, millis);
>>     _recursions = save;
>
> Yes, it can be re-written as something below, but is this more readable?
> 
> 
>   _recursions = 0;                                                                                               
>   ret = simple_wait(self, millis);                                                                                   
>   
>   if (self->is_Java_thread()) { // JavaThread re-enter                                                                                        
>     JavaThread* jt = self->as_Java_thread();                                                                           
>     {                                                                                                                  
>       ThreadInVMfromNative tivmfn(jt);                                                                                 
>       for (;;) {                                                                                                       
>         ExitOnSuspend eos(this);                                                                                       
>         {                                                                                                              
>           ThreadBlockInVMPreprocess<ExitOnSuspend> tbivmp(jt, eos);                                                    
>           simple_enter(jt);                                                                                            
>         }                                                                                                              
>         if (!eos.monitor_exited()) {                                                                                   
>           break;                                                                                                       
>         }                                                                                                              
>       }                                                                                                                
>       if (jt->is_interrupted(true)) {                                                                                  
>         ret = M_INTERRUPTED;                                                                                           
>       }                                                                                                                
>     }                                                                                                                  
>   } else { // Non-JavaThread re-enter                                                                 
>     assert(ret != M_INTERRUPTED, "Only JavaThreads can be interrupted");                                               
>     simple_enter(self);                                                                                            
>   }
>   _recursions = save;

Fixed

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

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

From rehn at openjdk.java.net  Thu May 20 11:42:06 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 20 May 2021 11:42:06 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5]
In-Reply-To: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
Message-ID: <dmYzr2HDJ3blDP8SoJmpaX2_zIrhUiveXWbLAbq-LN8=.11b41667-5f73-4801-97c3-c0ef13ac95b5@github.com>

> Please consider this change which removes the manual transitions to blocked.
> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
> 
> The object monitor code could be straight forward changed to use this instead of manual transitions.
> 
> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
> That made it possible to careful use ThreadInVMfromNative in raw monitors.
> 
> I also remove the early CAS in raw_enter.
> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
> 
> Passes t1-t7 and manual stressing relevant test groups.

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

 - Review fixes 2
 - Merge branch 'master' into 8265753
 - Review fixes
 - Merge branch 'master' into 8265753
 - Fixes for Dan
 - Merge branch 'master' into 8265753
 - Removed manual transitions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3875/files
  - new: https://git.openjdk.java.net/jdk/pull/3875/files/a8b8469c..6faf1422

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

  Stats: 4768 lines in 204 files changed: 3182 ins; 1013 del; 573 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875

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

From rehn at openjdk.java.net  Thu May 20 11:42:13 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 20 May 2021 11:42:13 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4]
In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com>
Message-ID: <Air9_3uzBkRRQ9MllZ3zqlTlrlrJP2mb-gY4w4whYIo=.97a50709-b573-4e5c-b0c1-d2349dfc77bc@github.com>

On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Review fixes
>  - Merge branch 'master' into 8265753
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Removed manual transitions

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 20/05/2021 5:10 pm, Robbin Ehn wrote:
> 
> > On Wed, 19 May 2021 14:25:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
> > > Just one more, rather unimportant comment...
> > > Either way: LGTM!
> > > Thanks, Richard.
> > 
> > 
> > Thanks!
> > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382:
> > > > 380:
> > > > 381:     _recursions = 0;
> > > > 382:     ret = simple_wait(self, millis);
> > > 
> > > 
> > > IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240.
> > > In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement.
> > > ```
> > >  _recursions = 0;
> > >  ret = simple_wait(self, millis);
> > >  _recursions = save;
> > > ```
> > 
> > 
> > Yes, it can be re-written as something below, but is this more readable?
> 
> I'd say yes with two minor modifications:
> 
> > _recursions = 0;
> > ret = simple_wait(self, millis);
> 
> + // Now we need to re-enter the monitor. For JavaThread's
> + // we need to manage suspend requests.
> 
> > if (self->is_Java_thread()) { // JavaThread re-enter
> > JavaThread* jt = self->as_Java_thread();
> > {
> 
> I think this extra block scope can also go.
> 
> Cheers,
> David
> -----

Fixed, thanks, Robbin

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

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

From stefank at openjdk.java.net  Thu May 20 12:03:00 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 20 May 2021 12:03:00 GMT
Subject: RFR: 8267464: Circular-dependency resiliant inline headers
Message-ID: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>

I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.

This is a small, contrived example to show the problem:

// a.hpp
#pragma once

void a1();
void a2();


// a.inline.hpp
#pragma once

#include "a.hpp"
#include "b.inline.hpp"

inline void a1() {
  b1();
}

inline void a2() {
}


// b.hpp
#pragma once

void b1();
void b2();


// b.inline.hpp
#pragma once

#include "a.inline.hpp"
#include "b.hpp"

inline void b1() {
}

inline void b2() {
  a1();
}

The following code compiles fine:

// a.cpp
#include "a.inline.hpp"

int main() {
  a1();

  return 0;
}

But the following:

// b.cpp
#include "b.inline.hpp"

int main() {
  b1();

  return 0;
}


fails with the this error message:

In file included from b.inline.hpp:3,
                 from b.cpp:1:
a.inline.hpp: In function ?void a1()?:
a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??

We can see the problem with g++ -E:

# 1 "a.inline.hpp" 1
# 1 "a.hpp" 1

void a1();
void a2();

# 4 "a.inline.hpp" 2

inline void a1() {
  b1();
}

inline void a2() {
}

# 4 "b.inline.hpp" 2
# 1 "b.hpp" 1

void b1();
void b2();

# 5 "b.inline.hpp" 2

inline void b1() {
}

inline void b2() {
  a1();
}

# 2 "b.cpp" 2

int main() {
  b1();

  return 0;
}


b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().

This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.

I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.

In the example above, b.inline.hpp would become:

// b.inline.hpp
#pragma once

#include "b.hpp"
#include "a.inline.hpp"

inline void b1() {
}

inline void b2() {
  a1();
}

and now both a.cpp and b.cpp compiles. The generated output now looks like this:

# 1 "b.inline.hpp" 1
# 1 "b.hpp" 1

void b1();
void b2();

# 4 "b.inline.hpp" 2
# 1 "a.inline.hpp" 1

# 1 "a.hpp" 1

void a1();
void a2();

# 4 "a.inline.hpp" 2

inline void a1() {
  b1();
}

inline void a2() {
}

# 5 "b.inline.hpp" 2

inline void b1() {
}

inline void b2() {
  a1();
}

# 2 "b.cpp" 2

int main() {
  b1();

  return 0;
}

The declarations come first, and the compiler is happy. 

An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.

Some notes about this patch:
1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.

What do you think?

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

Commit messages:
 - 8267464: Circular-dependency resiliant inline headers

Changes: https://git.openjdk.java.net/jdk/pull/4127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267464
  Stats: 459 lines in 224 files changed: 350 ins; 104 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

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

From david.holmes at oracle.com  Thu May 20 13:35:41 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 May 2021 23:35:41 +1000
Subject: [8u] RFR: 8267426 MonitorVmStartTerminate test timed out on
 Embedded VM
In-Reply-To: <19732680-A7C4-41CA-87C9-02CA29BDEB92@azul.com>
References: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com>
 <B7847F0C-D7BD-44FE-AA96-54DE47CBDFD7@azul.com>
 <cb69d603-c5bd-b47d-1de7-4cb8d753f8ef@oracle.com>
 <19732680-A7C4-41CA-87C9-02CA29BDEB92@azul.com>
Message-ID: <c862e182-92a8-c568-bdfe-661444558c1e@oracle.com>

On 20/05/2021 8:27 pm, Sergey Nazarkin wrote:
> Thanks David, I?ve tagged the bug
> 
> The test is not new, I tracked it down to jdk7. But EmbeddedVM build is quite tricky and it seems nobody care about it nowadays.

Looks like the test got a major overhaul after JDK 8 was released. That 
may be when it stopped working with SE Embedded. Or it may be we used to 
run the tests such that -XX:+UsePerfData was passed by jtreg ... I don't 
recall now. :)

Cheers,
David

> 
> /Sergey
> 
>> On May 20, 2021, at 03:50, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Sergey,
>>
>> Fix looks fine. I'm a little surprised we have any SE Embedded test issues arising - is this a new test?
>>
>> Cheers,
>> David
>>
>>
>> On 20/05/2021 6:28 am, Sergey Nazarkin wrote:
>>> Correct serviceability list address
>>>> On May 19, 2021, at 22:19, Sergey Nazarkin <snazarkin at azul.com> wrote:
>>>>
>>>> Hi!
>>>>
>>>> Please review small patch for the test that fails [1] on jdk8 built with JAVASE_EMBEDDED option.
>>>>
>>>> Embedded VM build disables [2] jvmstat instrumentation that prevent launched instance be detected by test agent. The fix [3] enables instrumentation for launched VM swarm and agent is able to detect them.
>>>>
>>>> The bug affects jdk8 only [4].
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8267426
>>>> [2] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/8c40ddd927ce/src/share/vm/runtime/globals.hpp#l3782
>>>> [3]  http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8267426/
>>>> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/bce3c3659531/src/hotspot/share/runtime/globals.hpp#l2413
>>>>
>>>>
>>>>
>>>>
> 

From sspitsyn at openjdk.java.net  Thu May 20 18:24:29 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 20 May 2021 18:24:29 GMT
Subject: RFR: 8266967: debug.cpp utility find() should print Java Object
 fields. [v2]
In-Reply-To: <3q3pcFTsL_lG-lh78-zZSkTomOw0vPLLAoPm6ez-TAM=.45e3cf48-009b-4899-ac3d-851338987959@github.com>
References: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>
 <3q3pcFTsL_lG-lh78-zZSkTomOw0vPLLAoPm6ez-TAM=.45e3cf48-009b-4899-ac3d-851338987959@github.com>
Message-ID: <QM9ylugFbx2jKrDl527y687mxOWKASaupX1YzYV8cjg=.076f5226-4f41-4a42-9bb8-8fec1e494845@github.com>

On Thu, 13 May 2021 13:24:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This change enables debug.cpp's find() utility to print Java Objects with their fields.
>> 
>> find() calls os::print_location, and Java heap objects are printed with instanceKlass oop_print_on.
>> Removing the ifdef for defining oop_print_on for instanceKlass, and also on methods in FieldPrinter and FieldDescriptor, make this work.
>> 
>> 
>> Checking other uses of os::print_location this might affect:
>> 
>> macroAssembler_x86.cpp has MacroAssembler::print_state32 and MacroAssembler::print_state64
>> which use os::print_location to print register contents and print words at top of stack.
>> These will be more verbose, as it already is in non-PRODUCT builds.
>> 
>> vmError uses os::print_location when showing the stack, i.e. this output:
>> 
>> Stack slot to memory mapping:
>> stack at sp + 0 slots: 0x0000000000000002 is an unknown value
>> ..etc...
>> 
>> ...will be more verbose when Java object references are found (for the 8 stack slots it tries to show).
>> 
>> 
>> Shenandoah uses os::print_location once, but for non-Java heap objects so nothing changes.
>> 
>> 
>> Manual testing on Linux-x64 and Windows: old behaviour shows these two lines only:
>> 
>> "Executing find"
>> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader
>> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader'
>> 
>> ...then with the change the full info:
>> 
>> "Executing find"
>> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader
>> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader'
>>  - ---- fields (total size 13 words):
>>  - private 'defaultAssertionStatus' 'Z' @12  false
>>  - private final 'parent' 'Ljava/lang/ClassLoader;' @24  a 'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x00000000ff0a0a
>> 40} (ff0a0a40)
>>  - private final 'name' 'Ljava/lang/String;' @28  "app"{0x00000000ff0d0060} (ff0d0060)
>>  - private final 'unnamedModule' 'Ljava/lang/Module;' @32  a 'java/lang/Module'{0x00000000ff0a0448} (ff0a0448)
>> ...etc...
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ifdef correction

Hi Kevin,
The fix looks okay to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From aivanov at openjdk.java.net  Thu May 20 18:28:41 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 20 May 2021 18:28:41 GMT
Subject: RFR: 8260690: JConsole User Guide Link from the Help menu is not
 accessible by keyboard
In-Reply-To: <xwUFe4reByexHCe7ip9yGeYxyGmmLbEJZr_cfj30cYA=.72231cd0-cfb4-4502-aed5-3034b597699d@github.com>
References: <xwUFe4reByexHCe7ip9yGeYxyGmmLbEJZr_cfj30cYA=.72231cd0-cfb4-4502-aed5-3034b597699d@github.com>
Message-ID: <YlFYKh2CdgBElZLyYVrp9BNsWFs1aEKDdyVfpJy-1JQ=.62a03f89-053b-4238-a475-00bb6fe8d999@github.com>

On Tue, 20 Apr 2021 11:02:50 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

> Hi All,
> 
> Could you please review this JConsole fix for JDK-17?
> 
> Problem:
> JConsole User Guide Link from the Help menu is not accessible by keyboard.
> 
> Fix:
> The JConsole User Guide Link can be highlighted and can now be accessed using keyboard.
> 
> Using the TAB key, the link can be highlighted and ENTER or SPACE key will browse the link.

Marked as reviewed by aivanov (Reviewer).

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

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

From kcr at openjdk.java.net  Thu May 20 18:31:33 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 20 May 2021 18:31:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <58-JOVfSiUl3xFtcjGhwaviPqV-amDLlusvj_yCwmj8=.6d3bbada-4a59-443a-9940-121606b64a71@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine.

I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected.

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

Marked as reviewed by kcr (Author).

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

From dholmes at openjdk.java.net  Thu May 20 22:09:39 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 20 May 2021 22:09:39 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5]
In-Reply-To: <dmYzr2HDJ3blDP8SoJmpaX2_zIrhUiveXWbLAbq-LN8=.11b41667-5f73-4801-97c3-c0ef13ac95b5@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <dmYzr2HDJ3blDP8SoJmpaX2_zIrhUiveXWbLAbq-LN8=.11b41667-5f73-4801-97c3-c0ef13ac95b5@github.com>
Message-ID: <TFVnBaxQzmZ8YxSy3hA5lcb6kWl00wJ9r5oJ7G8PzZw=.79154b98-145b-4bbe-b5d9-cc42d31d8abf@github.com>

On Thu, 20 May 2021 11:42:06 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Review fixes 2
>  - Merge branch 'master' into 8265753
>  - Review fixes
>  - Merge branch 'master' into 8265753
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Removed manual transitions

Updates mostly good but still a storestore issue to resolve.

Thanks,
David

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 379:

> 377:   ret = simple_wait(self, millis);
> 378: 
> 379:   // Now we need to re-enter the monitor. For JavaThread's

My bad: no apostrophe in JavaThreads

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212:

> 210:     _thread->frame_anchor()->make_walkable(_thread);
> 211:     OrderAccess::storestore();
> 212:     _thread->set_thread_state(_thread_in_native);

Can't help but think the ppc/aarch64 folk have it right and that set_thread_state should always (?) have release semantics - and would then be renamed release_set_thread_state(). Also avoids a double barrier on ppc/aarch64. Followup RFE?
But note that we need the storestore after all the make_walkable's that are followed by set_thread_state.

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

Changes requested by dholmes (Reviewer).

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

From cjplummer at openjdk.java.net  Fri May 21 01:17:36 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 21 May 2021 01:17:36 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v4]
In-Reply-To: <muAtxC9s7FVOy27tGFfZ0J9qrkc-sNt7qkFuNVf60js=.8b96a1b9-ce36-462e-88c2-33adb4041ae3@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <muAtxC9s7FVOy27tGFfZ0J9qrkc-sNt7qkFuNVf60js=.8b96a1b9-ce36-462e-88c2-33adb4041ae3@github.com>
Message-ID: <494YNA8YL_sAQGeq__piQp3cqbvwQW-rkV_UoqIIbqY=.99c2b2b5-861b-428c-9bbd-6bf44d350cce@github.com>

On Thu, 20 May 2021 03:03:09 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
>> 
>> As a result, remote name will be constructed as following:
>> 
>> 
>> //host[:port]/<serverNamePrefix>['_'<id>]
>> 
>> 
>> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>> 
>> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
>> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
>> 
>> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
>> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 133:

> 131:                 name = serverNamePrefix;
> 132:             } else {
> 133:                 throw new DebuggerException("Cannot set both sun.jvm.hotspot.rmi.serverNamePrefix and in --servername together");

Remove "in"

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

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

From ysuenaga at openjdk.java.net  Fri May 21 01:45:59 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 21 May 2021 01:45:59 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v5]
In-Reply-To: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
Message-ID: <rKYKNdSEDYU3CWK9vwTzJEWQk3szNAE0HoK7216IRWg=.2f9b6139-3a0b-4471-8cb3-0801c438411b@github.com>

> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
> 
> As a result, remote name will be constructed as following:
> 
> 
> //host[:port]/<serverNamePrefix>['_'<id>]
> 
> 
> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
> 
> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
> 
> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3669/files
  - new: https://git.openjdk.java.net/jdk/pull/3669/files/1315dc56..19d1f565

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

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

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

From ysuenaga at openjdk.java.net  Fri May 21 01:46:00 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 21 May 2021 01:46:00 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v4]
In-Reply-To: <494YNA8YL_sAQGeq__piQp3cqbvwQW-rkV_UoqIIbqY=.99c2b2b5-861b-428c-9bbd-6bf44d350cce@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <muAtxC9s7FVOy27tGFfZ0J9qrkc-sNt7qkFuNVf60js=.8b96a1b9-ce36-462e-88c2-33adb4041ae3@github.com>
 <494YNA8YL_sAQGeq__piQp3cqbvwQW-rkV_UoqIIbqY=.99c2b2b5-861b-428c-9bbd-6bf44d350cce@github.com>
Message-ID: <J0Xssa-IlJlWHBLLpDuthYQj_ps-TtpT1ODARGBLEiA=.8a931da8-b222-4148-a536-f6241138c3f5@github.com>

On Fri, 21 May 2021 01:14:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comments
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 133:
> 
>> 131:                 name = serverNamePrefix;
>> 132:             } else {
>> 133:                 throw new DebuggerException("Cannot set both sun.jvm.hotspot.rmi.serverNamePrefix and in --servername together");
> 
> Remove "in"

Thanks! I fixed it in new commit.

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

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

From cjplummer at openjdk.java.net  Fri May 21 01:52:32 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 21 May 2021 01:52:32 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v5]
In-Reply-To: <rKYKNdSEDYU3CWK9vwTzJEWQk3szNAE0HoK7216IRWg=.2f9b6139-3a0b-4471-8cb3-0801c438411b@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <rKYKNdSEDYU3CWK9vwTzJEWQk3szNAE0HoK7216IRWg=.2f9b6139-3a0b-4471-8cb3-0801c438411b@github.com>
Message-ID: <_3yS7PWHuyTyLxB_7A6UT2_pghY9-pPdrUehWuCW0LE=.e276f49c-3066-469a-b486-e4dbf637d758@github.com>

On Fri, 21 May 2021 01:45:59 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
>> 
>> As a result, remote name will be constructed as following:
>> 
>> 
>> //host[:port]/<serverNamePrefix>['_'<id>]
>> 
>> 
>> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>> 
>> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
>> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
>> 
>> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
>> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by cjplummer (Reviewer).

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

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

From weijun at openjdk.java.net  Fri May 21 01:58:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 01:58:47 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
Message-ID: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>

The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.

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

Depends on: https://git.openjdk.java.net/jdk/pull/4073

Commit messages:
 - 8267521: Post JEP 411 refactoring: maximum covering > 50K

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

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

From rehn at openjdk.java.net  Fri May 21 08:49:43 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 21 May 2021 08:49:43 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5]
In-Reply-To: <TFVnBaxQzmZ8YxSy3hA5lcb6kWl00wJ9r5oJ7G8PzZw=.79154b98-145b-4bbe-b5d9-cc42d31d8abf@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <dmYzr2HDJ3blDP8SoJmpaX2_zIrhUiveXWbLAbq-LN8=.11b41667-5f73-4801-97c3-c0ef13ac95b5@github.com>
 <TFVnBaxQzmZ8YxSy3hA5lcb6kWl00wJ9r5oJ7G8PzZw=.79154b98-145b-4bbe-b5d9-cc42d31d8abf@github.com>
Message-ID: <DZ_IXV3rsupcMTLVyTej2doZSfiH-GbUb_PNtSqZ8_g=.b0f5a236-5976-41e1-9943-7c3261bfc456@github.com>

On Thu, 20 May 2021 21:51:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Review fixes 2
>>  - Merge branch 'master' into 8265753
>>  - Review fixes
>>  - Merge branch 'master' into 8265753
>>  - Fixes for Dan
>>  - Merge branch 'master' into 8265753
>>  - Removed manual transitions
>
> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 379:
> 
>> 377:   ret = simple_wait(self, millis);
>> 378: 
>> 379:   // Now we need to re-enter the monitor. For JavaThread's
> 
> My bad: no apostrophe in JavaThreads

Fixed

> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212:
> 
>> 210:     _thread->frame_anchor()->make_walkable(_thread);
>> 211:     OrderAccess::storestore();
>> 212:     _thread->set_thread_state(_thread_in_native);
> 
> Can't help but think the ppc/aarch64 folk have it right and that set_thread_state should always (?) have release semantics - and would then be renamed release_set_thread_state(). Also avoids a double barrier on ppc/aarch64. Followup RFE?
> But note that we need the storestore after all the make_walkable's that are followed by set_thread_state.

Ah, you mean the pre-exiting missing of a storestore in TBIVM? Fixed.
But we have more of those.

Note that on TSO it's not needed, since both are volatile and will not be re-ordered by compiler.
Yes, the platform which actually do care about avoiding release for performance have it (because it's needed).
So yes it should always be there, good RFE!

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

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

From stefank at openjdk.java.net  Fri May 21 09:11:09 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 21 May 2021 09:11:09 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

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

  Clean up assembler_<cpu>.inline.hpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4127/files
  - new: https://git.openjdk.java.net/jdk/pull/4127/files/6f3fe6af..260c1115

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

  Stats: 45 lines in 28 files changed: 3 ins; 24 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

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

From dmarkov at openjdk.java.net  Fri May 21 09:38:30 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Fri, 21 May 2021 09:38:30 GMT
Subject: RFR: 8260690: JConsole User Guide Link from the Help menu is not
 accessible by keyboard
In-Reply-To: <xwUFe4reByexHCe7ip9yGeYxyGmmLbEJZr_cfj30cYA=.72231cd0-cfb4-4502-aed5-3034b597699d@github.com>
References: <xwUFe4reByexHCe7ip9yGeYxyGmmLbEJZr_cfj30cYA=.72231cd0-cfb4-4502-aed5-3034b597699d@github.com>
Message-ID: <30zElBoKee8iq1kkmw2R3Ks9NQFSEGJWhxRjG2crKVs=.b64f78ee-cb8f-4f18-8423-f73bc89cb78a@github.com>

On Tue, 20 Apr 2021 11:02:50 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

> Hi All,
> 
> Could you please review this JConsole fix for JDK-17?
> 
> Problem:
> JConsole User Guide Link from the Help menu is not accessible by keyboard.
> 
> Fix:
> The JConsole User Guide Link can be highlighted and can now be accessed using keyboard.
> 
> Using the TAB key, the link can be highlighted and ENTER or SPACE key will browse the link.

Marked as reviewed by dmarkov (Reviewer).

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

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

From rehn at openjdk.java.net  Fri May 21 09:41:10 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 21 May 2021 09:41:10 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6]
In-Reply-To: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
Message-ID: <IxgU8gedLpHnitBh2WhubcgZDGr1mPdGGbC_seLkdpc=.66a913a5-7315-4e41-85df-db9633a6b41f@github.com>

> Please consider this change which removes the manual transitions to blocked.
> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
> 
> The object monitor code could be straight forward changed to use this instead of manual transitions.
> 
> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
> That made it possible to careful use ThreadInVMfromNative in raw monitors.
> 
> I also remove the early CAS in raw_enter.
> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
> 
> Passes t1-t7 and manual stressing relevant test groups.

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

  Final fixes: last famous words

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3875/files
  - new: https://git.openjdk.java.net/jdk/pull/3875/files/6faf1422..cc15431e

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

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

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

From github.com+70650887+skodanda at openjdk.java.net  Fri May 21 09:45:39 2021
From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar)
Date: Fri, 21 May 2021 09:45:39 GMT
Subject: Integrated: 8260690: JConsole User Guide Link from the Help menu is
 not accessible by keyboard
In-Reply-To: <xwUFe4reByexHCe7ip9yGeYxyGmmLbEJZr_cfj30cYA=.72231cd0-cfb4-4502-aed5-3034b597699d@github.com>
References: <xwUFe4reByexHCe7ip9yGeYxyGmmLbEJZr_cfj30cYA=.72231cd0-cfb4-4502-aed5-3034b597699d@github.com>
Message-ID: <c4gMqTAA8mEMuY9HaUiQGJk0JjiR8oxQD6v3mnRRI08=.a8187547-3d89-4b3c-9a4c-bdeeb4e87fb8@github.com>

On Tue, 20 Apr 2021 11:02:50 GMT, K Suman Rajkumaar <github.com+70650887+skodanda at openjdk.org> wrote:

> Hi All,
> 
> Could you please review this JConsole fix for JDK-17?
> 
> Problem:
> JConsole User Guide Link from the Help menu is not accessible by keyboard.
> 
> Fix:
> The JConsole User Guide Link can be highlighted and can now be accessed using keyboard.
> 
> Using the TAB key, the link can be highlighted and ENTER or SPACE key will browse the link.

This pull request has now been integrated.

Changeset: b5d32bbf
Author:    K Suman Rajkumaar <70650887+skodanda at users.noreply.github.com>
Committer: Dmitry Markov <dmarkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b5d32bbfc716870904e91ce07a09f08929f2563e
Stats:     122 lines in 1 file changed: 108 ins; 0 del; 14 mod

8260690: JConsole User Guide Link from the Help menu is not accessible by keyboard

Reviewed-by: aivanov, dmarkov

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

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

From weijun at openjdk.java.net  Fri May 21 14:00:39 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 14:00:39 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <CYdb_wI7I2jN5d17ZTDTHbXSrTlcEiGLxlqL-LHQ8L0=.fd0b144a-1ef2-45a5-a4ec-aff71641beb6@github.com>

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.

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

  typo on windows

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/e3f0405a..d460efb8

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

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

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

From ayang at openjdk.java.net  Fri May 21 14:31:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 21 May 2021 14:31:12 GMT
Subject: RFR: 8267468: Rename refill waster counters in ThreadLocalAllocBuffer
Message-ID: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>

Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names.

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

Commit messages:
 - alias map
 - second
 - first

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

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

From dfuchs at openjdk.java.net  Fri May 21 15:36:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:36:08 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.base/share/classes/java/lang/SecurityManager.java line 104:

> 102:  * method will throw an {@code UnsupportedOperationException}). If the
> 103:  * {@systemProperty java.security.manager} system property is set to the
> 104:  * special token "{@code allow}", then a security manager will not be set at

Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

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

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

From dfuchs at openjdk.java.net  Fri May 21 15:55:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:55:07 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: <CYdb_wI7I2jN5d17ZTDTHbXSrTlcEiGLxlqL-LHQ8L0=.fd0b144a-1ef2-45a5-a4ec-aff71641beb6@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <CYdb_wI7I2jN5d17ZTDTHbXSrTlcEiGLxlqL-LHQ8L0=.fd0b144a-1ef2-45a5-a4ec-aff71641beb6@github.com>
Message-ID: <k2upNbKWXhuQFxL1hiEcjhDvV6KqILwRmeOKql6o0ZI=.3298dccc-d994-427e-b299-84e95082cc0d@github.com>

On Fri, 21 May 2021 14:00:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo on windows

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:

> 118:                         vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
> 119:                         return System.getProperty("file.encoding", "ISO8859_1");
> 120:                     }

It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:

> 548:      * @throws IOException if the connection was unsuccessful.
> 549:      */
> 550:     @SuppressWarnings("removal")

Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method?

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 921:

> 919:     }
> 920: 
> 921:     @SuppressWarnings("removal")

Could the scope be further reduced by applying it at line 926 in this method - at the cost of creating a temporary variable? The code could probably be further simplified by using a lambda...


            PrivilegedAction<Socket> pa = () -> new Socket(proxy);
            @SuppressWarnings("removal")
            var ps = AccessController.doPrivileged(pa);
            s = ps;

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

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

From sgehwolf at openjdk.java.net  Fri May 21 16:16:18 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 21 May 2021 16:16:18 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v2]
In-Reply-To: <9VBZqwiHrAzT_UHPsv2gIiGsSq9csV8cFOfjmgmhEwg=.50ae512b-5705-4c63-85ea-01f861e78024@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <9VBZqwiHrAzT_UHPsv2gIiGsSq9csV8cFOfjmgmhEwg=.50ae512b-5705-4c63-85ea-01f861e78024@github.com>
Message-ID: <UvUGJSb1BOK3IR5ki0dk5ikA5M4VrJZlMQ7PpHt-3is=.ecace5e0-50c7-405d-9cc9-262cea31bab5@github.com>

On Tue, 11 May 2021 14:57:32 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
>> 
>> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
>> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".
>
> Hao Tang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cpu.shares for OperatingSystemImpl.getCpuLoad()

@tanghaoth90 I've added a comment which should address the cpu shares based cpuLoad problem. Let me know what you think.

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

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

From sgehwolf at openjdk.java.net  Fri May 21 16:16:19 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 21 May 2021 16:16:19 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v2]
In-Reply-To: <GfXN3AoHt5Yi55L5vVJWEGV5lUZeUO62foe5zn_B234=.522648e8-0c17-4263-92e3-be575260e1d1@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
 <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>
 <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>
 <HCdl5UDmZqeuYMbB8cnr0qesiFw1x-NH6F5tbrI0eMs=.c5ed84c9-9f23-4890-a0b5-ddb5c323a931@github.com>
 <GfXN3AoHt5Yi55L5vVJWEGV5lUZeUO62foe5zn_B234=.522648e8-0c17-4263-92e3-be575260e1d1@github.com>
Message-ID: <_0A4T59iEBewRm5dMoroZ9fO5vN6KelqcHZavcALIm4=.8249eddd-fc07-4443-816e-5178a9f3a90b@github.com>

On Tue, 11 May 2021 15:48:43 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.
>> 
>> Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation.
>> 
>> We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways.
>> 1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` &  `share`);
>> 2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number.
>> 
>> Looking forward to your suggestion.
>
>> @tanghaoth90 My local testing suggests that your fix addresses the issue of CPU quotas set via `--cpu-quota/--cpu-period`. When using `--cpu-shares` the CPU load calculation is wrong since it will (wrongly) report host values. Lets look at them individually, fix the quota and shares case individually (i.e. when not both are set). Once that's done, quota will be preferred in the OperatingSystemMXBean impl, which is reasonable. I don't think we need to account for the shares-preferred-over-quota at this point since that changed in HotSpot in JDK 11 time-frame (JDK-8197589) and OperatingSystemMXBean has only been made container aware in JDK 14 (yes, it got backported, but still).
> 
> @jerboaa I have updated my fix by inserting a new branch for `--cpu-shares`. By setting up containers with different restrictions based on your suggestion, I noticed two problems for the CPU load calculation. Take [TestLoad.java](https://bugs.openjdk.java.net/secure/attachment/94530/TestLoad.java) as the example.
> 
> 1. `--cpu-quota=700000 --cpu-period=100000` as the restriction: the result is getting close to `6/7` slowly as time goes by, which indicates that the result of 
> 
> long usageNanos = containerMetrics.getCpuUsage();
> 
> is an accumulated CPU usage rather than a real-time CPU usage.
> According to the javadoc, `getCpuLoad()` _returns the "recent cpu usage"_. The current fix obviously does not address this issue.
> 
> 2. `--cpu-shares=2048` as the restriction: the "cpu-share" branch only returns `-1` since `containerMetrics.getCpuNumPeriods()` returns `0` (`nr_periods` of `cpu.stat` stays `0` when only `--cpu-shares` is set). By now, I have no idea to compute the elapsed time or the total available CPU time with the help of the methods of `jdk.internal.platform.CgroupMetrics`.
> 
> Any suggestion is appreciated. @jerboaa @argha-c

@tanghaoth90

As to your observation of 1). Yes, that's true and I'm not sure it's worth changing. We could change the javadoc.

As for 2) I've created a PR for your branch with a suggested implementation for cpu shares based accounting. It uses a similar heuristics than the getCpuLoad0() uses here:
https://github.com/openjdk/jdk/blob/master/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L278

That's the best I could think of. It's certainly more accurate than the current implementation.

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

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

From prr at openjdk.java.net  Fri May 21 18:03:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:03:01 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
 <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
Message-ID: <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>

On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
It is very straight forward to run the automated tests across all platforms these days.
I get the impression that no one is guaranteeing to do this straight after integration.
It sounds like it is up for deferral if time runs out.

The amount of follow-on work that I am hearing about here, and may be for tests, does not  make it sound
like this JEP is nearly as done as first presented.

If there was some expectation that groups responsible for an area would get involved with this
issue which I am assured was already known about, then why was it not raised before and made
part of the plan ?

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

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

From prr at openjdk.java.net  Fri May 21 18:31:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:31:01 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
Message-ID: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The client changes are fine except for the one misplaced (c)

test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:

> 1: /*
> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Probably the (c) update was meant to be on the .sh file that is actually modified.

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

Marked as reviewed by prr (Reviewer).

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

From simonis at openjdk.java.net  Fri May 21 19:29:17 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 21 May 2021 19:29:17 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after 8238048
Message-ID: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>

In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.

This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 

In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.

The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).

I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:

  // Copy the "source file name" attribute from new class version
  the_class->set_source_file_name_index(
    scratch_class->source_file_name_index());

Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?

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

Commit messages:
 - 8267555: Fix class file version during redefinition after 8238048

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

PR: https://git.openjdk.java.net/jdk/pull/4149

From weijun at openjdk.java.net  Fri May 21 19:50:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 19:50:15 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
 <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
Message-ID: <UgO9-C6Oo_ulIRbQWW6Jw5HEPeJHSAnpgfdXEfiQVNE=.bf8a2656-e9bf-4627-a37b-cc9ca84e6d1b@github.com>

On Fri, 21 May 2021 18:26:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust order of VM options
>
> test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> Probably the (c) update was meant to be on the .sh file that is actually modified.

Oops, I'll back it out. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Fri May 21 20:01:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:01:15 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v3]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <J7PKD_tgpaSH7oobcuRkh3qKFsr1wAPbxqEPaW7dJa0=.71e1df8c-8f2d-49b0-8a21-819907087678@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Phil
  
  reverted:

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Fri May 21 20:18:58 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:18:58 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: <k2upNbKWXhuQFxL1hiEcjhDvV6KqILwRmeOKql6o0ZI=.3298dccc-d994-427e-b299-84e95082cc0d@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <CYdb_wI7I2jN5d17ZTDTHbXSrTlcEiGLxlqL-LHQ8L0=.fd0b144a-1ef2-45a5-a4ec-aff71641beb6@github.com>
 <k2upNbKWXhuQFxL1hiEcjhDvV6KqILwRmeOKql6o0ZI=.3298dccc-d994-427e-b299-84e95082cc0d@github.com>
Message-ID: <-G6LsP9NmgT4W265oaeXphH-xSg2U-9ofbhBlay7_-w=.0241068a-301f-4f94-802e-69a8adb545a4@github.com>

On Fri, 21 May 2021 15:35:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:
> 
>> 118:                         vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
>> 119:                         return System.getProperty("file.encoding", "ISO8859_1");
>> 120:                     }
> 
> It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

You might say we thus avoid wasting the return value, as much as possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Fri May 21 20:23:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:23:14 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: <k2upNbKWXhuQFxL1hiEcjhDvV6KqILwRmeOKql6o0ZI=.3298dccc-d994-427e-b299-84e95082cc0d@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <CYdb_wI7I2jN5d17ZTDTHbXSrTlcEiGLxlqL-LHQ8L0=.fd0b144a-1ef2-45a5-a4ec-aff71641beb6@github.com>
 <k2upNbKWXhuQFxL1hiEcjhDvV6KqILwRmeOKql6o0ZI=.3298dccc-d994-427e-b299-84e95082cc0d@github.com>
Message-ID: <TnTeR-4Xk7slDLMBTPuFzsj8BIppB92tZ1OwEBEylEw=.850cff28-f809-4c23-ad67-6c1e19977d30@github.com>

On Fri, 21 May 2021 15:37:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:
> 
>> 548:      * @throws IOException if the connection was unsuccessful.
>> 549:      */
>> 550:     @SuppressWarnings("removal")
> 
> Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method?

I'll probably need to assign the doPriv result on L631 to a tmp variable and then assign it to `s`. Are you OK with this ugliness? Update: Ah, I see you already have similar suggestion in the next comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Fri May 21 20:37:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:37:30 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  update FtpClient.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/d460efb8..60d97a4c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01-02

  Stats: 23 lines in 1 file changed: 0 ins; 12 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From prr at openjdk.java.net  Fri May 21 20:46:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 20:46:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Fri May 21 20:55:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:55:02 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>
Message-ID: <S-kozOfLwraS98p1UoWwwNGs-M6kfUYjtcFVwtnFChY=.13224ab0-59c6-42b9-be32-46d2599b7acf@github.com>

On Fri, 21 May 2021 20:43:05 GMT, Phil Race <prr at openjdk.org> wrote:

> I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
> 
> > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
> 
> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
> > 57:                 ProcessCommunicator
> > 58:                         .executeChildProcess(Consumer.class, new String[0]);
> > 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

I replied right in the thread but unfortunately GitHub does not display it at the end of page.

This is because the process is now launched with `-Djava.security.manager=allow` (because of another change in https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in stderr. Therefore I switched to stdout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From kbarrett at openjdk.java.net  Sat May 22 05:53:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 22 May 2021 05:53:59 GMT
Subject: RFR: 8267468: Rename refill waster counters in
 ThreadLocalAllocBuffer
In-Reply-To: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
References: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
Message-ID: <L2rUpy9F2WBGBToBTsS3S_WC5Up8-RntBVinIFoRxMo=.b814ca68-e271-49a8-a90c-a6bdf019cac0@github.com>

On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4146

From alanb at openjdk.java.net  Sat May 22 07:00:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 07:00:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
 <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
 <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>
Message-ID: <EY0wxSpTN5BT63blVVvIHQ69tvBmgDTXcSroIDhlhcA=.2e93e74b-33e5-444e-8bcb-c8ffc3621597@github.com>

On Fri, 21 May 2021 18:00:13 GMT, Phil Race <prr at openjdk.org> wrote:

> Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
> It is very straight forward to run the automated tests across all platforms these days.
> I get the impression that no one is guaranteeing to do this straight after integration.
> It sounds like it is up for deferral if time runs out.
> 
> The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound
> like this JEP is nearly as done as first presented.
> 
> If there was some expectation that groups responsible for an area would get involved with this
> issue which I am assured was already known about, then why was it not raised before and made
> part of the plan ?

Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR.  PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From github.com+7947546+tanghaoth90 at openjdk.java.net  Sun May 23 07:08:13 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Sun, 23 May 2021 07:08:13 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v3]
In-Reply-To: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
Message-ID: <etu0xTuODghvnqTH9elIsORX2yd_3X_cwfuoN3wPEjg=.80e9dc8c-205d-46dc-a597-7869db48cea1@github.com>

> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
> 
> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".

Hao Tang has updated the pull request incrementally with one additional commit since the last revision:

  Add cpuLoad implementation for cpu shares quota

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3656/files
  - new: https://git.openjdk.java.net/jdk/pull/3656/files/81867f21..d76fd441

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=01-02

  Stats: 79 lines in 4 files changed: 74 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3656.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3656/head:pull/3656

PR: https://git.openjdk.java.net/jdk/pull/3656

From mullan at openjdk.java.net  Sun May 23 16:40:59 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Sun, 23 May 2021 16:40:59 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
Message-ID: <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>

On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
> 
>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>> 103:  * {@systemProperty java.security.manager} system property is set to the
>> 104:  * special token "{@code allow}", then a security manager will not be set at
> 
> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, I would just keep the first one. (I think it's ok to have more than one, if they are defined in different APIs).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From kbarrett at openjdk.java.net  Mon May 24 00:17:01 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 24 May 2021 00:17:01 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2]
In-Reply-To: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>
Message-ID: <6K69ZSv9jA-M9nRoeCAkw-PygKL2GVUg30NqfI0wbwo=.b082724d-986d-4bbb-8bd0-175200f3031f@github.com>

On Fri, 21 May 2021 09:11:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up assembler_<cpu>.inline.hpp

Code changes look fine.  This needs an update to the style guide too.

-------------

Changes requested by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4127

From dholmes at openjdk.java.net  Mon May 24 02:10:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 24 May 2021 02:10:58 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5]
In-Reply-To: <DZ_IXV3rsupcMTLVyTej2doZSfiH-GbUb_PNtSqZ8_g=.b0f5a236-5976-41e1-9943-7c3261bfc456@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <dmYzr2HDJ3blDP8SoJmpaX2_zIrhUiveXWbLAbq-LN8=.11b41667-5f73-4801-97c3-c0ef13ac95b5@github.com>
 <TFVnBaxQzmZ8YxSy3hA5lcb6kWl00wJ9r5oJ7G8PzZw=.79154b98-145b-4bbe-b5d9-cc42d31d8abf@github.com>
 <DZ_IXV3rsupcMTLVyTej2doZSfiH-GbUb_PNtSqZ8_g=.b0f5a236-5976-41e1-9943-7c3261bfc456@github.com>
Message-ID: <s6kATFQwto8fr2IXsesWA0nlMyPRzV0001OVdZSw2pY=.32615899-0411-4dc0-ae85-f3591a9329c6@github.com>

On Fri, 21 May 2021 08:45:29 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212:
>> 
>>> 210:     _thread->frame_anchor()->make_walkable(_thread);
>>> 211:     OrderAccess::storestore();
>>> 212:     _thread->set_thread_state(_thread_in_native);
>> 
>> Can't help but think the ppc/aarch64 folk have it right and that set_thread_state should always (?) have release semantics - and would then be renamed release_set_thread_state(). Also avoids a double barrier on ppc/aarch64. Followup RFE?
>> But note that we need the storestore after all the make_walkable's that are followed by set_thread_state.
>
> Ah, you mean the pre-exiting missing of a storestore in TBIVM? Fixed.
> But we have more of those.
> 
> Note that on TSO it's not needed, since both are volatile and will not be re-ordered by compiler.
> Yes, the platform which actually do care about avoiding release for performance have it (because it's needed).
> So yes it should always be there, good RFE!

Okay I will file a RFE to get the memory ordering semantics of set_thread_state cleaned up so we don't have any missing barriers where needed, nor redundant barriers.

Note that the expectation is that we write the code for the loosest possible memory model with all barriers expressed in the code, and it is then up to the implementation of those barriers to reduce it to nothing if not needed on a given platform.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From dholmes at openjdk.java.net  Mon May 24 02:33:03 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 24 May 2021 02:33:03 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5]
In-Reply-To: <s6kATFQwto8fr2IXsesWA0nlMyPRzV0001OVdZSw2pY=.32615899-0411-4dc0-ae85-f3591a9329c6@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <dmYzr2HDJ3blDP8SoJmpaX2_zIrhUiveXWbLAbq-LN8=.11b41667-5f73-4801-97c3-c0ef13ac95b5@github.com>
 <TFVnBaxQzmZ8YxSy3hA5lcb6kWl00wJ9r5oJ7G8PzZw=.79154b98-145b-4bbe-b5d9-cc42d31d8abf@github.com>
 <DZ_IXV3rsupcMTLVyTej2doZSfiH-GbUb_PNtSqZ8_g=.b0f5a236-5976-41e1-9943-7c3261bfc456@github.com>
 <s6kATFQwto8fr2IXsesWA0nlMyPRzV0001OVdZSw2pY=.32615899-0411-4dc0-ae85-f3591a9329c6@github.com>
Message-ID: <R604s_tAnxYHC5f9I16aF4WoJoPobpED_VsOnwJFCh4=.d15da907-37f4-45af-90fd-402bb5c9679f@github.com>

On Mon, 24 May 2021 02:08:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ah, you mean the pre-exiting missing of a storestore in TBIVM? Fixed.
>> But we have more of those.
>> 
>> Note that on TSO it's not needed, since both are volatile and will not be re-ordered by compiler.
>> Yes, the platform which actually do care about avoiding release for performance have it (because it's needed).
>> So yes it should always be there, good RFE!
>
> Okay I will file a RFE to get the memory ordering semantics of set_thread_state cleaned up so we don't have any missing barriers where needed, nor redundant barriers.
> 
> Note that the expectation is that we write the code for the loosest possible memory model with all barriers expressed in the code, and it is then up to the implementation of those barriers to reduce it to nothing if not needed on a given platform.
> 
> Thanks,
> David

I have filed JDK-8267585, but I realize now what you are saying. The existing code handles the barrier inconsistently. In most places it is only inside set_thread_state, for those platforms that need it. Elsewhere it is explicit in the code that calls set_thread_state - which leads to redundant barriers on the platforms that need them. I mistakenly flagged the implicit cases as a bug based on the existence of the explicit cases - but that is not the case. Sorry for the confusion.

The additional storestore barriers you added before the call to set_thread_state can be removed, and I will tidy this up using the new RFE.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From rehn at openjdk.java.net  Mon May 24 06:46:11 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 24 May 2021 06:46:11 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6]
In-Reply-To: <IxgU8gedLpHnitBh2WhubcgZDGr1mPdGGbC_seLkdpc=.66a913a5-7315-4e41-85df-db9633a6b41f@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <IxgU8gedLpHnitBh2WhubcgZDGr1mPdGGbC_seLkdpc=.66a913a5-7315-4e41-85df-db9633a6b41f@github.com>
Message-ID: <0JV9oMEZMPk-NIIsIQXvsQwCz1gbs40NtHLARinkI68=.4c4ad9b7-6cca-4e39-83c4-869bbe2853aa@github.com>

On Fri, 21 May 2021 09:41:10 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Final fixes: last famous words

Are we good to go?

Thanks, Robbin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From rehn at openjdk.java.net  Mon May 24 06:46:11 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 24 May 2021 06:46:11 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5]
In-Reply-To: <R604s_tAnxYHC5f9I16aF4WoJoPobpED_VsOnwJFCh4=.d15da907-37f4-45af-90fd-402bb5c9679f@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <dmYzr2HDJ3blDP8SoJmpaX2_zIrhUiveXWbLAbq-LN8=.11b41667-5f73-4801-97c3-c0ef13ac95b5@github.com>
 <TFVnBaxQzmZ8YxSy3hA5lcb6kWl00wJ9r5oJ7G8PzZw=.79154b98-145b-4bbe-b5d9-cc42d31d8abf@github.com>
 <DZ_IXV3rsupcMTLVyTej2doZSfiH-GbUb_PNtSqZ8_g=.b0f5a236-5976-41e1-9943-7c3261bfc456@github.com>
 <s6kATFQwto8fr2IXsesWA0nlMyPRzV0001OVdZSw2pY=.32615899-0411-4dc0-ae85-f3591a9329c6@github.com>
 <R604s_tAnxYHC5f9I16aF4WoJoPobpED_VsOnwJFCh4=.d15da907-37f4-45af-90fd-402bb5c9679f@github.com>
Message-ID: <T6YHFmaSU4kes9yNvjp_0mv0wcwxgY5g-tsYfTOhEQ0=.9569793e-e421-4b62-a504-ea3cfbd22873@github.com>

On Mon, 24 May 2021 02:29:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Okay I will file a RFE to get the memory ordering semantics of set_thread_state cleaned up so we don't have any missing barriers where needed, nor redundant barriers.
>> 
>> Note that the expectation is that we write the code for the loosest possible memory model with all barriers expressed in the code, and it is then up to the implementation of those barriers to reduce it to nothing if not needed on a given platform.
>> 
>> Thanks,
>> David
>
> I have filed JDK-8267585, but I realize now what you are saying. The existing code handles the barrier inconsistently. In most places it is only inside set_thread_state, for those platforms that need it. Elsewhere it is explicit in the code that calls set_thread_state - which leads to redundant barriers on the platforms that need them. I mistakenly flagged the implicit cases as a bug based on the existence of the explicit cases - but that is not the case. Sorry for the confusion.
> 
> The additional storestore barriers you added before the call to set_thread_state can be removed, and I will tidy this up using the new RFE.
> 
> Thanks,
> David

Sounds good, thank.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From eosterlund at openjdk.java.net  Mon May 24 08:37:11 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 24 May 2021 08:37:11 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2]
In-Reply-To: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>
Message-ID: <uUCAaBd3TtMTQuUvhGwTvKH3xtZC_je0Fg9oFUX1qmg=.0f12157d-a0fc-44c9-95b7-8b0a55a80c73@github.com>

On Fri, 21 May 2021 09:11:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up assembler_<cpu>.inline.hpp

Looks great!

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4127

From dfuchs at openjdk.java.net  Mon May 24 09:03:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 May 2021 09:03:10 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
Message-ID: <uZFOdkIRuHXdV9eeHK7gxVahxBm7-rwv3G8AyFXXh8k=.73f7b82b-95ea-4dea-a8c8-b748207a76d0@github.com>

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4138

From stefank at openjdk.java.net  Mon May 24 12:14:10 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 24 May 2021 12:14:10 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v3]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <aybWpryDEkLIPzdH-5zU4yu2nMcknZyxlyKX2oVHutE=.6232d6e0-13f4-4e3a-b202-491ff54e41ab@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Clean up assembler_<cpu>.inline.hpp
 - 8267464: Circular-dependency resiliant inline headers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4127/files
  - new: https://git.openjdk.java.net/jdk/pull/4127/files/260c1115..4bcd4348

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=01-02

  Stats: 5145 lines in 153 files changed: 2603 ins; 1960 del; 582 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Mon May 24 12:14:10 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 24 May 2021 12:14:10 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2]
In-Reply-To: <6K69ZSv9jA-M9nRoeCAkw-PygKL2GVUg30NqfI0wbwo=.b082724d-986d-4bbb-8bd0-175200f3031f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com>
 <6K69ZSv9jA-M9nRoeCAkw-PygKL2GVUg30NqfI0wbwo=.b082724d-986d-4bbb-8bd0-175200f3031f@github.com>
Message-ID: <NEjQTx8fQoTPVaeuCiXBa5u-sSrvgLj_TV3jyuNndo0=.2dee63f3-535d-45af-a566-09ee1120e05d@github.com>

On Mon, 24 May 2021 00:14:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up assembler_<cpu>.inline.hpp
>
> Code changes look fine.  This needs an update to the style guide too.

Thanks @kimbarrett and @fisk for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Mon May 24 12:58:45 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 24 May 2021 12:58:45 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Update HotSpot style guide documents

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4127/files
  - new: https://git.openjdk.java.net/jdk/pull/4127/files/4bcd4348..ba9ad1b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=02-03

  Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From weijun at openjdk.java.net  Mon May 24 13:53:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  keep only one systemProperty tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02-03

  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 24 13:53:37 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:37 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
 <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>
Message-ID: <lPk0z6baFFN6QyO0FyiIGkTu9xxIRjx0mu2IET_Kl30=.94dea9d7-9715-41c9-8069-91b5b91a6390@github.com>

On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
>> 
>>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>>> 103:  * {@systemProperty java.security.manager} system property is set to the
>>> 104:  * special token "{@code allow}", then a security manager will not be set at
>> 
>> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.
>
> Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, so we should remove those too.

New commit pushed. There is only one `@systemProperty` tag now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 24 14:05:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 14:05:08 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v4]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <ErcuQXTihK3DvF1qE6VRicIPIaRHK9upkv59SGzW_PA=.b5fbb915-d64e-42bc-b0ff-a02766c6ba9f@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:

 - Merge branch 'master' into 8267184
 - feedback from Phil
   
   reverted:
 - adjust order of VM options
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02-03

  Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Mon May 24 17:02:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 17:02:13 GMT
Subject: Integrated: 8267184: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <3rH0Qzq38uj4gzgkoDyLE_SnE47c8710ZvGAeSK6UA4=.e080d8bc-838b-4d62-87ff-ca8b12445c8a@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

This pull request has now been integrated.

Changeset: 640a2afd
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7
Stats:     1028 lines in 852 files changed: 252 ins; 9 del; 767 mod

8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From dcubed at openjdk.java.net  Mon May 24 18:25:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 24 May 2021 18:25:06 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6]
In-Reply-To: <IxgU8gedLpHnitBh2WhubcgZDGr1mPdGGbC_seLkdpc=.66a913a5-7315-4e41-85df-db9633a6b41f@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <IxgU8gedLpHnitBh2WhubcgZDGr1mPdGGbC_seLkdpc=.66a913a5-7315-4e41-85df-db9633a6b41f@github.com>
Message-ID: <opjB0xIRCY-O4IdzVH18wIGIuwQ6bM6y16ah6htQjyo=.0ecca1cf-89cf-4d27-b980-2d7be8085302@github.com>

On Fri, 21 May 2021 09:41:10 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Final fixes: last famous words

Thumbs up.

I just have some minor questions about a couple of the details.
Nothing blocking.

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 405:

> 403: 
> 404:   guarantee(self == _owner, "invariant");
> 405:   guarantee(save == _recursions, "invariant");

Since you just restored the `_recursions` field on L402, why do
you need this guarantee() 2 code lines later?

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212:

> 210:     _thread->frame_anchor()->make_walkable(_thread);
> 211:     OrderAccess::storestore();
> 212:     _thread->set_thread_state(_thread_in_native);

Please add a comment to the `storestore()` call:
// Keep thread_state change and make_walkable() separate.

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 251:

> 249:     thread->frame_anchor()->make_walkable(thread);
> 250:     OrderAccess::storestore();
> 251:     thread->set_thread_state(_thread_blocked);

Please add a comment to the storestore() call:
// Keep thread_state change and make_walkable() separate.

src/hotspot/share/runtime/objectMonitor.cpp line 435:

> 433:         ThreadBlockInVMPreprocess<ExitOnSuspend> tbivs(current, eos);
> 434:         EnterI(current);
> 435:         current->set_current_pending_monitor(NULL);

`current->set_current_pending_monitor(this)` is called above on L413
which is before the `for(;;)` loop so after this call to clear the pending
monitor, if we loop again, we will no longer have a pending monitor set.

That's a change in behavior from when the pending monitor was set to
NULL on old L435 below. I'm not sure why you move the code from old
L435 (outside the loop) to new L435 (inside the loop).

Update: I found this resolved comment below:

> And I set current->set_current_pending_monitor(om); to OM again
> in ExitOnSuspend if we exit the OM.

so that explains why we don't have a big change in behavior.

src/hotspot/share/runtime/objectMonitor.cpp line 451:

> 449:     // We cleared the pending monitor info since we've just gotten past
> 450:     // the enter-check-for-suspend dance and we now own the monitor free
> 451:     // and clear, i.e., it is no longer pending.

This comment explains why the set-pending-to-NULL code was here
(outside the loop). You moved the code, but now the comment is
misplaced and the code no longer works the same.

Update: I found this resolved comment below:

    And I set current->set_current_pending_monitor(om); to OM again
    in ExitOnSuspend if we exit the OM.

so that explains why we don't have a big change in behavior.

However, I think you still need to do something about this comment.

There is still an observable change in behavior in that the current
pending monitor can cycle between set->NULL->set->NULL when
we run into a suspend request. Previously, it did not cycle.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3875

From weijun at openjdk.java.net  Mon May 24 21:51:32 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 21:51:32 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <uZFOdkIRuHXdV9eeHK7gxVahxBm7-rwv3G8AyFXXh8k=.73f7b82b-95ea-4dea-a8c8-b748207a76d0@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
 <uZFOdkIRuHXdV9eeHK7gxVahxBm7-rwv3G8AyFXXh8k=.73f7b82b-95ea-4dea-a8c8-b748207a76d0@github.com>
Message-ID: <Z9cjMOMOHf9x-s6etCh2UndHcYFdv8xDkoEsCkRxM1s=.6bfb5a77-5987-45db-a0ce-bd150b328a4f@github.com>

On Mon, 24 May 2021 09:00:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

Assigning to a useless "dummy" variable looks ugly. Extracting the call to a method might make it faraway from its caller. In L114 of `FtpClient.java` I managed to invent a return value and I thought it was perfect. But you said it's "a bit strange". :-(

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From github.com+7947546+tanghaoth90 at openjdk.java.net  Tue May 25 06:25:23 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Tue, 25 May 2021 06:25:23 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v4]
In-Reply-To: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
Message-ID: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com>

> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
> 
> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".

Hao Tang has updated the pull request incrementally with one additional commit since the last revision:

  Fix compile errors on MacOS

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3656/files
  - new: https://git.openjdk.java.net/jdk/pull/3656/files/d76fd441..066083e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3656.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3656/head:pull/3656

PR: https://git.openjdk.java.net/jdk/pull/3656

From rehn at openjdk.java.net  Tue May 25 06:35:11 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 25 May 2021 06:35:11 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6]
In-Reply-To: <opjB0xIRCY-O4IdzVH18wIGIuwQ6bM6y16ah6htQjyo=.0ecca1cf-89cf-4d27-b980-2d7be8085302@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <IxgU8gedLpHnitBh2WhubcgZDGr1mPdGGbC_seLkdpc=.66a913a5-7315-4e41-85df-db9633a6b41f@github.com>
 <opjB0xIRCY-O4IdzVH18wIGIuwQ6bM6y16ah6htQjyo=.0ecca1cf-89cf-4d27-b980-2d7be8085302@github.com>
Message-ID: <tdvIZU_uxyFFktorfeFbeR1anosVVBK0JE28djptYkQ=.b431b98f-aadb-486c-9648-b6bf630832b9@github.com>

On Mon, 24 May 2021 16:28:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Final fixes: last famous words
>
> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 405:
> 
>> 403: 
>> 404:   guarantee(self == _owner, "invariant");
>> 405:   guarantee(save == _recursions, "invariant");
> 
> Since you just restored the `_recursions` field on L402, why do
> you need this guarantee() 2 code lines later?

I left it since if we do changes here those two should be true even after any changes.
I can remove it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From rehn at openjdk.java.net  Tue May 25 06:43:12 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 25 May 2021 06:43:12 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6]
In-Reply-To: <opjB0xIRCY-O4IdzVH18wIGIuwQ6bM6y16ah6htQjyo=.0ecca1cf-89cf-4d27-b980-2d7be8085302@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <IxgU8gedLpHnitBh2WhubcgZDGr1mPdGGbC_seLkdpc=.66a913a5-7315-4e41-85df-db9633a6b41f@github.com>
 <opjB0xIRCY-O4IdzVH18wIGIuwQ6bM6y16ah6htQjyo=.0ecca1cf-89cf-4d27-b980-2d7be8085302@github.com>
Message-ID: <tSGFbVCrbCET8FykDPPSKjUSfooUNcQjE8icqLTm8ac=.1c23c374-3879-4a57-8330-c753dc41dd55@github.com>

On Mon, 24 May 2021 17:44:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Final fixes: last famous words
>
> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212:
> 
>> 210:     _thread->frame_anchor()->make_walkable(_thread);
>> 211:     OrderAccess::storestore();
>> 212:     _thread->set_thread_state(_thread_in_native);
> 
> Please add a comment to the `storestore()` call:
> // Keep thread_state change and make_walkable() separate.

Fixed

> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 251:
> 
>> 249:     thread->frame_anchor()->make_walkable(thread);
>> 250:     OrderAccess::storestore();
>> 251:     thread->set_thread_state(_thread_blocked);
> 
> Please add a comment to the storestore() call:
> // Keep thread_state change and make_walkable() separate.

Fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From rehn at openjdk.java.net  Tue May 25 06:49:16 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 25 May 2021 06:49:16 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6]
In-Reply-To: <opjB0xIRCY-O4IdzVH18wIGIuwQ6bM6y16ah6htQjyo=.0ecca1cf-89cf-4d27-b980-2d7be8085302@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <IxgU8gedLpHnitBh2WhubcgZDGr1mPdGGbC_seLkdpc=.66a913a5-7315-4e41-85df-db9633a6b41f@github.com>
 <opjB0xIRCY-O4IdzVH18wIGIuwQ6bM6y16ah6htQjyo=.0ecca1cf-89cf-4d27-b980-2d7be8085302@github.com>
Message-ID: <ksJUMPkuWa5PTBBWhrz3JoXt-mpuN6B-UhPnXXDFSGA=.933c9149-4d5b-45f0-9a14-ed7bc5c737f5@github.com>

On Mon, 24 May 2021 17:57:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Final fixes: last famous words
>
> src/hotspot/share/runtime/objectMonitor.cpp line 451:
> 
>> 449:     // We cleared the pending monitor info since we've just gotten past
>> 450:     // the enter-check-for-suspend dance and we now own the monitor free
>> 451:     // and clear, i.e., it is no longer pending.
> 
> This comment explains why the set-pending-to-NULL code was here
> (outside the loop). You moved the code, but now the comment is
> misplaced and the code no longer works the same.
> 
> Update: I found this resolved comment below:
> 
>     And I set current->set_current_pending_monitor(om); to OM again
>     in ExitOnSuspend if we exit the OM.
> 
> so that explains why we don't have a big change in behavior.
> 
> However, I think you still need to do something about this comment.
> 
> There is still an observable change in behavior in that the current
> pending monitor can cycle between set->NULL->set->NULL when
> we run into a suspend request. Previously, it did not cycle.

If we stop for a suspend request current pending monitor will always be set, so the cycling cannot be seen.
Updated comment(s).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From rehn at openjdk.java.net  Tue May 25 07:06:58 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 25 May 2021 07:06:58 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7]
In-Reply-To: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
Message-ID: <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>

> Please consider this change which removes the manual transitions to blocked.
> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
> 
> The object monitor code could be straight forward changed to use this instead of manual transitions.
> 
> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
> That made it possible to careful use ThreadInVMfromNative in raw monitors.
> 
> I also remove the early CAS in raw_enter.
> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
> 
> Passes t1-t7 and manual stressing relevant test groups.

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Fixes for Dan
 - Merge branch 'master' into 8265753
 - Final fixes: last famous words
 - Review fixes 2
 - Merge branch 'master' into 8265753
 - Review fixes
 - Merge branch 'master' into 8265753
 - Fixes for Dan
 - Merge branch 'master' into 8265753
 - Removed manual transitions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3875/files
  - new: https://git.openjdk.java.net/jdk/pull/3875/files/cc15431e..30d62e85

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=05-06

  Stats: 9596 lines in 1190 files changed: 4469 ins; 2824 del; 2303 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875

PR: https://git.openjdk.java.net/jdk/pull/3875

From rehn at openjdk.java.net  Tue May 25 07:12:08 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 25 May 2021 07:12:08 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6]
In-Reply-To: <opjB0xIRCY-O4IdzVH18wIGIuwQ6bM6y16ah6htQjyo=.0ecca1cf-89cf-4d27-b980-2d7be8085302@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <IxgU8gedLpHnitBh2WhubcgZDGr1mPdGGbC_seLkdpc=.66a913a5-7315-4e41-85df-db9633a6b41f@github.com>
 <opjB0xIRCY-O4IdzVH18wIGIuwQ6bM6y16ah6htQjyo=.0ecca1cf-89cf-4d27-b980-2d7be8085302@github.com>
Message-ID: <NeJ6HbtWAbvAseckz_fpnZeTDt4rsNaf6EBdTs-8mq8=.558b8226-bf2b-48b2-ab9d-89d676f80705@github.com>

On Mon, 24 May 2021 18:12:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up.
> 
> I just have some minor questions about a couple of the details.
> Nothing blocking.

Thanks Dan!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From sgehwolf at openjdk.java.net  Tue May 25 09:56:00 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 25 May 2021 09:56:00 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v4]
In-Reply-To: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com>
Message-ID: <p62JHQkSIWKMHcPNPxlsWLCxJUJUxW5AVUzYMnqAUxw=.f24d9da4-d750-4c56-97bc-ada07dd6ac6b@github.com>

On Tue, 25 May 2021 06:25:23 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
>> 
>> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
>> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".
>
> Hao Tang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compile errors on MacOS

Bumping number of required reviewers to 2 as I'm a contributing author of the change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From github.com+7947546+tanghaoth90 at openjdk.java.net  Tue May 25 11:42:21 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Tue, 25 May 2021 11:42:21 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v5]
In-Reply-To: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
Message-ID: <2L47jsQSBzF9uwmdBG-_DVGjA5PNNKy1tCBbXrepXys=.d606890e-c4ea-4452-bd59-a503c22fc076@github.com>

> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
> 
> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".

Hao Tang has updated the pull request incrementally with one additional commit since the last revision:

  remove PER_CPU_SHARES

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3656/files
  - new: https://git.openjdk.java.net/jdk/pull/3656/files/066083e9..c7abec03

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3656.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3656/head:pull/3656

PR: https://git.openjdk.java.net/jdk/pull/3656

From sgehwolf at openjdk.java.net  Tue May 25 11:42:42 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 25 May 2021 11:42:42 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v4]
In-Reply-To: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com>
Message-ID: <nhZJCKaArAejfiHhndWeWMfkKw5KbY3JOHYvxd6xgCA=.e26504cd-675f-45dd-b8aa-b117c3507f94@github.com>

On Tue, 25 May 2021 06:25:23 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
>> 
>> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
>> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".
>
> Hao Tang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compile errors on MacOS

LGTM. Nit: Please remove `PER_CPU_SHARES` constant as it's no longer used.

src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 44:

> 42: 
> 43:     private static final int MAX_ATTEMPTS_NUMBER = 10;
> 44:     private static final int PER_CPU_SHARES = 1024;

I think this is no longer used anywhere so can get removed.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3656

From rrich at openjdk.java.net  Tue May 25 13:08:06 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Tue, 25 May 2021 13:08:06 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7]
In-Reply-To: <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
Message-ID: <pR-p8IFnyA-_sBNbmBaVZbQNemtAF37HRQSVh7-AbSQ=.8de7c1c2-1e27-4b65-b077-3a235e57e095@github.com>

On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Final fixes: last famous words
>  - Review fixes 2
>  - Merge branch 'master' into 8265753
>  - Review fixes
>  - Merge branch 'master' into 8265753
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Removed manual transitions

Still looks good to me.

Cheer's, Richard.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From rehn at openjdk.java.net  Tue May 25 13:38:03 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 25 May 2021 13:38:03 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7]
In-Reply-To: <pR-p8IFnyA-_sBNbmBaVZbQNemtAF37HRQSVh7-AbSQ=.8de7c1c2-1e27-4b65-b077-3a235e57e095@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
 <pR-p8IFnyA-_sBNbmBaVZbQNemtAF37HRQSVh7-AbSQ=.8de7c1c2-1e27-4b65-b077-3a235e57e095@github.com>
Message-ID: <375JabqE79ZBg7y-VsUTkHoex6Bou-NKSJyZvcfR-mY=.3e38489a-0e46-4828-92e2-2451508f0a63@github.com>

On Tue, 25 May 2021 13:04:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Still looks good to me.
> 
> Cheer's, Richard.

Thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From mullan at openjdk.java.net  Tue May 25 13:51:01 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 25 May 2021 13:51:01 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security
In-Reply-To: <way7gZK55c5Z7hEWz3Wqw9QioheO1aw2ZSDMq5UAb58=.01dc300c-85ee-4de7-bef4-eff05fd17bb6@github.com>
References: <way7gZK55c5Z7hEWz3Wqw9QioheO1aw2ZSDMq5UAb58=.01dc300c-85ee-4de7-bef4-eff05fd17bb6@github.com>
Message-ID: <s8BlanjshcMx9F19eeR_v2jLQyqt000Kzy_pBERzx9U=.653dd1fd-0fb6-4be9-9a43-2015d3ab3db4@github.com>

On Mon, 24 May 2021 20:23:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target.

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 709:

> 707:                         }
> 708:                         if (GSSUtil.useSubjectCredsOnly(caller)) {
> 709:                             @SuppressWarnings("removal")

It looks like you missed removing the @SuppressWarnings("removal") from the initSecContext method above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4172

From weijun at openjdk.java.net  Tue May 25 16:20:35 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 25 May 2021 16:20:35 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2]
In-Reply-To: <way7gZK55c5Z7hEWz3Wqw9QioheO1aw2ZSDMq5UAb58=.01dc300c-85ee-4de7-bef4-eff05fd17bb6@github.com>
References: <way7gZK55c5Z7hEWz3Wqw9QioheO1aw2ZSDMq5UAb58=.01dc300c-85ee-4de7-bef4-eff05fd17bb6@github.com>
Message-ID: <Q1a3623Qxt6hX8et_Z9cYOuqbP9hGAEpprDP-vLBJTs=.2af92f8a-33ee-4c71-b85d-cb0268c47fd0@github.com>

> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target.
> 
> I'll add a copyright year update commit before integration.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more change

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4172/files
  - new: https://git.openjdk.java.net/jdk/pull/4172/files/b22fd7d7..176f44e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4172&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4172&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4172.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4172/head:pull/4172

PR: https://git.openjdk.java.net/jdk/pull/4172

From weijun at openjdk.java.net  Tue May 25 16:20:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 25 May 2021 16:20:38 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2]
In-Reply-To: <s8BlanjshcMx9F19eeR_v2jLQyqt000Kzy_pBERzx9U=.653dd1fd-0fb6-4be9-9a43-2015d3ab3db4@github.com>
References: <way7gZK55c5Z7hEWz3Wqw9QioheO1aw2ZSDMq5UAb58=.01dc300c-85ee-4de7-bef4-eff05fd17bb6@github.com>
 <s8BlanjshcMx9F19eeR_v2jLQyqt000Kzy_pBERzx9U=.653dd1fd-0fb6-4be9-9a43-2015d3ab3db4@github.com>
Message-ID: <WDH0hqB9jfgDxy_3FMgbtx2PPhfUe6J5Ro85qwaAB2g=.89385efc-2298-44e4-ac73-7a020c3c59f7@github.com>

On Tue, 25 May 2021 13:44:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   one more change
>
> src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 709:
> 
>> 707:                         }
>> 708:                         if (GSSUtil.useSubjectCredsOnly(caller)) {
>> 709:                             @SuppressWarnings("removal")
> 
> It looks like you missed removing the @SuppressWarnings("removal") from the initSecContext method above.

Oops. Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4172

From sspitsyn at openjdk.java.net  Tue May 25 20:17:35 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 25 May 2021 20:17:35 GMT
Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v5]
In-Reply-To: <rKYKNdSEDYU3CWK9vwTzJEWQk3szNAE0HoK7216IRWg=.2f9b6139-3a0b-4471-8cb3-0801c438411b@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
 <rKYKNdSEDYU3CWK9vwTzJEWQk3szNAE0HoK7216IRWg=.2f9b6139-3a0b-4471-8cb3-0801c438411b@github.com>
Message-ID: <c7ANVLlAzEmtRoVfmBDijZzkY5jY69p8xQL0L7nwSPM=.53eb2eab-bf87-4a43-bb29-f4ff68b154f0@github.com>

On Fri, 21 May 2021 01:45:59 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
>> 
>> As a result, remote name will be constructed as following:
>> 
>> 
>> //host[:port]/<serverNamePrefix>['_'<id>]
>> 
>> 
>> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
>> 
>> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
>> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
>> 
>> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
>> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Hi Yasumasa,

It looks good to me.

Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3669

From mullan at openjdk.java.net  Tue May 25 21:28:35 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 25 May 2021 21:28:35 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2]
In-Reply-To: <Q1a3623Qxt6hX8et_Z9cYOuqbP9hGAEpprDP-vLBJTs=.2af92f8a-33ee-4c71-b85d-cb0268c47fd0@github.com>
References: <way7gZK55c5Z7hEWz3Wqw9QioheO1aw2ZSDMq5UAb58=.01dc300c-85ee-4de7-bef4-eff05fd17bb6@github.com>
 <Q1a3623Qxt6hX8et_Z9cYOuqbP9hGAEpprDP-vLBJTs=.2af92f8a-33ee-4c71-b85d-cb0268c47fd0@github.com>
Message-ID: <6MXMOwoTFMlNVcPM_87-RhJ-J99JKyzY4PRFjx4SM1M=.fbc66aa4-e548-44e8-97c0-024a846af89d@github.com>

On Tue, 25 May 2021 16:20:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more change

Update copyright dates to 2021, if applicable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4172

From weijun at openjdk.java.net  Tue May 25 21:38:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 25 May 2021 21:38:38 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2]
In-Reply-To: <6MXMOwoTFMlNVcPM_87-RhJ-J99JKyzY4PRFjx4SM1M=.fbc66aa4-e548-44e8-97c0-024a846af89d@github.com>
References: <way7gZK55c5Z7hEWz3Wqw9QioheO1aw2ZSDMq5UAb58=.01dc300c-85ee-4de7-bef4-eff05fd17bb6@github.com>
 <Q1a3623Qxt6hX8et_Z9cYOuqbP9hGAEpprDP-vLBJTs=.2af92f8a-33ee-4c71-b85d-cb0268c47fd0@github.com>
 <6MXMOwoTFMlNVcPM_87-RhJ-J99JKyzY4PRFjx4SM1M=.fbc66aa4-e548-44e8-97c0-024a846af89d@github.com>
Message-ID: <Kv4c9ljrS69ovL88Sa-xhPWiErIYngJYViXfj1nrNlY=.fcdd00e5-0e3d-4b61-a8c5-a7c3404dcba0@github.com>

On Tue, 25 May 2021 21:25:54 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Update copyright dates to 2021, if applicable.

Will do. Since this PR can only be integrated after its parent PR #4073 is integrated. I'll delay the copyright update by then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4172

From cjplummer at openjdk.java.net  Tue May 25 21:43:21 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 25 May 2021 21:43:21 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file
In-Reply-To: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
Message-ID: <o5n_t3tH-C_EbGf2HR30KOvMl5I0uNEOQY1JJdZUTjs=.397f5f75-ec5c-442d-8f12-2562b2b3ce8f@github.com>

On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
> 
> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
> 
> Reviews of the CSR linked to the bug would be appreciated as well.

@AntonKozlov I thought there was recently a thread were you discussed this, but I can't find it. If there was one, can you include a link? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4183

From github.com+7947546+tanghaoth90 at openjdk.java.net  Tue May 25 21:46:51 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Tue, 25 May 2021 21:46:51 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v4]
In-Reply-To: <p62JHQkSIWKMHcPNPxlsWLCxJUJUxW5AVUzYMnqAUxw=.f24d9da4-d750-4c56-97bc-ada07dd6ac6b@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com>
 <p62JHQkSIWKMHcPNPxlsWLCxJUJUxW5AVUzYMnqAUxw=.f24d9da4-d750-4c56-97bc-ada07dd6ac6b@github.com>
Message-ID: <1jNGqnPyx5PErHwQYny5mkEtPAXyIsiBAty34hIWGpM=.6254f320-a65b-4ea1-b590-d14f97f45f55@github.com>

On Tue, 25 May 2021 09:53:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Hao Tang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compile errors on MacOS
>
> Bumping number of required reviewers to 2 as I'm a contributing author of the change.

@jerboaa Thank you for the cpu-shares-based load calculation! I also update the cpu-quota-based load calculation to use the same strategy as the cpu-shares-based one, because my previous implementation always reports the average load since the container starts.
Another change is to set the initial value of `usageTicks`/`totalTicks` to zero. Therefore, the first call of `getCpuLoad` can also report a reasonable result.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From github.com+7947546+tanghaoth90 at openjdk.java.net  Tue May 25 21:46:27 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Tue, 25 May 2021 21:46:27 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v6]
In-Reply-To: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
Message-ID: <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>

> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
> 
> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".

Hao Tang has updated the pull request incrementally with two additional commits since the last revision:

 - Use historical-value-based formula for both cpu-quota-based and cpu-shares-based calculation
 - rename usageTicks and totalTicks

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3656/files
  - new: https://git.openjdk.java.net/jdk/pull/3656/files/c7abec03..eba3bc10

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=04-05

  Stats: 81 lines in 1 file changed: 32 ins; 39 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3656.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3656/head:pull/3656

PR: https://git.openjdk.java.net/jdk/pull/3656

From mullan at openjdk.java.net  Tue May 25 21:53:04 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 25 May 2021 21:53:04 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2]
In-Reply-To: <Q1a3623Qxt6hX8et_Z9cYOuqbP9hGAEpprDP-vLBJTs=.2af92f8a-33ee-4c71-b85d-cb0268c47fd0@github.com>
References: <way7gZK55c5Z7hEWz3Wqw9QioheO1aw2ZSDMq5UAb58=.01dc300c-85ee-4de7-bef4-eff05fd17bb6@github.com>
 <Q1a3623Qxt6hX8et_Z9cYOuqbP9hGAEpprDP-vLBJTs=.2af92f8a-33ee-4c71-b85d-cb0268c47fd0@github.com>
Message-ID: <WoPpEkBgS02Zjphivj9RSSl-j0bhG__ogcLqyI_WAwM=.1b313ef0-8113-41a1-8cb9-4eb2d16e6dc8@github.com>

On Tue, 25 May 2021 16:20:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more change

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4172

From sspitsyn at openjdk.java.net  Tue May 25 22:39:15 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 25 May 2021 22:39:15 GMT
Subject: RFR: 8267468: Rename refill waster counters in
 ThreadLocalAllocBuffer
In-Reply-To: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
References: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
Message-ID: <FZ5yWJjMLyZghEvkkBfTm6e_hT8GcdJS18agd27EJFc=.576d6ae0-fb84-401c-9916-830d954c836f@github.com>

On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names.

Hi Albert,
Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4146

From serguei.spitsyn at oracle.com  Tue May 25 22:42:36 2021
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 25 May 2021 22:42:36 +0000
Subject: [8u] RFR: 8267426 MonitorVmStartTerminate test timed out on
 Embedded VM
In-Reply-To: <c862e182-92a8-c568-bdfe-661444558c1e@oracle.com>
References: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com>
 <B7847F0C-D7BD-44FE-AA96-54DE47CBDFD7@azul.com>
 <cb69d603-c5bd-b47d-1de7-4cb8d753f8ef@oracle.com>
 <19732680-A7C4-41CA-87C9-02CA29BDEB92@azul.com>
 <c862e182-92a8-c568-bdfe-661444558c1e@oracle.com>
Message-ID: <373AE15B-B432-4812-BCBF-048C90B92066@oracle.com>

Hi Sergey,

It looks good to me too (if you need one more review).

Thanks,
Serguei

?On 5/20/21, 6:36 AM, "jdk8u-dev on behalf of David Holmes" <jdk8u-dev-retn at openjdk.java.net on behalf of david.holmes at oracle.com> wrote:

    On 20/05/2021 8:27 pm, Sergey Nazarkin wrote:
    > Thanks David, I?ve tagged the bug
    > 
    > The test is not new, I tracked it down to jdk7. But EmbeddedVM build is quite tricky and it seems nobody care about it nowadays.
    
    Looks like the test got a major overhaul after JDK 8 was released. That 
    may be when it stopped working with SE Embedded. Or it may be we used to 
    run the tests such that -XX:+UsePerfData was passed by jtreg ... I don't 
    recall now. :)
    
    Cheers,
    David
    
    > 
    > /Sergey
    > 
    >> On May 20, 2021, at 03:50, David Holmes <david.holmes at oracle.com> wrote:
    >>
    >> Hi Sergey,
    >>
    >> Fix looks fine. I'm a little surprised we have any SE Embedded test issues arising - is this a new test?
    >>
    >> Cheers,
    >> David
    >>
    >>
    >> On 20/05/2021 6:28 am, Sergey Nazarkin wrote:
    >>> Correct serviceability list address
    >>>> On May 19, 2021, at 22:19, Sergey Nazarkin <snazarkin at azul.com> wrote:
    >>>>
    >>>> Hi!
    >>>>
    >>>> Please review small patch for the test that fails [1] on jdk8 built with JAVASE_EMBEDDED option.
    >>>>
    >>>> Embedded VM build disables [2] jvmstat instrumentation that prevent launched instance be detected by test agent. The fix [3] enables instrumentation for launched VM swarm and agent is able to detect them.
    >>>>
    >>>> The bug affects jdk8 only [4].
    >>>>
    >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8267426
    >>>> [2] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/8c40ddd927ce/src/share/vm/runtime/globals.hpp#l3782
    >>>> [3]  http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8267426/
    >>>> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/bce3c3659531/src/hotspot/share/runtime/globals.hpp#l2413
    >>>>
    >>>>
    >>>>
    >>>>
    > 
    


From dholmes at openjdk.java.net  Tue May 25 23:03:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 25 May 2021 23:03:28 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7]
In-Reply-To: <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
Message-ID: <KihtaWY59ro-kQz9sfB6aQav1brA7VIMolTloWCwANI=.5a4489c4-d466-47d7-ba9a-57aedbaed65b@github.com>

On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Final fixes: last famous words
>  - Review fixes 2
>  - Merge branch 'master' into 8265753
>  - Review fixes
>  - Merge branch 'master' into 8265753
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Removed manual transitions

Nothing further from me.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3875

From dholmes at openjdk.java.net  Tue May 25 23:06:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 25 May 2021 23:06:14 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4]
In-Reply-To: <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
Message-ID: <JJ2sP-JmHk_FqKvNN5nNupat_4C05iDLnnhJ6ftzj3s=.51e6bcba-1a1e-44e0-9788-68889cca4506@github.com>

On Mon, 24 May 2021 12:58:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update HotSpot style guide documents

doc/hotspot-style.html line 97:

> 95: <li><p>Do not put non-trivial function implementations in .hpp files. If the implementation depends on other .hpp files, put it in a .cpp or a .inline.hpp file.</p></li>
> 96: <li><p>.inline.hpp files should only be included in .cpp or .inline.hpp files.</p></li>
> 97: <li><p>All .inline.hpp files should include their corresponding .hpp file as the first include line. Externally used declarations should be put in the .hpp file, and not in the the .inline.hpp file. This rule exists to resolve problems with circular dependencies between.inline.hpp files.</p></li>

typo: the the
Need space after between on last line

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From github.com+7947546+tanghaoth90 at openjdk.java.net  Wed May 26 01:55:14 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Wed, 26 May 2021 01:55:14 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v4]
In-Reply-To: <nhZJCKaArAejfiHhndWeWMfkKw5KbY3JOHYvxd6xgCA=.e26504cd-675f-45dd-b8aa-b117c3507f94@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com>
 <nhZJCKaArAejfiHhndWeWMfkKw5KbY3JOHYvxd6xgCA=.e26504cd-675f-45dd-b8aa-b117c3507f94@github.com>
Message-ID: <hTOiv1rQJWBSNnF3we97n_URMx82pyjNlj0uqeflij0=.15cbc6d8-49b4-476f-b863-1d8d3bd19f8a@github.com>

On Tue, 25 May 2021 09:56:50 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Hao Tang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compile errors on MacOS
>
> src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 44:
> 
>> 42: 
>> 43:     private static final int MAX_ATTEMPTS_NUMBER = 10;
>> 44:     private static final int PER_CPU_SHARES = 1024;
> 
> I think this is no longer used anywhere so can get removed.

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From dholmes at openjdk.java.net  Wed May 26 02:21:11 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 26 May 2021 02:21:11 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4]
In-Reply-To: <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
Message-ID: <OZ5FPnyyi36m1M6vwvoHhLIyPaohJWRnLV8BQaoBleo=.552f9b74-912c-44a2-b229-d143ee857302@github.com>

On Mon, 24 May 2021 12:58:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update HotSpot style guide documents

Hi Stefan,

I think this policy makes a lot of sense!

I only scanned through the changes to get a sense of them but it all seemed fine.

Thanks,
David

doc/hotspot-style.md line 142:

> 140: 
> 141: * All .inline.hpp files should include their corresponding .hpp file
> 142: as the first include line. Externally used declarations should be put

Do we need to spell out it should be first unless precompiled.hpp is included?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4127

From github.com+7947546+tanghaoth90 at openjdk.java.net  Wed May 26 06:24:15 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Wed, 26 May 2021 06:24:15 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v6]
In-Reply-To: <_0A4T59iEBewRm5dMoroZ9fO5vN6KelqcHZavcALIm4=.8249eddd-fc07-4443-816e-5178a9f3a90b@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <mpr9-HOuLoLkvAIUYwpEmXXn7uHJiIpjkD1IvpMMmcQ=.7f9aa9b3-499e-49cc-9b50-e5f94f8337a5@github.com>
 <ciclPxFHxHXTncwV3kn7yt-MiFjBKj0q6wZ_6Y4iAzc=.0ddcfe74-4eba-4982-aa84-bc8044ecc8ef@github.com>
 <gEaFq8QmMAU9HS-Ci9Q4rH5LBCmbcDh9WBhQjrzysSw=.73d37c1d-a429-419b-8af6-0da3c3937c38@github.com>
 <HCdl5UDmZqeuYMbB8cnr0qesiFw1x-NH6F5tbrI0eMs=.c5ed84c9-9f23-4890-a0b5-ddb5c323a931@github.com>
 <GfXN3AoHt5Yi55L5vVJWEGV5lUZeUO62foe5zn_B234=.522648e8-0c17-4263-92e3-be575260e1d1@github.com>
 <_0A4T59iEBewRm5dMoroZ9fO5vN6KelqcHZavcALIm4=.8249eddd-fc07-4443-816e-5178a9f3a90b@github.com>
Message-ID: <K_SW8OBvuVlRezZovMAcwVZqufGo0ncMkH_jWp9x1Ms=.76e59e11-1a95-49b7-8c50-830ed1394928@github.com>

On Fri, 21 May 2021 16:11:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> @tanghaoth90 My local testing suggests that your fix addresses the issue of CPU quotas set via `--cpu-quota/--cpu-period`. When using `--cpu-shares` the CPU load calculation is wrong since it will (wrongly) report host values. Lets look at them individually, fix the quota and shares case individually (i.e. when not both are set). Once that's done, quota will be preferred in the OperatingSystemMXBean impl, which is reasonable. I don't think we need to account for the shares-preferred-over-quota at this point since that changed in HotSpot in JDK 11 time-frame (JDK-8197589) and OperatingSystemMXBean has only been made container aware in JDK 14 (yes, it got backported, but still).
>> 
>> @jerboaa I have updated my fix by inserting a new branch for `--cpu-shares`. By setting up containers with different restrictions based on your suggestion, I noticed two problems for the CPU load calculation. Take [TestLoad.java](https://bugs.openjdk.java.net/secure/attachment/94530/TestLoad.java) as the example.
>> 
>> 1. `--cpu-quota=700000 --cpu-period=100000` as the restriction: the result is getting close to `6/7` slowly as time goes by, which indicates that the result of 
>> 
>> long usageNanos = containerMetrics.getCpuUsage();
>> 
>> is an accumulated CPU usage rather than a real-time CPU usage.
>> According to the javadoc, `getCpuLoad()` _returns the "recent cpu usage"_. The current fix obviously does not address this issue.
>> 
>> 2. `--cpu-shares=2048` as the restriction: the "cpu-share" branch only returns `-1` since `containerMetrics.getCpuNumPeriods()` returns `0` (`nr_periods` of `cpu.stat` stays `0` when only `--cpu-shares` is set). By now, I have no idea to compute the elapsed time or the total available CPU time with the help of the methods of `jdk.internal.platform.CgroupMetrics`.
>> 
>> Any suggestion is appreciated. @jerboaa @argha-c
>
> @tanghaoth90
> 
> As to your observation of 1). Yes, that's true and I'm not sure it's worth changing. We could change the javadoc.
> 
> As for 2) I've created a PR for your branch with a suggested implementation for cpu shares based accounting. It uses a similar heuristics than the getCpuLoad0() uses here:
> https://github.com/openjdk/jdk/blob/master/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L278
> 
> That's the best I could think of. It's certainly more accurate than the current implementation.

@jerboaa Just read your comment about my observation (due to the weird format of github pull request). Sorry for making further [change](https://github.com/openjdk/jdk/pull/3656/commits/eba3bc10b4ebd) for the `quota` branch without asking for your suggestion. For now, I still hold a different opinion about the `quota` branch. My local test shows that

podman run --cpu-shares=4096 <image>
podman run --cpu-quota=400000 --cpu-period=100000 <image>

yields the same result after the change, otherwise the second one still prints the average cpu load.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From rehn at openjdk.java.net  Wed May 26 06:24:23 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 26 May 2021 06:24:23 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7]
In-Reply-To: <KihtaWY59ro-kQz9sfB6aQav1brA7VIMolTloWCwANI=.5a4489c4-d466-47d7-ba9a-57aedbaed65b@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
 <KihtaWY59ro-kQz9sfB6aQav1brA7VIMolTloWCwANI=.5a4489c4-d466-47d7-ba9a-57aedbaed65b@github.com>
Message-ID: <i0G7JRo82t6lxArUUaCyL1k4rGLsgwkH0hygyJAFs5I=.8e9b3423-caa5-4f38-b429-e2fb125355e6@github.com>

On Tue, 25 May 2021 22:59:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Nothing further from me.
> 
> Thanks,
> David

Thank you David!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From stefank at openjdk.java.net  Wed May 26 06:38:47 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 26 May 2021 06:38:47 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v5]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <c-OaKR1PFHIGfLRVAIG-RHC5EnozbxTHzTMq_5TRl_g=.140285a5-9230-4931-9679-8945670749d8@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review dholmes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4127/files
  - new: https://git.openjdk.java.net/jdk/pull/4127/files/ba9ad1b1..0cf6257d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=03-04

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Wed May 26 06:38:53 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 26 May 2021 06:38:53 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4]
In-Reply-To: <OZ5FPnyyi36m1M6vwvoHhLIyPaohJWRnLV8BQaoBleo=.552f9b74-912c-44a2-b229-d143ee857302@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
 <OZ5FPnyyi36m1M6vwvoHhLIyPaohJWRnLV8BQaoBleo=.552f9b74-912c-44a2-b229-d143ee857302@github.com>
Message-ID: <O9teAMehggUiNNgTYGybK7Y7096B-qRUJy9GCCbUFhU=.4ab3e9e9-7a4f-437f-96f1-09125677e709@github.com>

On Wed, 26 May 2021 02:18:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Stefan,
> 
> I think this policy makes a lot of sense!
> 
> I only scanned through the changes to get a sense of them but it all seemed fine.
> 
> Thanks,
> David

Thanks a lot for reviewing!

> doc/hotspot-style.html line 97:
> 
>> 95: <li><p>Do not put non-trivial function implementations in .hpp files. If the implementation depends on other .hpp files, put it in a .cpp or a .inline.hpp file.</p></li>
>> 96: <li><p>.inline.hpp files should only be included in .cpp or .inline.hpp files.</p></li>
>> 97: <li><p>All .inline.hpp files should include their corresponding .hpp file as the first include line. Externally used declarations should be put in the .hpp file, and not in the the .inline.hpp file. This rule exists to resolve problems with circular dependencies between.inline.hpp files.</p></li>
> 
> typo: the the
> Need space after between on last line

Fixed.

> doc/hotspot-style.md line 142:
> 
>> 140: 
>> 141: * All .inline.hpp files should include their corresponding .hpp file
>> 142: as the first include line. Externally used declarations should be put
> 
> Do we need to spell out it should be first unless precompiled.hpp is included?

We should never include precompiled.hpp from an .inline.hpp file, so I don't think we need to state that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From ayang at openjdk.java.net  Wed May 26 06:53:17 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 26 May 2021 06:53:17 GMT
Subject: RFR: 8267468: Rename refill waster counters in
 ThreadLocalAllocBuffer
In-Reply-To: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
References: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
Message-ID: <4yHlfwn57DzEGk0FzmvZpC-x5811b8e0gvTaeeEw-5w=.340ae43e-9293-4623-8c1e-d1de77eb41bd@github.com>

On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names.

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4146

From ayang at openjdk.java.net  Wed May 26 06:53:17 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 26 May 2021 06:53:17 GMT
Subject: Integrated: 8267468: Rename refill waster counters in
 ThreadLocalAllocBuffer
In-Reply-To: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
References: <A8jXJwX_YJDobvFww7aTCSVbsxTW2ltOxqBB9v1u4RI=.83dc33f0-9363-40fa-83ae-c9a4ce5feb00@github.com>
Message-ID: <FeJKq4QLFdLy3GuWZIeJCdW4tJaWBdy_QuoOo7FU8rk=.990baf26-a7a7-473b-a406-b9a1a0337cbd@github.com>

On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names.

This pull request has now been integrated.

Changeset: 03944168
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/039441689d21f3dccf515bb2be89608b0772a235
Stats:     45 lines in 4 files changed: 2 ins; 0 del; 43 mod

8267468: Rename refill waster counters in ThreadLocalAllocBuffer

Reviewed-by: kbarrett, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4146

From dholmes at openjdk.java.net  Wed May 26 07:56:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 26 May 2021 07:56:13 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4]
In-Reply-To: <O9teAMehggUiNNgTYGybK7Y7096B-qRUJy9GCCbUFhU=.4ab3e9e9-7a4f-437f-96f1-09125677e709@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <TU_1CODSKvFOzDmPEOShcp92o2pleQDQQXZFMfQ0j-Q=.0a220517-a6e1-4b10-871e-2c1ffeb58baf@github.com>
 <OZ5FPnyyi36m1M6vwvoHhLIyPaohJWRnLV8BQaoBleo=.552f9b74-912c-44a2-b229-d143ee857302@github.com>
 <O9teAMehggUiNNgTYGybK7Y7096B-qRUJy9GCCbUFhU=.4ab3e9e9-7a4f-437f-96f1-09125677e709@github.com>
Message-ID: <zblvBz4I_k_n6eghRSSvY3Y4RqM6QUS7BqqBiT3JYlA=.6cd16585-e5c4-4a8c-ba73-6fadce910632@github.com>

On Wed, 26 May 2021 06:35:29 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> doc/hotspot-style.md line 142:
>> 
>>> 140: 
>>> 141: * All .inline.hpp files should include their corresponding .hpp file
>>> 142: as the first include line. Externally used declarations should be put
>> 
>> Do we need to spell out it should be first unless precompiled.hpp is included?
>
> We should never include precompiled.hpp from an .inline.hpp file, so I don't think we need to state that.

Ah. Right. :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From sgehwolf at openjdk.java.net  Wed May 26 08:06:15 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 26 May 2021 08:06:15 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v4]
In-Reply-To: <p62JHQkSIWKMHcPNPxlsWLCxJUJUxW5AVUzYMnqAUxw=.f24d9da4-d750-4c56-97bc-ada07dd6ac6b@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com>
 <p62JHQkSIWKMHcPNPxlsWLCxJUJUxW5AVUzYMnqAUxw=.f24d9da4-d750-4c56-97bc-ada07dd6ac6b@github.com>
Message-ID: <8j5D125IbrWFmQ30WHFHau1e3Uv7fzMA7eOjywr5lxU=.aed0925b-5220-4300-b99e-d0c0c282a379@github.com>

On Tue, 25 May 2021 09:53:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Hao Tang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix compile errors on MacOS
>
> Bumping number of required reviewers to 2 as I'm a contributing author of the change.

> @jerboaa Thank you for the cpu-shares-based load calculation! I also update the cpu-quota-based load calculation to use the same strategy as the cpu-shares-based one, because my previous implementation always reports the average load since the container starts.

OK.

> Another change is to set the initial value of `usageTicks`/`totalTicks` to zero. Therefore, the first call of `getCpuLoad` can also report a reasonable result.

Seems reasonable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From sgehwolf at openjdk.java.net  Wed May 26 08:06:15 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 26 May 2021 08:06:15 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v6]
In-Reply-To: <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
Message-ID: <lIoYPd8ofI5PQFdUc1i4NKHxjlcv_B98Lk7AitTykeE=.c00c3e9f-a858-4c92-a340-229cfb9ddf05@github.com>

On Tue, 25 May 2021 21:46:27 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
>> 
>> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
>> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".
>
> Hao Tang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use historical-value-based formula for both cpu-quota-based and cpu-shares-based calculation
>  - rename usageTicks and totalTicks

Still good.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3656

From sgehwolf at redhat.com  Wed May 26 08:30:26 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 26 May 2021 10:30:26 +0200
Subject: OperatingSystemImpl should factor cpu shares when calculating
 system load
In-Reply-To: <5aba1620-d10c-6586-8c3d-673ac58f6c4c@oracle.com>
References: <CAOz0wjGW=4dOhs6M0-S8nkntbZ0AODue8X8xrDx2Weds0b+LXQ@mail.gmail.com>
 <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com>
 <CAOz0wjH9qbrXx1qHinJoE7aJFxPJR_Z3hN23rK+g3Lbyoo=Dow@mail.gmail.com>
 <6da4ac22-b109-6470-1145-a878cb6d235d@oracle.com>
 <5aba1620-d10c-6586-8c3d-673ac58f6c4c@oracle.com>
Message-ID: <7b47298b5c53ff94e52d781f90deee9b570dfe1d.camel@redhat.com>

On Mon, 2021-05-03 at 17:57 -0700, Laurence Cable wrote:
> 
> On 5/3/21 4:50 PM, David Holmes wrote:
> > On 4/05/2021 9:07 am, Argha C wrote:
> > > Hello David,
> > > It does look quite similar.
> > > The crux is factoring in the sum of cpu time across all?shares, 
> > > instead of a single cpu share.
> > > My proposal for implementing the fix is slightly different from
> > > the PR, but happy to trust your advice on taking this forward.
> > 
> > I would suggest liaising with the contributors of
> > 
> > https://github.com/openjdk/jdk/pull/3656
> > 
> > so see if all of the issues can be addressed together.
> 
> +1!

David, Larry:

https://github.com/openjdk/jdk/pull/3656

... is ready for integration. Could we get a second review, please? It
addresses wrong cpuLoad() calculation of cpu quota and cpu shares-based
cpu limits in containers.

Thoughts?

Thanks,
Severin


From david.holmes at oracle.com  Wed May 26 08:45:34 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 26 May 2021 18:45:34 +1000
Subject: OperatingSystemImpl should factor cpu shares when calculating
 system load
In-Reply-To: <7b47298b5c53ff94e52d781f90deee9b570dfe1d.camel@redhat.com>
References: <CAOz0wjGW=4dOhs6M0-S8nkntbZ0AODue8X8xrDx2Weds0b+LXQ@mail.gmail.com>
 <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com>
 <CAOz0wjH9qbrXx1qHinJoE7aJFxPJR_Z3hN23rK+g3Lbyoo=Dow@mail.gmail.com>
 <6da4ac22-b109-6470-1145-a878cb6d235d@oracle.com>
 <5aba1620-d10c-6586-8c3d-673ac58f6c4c@oracle.com>
 <7b47298b5c53ff94e52d781f90deee9b570dfe1d.camel@redhat.com>
Message-ID: <e6bfd975-64e9-c92b-779f-d15ac3153d65@oracle.com>

Hi Severin,

On 26/05/2021 6:30 pm, Severin Gehwolf wrote:
> On Mon, 2021-05-03 at 17:57 -0700, Laurence Cable wrote:
>>
>> On 5/3/21 4:50 PM, David Holmes wrote:
>>> On 4/05/2021 9:07 am, Argha C wrote:
>>>> Hello David,
>>>> It does look quite similar.
>>>> The crux is factoring in the sum of cpu time across all?shares,
>>>> instead of a single cpu share.
>>>> My proposal for implementing the fix is slightly different from
>>>> the PR, but happy to trust your advice on taking this forward.
>>>
>>> I would suggest liaising with the contributors of
>>>
>>> https://github.com/openjdk/jdk/pull/3656
>>>
>>> so see if all of the issues can be addressed together.
>>
>> +1!
> 
> David, Larry:
> 
> https://github.com/openjdk/jdk/pull/3656
> 
> ... is ready for integration. Could we get a second review, please? It
> addresses wrong cpuLoad() calculation of cpu quota and cpu shares-based
> cpu limits in containers.
> 
> Thoughts?

Sorry, although I connected the two bugs reports I'm not familiar enough 
with this area to review anything. I don't work with containers and 
don't understand their resource management strategies or how the VM 
should report them.

David
-----

> Thanks,
> Severin
> 

From akozlov at openjdk.java.net  Wed May 26 09:37:13 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 26 May 2021 09:37:13 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file
In-Reply-To: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
Message-ID: <Ktccd3weJ015z80-5inlYTEjvFXGFFVyxTYUkpjlXrA=.22348f7f-508a-4e9a-90ac-f47ec5ecb0a9@github.com>

On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
> 
> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
> 
> Reviews of the CSR linked to the bug would be appreciated as well.

AFAIK such enhancement was not discussed before. Please consider this review request also as a start of a discussion. The implementation is rather small, so I thought it was not worth a separate CFD in advance.

I added few details to the bug. The change does not depend on a particular operating system, but on Linux, for example, the new option allows sending the dump to the external LZ4 process. It provides a compressed dump of the heap 2x faster than it is possible now, at the speed comparable to writing uncompressed dump.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4183

From kbarrett at openjdk.java.net  Wed May 26 14:38:15 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 26 May 2021 14:38:15 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v5]
In-Reply-To: <c-OaKR1PFHIGfLRVAIG-RHC5EnozbxTHzTMq_5TRl_g=.140285a5-9230-4931-9679-8945670749d8@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <c-OaKR1PFHIGfLRVAIG-RHC5EnozbxTHzTMq_5TRl_g=.140285a5-9230-4931-9679-8945670749d8@github.com>
Message-ID: <GljqMekBQKJKTwU-8ELrwL-oKyRgC6y3S_vI62IlP1U=.8af96aac-9fbc-42ca-b091-78280473188b@github.com>

On Wed, 26 May 2021 06:38:47 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review dholmes

doc/hotspot-style.md line 142:

> 140: 
> 141: * All .inline.hpp files should include their corresponding .hpp file
> 142: as the first include line. Externally used declarations should be put

I think by "Externally used declarations" you mean "declarations needed by other headers"?  Maybe say it that way, or some other wording?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From dcubed at openjdk.java.net  Wed May 26 14:48:24 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 26 May 2021 14:48:24 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7]
In-Reply-To: <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
Message-ID: <yJKAWrCzbzqaN1HK9DtAsPKWsBUMtvIVDsESr_g2PFo=.65c2805e-084b-4c22-afa7-025d44d36333@github.com>

On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Final fixes: last famous words
>  - Review fixes 2
>  - Merge branch 'master' into 8265753
>  - Review fixes
>  - Merge branch 'master' into 8265753
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Removed manual transitions

Thumbs up.

Reviewed the incremental between v05 -> v06. Looks good.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3875

From pchilanomate at openjdk.java.net  Wed May 26 15:21:22 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 26 May 2021 15:21:22 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <mBOAhpOonAVk-a2VuEkm9KgcSArh9uDxDwmepNvqERI=.f99faad9-ccc5-4977-8533-e64754dc0d84@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
 <mBOAhpOonAVk-a2VuEkm9KgcSArh9uDxDwmepNvqERI=.f99faad9-ccc5-4977-8533-e64754dc0d84@github.com>
Message-ID: <QNviEgghLvHBMQS9TGgiA91NzwaGgD-MMkacLt2kNUs=.cf2ede16-027f-461d-a1c5-de13c4fd92c9@github.com>

On Mon, 17 May 2021 07:43:06 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 277:
>> 
>>> 275: class ThreadBlockInVM {
>>> 276:   InFlightMutexRelease _ifmr;
>>> 277:   ThreadBlockInVMPreprocess<InFlightMutexRelease> _tbivmpp;
>> 
>> Why delegate to the TBIVMPP instead of extending it?
>
> I need to run the InFlightMutexRelease constructor before I can run the ThreadBlockInVMPreprocess constructor.

Just for consistency, shouldn't we just use ThreadBlockInVMPreprocess in mutex.cpp as we are using it in objectMonitor.cpp?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From coleenp at openjdk.java.net  Wed May 26 17:15:14 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 26 May 2021 17:15:14 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048
In-Reply-To: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
Message-ID: <h_kb477-bO0tB2eftLaL63bzxFpsG2DmQ2e4t902qtY=.9be30237-e896-499d-84e9-1d10d8f3c488@github.com>

On Fri, 21 May 2021 19:20:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
> 
> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
> 
> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
> 
> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
> 
> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
> 
>   // Copy the "source file name" attribute from new class version
>   the_class->set_source_file_name_index(
>     scratch_class->source_file_name_index());
> 
> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?

I'm sorry for the delay and for introducing the bug.  I'm hopefully back in the frame of mind I was in when making the change.  See if what I said makes sense.

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1861:

> 1859:   // Save fields from the old_cp.
> 1860:   merge_cp->copy_fields(old_cp(), true /* skip_version */);
> 1861:   scratch_cp->copy_fields(old_cp(), true /* skip_version */);

Rather than calling copy_fields, maybe this should revert this:
-  if (old_cp->has_dynamic_constant()) {
-    merge_cp->set_has_dynamic_constant();
-    scratch_cp->set_has_dynamic_constant();
-  }

And then the merge_cp->copy_fields(scratch_cp); ?

The merged_cp should look like the scratch_cp (with version number and generic signature, etc) until after verification and then I guess it should look like the old_cp at the end in redefine_single_class().

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4412:

> 4410:   the_class->constants()->set_major_version(scratch_class->constants()->major_version());
> 4411:   scratch_class->constants()->set_major_version(old_major_version);
> 4412: 

This looks correct. copy_fields doesn't swap the versions, and I think that's what we want to do.
The source_name_index should match the scratch_class which is above, and the generic_signature_index is checked that it matches, and the one in the scratch constant pool should be adjusted to match the merged constant pool.  So I think that's ok.

test/hotspot/jtreg/runtime/ConstantPool/ClassVersion/ClassVersionAfterRedefine.java line 1:

> 1: /*

Can you put this test in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses directory?
All the tests do redefinition differently.  There is a library RedefineClassHelper that you might be able to use and not have to deal with starting the agent.

@ compile TestClassXXX.jasm   // this is the old one
then in the test read all of TestClassNew.jasm bytecodes, and s/New/XXX/ and use
RedefineClassHelper.redefine(TestClassXXX.class, newBytes);

See RedefineRunningMethods.java in that directory for an example.

-------------

Changes requested by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4149

From stefank at openjdk.java.net  Wed May 26 18:00:54 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 26 May 2021 18:00:54 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v6]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review kbarrett

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4127/files
  - new: https://git.openjdk.java.net/jdk/pull/4127/files/0cf6257d..340bcf49

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=04-05

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From sgehwolf at openjdk.java.net  Wed May 26 18:03:16 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 26 May 2021 18:03:16 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v6]
In-Reply-To: <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
Message-ID: <1cIXMnCe0NR1K4A3AXD9NhV7SpirI6caIXLt3LSJXNk=.0a5ffbf8-c159-4db1-923f-cc9314e5bfa9@github.com>

On Tue, 25 May 2021 21:46:27 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
>> 
>> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
>> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".
>
> Hao Tang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use historical-value-based formula for both cpu-quota-based and cpu-shares-based calculation
>  - rename usageTicks and totalTicks

Any other reviewers, please? @YaSuenag perhaps?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From rehn at openjdk.java.net  Wed May 26 18:35:33 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 26 May 2021 18:35:33 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <QNviEgghLvHBMQS9TGgiA91NzwaGgD-MMkacLt2kNUs=.cf2ede16-027f-461d-a1c5-de13c4fd92c9@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
 <mBOAhpOonAVk-a2VuEkm9KgcSArh9uDxDwmepNvqERI=.f99faad9-ccc5-4977-8533-e64754dc0d84@github.com>
 <QNviEgghLvHBMQS9TGgiA91NzwaGgD-MMkacLt2kNUs=.cf2ede16-027f-461d-a1c5-de13c4fd92c9@github.com>
Message-ID: <CDbRtn2ezl8EadyQ8JuU3fjVFaH9V6ORFqdkaHEallU=.e344762f-cda3-40be-9859-d178e49c4984@github.com>

On Wed, 26 May 2021 15:18:43 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I need to run the InFlightMutexRelease constructor before I can run the ThreadBlockInVMPreprocess constructor.
>
> Just for consistency, shouldn't we just use ThreadBlockInVMPreprocess in mutex.cpp as we are using it in objectMonitor.cpp?

You mean revert your change of having the monitor as a parameter to ThreadBlockInVM?
And instead just place InFlightMutexRelease in mutex and directly use ThreadBlockInVMPreprocess as OM?
I don't mind mind either way, but I feel changing two of three locking implementation is enough in one change-set :)
So I can open an RFE if you want?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From pchilanomate at openjdk.java.net  Wed May 26 18:50:51 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 26 May 2021 18:50:51 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7]
In-Reply-To: <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
Message-ID: <JAXN_-Z2o_frsS6uQ4XuAsVsrQWIjieZEbMooPRP42k=.fc500c77-fbb8-4225-9296-2f720ecc9f78@github.com>

On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider this change which removes the manual transitions to blocked.
>> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
>> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
>> 
>> The object monitor code could be straight forward changed to use this instead of manual transitions.
>> 
>> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
>> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
>> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
>> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
>> That made it possible to careful use ThreadInVMfromNative in raw monitors.
>> 
>> I also remove the early CAS in raw_enter.
>> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
>> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
>> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
>> 
>> Passes t1-t7 and manual stressing relevant test groups.
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Final fixes: last famous words
>  - Review fixes 2
>  - Merge branch 'master' into 8265753
>  - Review fixes
>  - Merge branch 'master' into 8265753
>  - Fixes for Dan
>  - Merge branch 'master' into 8265753
>  - Removed manual transitions

Marked as reviewed by pchilanomate (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From pchilanomate at openjdk.java.net  Wed May 26 18:50:52 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 26 May 2021 18:50:52 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]
In-Reply-To: <CDbRtn2ezl8EadyQ8JuU3fjVFaH9V6ORFqdkaHEallU=.e344762f-cda3-40be-9859-d178e49c4984@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <uZYfFeWrkPUL6ZCgAnWfInDHpEu_-30nJCdT4M01YQ8=.5aa6d7a7-61b2-410f-9d62-9d9ed290298b@github.com>
 <ze7HuoXFjNvPK3Hq6RBS0k3bnAJl3zYMGnYFWGqyvHE=.d79ba0c4-65ab-4e56-bc4d-f44568e2a407@github.com>
 <mBOAhpOonAVk-a2VuEkm9KgcSArh9uDxDwmepNvqERI=.f99faad9-ccc5-4977-8533-e64754dc0d84@github.com>
 <QNviEgghLvHBMQS9TGgiA91NzwaGgD-MMkacLt2kNUs=.cf2ede16-027f-461d-a1c5-de13c4fd92c9@github.com>
 <CDbRtn2ezl8EadyQ8JuU3fjVFaH9V6ORFqdkaHEallU=.e344762f-cda3-40be-9859-d178e49c4984@github.com>
Message-ID: <2EZdZ8P_QGnZuMmQtUdXmT2LhfY2p043OvLIARFjpb0=.0f89ec87-668d-46e0-bda0-cce14ddb2a37@github.com>

On Wed, 26 May 2021 18:30:16 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Just for consistency, shouldn't we just use ThreadBlockInVMPreprocess in mutex.cpp as we are using it in objectMonitor.cpp?
>
> You mean revert your change of having the monitor as a parameter to ThreadBlockInVM?
> And instead just place InFlightMutexRelease in mutex and directly use ThreadBlockInVMPreprocess as OM?
> I don't mind mind either way, but I feel changing two of three locking implementation is enough in one change-set :)
> So I can open an RFE if you want?

Right, so when we added the _in_flight_mutex_addr to TBIVM this was the only case where we would need to check a condition and execute some action, but now that we are doing it from objectMonitors and jvmtiRawMonitors too then it seems we should use it the same way here. Sure, we can do it in another RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From kbarrett at openjdk.java.net  Wed May 26 23:06:05 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 26 May 2021 23:06:05 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v6]
In-Reply-To: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com>
Message-ID: <OPTS0x5KcDzroluKpqAFeuFg0km3_z0BrJuEPgDSPyg=.e2006f2c-07e0-42fc-a685-79dea3d0f5ac@github.com>

On Wed, 26 May 2021 18:00:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review kbarrett

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4127

From ysuenaga at openjdk.java.net  Thu May 27 00:50:15 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 27 May 2021 00:50:15 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v6]
In-Reply-To: <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
Message-ID: <Y_AmHNdx5sri2qyn5wcsTRERvhfzVBpa7GLA_VIBeW4=.58458a23-b2f5-4eda-ad8b-43c96106bb01@github.com>

On Tue, 25 May 2021 21:46:27 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
>> 
>> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
>> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".
>
> Hao Tang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use historical-value-based formula for both cpu-quota-based and cpu-shares-based calculation
>  - rename usageTicks and totalTicks

I haven't followed yet all of discussions in this review, but I concern this PR changes the meaning of `getCpuLoad()`.

`getCpuLoad()` has been based on total time since the start of the container, but after this PR, it is based on the ticks in earlier call. Is it ok?  
IMHO it can be accepted because it is the same with load average on Linux, but I concern we may need CSR because this PR changes behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From ysuenaga at openjdk.java.net  Thu May 27 04:57:08 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 27 May 2021 04:57:08 GMT
Subject: Integrated: 8263635: Add --servername option to jhsdb debugd
In-Reply-To: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
References: <r0KX5ZoIRTrbxZ5YuKxlVisQcAd2hlxZ9h6DMOZSSTM=.135cb9fe-adf9-4a8b-801b-e154e031aeca@github.com>
Message-ID: <heSmH0ffM_oEYVQmskGlzNbH_wDtmX-MW7oqYmdFBVI=.5f8f2268-1c42-4fda-b59d-40a3b97ed3b6@github.com>

On Sun, 25 Apr 2021 03:15:07 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default.
> 
> As a result, remote name will be constructed as following:
> 
> 
> //host[:port]/<serverNamePrefix>['_'<id>]
> 
> 
> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option.
> 
> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose.
> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`.
> 
> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it.
> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC.

This pull request has now been integrated.

Changeset: 37bc4e2e
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/37bc4e2e3c2968d7419dae4f421755b6f7d06090
Stats:     153 lines in 12 files changed: 49 ins; 10 del; 94 mod

8263635: Add --servername option to jhsdb debugd

Reviewed-by: cjplummer, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/3669

From ysuenaga at openjdk.java.net  Thu May 27 05:03:04 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 27 May 2021 05:03:04 GMT
Subject: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965
In-Reply-To: <SEstazl5HPdp9XNAaPGKtXNhdhq4eGocYHFpS7GHuZA=.926a304e-f0b9-43c7-b05c-01b0dd944bcf@github.com>
References: <SEstazl5HPdp9XNAaPGKtXNhdhq4eGocYHFpS7GHuZA=.926a304e-f0b9-43c7-b05c-01b0dd944bcf@github.com>
Message-ID: <0Se6sGcQIcQluyLcvnGv8A3a_6SBRCkUOskxbqdBSfU=.5a11da9b-94ae-4e26-af77-505722bdbd71@github.com>

On Mon, 17 May 2021 12:07:13 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Following jtreg tests for SA would fail because SA has not followed [JDK-8220587](https://bugs.openjdk.java.net/browse/JDK-8220587) and [JDK-8224965](https://bugs.openjdk.java.net/browse/JDK-8224965).
> 
> * serviceability/sa/ClhsdbDumpheap.java
> * serviceability/sa/ClhsdbFindPC.java
> * serviceability/sa/ClhsdbInspect.java
> * serviceability/sa/ClhsdbSymbol.java
> * serviceability/sa/TestHeapDumpForInvokeDynamic.java
> * serviceability/sa/TestJmapCore.java
> * serviceability/sa/TestJmapCoreMetaspace.java
> 
> They need to handle relocated objects and/or live regions (pages). SA should handle them.
> 
> This change passes serviceability/sa jtreg tests on Linux x64 with -vmoption:-XX:+UseZGC, but I want to know this change works fine on testbed for ZGC in Oracle. Could you help?

Ping: could you review this change?
I know this is too big to review, so it is also welcome to comment to divide this PR.

This PR would fix [JDK-8267045](https://bugs.openjdk.java.net/browse/JDK-8267045) which is marked as P3. If we can mark P3 to this PR, we can get more time to review.
I think SA should support ZGC as possible in next major release.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4057

From stefank at openjdk.java.net  Thu May 27 07:15:06 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 27 May 2021 07:15:06 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v6]
In-Reply-To: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com>
Message-ID: <vppezzVF1Dqm4_tYrVa-8ssZ5RFULMteG0dQIRoRhJ8=.cd8da840-13a6-436e-b1c6-07ffbe9eaff7@github.com>

On Wed, 26 May 2021 18:00:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review kbarrett

@vnkozlov Can we considered the proposed changes to HotSpot Coding Style sufficiently reviewed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From github.com+7947546+tanghaoth90 at openjdk.java.net  Thu May 27 08:40:12 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Thu, 27 May 2021 08:40:12 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v6]
In-Reply-To: <Y_AmHNdx5sri2qyn5wcsTRERvhfzVBpa7GLA_VIBeW4=.58458a23-b2f5-4eda-ad8b-43c96106bb01@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
 <Y_AmHNdx5sri2qyn5wcsTRERvhfzVBpa7GLA_VIBeW4=.58458a23-b2f5-4eda-ad8b-43c96106bb01@github.com>
Message-ID: <HBeSpGw939dXYib_gr7NsSneZ4-2B2NxpWnPONBJkdA=.09800744-7a99-4592-ae55-91062453ce32@github.com>

On Thu, 27 May 2021 00:47:23 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `getCpuLoad()` has been based on total time since the start of the container, but after this PR, it is based on the ticks in earlier call. Is it ok?
> IMHO it can be accepted because it is the same with load average on Linux, but I concern we may need CSR because this PR changes behavior.

@YaSuenag Thanks for your comment. I can give two reasons for that.
1. The javadoc of `OperatingSystemMXBean.getCpuLoad` indicates the method should return "recent cpu usage".
https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java#L156
2. The initial (container-unaware) implementation `getCpuLoad0` does reports recent CPU load, which the container-aware implementation must be consistent.

> but after this PR, it is based on the ticks in earlier call. Is it ok?

The result might be too coarse/inaccurate, if the time between two calls is too long/short. Any comments for that?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From sgehwolf at openjdk.java.net  Thu May 27 08:56:07 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 27 May 2021 08:56:07 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v6]
In-Reply-To: <Y_AmHNdx5sri2qyn5wcsTRERvhfzVBpa7GLA_VIBeW4=.58458a23-b2f5-4eda-ad8b-43c96106bb01@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
 <Y_AmHNdx5sri2qyn5wcsTRERvhfzVBpa7GLA_VIBeW4=.58458a23-b2f5-4eda-ad8b-43c96106bb01@github.com>
Message-ID: <7IXKfZfx7S4zHKfhgZRKoneDcqI1FQQm7-7Qgs68ACc=.fb51e01a-0310-4fe8-adc9-09db5a3d886a@github.com>

On Thu, 27 May 2021 00:47:23 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I haven't followed yet all of discussions in this review, but I concern this PR changes the meaning of `getCpuLoad()`.

Does it? Here is the javadoc:
https://docs.oracle.com/en/java/javase/16/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html#getCpuLoad()

It says:

Returns the "recent cpu usage" for the operating environment. This value is a double in the [0.0,1.0] interval.


If I run outside a container, getCpuLoad0() is being used which uses a similar calculation. So in my book this fixes the bug (earlier reporting is just plain wrong, see bug for details) and just brings it in line with the non-container values.

Also note that the cpu quota-based limits implementation as been changed to also report recent load values. But I'm not sure it's worth discussing this further as the previous implementation (supposedly reporting an average) was wrong.

> `getCpuLoad()` has been based on total time since the start of the container, but after this PR, it is based on the ticks in earlier call. Is it ok?

IMHO, yes as the previous implementation was incorrect. I suspect nobody noticed until now.

> IMHO it can be accepted because it is the same with load average on Linux, but I concern we may need CSR because this PR changes behavior.

I disagree. This change makes `getCpuLoad()` behave similar in all cases: non-container case[1], cpu affinity-based[2], cpu-quota-based[3] and cpu-shares based[3] cpu-limits. That wasn't previously the case.

[1] https://bugs.openjdk.java.net/browse/JDK-8265836?focusedCommentId=14423632&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14423632
[2] https://bugs.openjdk.java.net/browse/JDK-8265836?focusedCommentId=14423633&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14423633
[3] https://bugs.openjdk.java.net/browse/JDK-8265836?focusedCommentId=14423371&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14423371

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From ysuenaga at openjdk.java.net  Thu May 27 09:22:09 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 27 May 2021 09:22:09 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v6]
In-Reply-To: <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
Message-ID: <mWLb_Jgc_90DI9ibTRkl5h0ky-NSCzqxc2vgi82pd9U=.6bf2d5a9-30f7-43a6-a14f-cf880deb0372@github.com>

On Tue, 25 May 2021 21:46:27 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
>> 
>> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
>> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".
>
> Hao Tang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use historical-value-based formula for both cpu-quota-based and cpu-shares-based calculation
>  - rename usageTicks and totalTicks

@tanghaoth90 @jerboaa Thank you for explanation!

> The result might be too coarse/inaccurate, if the time between two calls is too long/short. Any comments for that?

I concerned about that too. Javadoc says "recent cpu usage" about this - it is ambiguous. In other words, our concerns are tolerated IMHO.
Of course it is better if we can get sampling value, but it is difficult now. Maybe we can implement sampling thread, but we need to think some things (e.g. sampling frequency). I'm not sure it is worth to work for it.

I think it is important that `getCpuLoad()` behaves similar in all cases, and also I can't see any problems in your change. So I give +1 to your change ??

-------------

Marked as reviewed by ysuenaga (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3656

From sgehwolf at openjdk.java.net  Thu May 27 09:37:08 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 27 May 2021 09:37:08 GMT
Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect
 CPU load inside a container [v6]
In-Reply-To: <HBeSpGw939dXYib_gr7NsSneZ4-2B2NxpWnPONBJkdA=.09800744-7a99-4592-ae55-91062453ce32@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
 <kM9b3ZcIl8iMoT1v65uJb6AyYXOVDCYWDEIkvS2XLc0=.26b2be24-0a53-4b91-8ed8-99a7332faa6a@github.com>
 <Y_AmHNdx5sri2qyn5wcsTRERvhfzVBpa7GLA_VIBeW4=.58458a23-b2f5-4eda-ad8b-43c96106bb01@github.com>
 <HBeSpGw939dXYib_gr7NsSneZ4-2B2NxpWnPONBJkdA=.09800744-7a99-4592-ae55-91062453ce32@github.com>
Message-ID: <zfR5kizw1LFA7Do_-2Xf-PmZTHXd2-4gy3mpV2tiECY=.639df7ef-9f40-4f51-a2de-3caa0beee136@github.com>

On Thu, 27 May 2021 08:37:11 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> I haven't followed yet all of discussions in this review, but I concern this PR changes the meaning of `getCpuLoad()`.
>> 
>> `getCpuLoad()` has been based on total time since the start of the container, but after this PR, it is based on the ticks in earlier call. Is it ok?  
>> IMHO it can be accepted because it is the same with load average on Linux, but I concern we may need CSR because this PR changes behavior.
>
>> `getCpuLoad()` has been based on total time since the start of the container, but after this PR, it is based on the ticks in earlier call. Is it ok?
>> IMHO it can be accepted because it is the same with load average on Linux, but I concern we may need CSR because this PR changes behavior.
> 
> @YaSuenag Thanks for your comment. I can give two reasons for that.
> 1. The javadoc of `OperatingSystemMXBean.getCpuLoad` indicates the method should return "recent cpu usage".
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java#L156
> 2. The initial (container-unaware) implementation `getCpuLoad0` does reports recent CPU load, which the container-aware implementation must be consistent.
> 
>> but after this PR, it is based on the ticks in earlier call. Is it ok?
> 
> The result might be too coarse/inaccurate, if the time between two calls is too long/short. Any comments for that?

> @tanghaoth90 @jerboaa Thank you for explanation!

Thanks very much for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From simonis at openjdk.java.net  Thu May 27 10:26:46 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 27 May 2021 10:26:46 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048 [v2]
In-Reply-To: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
Message-ID: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>

> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
> 
> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
> 
> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
> 
> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
> 
> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
> 
>   // Copy the "source file name" attribute from new class version
>   the_class->set_source_file_name_index(
>     scratch_class->source_file_name_index());
> 
> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  8267555: Fix class file version during redefinition after 8238048

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4149/files
  - new: https://git.openjdk.java.net/jdk/pull/4149/files/25f07246..45d6d006

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4149&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4149&range=00-01

  Stats: 262 lines in 7 files changed: 102 ins; 150 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4149/head:pull/4149

PR: https://git.openjdk.java.net/jdk/pull/4149

From simonis at openjdk.java.net  Thu May 27 10:26:48 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 27 May 2021 10:26:48 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048
In-Reply-To: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
Message-ID: <xQrlnSWUpwVA6Hr0tIfyhCXWOC6LFVKb1AImBzPF9Qk=.94f5dd5c-2945-49ba-8c10-c1cf18de4bfb@github.com>

On Fri, 21 May 2021 19:20:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
> 
> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
> 
> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
> 
> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
> 
> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
> 
>   // Copy the "source file name" attribute from new class version
>   the_class->set_source_file_name_index(
>     scratch_class->source_file_name_index());
> 
> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?

Hi Coleen,

thanks for reviewing my change. I've updated the code as suggested and moved the test to the new location. Thanks for pointing me to `RedefineClassHelper`. That considerably simplifies the test. Please let me know what you think?

Best regards,
Volker

-------------

PR: https://git.openjdk.java.net/jdk/pull/4149

From simonis at openjdk.java.net  Thu May 27 10:26:52 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 27 May 2021 10:26:52 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048 [v2]
In-Reply-To: <h_kb477-bO0tB2eftLaL63bzxFpsG2DmQ2e4t902qtY=.9be30237-e896-499d-84e9-1d10d8f3c488@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
 <h_kb477-bO0tB2eftLaL63bzxFpsG2DmQ2e4t902qtY=.9be30237-e896-499d-84e9-1d10d8f3c488@github.com>
Message-ID: <AIveVwiegIWGcw0OxQAxbk1-KGtlYLJiI5ttLo50Z9E=.2f973dea-cc27-4248-83cb-94ae9f781a3d@github.com>

On Wed, 26 May 2021 16:42:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267555: Fix class file version during redefinition after 8238048
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1861:
> 
>> 1859:   // Save fields from the old_cp.
>> 1860:   merge_cp->copy_fields(old_cp(), true /* skip_version */);
>> 1861:   scratch_cp->copy_fields(old_cp(), true /* skip_version */);
> 
> Rather than calling copy_fields, maybe this should revert this:
> -  if (old_cp->has_dynamic_constant()) {
> -    merge_cp->set_has_dynamic_constant();
> -    scratch_cp->set_has_dynamic_constant();
> -  }
> 
> And then the merge_cp->copy_fields(scratch_cp); ?
> 
> The merged_cp should look like the scratch_cp (with version number and generic signature, etc) until after verification and then I guess it should look like the old_cp at the end in redefine_single_class().

Yes, that works as well. Updated as suggested.

> test/hotspot/jtreg/runtime/ConstantPool/ClassVersion/ClassVersionAfterRedefine.java line 1:
> 
>> 1: /*
> 
> Can you put this test in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses directory?
> All the tests do redefinition differently.  There is a library RedefineClassHelper that you might be able to use and not have to deal with starting the agent.
> 
> @ compile TestClassXXX.jasm   // this is the old one
> then in the test read all of TestClassNew.jasm bytecodes, and s/New/XXX/ and use
> RedefineClassHelper.redefine(TestClassXXX.class, newBytes);
> 
> See RedefineRunningMethods.java in that directory for an example.

Moved the test to `test/hotspot/jtreg/serviceability/jvmti/RedefineClasses` and use `RedefineClassHelper` as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4149

From coleenp at openjdk.java.net  Thu May 27 13:21:08 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 27 May 2021 13:21:08 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048 [v2]
In-Reply-To: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
 <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>
Message-ID: <aYkfujXbeY308xJ_b5u_Dj-sYsXOmjF666oWw1Z4Yj8=.f8aeb31c-a73a-4170-a451-797826b31c89@github.com>

On Thu, 27 May 2021 10:26:46 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
>> 
>> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
>> 
>> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
>> 
>> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
>> 
>> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
>> 
>>   // Copy the "source file name" attribute from new class version
>>   the_class->set_source_file_name_index(
>>     scratch_class->source_file_name_index());
>> 
>> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267555: Fix class file version during redefinition after 8238048

Yes, this looks good.  Isn't RedefineClassHelper great?  Thanks!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4149

From lzang at openjdk.java.net  Thu May 27 14:00:03 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 27 May 2021 14:00:03 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file
In-Reply-To: <Ktccd3weJ015z80-5inlYTEjvFXGFFVyxTYUkpjlXrA=.22348f7f-508a-4e9a-90ac-f47ec5ecb0a9@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <Ktccd3weJ015z80-5inlYTEjvFXGFFVyxTYUkpjlXrA=.22348f7f-508a-4e9a-90ac-f47ec5ecb0a9@github.com>
Message-ID: <9mOfQ5-mxg39XJd4oaRdes-0Ci9C62DiHxjLlK5ohUo=.0ecf4b35-0090-4272-a8b1-1bd1cae3bf98@github.com>

On Wed, 26 May 2021 09:34:06 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> AFAIK such enhancement was not discussed before. Please consider this review request also as a start of a discussion. The implementation is rather small, so I thought it was not worth a separate CFD in advance.
> 
> I added few details to the bug. The change does not depend on a particular operating system, but on Linux, for example, the new option allows sending the dump to the external LZ4 process. It provides a compressed dump of the heap 2x faster than it is possible now, at the speed comparable to writing uncompressed dump.
> 
> Thanks!

Hi @AntonKozlov, 
I am not a reviewer, just a tiny hint that you may need to add test cases. 
Thanks,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/4183

From lzang at openjdk.java.net  Thu May 27 14:04:07 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 27 May 2021 14:04:07 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file
In-Reply-To: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
Message-ID: <_Q4Udr3OeDaLPcDEuGfcUXCW1WNx_tCQCO3u3iMWPIU=.0cd90173-a8b5-43ef-b11f-6a6cc1d52517@github.com>

On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
> 
> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
> 
> Reviews of the CSR linked to the bug would be appreciated as well.

Moreover, it seems the /csr label is required

-------------

PR: https://git.openjdk.java.net/jdk/pull/4183

From github.com+7947546+tanghaoth90 at openjdk.java.net  Thu May 27 14:44:13 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Thu, 27 May 2021 14:44:13 GMT
Subject: Integrated: 8265836: OperatingSystemImpl.getCpuLoad() returns
 incorrect CPU load inside a container
In-Reply-To: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
References: <mQbmUMkMnJcBO4c8IiW1GCxVcLSLDq_2jpdwy1aep9E=.e49c5e59-5939-48b8-9b21-e613900d1fb8@github.com>
Message-ID: <HMBZo77z6vk1bHB9lobfLAzL1y11_lpXbmH7UOCIyVs=.372f0169-b1e8-4252-a290-3f40d95f58a4@github.com>

On Fri, 23 Apr 2021 13:33:42 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%.
> 
> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct).
> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos".

This pull request has now been integrated.

Changeset: ef368b32
Author:    Hao Tang <albert.th at alibaba-inc.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ef368b32bc8609bdc46cda628fa25e9bcad751e3
Stats:     90 lines in 4 files changed: 78 ins; 2 del; 10 mod

8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container

Co-authored-by: Shaojun Wang <jeffery.wsj at alibaba-inc.com>
Co-authored-by: Severin Gehwolf <sgehwolf at openjdk.org>
Reviewed-by: sgehwolf, ysuenaga

-------------

PR: https://git.openjdk.java.net/jdk/pull/3656

From mdoerr at openjdk.java.net  Thu May 27 15:53:05 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 27 May 2021 15:53:05 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor
In-Reply-To: <lEVd8GWCnkTYebMPw1gfVJpqtg_HbTLhUjCfXlClfw8=.c7a834dc-54f1-4887-9286-6a87232dad96@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <lEVd8GWCnkTYebMPw1gfVJpqtg_HbTLhUjCfXlClfw8=.c7a834dc-54f1-4887-9286-6a87232dad96@github.com>
Message-ID: <MDX1m3zKLWNk3fYxJTPHWFR2Ejih_2o2GRqkmOCsXb0=.6c251eb0-4739-45e4-b540-43f77fcb201f@github.com>

On Thu, 27 May 2021 15:19:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I wonder if this should be changed to perform the read once by using Atomic::load? That's the guidance we've given the last few years. Some background for this: JDK-8234192.

Hi Stefan, thanks for looking at it and thanks for the pointer. I do remember that Atomic::load should be preferred. But I would have to use it in thread.hpp and I don't know if I should change it in current_waiting_monitor() and current_pending_monitor(). Would it be acceptable to change the general code for this special usage? I'm not against doing it, I just want to double-check. It may improve reliability in general.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From dcubed at openjdk.java.net  Thu May 27 16:47:07 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 27 May 2021 16:47:07 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor
In-Reply-To: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
Message-ID: <HQarhXBal0LBeH8IXfpUOBALyUKQJ9Qm5UP4osvBdfI=.3c4d37a8-7f6c-4fb9-b383-7bffd0c15b4e@github.com>

On Thu, 27 May 2021 09:56:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.

Thumbs up.

The code that you're fixing is indeed a special case and I wrote the new test
(serviceability/monitoring/ThreadInfo/GetLockOwnerName/GetLockOwnerName.java)
specifically to stress the crashing code path. Unfortunately, I have never seen the
new test fail in our test in Mach5 or in my testing in my lab. We did get a single closed
test failure back on 2021.03.20 which is what started me down the path of creating
the new test. That single failure has never reproduced in the original closed test nor
in the targeted test that I wrote (GetLockOwnerName.java).

The similar usage in JVM/TI is safe for exactly the reasons explained in the comment so a
general Atomic::load() solution in current_waiting_monitor() or current_pending_monitor()
is not necessary.

I think your solution of adding `volatile` to `wait_obj` and `enter_obj` is a good solution.
I would like to see a comment added to explain the need for the `volatile`. I'll add an
embedded comment in the other PR view.

Using either `wait_obj` or `enter_obj` after it has been cleared from the JavaThread is
safe. The ObjectMonitor can only have gone through the first stage of async deflation.
The ObjectMonitor's memory cannot be freed until after a handshake with all threads
is completed and that cannot happen while this thread is executing the code that is
using `wait_obj` or `enter_obj`.

src/hotspot/share/services/threadService.cpp line 232:

> 230:   // ObjectMonitor by the time this object reference is processed
> 231:   // by the caller.
> 232:   ObjectMonitor* volatile wait_obj = thread->current_waiting_monitor();

Please add a comment above this declaration. Something like:


// Using 'volatile' to prevent the compiler from generating code that
// reloads 'wait_obj' from memory when used below.

src/hotspot/share/services/threadService.cpp line 239:

> 237:     obj = wait_obj->object();
> 238:   } else {
> 239:     ObjectMonitor* volatile enter_obj = thread->current_pending_monitor();

Please add a comment above this declaration. Something like:


// Using 'volatile' to prevent the compiler from generating code that
// reloads 'enter_obj' from memory when used below.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4224

From mdoerr at openjdk.java.net  Thu May 27 16:56:25 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 27 May 2021 16:56:25 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2]
In-Reply-To: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
Message-ID: <l0XAMumKuxOuvIxhwAv_xhnvL2iB2X7kLQFqp_O9U8c=.503d7c8d-caa0-443c-8a7b-cf9058f961e2@github.com>

> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Add comments as suggested by Dan.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4224/files
  - new: https://git.openjdk.java.net/jdk/pull/4224/files/6e444fab..97a7df60

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=00-01

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4224.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224

PR: https://git.openjdk.java.net/jdk/pull/4224

From mdoerr at openjdk.java.net  Thu May 27 17:01:12 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 27 May 2021 17:01:12 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2]
In-Reply-To: <l0XAMumKuxOuvIxhwAv_xhnvL2iB2X7kLQFqp_O9U8c=.503d7c8d-caa0-443c-8a7b-cf9058f961e2@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <l0XAMumKuxOuvIxhwAv_xhnvL2iB2X7kLQFqp_O9U8c=.503d7c8d-caa0-443c-8a7b-cf9058f961e2@github.com>
Message-ID: <DIsbbgnPIX53W-1OQRYrYGMoe-x0rLPsjV3WePdWYxk=.42a0a330-4b4a-4ef2-a828-9744a74bdaeb@github.com>

On Thu, 27 May 2021 16:56:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments as suggested by Dan.

Thanks for the review! Comment added. We have only seen the crash on s390. It depends on the platform if the compiler tends to reload values more or less.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From prr at openjdk.java.net  Thu May 27 17:15:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:15:06 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>
Message-ID: <PVcp8pf1_KCxa_lAv-EYuhfoJ2XJ98AJmKrXQ6a_KEw=.4ce5565b-665e-4b2a-a240-3cfc6ef9e28d@github.com>

On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep only one systemProperty tag

Marked as reviewed by prr (Reviewer).

I'm OK with this now given that the refactoring is already underway at https://github.com/openjdk/jdk/pull/4138

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Thu May 27 17:46:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:46:07 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
Message-ID: <VHXPRMEIZVe_UgnmbjO2S9neB2ZjBWNCtEoB6VQmEoQ=.28f343f9-888e-4819-b27a-f08b02b978e8@github.com>

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

src/java.desktop/share/classes/java/awt/Component.java line 630:

> 628:         }
> 629: 
> 630:         @SuppressWarnings("removal")

I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
that was needed because of the usage in this static block and you could not apply the annotation here.
Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
Can you explain ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Thu May 27 20:16:25 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 27 May 2021 20:16:25 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04
  Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From lmesnik at openjdk.java.net  Thu May 27 20:20:22 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 27 May 2021 20:20:22 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace
Message-ID: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>

8265148: StackWatermarkSet being updated during AsyncGetCallTrace

-------------

Commit messages:
 - space removed.
 - 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

Changes: https://git.openjdk.java.net/jdk/pull/4217/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4217&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265148
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4217.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4217/head:pull/4217

PR: https://git.openjdk.java.net/jdk/pull/4217

From lmesnik at openjdk.java.net  Thu May 27 20:20:22 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 27 May 2021 20:20:22 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
Message-ID: <Fbhme2KVcKdDfmGd8tFycrlsq6HApTtEpLpcjV1evnE=.055ab6ed-735f-49b7-a4b0-bad0777d6c0d@github.com>

On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

I verified that running sunflow with async-profiler crashed VM before the fix and finished successfully after the fix. I compared data for G1GC for older JDK before https://bugs.openjdk.java.net/browse/JDK-8253180 is implemented. The results look pretty similar.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4217

From sspitsyn at openjdk.java.net  Thu May 27 21:31:05 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 27 May 2021 21:31:05 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048 [v2]
In-Reply-To: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
 <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>
Message-ID: <uQPa1I7oV3HTmMKrp7cLtnBoP0KAKShXTVtcwKTuy8U=.badb9edc-26f9-4794-94e3-a8ade4d4f170@github.com>

On Thu, 27 May 2021 10:26:46 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
>> 
>> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
>> 
>> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
>> 
>> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
>> 
>> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
>> 
>>   // Copy the "source file name" attribute from new class version
>>   the_class->set_source_file_name_index(
>>     scratch_class->source_file_name_index());
>> 
>> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267555: Fix class file version during redefinition after 8238048

Hi Volker,
The fix looks okay to me.
Thank you for fixing it!
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4149

From amenkov at openjdk.java.net  Thu May 27 23:09:24 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 27 May 2021 23:09:24 GMT
Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java fails
 with connection refused error.
Message-ID: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>

nsk test framework for testing jdi/jdwp assumes that the test launch debuggee first and then creates IOPipe to communicate with debuggee (debugger listens, debugee connects to the IOPipe socket).
This makes possible failure when debuggee tries to connect before debugger starts listening.
The fix changes logic of the tests to start listening on IOPipe socket before launch debuggee.
Other tests which use IOPipe/SocketIOPipe and have the same issue (there are a lot of them) will be fixes as separate issues.

Couple details about the fix:
- debugee.getPipeServerSocket() just calls binder.getPipeServerSocket(), returned ServerSocket can be changed only by DebugeeBinder.prepareForPipeConnection which is called by some tests;
- connectingProcess logic is broken. The only place it's used is BasicSocketConnection.checkConnectingProcess, which is called from SocketConnection.continueAttach. But continueAttach is called from debuggee code (listening == false) while connectingProcess is set only from debugger code (listening == true). So it didn't work and I dropped it.

Testing: all tests which use IOPipe/SocketIOPipe classes:
- test/hotspot/jtreg/serviceability/dcmd/framework
- test/hotspot/jtreg/vmTestbase/nsk/jdi
- test/hotspot/jtreg/vmTestbase/nsk/jdwp

-------------

Commit messages:
 - FIx for serviceability/dcmd/framework tests

Changes: https://git.openjdk.java.net/jdk/pull/4235/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4235&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8237388
  Stats: 143 lines in 5 files changed: 74 ins; 51 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4235.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4235/head:pull/4235

PR: https://git.openjdk.java.net/jdk/pull/4235

From dholmes at openjdk.java.net  Thu May 27 23:11:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 27 May 2021 23:11:06 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
Message-ID: <stwusYKU6iyfkN1VUgpp4imx06ckRQmTKSDLa7l1_yw=.a8cb978a-c4bf-4cc6-b647-706d7d370c98@github.com>

On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

Hi Leonid,

Someone familiar with Stackwatermarks will need to comment about the validity of doing this, my only comment is to document why it is being turned off.

Thanks,
David

src/hotspot/share/prims/forte.cpp line 326:

> 324:     int loop_count;
> 325:     int loop_max = MaxJavaStackTraceDepth * 2;
> 326:     RegisterMap map(thread, false, false);

Can we add some comments as to what the false parameters mean please.

RegisterMap map(thread, false /* no update */, false /*no stackwatermark frame processing */);

Though it may be that a more elaborate block comment is needed to explain why we don't want stackwatermark frame processing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4217

From weijun at openjdk.java.net  Fri May 28 02:01:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:01:19 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>
Message-ID: <hhtFKkkecHjmFc0a4jIaZsr7J9jfbBBCIl2z45lU8Rk=.f90b843b-b655-4106-83ee-dcfd9edfdee2@github.com>

On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Two files were removed by JEP 403 and JEP 407, respectively. One method in `XMLSchemaFactory.java` got [its own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429) `@SuppressWarnings` and have to be merged with the one here. Another file `ResourceBundle.java` had a portion of a method extracted into a [new method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175) and the annotation must be moved there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Fri May 28 02:54:05 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:54:05 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <VHXPRMEIZVe_UgnmbjO2S9neB2ZjBWNCtEoB6VQmEoQ=.28f343f9-888e-4819-b27a-f08b02b978e8@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
 <VHXPRMEIZVe_UgnmbjO2S9neB2ZjBWNCtEoB6VQmEoQ=.28f343f9-888e-4819-b27a-f08b02b978e8@github.com>
Message-ID: <U7wtFZQMD3K1ydYS7ve7Rgn3f0AQtDQBpta3S1pvpnI=.c48de5eb-d250-4a92-92e9-a3158ce7837c@github.com>

On Thu, 27 May 2021 17:42:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update FtpClient.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 630:
> 
>> 628:         }
>> 629: 
>> 630:         @SuppressWarnings("removal")
> 
> I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
> that was needed because of the usage in this static block and you could not apply the annotation here.
> Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
> Can you explain ?

There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From prr at openjdk.java.net  Fri May 28 03:15:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 28 May 2021 03:15:12 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <U7wtFZQMD3K1ydYS7ve7Rgn3f0AQtDQBpta3S1pvpnI=.c48de5eb-d250-4a92-92e9-a3158ce7837c@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
 <VHXPRMEIZVe_UgnmbjO2S9neB2ZjBWNCtEoB6VQmEoQ=.28f343f9-888e-4819-b27a-f08b02b978e8@github.com>
 <U7wtFZQMD3K1ydYS7ve7Rgn3f0AQtDQBpta3S1pvpnI=.c48de5eb-d250-4a92-92e9-a3158ce7837c@github.com>
Message-ID: <whPYE3meJmN84VsHs987fWBJTACWuKncgI5AzVawutA=.7a91414e-1c0e-4895-8ce5-1be384b4b63b@github.com>

On Fri, 28 May 2021 02:50:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 630:
>> 
>>> 628:         }
>>> 629: 
>>> 630:         @SuppressWarnings("removal")
>> 
>> I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
>> that was needed because of the usage in this static block and you could not apply the annotation here.
>> Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
>> Can you explain ?
>
> There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.

Ok. But I will quote you
"This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class"

So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated.

Why has the explanation changed ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Fri May 28 03:22:03 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 03:22:03 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <whPYE3meJmN84VsHs987fWBJTACWuKncgI5AzVawutA=.7a91414e-1c0e-4895-8ce5-1be384b4b63b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
 <VHXPRMEIZVe_UgnmbjO2S9neB2ZjBWNCtEoB6VQmEoQ=.28f343f9-888e-4819-b27a-f08b02b978e8@github.com>
 <U7wtFZQMD3K1ydYS7ve7Rgn3f0AQtDQBpta3S1pvpnI=.c48de5eb-d250-4a92-92e9-a3158ce7837c@github.com>
 <whPYE3meJmN84VsHs987fWBJTACWuKncgI5AzVawutA=.7a91414e-1c0e-4895-8ce5-1be384b4b63b@github.com>
Message-ID: <XI0Tn6rP6qjb2gCc3xbHipS_PHau77tF18Ii6wzplLk=.ed4e454b-541d-4545-ae5b-602713b2a6b5@github.com>

On Fri, 28 May 2021 03:12:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.
>
> Ok. But I will quote you
> "This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class"
> 
> So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated.
> 
> Why has the explanation changed ?

I should have been more precise. An annotation can only be added on a declaration, whether it's a variable, a method, or a class. Static block is not a declaration and the only one covers it is the class. But then if it's on a local variable declaration inside a static block, we certainly can annotate on that variable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From dholmes at openjdk.java.net  Fri May 28 06:49:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 28 May 2021 06:49:04 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2]
In-Reply-To: <l0XAMumKuxOuvIxhwAv_xhnvL2iB2X7kLQFqp_O9U8c=.503d7c8d-caa0-443c-8a7b-cf9058f961e2@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <l0XAMumKuxOuvIxhwAv_xhnvL2iB2X7kLQFqp_O9U8c=.503d7c8d-caa0-443c-8a7b-cf9058f961e2@github.com>
Message-ID: <IK7YQ2HXnC_QavvmXHn1FrCdXIKazdpshUwIKtAWNyY=.70bbff96-a063-43f4-86f8-06f22fdc66db@github.com>

On Thu, 27 May 2021 16:56:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments as suggested by Dan.

Hi Martin,

I'm with @stefank. This special case is a race condition and the solution for that is Atomic::load/store. Given Atomic::load/store don't actually need to do anything in practice (other than act as marker of a race) I don't have any qualms about using them all the time.

Seperately, I'm unclear why we allow this race to exist. I thought we took snapshots when threads were known to be safe and stable. But that is a separate issue.

Cheers,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From ysuenaga at openjdk.java.net  Fri May 28 07:10:06 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 28 May 2021 07:10:06 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2]
In-Reply-To: <lEVd8GWCnkTYebMPw1gfVJpqtg_HbTLhUjCfXlClfw8=.c7a834dc-54f1-4887-9286-6a87232dad96@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <lEVd8GWCnkTYebMPw1gfVJpqtg_HbTLhUjCfXlClfw8=.c7a834dc-54f1-4887-9286-6a87232dad96@github.com>
Message-ID: <xeX2YSuouikOTzyDem6tep2kEuIdZF0oSSIl0IC0ZS0=.196e6dcb-5f93-4aaf-9b50-a16547f61961@github.com>

On Thu, 27 May 2021 15:19:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comments as suggested by Dan.
>
> I wonder if this should be changed to perform the read once by using Atomic::load? That's the guidance we've given the last few years. Some background for this: JDK-8234192.

I agree with @stefank and @dholmes-ora . It is nature to happen the change in thread.hpp to fix this problem.

> Seperately, I'm unclear why we allow this race to exist. I thought we took snapshots when threads were known to be safe and stable. But that is a separate issue.

Now we have Thread-Local handshake. I think we should use it at here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From stefank at openjdk.java.net  Fri May 28 07:15:01 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 May 2021 07:15:01 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
Message-ID: <MfPw3vK_xlSoeP9gu_V7e0BgGhpFuEQCr67GgXjtH-E=.388104e8-d7d0-475c-a6c4-8f884fb70e3b@github.com>

On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

Looks good. Could you verify the fix with ZGC? G1 doesn't use it, so testing with G1 will only show that we don't hit the failing assert anymore.

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4217

From stefank at openjdk.java.net  Fri May 28 07:24:37 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 May 2021 07:24:37 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v7]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <TWlRdyfYQGw3V7VvZj79_r7HZBH_xpdIas1WlgIR2Gw=.52b9787a-4d85-4109-96ab-b18ab9c61146@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Review kbarrett
 - Review dholmes
 - Update HotSpot style guide documents
 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Clean up assembler_<cpu>.inline.hpp
 - 8267464: Circular-dependency resiliant inline headers

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=06
  Stats: 490 lines in 242 files changed: 349 ins; 118 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From rehn at openjdk.java.net  Fri May 28 07:30:11 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 28 May 2021 07:30:11 GMT
Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7]
In-Reply-To: <yJKAWrCzbzqaN1HK9DtAsPKWsBUMtvIVDsESr_g2PFo=.65c2805e-084b-4c22-afa7-025d44d36333@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
 <unMxwm1LbCyFMSc-0BsE8GcyOw52i0fodtTciLfNGq4=.3e5ab122-407e-4c59-912e-87564a01ade1@github.com>
 <yJKAWrCzbzqaN1HK9DtAsPKWsBUMtvIVDsESr_g2PFo=.65c2805e-084b-4c22-afa7-025d44d36333@github.com>
Message-ID: <OEqjL1szyXby1-TEzqzjYq4rrlKg3I0MQLvAQZFgPZ8=.40dc98a0-b01e-4431-9ad1-af300d653670@github.com>

On Wed, 26 May 2021 14:45:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up.
> 
> Reviewed the incremental between v05 -> v06. Looks good.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From rehn at openjdk.java.net  Fri May 28 07:34:15 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 28 May 2021 07:34:15 GMT
Subject: Integrated: 8265753: Remove manual JavaThread transitions to blocked
In-Reply-To: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
References: <GPqH8rH0rccPLxHzHJ9VDWZggGOGrHJpvEHTa0dnut4=.80f13595-6f0b-4e8e-bb7a-1df4bbb8d753@github.com>
Message-ID: <yrXMGON6giNrrY88RQMLVTGtqs9UetVHypEfJhLYG1w=.5aac7762-82bb-4a75-86ab-25c8a736ce94@github.com>

On Wed, 5 May 2021 08:11:04 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Please consider this change which removes the manual transitions to blocked.
> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing.
> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint.
> 
> The object monitor code could be straight forward changed to use this instead of manual transitions.
> 
> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs).
> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held.
> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state.
> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll.
> That made it possible to careful use ThreadInVMfromNative in raw monitors.
> 
> I also remove the early CAS in raw_enter.
> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor.
> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence.
> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware)
> 
> Passes t1-t7 and manual stressing relevant test groups.

This pull request has now been integrated.

Changeset: 97ec5ad0
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/97ec5ad0a6ed2cd87a9c75b0559e9bb55b72121e
Stats:     340 lines in 8 files changed: 119 ins; 150 del; 71 mod

8265753: Remove manual JavaThread transitions to blocked

Reviewed-by: dcubed, rrich, dholmes, pchilanomate

-------------

PR: https://git.openjdk.java.net/jdk/pull/3875

From simonis at openjdk.java.net  Fri May 28 08:36:09 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 28 May 2021 08:36:09 GMT
Subject: RFR: 8267555: Fix class file version during redefinition after
 8238048 [v2]
In-Reply-To: <uQPa1I7oV3HTmMKrp7cLtnBoP0KAKShXTVtcwKTuy8U=.badb9edc-26f9-4794-94e3-a8ade4d4f170@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
 <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com>
 <uQPa1I7oV3HTmMKrp7cLtnBoP0KAKShXTVtcwKTuy8U=.badb9edc-26f9-4794-94e3-a8ade4d4f170@github.com>
Message-ID: <8II7jI95WRg4a_7C-LgrZdQro-CTGErSHJlzvq-LQgc=.031c253b-f484-488e-8784-6d0240987b90@github.com>

On Thu, 27 May 2021 21:28:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267555: Fix class file version during redefinition after 8238048
>
> Hi Volker,
> The fix looks okay to me.
> Thank you for fixing it!
> Serguei

Thanks for the reviews @sspitsyn and @coleenp.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4149

From simonis at openjdk.java.net  Fri May 28 08:36:10 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 28 May 2021 08:36:10 GMT
Subject: Integrated: 8267555: Fix class file version during redefinition after
 8238048
In-Reply-To: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
References: <YACT64dWS_lLXI5waIVLO-lHcxQHfRzsmDarYOf0ObY=.93d42deb-bf4b-4000-8801-ba1b44015904@github.com>
Message-ID: <EdqsL71aym5FO6eB5lO9UOIBRNg5MPM6QcUdd8yWASE=.8c24c252-8e22-47eb-bdc3-872cab2cba3f@github.com>

On Fri, 21 May 2021 19:20:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version.
> 
> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. 
> 
> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail.
> 
> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before  [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048).
> 
> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in  `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`:
> 
>   // Copy the "source file name" attribute from new class version
>   the_class->set_source_file_name_index(
>     scratch_class->source_file_name_index());
> 
> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes?

This pull request has now been integrated.

Changeset: 1d2c7ac3
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1d2c7ac3f7492b335757bf0fd3f6ca3941c5fc72
Stats:     208 lines in 5 files changed: 204 ins; 1 del; 3 mod

8267555: Fix class file version during redefinition after 8238048

Reviewed-by: coleenp, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4149

From mdoerr at openjdk.java.net  Fri May 28 10:13:25 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 28 May 2021 10:13:25 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3]
In-Reply-To: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
Message-ID: <F3bWCCRYdkwdChv2y1moojCGnUu6VVBYpjpGg78E1_A=.fb2aa3c7-88fa-4cf5-b9c0-517671bee0a0@github.com>

> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  New solution: Use Atomic::load/store in current_pending/waiting_monitor accessors.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4224/files
  - new: https://git.openjdk.java.net/jdk/pull/4224/files/97a7df60..f4005ec0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=01-02

  Stats: 14 lines in 2 files changed: 3 ins; 5 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4224.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224

PR: https://git.openjdk.java.net/jdk/pull/4224

From mdoerr at openjdk.java.net  Fri May 28 10:19:04 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 28 May 2021 10:19:04 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3]
In-Reply-To: <F3bWCCRYdkwdChv2y1moojCGnUu6VVBYpjpGg78E1_A=.fb2aa3c7-88fa-4cf5-b9c0-517671bee0a0@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <F3bWCCRYdkwdChv2y1moojCGnUu6VVBYpjpGg78E1_A=.fb2aa3c7-88fa-4cf5-b9c0-517671bee0a0@github.com>
Message-ID: <EYpQ3PQdhJ5j9ASwIq9VoGDxQuvE6ALHZu-ZKLdNPRk=.98cbb248-995b-4558-a42d-2da5fc3a7ecd@github.com>

On Fri, 28 May 2021 10:13:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New solution: Use Atomic::load/store in current_pending/waiting_monitor accessors.

Thanks, folks, for reviewing!
Changed to use Atomic::load/store. With this version, we use volatile accesses to these two members consistently. This may restrict compiler optimizations a bit, but I wouldn't expect a performance problem.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From akozlov at openjdk.java.net  Fri May 28 10:49:32 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 28 May 2021 10:49:32 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v2]
In-Reply-To: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
Message-ID: <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>

> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
> 
> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
> 
> Reviews of the CSR linked to the bug would be appreciated as well.

Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Extend HeapDumpTest

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4183/files
  - new: https://git.openjdk.java.net/jdk/pull/4183/files/c3b4bc58..7faa6900

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=00-01

  Stats: 12 lines in 2 files changed: 7 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4183.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4183/head:pull/4183

PR: https://git.openjdk.java.net/jdk/pull/4183

From akozlov at openjdk.java.net  Fri May 28 11:01:05 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 28 May 2021 11:01:05 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file
In-Reply-To: <9mOfQ5-mxg39XJd4oaRdes-0Ci9C62DiHxjLlK5ohUo=.0ecf4b35-0090-4272-a8b1-1bd1cae3bf98@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <Ktccd3weJ015z80-5inlYTEjvFXGFFVyxTYUkpjlXrA=.22348f7f-508a-4e9a-90ac-f47ec5ecb0a9@github.com>
 <9mOfQ5-mxg39XJd4oaRdes-0Ci9C62DiHxjLlK5ohUo=.0ecf4b35-0090-4272-a8b1-1bd1cae3bf98@github.com>
Message-ID: <RZpBJo9ldwLxqPbzprzWDpgwjYNpXgTMAZo-5xBfn38=.0436deac-2bbb-4fc8-a6ea-0e9c6837ce0b@github.com>

On Thu, 27 May 2021 13:57:05 GMT, Lin Zang <lzang at openjdk.org> wrote:

> you may need to add test cases

A test is trivial. Just in case, I've added it.

> it seems the /csr label is required

Is the label really required? I don't see any integrated RFR with the label. I won't push this before CSR is approved anyway.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4183

From lzang at openjdk.java.net  Fri May 28 11:53:08 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 28 May 2021 11:53:08 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v2]
In-Reply-To: <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
Message-ID: <d0v021LsgKZ-ohQ7fazAP6oKkPBePOlH5paMzi0Zzvo=.d9c79952-a3ad-43e4-b42e-f070f1d7e9dc@github.com>

On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend HeapDumpTest

Hi Anton,

> Is the label really required? I don't see any integrated RFR with the label. I won't push this before CSR is approved anyway.

AFAIK, the `csr` label will be removed by the `bot` when it gets approved.  I usually add it in PR when CSR is required, and maybe it could help reviewer notice it and hence review the CSR. Also it could help guarantee the PR not to be pushed when CSR is not approved.  

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/4183

From ysuenaga at openjdk.java.net  Fri May 28 12:54:05 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 28 May 2021 12:54:05 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3]
In-Reply-To: <F3bWCCRYdkwdChv2y1moojCGnUu6VVBYpjpGg78E1_A=.fb2aa3c7-88fa-4cf5-b9c0-517671bee0a0@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <F3bWCCRYdkwdChv2y1moojCGnUu6VVBYpjpGg78E1_A=.fb2aa3c7-88fa-4cf5-b9c0-517671bee0a0@github.com>
Message-ID: <Wg4sFHsxKi0M1Uh0BAq6NI5nYckJHscHhStfgFiUx6Y=.27a51f15-ba7d-4c20-ad4e-58139f2ce045@github.com>

On Fri, 28 May 2021 10:13:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New solution: Use Atomic::load/store in current_pending/waiting_monitor accessors.

Shouldn't we add `volatile` to both `_current_pending_monitor` and `_current_waiting_monitor`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From ysuenaga at openjdk.java.net  Fri May 28 12:59:07 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 28 May 2021 12:59:07 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v2]
In-Reply-To: <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
Message-ID: <AncyDYOcYbAtueF04H7u5lAlf0usgNGeaurPJHeDCkI=.5c95e6f6-59c7-4bdf-a604-0b842bbad0ff@github.com>

On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend HeapDumpTest

I think `-f` (force) is more suitable like `cp` on Linux - Maybe it should be discussed on CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4183

From mdoerr at openjdk.java.net  Fri May 28 13:15:29 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 28 May 2021 13:15:29 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v4]
In-Reply-To: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
Message-ID: <s8TxPq03gCBHcjhkV4bBykqCEf9hc0jnzDF-H5mYqoE=.6286c416-1fb7-4b5e-b5c2-5339b08e29a7@github.com>

> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Make the 2 member fields volatile.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4224/files
  - new: https://git.openjdk.java.net/jdk/pull/4224/files/f4005ec0..932a7dfd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=02-03

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4224.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224

PR: https://git.openjdk.java.net/jdk/pull/4224

From mdoerr at openjdk.java.net  Fri May 28 13:25:23 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 28 May 2021 13:25:23 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v5]
In-Reply-To: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
Message-ID: <NDDmHQImObn6ryA8jZzj7xSEK-aISysOb3dPeiRHtho=.d6b478ca-38a9-4131-9bde-d7fbb1d78c01@github.com>

> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  whitespace fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4224/files
  - new: https://git.openjdk.java.net/jdk/pull/4224/files/932a7dfd..c3e58884

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4224.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224

PR: https://git.openjdk.java.net/jdk/pull/4224

From mdoerr at openjdk.java.net  Fri May 28 13:25:24 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 28 May 2021 13:25:24 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3]
In-Reply-To: <Wg4sFHsxKi0M1Uh0BAq6NI5nYckJHscHhStfgFiUx6Y=.27a51f15-ba7d-4c20-ad4e-58139f2ce045@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <F3bWCCRYdkwdChv2y1moojCGnUu6VVBYpjpGg78E1_A=.fb2aa3c7-88fa-4cf5-b9c0-517671bee0a0@github.com>
 <Wg4sFHsxKi0M1Uh0BAq6NI5nYckJHscHhStfgFiUx6Y=.27a51f15-ba7d-4c20-ad4e-58139f2ce045@github.com>
Message-ID: <ght66hGDIsdeBXO-3tRCnH-qPJIVcJFQtfDKQfXhRw0=.291bec04-018a-4d53-9807-512f2c1883ba@github.com>

On Fri, 28 May 2021 12:51:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Shouldn't we add `volatile` to both `_current_pending_monitor` and `_current_waiting_monitor`?

Right. Done. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From dcubed at openjdk.java.net  Fri May 28 13:30:14 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 28 May 2021 13:30:14 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v5]
In-Reply-To: <NDDmHQImObn6ryA8jZzj7xSEK-aISysOb3dPeiRHtho=.d6b478ca-38a9-4131-9bde-d7fbb1d78c01@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <NDDmHQImObn6ryA8jZzj7xSEK-aISysOb3dPeiRHtho=.d6b478ca-38a9-4131-9bde-d7fbb1d78c01@github.com>
Message-ID: <-N7ZeEqwfU4zlySMnBX3O8uBc01N9uWgqxRotI_Y7EQ=.e9cd29e9-6e78-4829-a1c6-6b2bea341280@github.com>

On Fri, 28 May 2021 13:25:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace fix

Thumbs up. Just a couple of suggestions about the comments.

src/hotspot/share/runtime/thread.hpp line 757:

> 755:   ObjectMonitor* current_pending_monitor() {
> 756:     // Using atomic load to prevent compilers from reloading (ThreadService::get_current_contended_monitor).
> 757:     // In case of concurrent modification, reloading pointer after NULL check must be prevented.

Perhaps rewrite the comment like this:

// Use Atomic::load() to prevent data race between concurrent modification and
// concurrent readers, e.g., ThreadService::get_current_contended_monitor().

src/hotspot/share/runtime/thread.hpp line 770:

> 768:   }
> 769:   ObjectMonitor* current_waiting_monitor() {
> 770:     // Using atomic load as in current_pending_monitor.

Perhaps:
`// See the comment in current_pending_monitor() above.`

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4224

From mdoerr at openjdk.java.net  Fri May 28 13:42:30 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 28 May 2021 13:42:30 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6]
In-Reply-To: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
Message-ID: <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>

> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Improve comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4224/files
  - new: https://git.openjdk.java.net/jdk/pull/4224/files/c3e58884..49354d0d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=04-05

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4224.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224

PR: https://git.openjdk.java.net/jdk/pull/4224

From dcubed at openjdk.java.net  Fri May 28 13:42:30 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 28 May 2021 13:42:30 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6]
In-Reply-To: <xeX2YSuouikOTzyDem6tep2kEuIdZF0oSSIl0IC0ZS0=.196e6dcb-5f93-4aaf-9b50-a16547f61961@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <lEVd8GWCnkTYebMPw1gfVJpqtg_HbTLhUjCfXlClfw8=.c7a834dc-54f1-4887-9286-6a87232dad96@github.com>
 <xeX2YSuouikOTzyDem6tep2kEuIdZF0oSSIl0IC0ZS0=.196e6dcb-5f93-4aaf-9b50-a16547f61961@github.com>
Message-ID: <SjLdg3fIgVbJoUqpwdGpT4UYzD-4OzUpYTU8zZCqgDE=.87ea3a63-3ddd-4a2b-a0b9-4bd9361d59f7@github.com>

On Fri, 28 May 2021 07:06:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I thought we took snapshots when threads were known to be safe and stable.

When we ask for snapshots with stack traces, we use a safepoint to get all of
target thread's stack traces at the same time. Obviously that code path is safe.

The "other" code path is when we don't ask for stack traces and that path has
always been carefully coded to return non stack trace information in a safe manner,
but it does not use a safepoint or a handshake. 

This duality in code paths is why the new test I wrote:
serviceability/monitoring/ThreadInfo/GetLockOwnerName/GetLockOwnerName.java
makes alternating calls of asking for the stack trace and then not.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From mdoerr at openjdk.java.net  Fri May 28 13:42:31 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 28 May 2021 13:42:31 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v5]
In-Reply-To: <NDDmHQImObn6ryA8jZzj7xSEK-aISysOb3dPeiRHtho=.d6b478ca-38a9-4131-9bde-d7fbb1d78c01@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <NDDmHQImObn6ryA8jZzj7xSEK-aISysOb3dPeiRHtho=.d6b478ca-38a9-4131-9bde-d7fbb1d78c01@github.com>
Message-ID: <I_lGQAtalmm-LCbGaJarrFzPKXJUTPsrlqSaJ2YCM9U=.cffb3d88-3c87-4519-ae7b-216868ab3720@github.com>

On Fri, 28 May 2021 13:25:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace fix

Thanks for the review! I have improved the comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From dcubed at openjdk.java.net  Fri May 28 13:50:15 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 28 May 2021 13:50:15 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6]
In-Reply-To: <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>
Message-ID: <rRJdqFoLihM7C1Ogg2xU25XJVPeOnciDqW8a8IXRozw=.02b90879-5b3f-4843-bbfa-f8853c62308c@github.com>

On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments.

Thumbs up.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4224

From stefank at openjdk.java.net  Fri May 28 14:04:06 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 May 2021 14:04:06 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6]
In-Reply-To: <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>
Message-ID: <ZQN-klGZ6hG0hdtr1sAcGg2kX202vIjfye1-x8GhkJQ=.f61349fe-1926-4c83-9556-cfebe9de4473@github.com>

On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments.

Looks good. Thanks!

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4224

From eosterlund at openjdk.java.net  Fri May 28 15:34:06 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 28 May 2021 15:34:06 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
Message-ID: <yCCIz0P3rO1flKmzfXaO2S1svaS9Ru2otSw9H8dh96A=.c01daef3-4897-4828-9b9c-50c8d2ecadc4@github.com>

On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

Looks good, but please test with ZGC before integrating.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4217

From ysuenaga at openjdk.java.net  Fri May 28 16:04:06 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 28 May 2021 16:04:06 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6]
In-Reply-To: <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>
Message-ID: <iEHaFJYtqBAKiDUzx0pwa79olLgZ2M6x7Z2DOh3Lnps=.61541afc-9757-412c-85d8-54e2a8dceaaf@github.com>

On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments.

Marked as reviewed by ysuenaga (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From akozlov at openjdk.java.net  Fri May 28 16:07:12 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 28 May 2021 16:07:12 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v2]
In-Reply-To: <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
Message-ID: <5t-TViZqHB79VDJSiOs4pY2wiYiIvwm35G5G7us7Rl8=.9ef26c20-d5fc-4a6b-b527-52d7db59cee6@github.com>

On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend HeapDumpTest

`-f` is overloaded with meanings in various Unix utilities, I'd like to keep it specific. For example, `cp -f` will actually do something different, it will delete the file and create a new one. `jcmd -rewrite` will reuse the same file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4183

From kvn at openjdk.java.net  Fri May 28 18:17:57 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 28 May 2021 18:17:57 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v7]
In-Reply-To: <TWlRdyfYQGw3V7VvZj79_r7HZBH_xpdIas1WlgIR2Gw=.52b9787a-4d85-4109-96ab-b18ab9c61146@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <TWlRdyfYQGw3V7VvZj79_r7HZBH_xpdIas1WlgIR2Gw=.52b9787a-4d85-4109-96ab-b18ab9c61146@github.com>
Message-ID: <ZzNXCG-_aGi5K69VSWVlUcjAU3piGMfgV8Id67FoSCs=.bdc435f4-075e-4657-bc8e-0fa3b5cab22a@github.com>

On Fri, 28 May 2021 07:24:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
>  - Review kbarrett
>  - Review dholmes
>  - Update HotSpot style guide documents
>  - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
>  - Clean up assembler_<cpu>.inline.hpp
>  - 8267464: Circular-dependency resiliant inline headers

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4127

From dcubed at openjdk.java.net  Fri May 28 21:45:29 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 28 May 2021 21:45:29 GMT
Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers
Message-ID: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>

A trivial fix to cleanup Threads_lock comments in JVM/TI function headers.

Also remove errant text added by the jframeID XSL template code:


// java_thread - unchecked
// depth - pre-checked as non-negative


The first line about `jthread` is output in error.
Only the second line about `depth` should be included.

This fix is tested with a Mach5 Tier1 job set.

-------------

Commit messages:
 - 8264800: cleanup Threads_lock comments in JVM/TI function headers

Changes: https://git.openjdk.java.net/jdk/pull/4254/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4254&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264800
  Stats: 91 lines in 3 files changed: 0 ins; 52 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4254.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4254/head:pull/4254

PR: https://git.openjdk.java.net/jdk/pull/4254

From dholmes at openjdk.java.net  Fri May 28 21:56:17 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 28 May 2021 21:56:17 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6]
In-Reply-To: <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>
Message-ID: <LuTcHmFJWT-mJXfhX1_1HumihPy5d7T6lVLm_wudEJ8=.c5eb5fe2-8da5-43ac-93a8-cf636dde9a77@github.com>

On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments.

Looks good.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4224

From dcubed at openjdk.java.net  Fri May 28 21:57:31 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 28 May 2021 21:57:31 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based to
 time based
Message-ID: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>

The Thread-SMR project added counter based tests for various APIs.
See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".

Time based tests are more appropriate for stress kits so I'm
updating the counter based tests to be time based instead.

Two of the updated tests have shaken out failures that are tracked by:

    JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"

    JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"

These updated tests are test via Mach5 Tier[134567] (in progress).
They have also been test by my Stress Kit runs for jdk-17+2[0-4].

-------------

Commit messages:
 - Use portable LL format from jni_tools.h for printf() with jlong.
 - 8266130: covert Thread-SMR stress tests from counter based to time based

Changes: https://git.openjdk.java.net/jdk/pull/4237/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4237&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266130
  Stats: 981 lines in 20 files changed: 396 ins; 291 del; 294 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4237.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4237/head:pull/4237

PR: https://git.openjdk.java.net/jdk/pull/4237

From duke at openjdk.java.net  Fri May 28 22:42:22 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 28 May 2021 22:42:22 GMT
Subject: Withdrawn: 8264311: Heap object statistics
In-Reply-To: <elD7YoD5xbRC9TqkFWH6_kVcnsowTKjGs_YgdSLMVck=.80d78d4f-4fe0-4c76-8255-90abb8034c4d@github.com>
References: <elD7YoD5xbRC9TqkFWH6_kVcnsowTKjGs_YgdSLMVck=.80d78d4f-4fe0-4c76-8255-90abb8034c4d@github.com>
Message-ID: <DlEp1iqc3Nny66D-77JMuL9TZvWWzymKhsS4COrc3xQ=.f52b717a-0ee7-46b0-88e8-78d1bbda4073@github.com>

On Tue, 30 Mar 2021 15:04:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> For Lilliput evaluation, it would be useful to be able to get some statistics about heap objects, e.g. how many objects there typically are, what is their (average) size, how big is the live data set, how many objecs have an identity hash code and how many objects are locked. Some of that information may be useful for general purpose too, e.g. the avg live data set and object size/count information might be quite useful to have.
> 
> Heap object statistics can be gathered and printed by invoking java with -XX:+UnlockDiagnosticVMOptions -XX:+HeapObjectStats -Xlog:heap+stats. It will impact performance of the workload. The sampling interval can be specificed by -XX:HeapObjectStatsSamplingInterval=X (in ms) and defaults to 500 (ms).
> 
> Testing:
>  - [x] Some manual tests, verifying the plausability of the output by hand
>  - [ ] tier1
>  - [ ] tier2

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3271

From ysuenaga at openjdk.java.net  Sat May 29 01:22:21 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 29 May 2021 01:22:21 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v2]
In-Reply-To: <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
Message-ID: <qsdnlTfwgwvpmSIU-1fGs-ScKUxLvNacnp0Kqwe49K4=.daeef159-3417-4aa3-bdd6-1c9c3a7b2e8e@github.com>

On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend HeapDumpTest

Hmm... it looks like the same result for the user between `-f` and `-rewrite`, and also many users will be easy to imagine the result in case of `-f`.

Let's see comments from other reviewers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4183

From dcubed at openjdk.java.net  Sat May 29 13:46:22 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 29 May 2021 13:46:22 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based
In-Reply-To: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
Message-ID: <WCY5mYbIiptaT35QRtSdq1qfccLRvIKonjMKE4Fc3Lk=.8ffdda31-5d58-4bb7-a57c-5ca9ccdda17b@github.com>

On Fri, 28 May 2021 00:13:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> The Thread-SMR project added counter based tests for various APIs.
> See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
> 
> Time based tests are more appropriate for stress kits so I'm
> updating the counter based tests to be time based instead.
> 
> Two of the updated tests have shaken out failures that are tracked by:
> 
>     JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL"
> 
>     JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be"
> 
> These updated tests are tested via Mach5 Tier[134567].
> They have also been test by my Stress Kit runs for jdk-17+2[0-4].

Here are my Mach5 Tier[1-7] results:

Mach5 Tier1:
- no failures
- 25 runs of the updated tests in Tier1

Mach5 Tier2:
- 1 known, unrelated failure
- The updated tests don't run in Tier2.

Mach5 Tier3:
- 5 known, unrelated test failures
- 70 runs of the updated tests

Mach5 Tier4:
- 17 runs of the updated tests
- 2 known, unrelated test failures

Mach5 Tier5:
- 56 runs of the updated tests
- 1 known, unrelated failure, 3 failures of the updated tests linked to the known bugs

Mach5 Tier6:
- 122 runs of the updated tests
- 2 failures of the updated tests, linked to the known bugs

Mach5 Tier7:
- 151 runs of the updated tests
- 1 failure of the updated tests, linked to the known bug 

Because of the failures in the upper tiers, when this PR is integrated I will be ProblemListing:

vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java 8264605
vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java 8266593

The suspendthrd003/8264605 failure had been seen one time in the CI on 2021.04.01
(April Fools Day!) and is now much more reproducible with the updated version. The
popframe011/8266593 failure had never been seen before being updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4237

From coleenp at openjdk.java.net  Sat May 29 15:50:19 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Sat, 29 May 2021 15:50:19 GMT
Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function
 headers
In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
Message-ID: <zwo98_z6Bon7SG3dsBjnZYnMu8gO1RgSegqDI4NNUu0=.ed5ad63e-2595-4287-bc1b-034412acddce@github.com>

On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers.
> 
> Also remove errant text added by the jframeID XSL template code:
> 
> 
> // java_thread - unchecked
> // depth - pre-checked as non-negative
> 
> 
> The first line about `jthread` is output in error.
> Only the second line about `depth` should be included.
> 
> This fix is tested with a Mach5 Tier1 job set.

Yes, looks trivial and fine.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4254

From dcubed at openjdk.java.net  Sat May 29 16:35:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 29 May 2021 16:35:17 GMT
Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function
 headers
In-Reply-To: <zwo98_z6Bon7SG3dsBjnZYnMu8gO1RgSegqDI4NNUu0=.ed5ad63e-2595-4287-bc1b-034412acddce@github.com>
References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
 <zwo98_z6Bon7SG3dsBjnZYnMu8gO1RgSegqDI4NNUu0=.ed5ad63e-2595-4287-bc1b-034412acddce@github.com>
Message-ID: <_Xn-IYh41j6i8Zb_Nl6FpYElGoEFEo1blJBwIOUYoFY=.24dff08f-26f2-493a-a78e-a01f90fa8ab2@github.com>

On Sat, 29 May 2021 15:47:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers.
>> 
>> Also remove errant text added by the jframeID XSL template code:
>> 
>> 
>> // java_thread - unchecked
>> // depth - pre-checked as non-negative
>> 
>> 
>> The first line about `jthread` is output in error.
>> Only the second line about `depth` should be included.
>> 
>> This fix is tested with a Mach5 Tier1 job set.
>
> Yes, looks trivial and fine.

@coleenp - Thanks for the fast review! Do you think I should wait for a
Serviceability team member review or just integrate? I _think_ they still
trust me to change comments... :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4254

From prr at openjdk.java.net  Sun May 30 17:44:23 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 30 May 2021 17:44:23 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
Message-ID: <nJPC4wkzrEB1S-50zDd6rH7nAYjitSHUl02KPNfVYeU=.cdfeb19c-16a2-47ee-b562-bade124de429@github.com>

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From rehn at openjdk.java.net  Mon May 31 06:44:20 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 31 May 2021 06:44:20 GMT
Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function
 headers
In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
Message-ID: <a7J2c_Cg-Y69ZGZBuNiUJmJvnEw0PYN84C3JHRaQDhA=.cde93a9d-1644-455b-b4ff-f269c0ec65c4@github.com>

On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers.
> 
> Also remove errant text added by the jframeID XSL template code:
> 
> 
> // java_thread - unchecked
> // depth - pre-checked as non-negative
> 
> 
> The first line about `jthread` is output in error.
> Only the second line about `depth` should be included.
> 
> This fix is tested with a Mach5 Tier1 job set.

Marked as reviewed by rehn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4254

From stefank at openjdk.java.net  Mon May 31 06:44:45 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 May 2021 06:44:45 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v8]
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <h2kGJHrmJJW7MWGbxj2OBWvKfOpU3xBrLhkF3rp0ABA=.d5b055ef-8ee5-49e4-9164-2ffc26d3d2aa@github.com>

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Review kbarrett
 - Review dholmes
 - Update HotSpot style guide documents
 - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
 - Clean up assembler_<cpu>.inline.hpp
 - 8267464: Circular-dependency resiliant inline headers

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=07
  Stats: 490 lines in 242 files changed: 349 ins; 118 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127

PR: https://git.openjdk.java.net/jdk/pull/4127

From dholmes at openjdk.java.net  Mon May 31 07:06:20 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 31 May 2021 07:06:20 GMT
Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function
 headers
In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
Message-ID: <5XsEmp8-WkUG9TATjla1pIlWNXPS2r37n0sM6m3Of0A=.930f8486-4575-4367-abb0-d34ee9d74c35@github.com>

On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers.
> 
> Also remove errant text added by the jframeID XSL template code:
> 
> 
> // java_thread - unchecked
> // depth - pre-checked as non-negative
> 
> 
> The first line about `jthread` is output in error.
> Only the second line about `depth` should be included.
> 
> This fix is tested with a Mach5 Tier1 job set.

Hi Dan,

I _think_ this is okay. It is rather confusing though as I couldn't figure out why some functions have the threadsList-handle as part of the code generated via the XML file, and some have it in the jvmtiEnv part of the code - e.g. compare SetThreadLocalStorage and GetThreadLocalStorage. 

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4254

From mdoerr at openjdk.java.net  Mon May 31 08:32:26 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 31 May 2021 08:32:26 GMT
Subject: Integrated: 8267842: SIGSEGV in get_current_contended_monitor
In-Reply-To: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
Message-ID: <tUGT0FGCyGetI8goHScwidk3Do84GSBMbgjZPgw21Go=.63502008-ccdb-4f78-8ee7-975cadec1e70@github.com>

On Thu, 27 May 2021 09:56:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.

This pull request has now been integrated.

Changeset: 1e29005a
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1e29005a22c7951242cf3b0d8cf2e6adc0b7b315
Stats:     12 lines in 2 files changed: 4 ins; 0 del; 8 mod

8267842: SIGSEGV in get_current_contended_monitor

Reviewed-by: stefank, dcubed, ysuenaga, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From mdoerr at openjdk.java.net  Mon May 31 08:32:26 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 31 May 2021 08:32:26 GMT
Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6]
In-Reply-To: <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>
References: <PrAEDzQFcD3XwahLomQgWwY1pj9BYvU-AyOFj547cTw=.76bd20ef-26dd-4811-9a18-6fc44bb1cc6d@github.com>
 <MwMEnDIPfvyBk-FXn17u9kqPmMkvVrrqHLQmFxm8jUA=.9fe698c5-e399-4a51-9434-13b0d33578f1@github.com>
Message-ID: <S5FZQ_i2US5bOIYyEnjZ6Hpkdr7NWaYWFIojo0ZTjUs=.37113f37-4a8d-4fee-be88-a6e7949267a0@github.com>

On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments.

Thanks for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4224

From akozlov at openjdk.java.net  Mon May 31 08:38:23 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 31 May 2021 08:38:23 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v2]
In-Reply-To: <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <Epd3TN_GGAA3nbompBCBjQJr24Y6Qsy_DO_omMm6gc8=.9953b1ef-707c-4197-9c67-f9b0e994b6aa@github.com>
Message-ID: <r6J76iLmVghNyoCh3-I1-ZXTU8nqYlqN3-e8KxaQzHs=.ab4c773c-5e8f-4823-9683-2726fd86d115@github.com>

On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review a small change that adds an option to GC.heap_dump to use an existing file. 
>> 
>> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first.
>> 
>> Reviews of the CSR linked to the bug would be appreciated as well.
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend HeapDumpTest

Agree, I would like to hear more feedback.

I still don't think we need to provide a (false) similarity with existing tools. For example:
* `cp` succeeds if the target file exists; `jcmd` bails out in this case
* `cp -f` unlinks and creates a new file (so it is just a convenient substitution to `rm -f; cp`); `jcmd -rewrite` rewrites the file -- this cannot be achieved without making changes to the Hotspot.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4183

From stefank at openjdk.java.net  Mon May 31 09:02:31 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 May 2021 09:02:31 GMT
Subject: RFR: 8267464: Circular-dependency resilient inline headers [v8]
In-Reply-To: <h2kGJHrmJJW7MWGbxj2OBWvKfOpU3xBrLhkF3rp0ABA=.d5b055ef-8ee5-49e4-9164-2ffc26d3d2aa@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
 <h2kGJHrmJJW7MWGbxj2OBWvKfOpU3xBrLhkF3rp0ABA=.d5b055ef-8ee5-49e4-9164-2ffc26d3d2aa@github.com>
Message-ID: <ARWfm7kOPHXGZRJRYsnnJNPFSMMSlCV4Mj85tE9FpTI=.f5a7a6e3-ad08-46e5-8fa8-dbc318a2d24e@github.com>

On Mon, 31 May 2021 06:44:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
>> 
>> This is a small, contrived example to show the problem:
>> 
>> // a.hpp
>> #pragma once
>> 
>> void a1();
>> void a2();
>> 
>> 
>> // a.inline.hpp
>> #pragma once
>> 
>> #include "a.hpp"
>> #include "b.inline.hpp"
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> 
>> // b.hpp
>> #pragma once
>> 
>> void b1();
>> void b2();
>> 
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "a.inline.hpp"
>> #include "b.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> The following code compiles fine:
>> 
>> // a.cpp
>> #include "a.inline.hpp"
>> 
>> int main() {
>>   a1();
>> 
>>   return 0;
>> }
>> 
>> But the following:
>> 
>> // b.cpp
>> #include "b.inline.hpp"
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> fails with the this error message:
>> 
>> In file included from b.inline.hpp:3,
>>                  from b.cpp:1:
>> a.inline.hpp: In function ?void a1()?:
>> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
>> 
>> We can see the problem with g++ -E:
>> 
>> # 1 "a.inline.hpp" 1
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> 
>> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
>> 
>> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
>> 
>> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
>> 
>> In the example above, b.inline.hpp would become:
>> 
>> // b.inline.hpp
>> #pragma once
>> 
>> #include "b.hpp"
>> #include "a.inline.hpp"
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
>> 
>> # 1 "b.inline.hpp" 1
>> # 1 "b.hpp" 1
>> 
>> void b1();
>> void b2();
>> 
>> # 4 "b.inline.hpp" 2
>> # 1 "a.inline.hpp" 1
>> 
>> # 1 "a.hpp" 1
>> 
>> void a1();
>> void a2();
>> 
>> # 4 "a.inline.hpp" 2
>> 
>> inline void a1() {
>>   b1();
>> }
>> 
>> inline void a2() {
>> }
>> 
>> # 5 "b.inline.hpp" 2
>> 
>> inline void b1() {
>> }
>> 
>> inline void b2() {
>>   a1();
>> }
>> 
>> # 2 "b.cpp" 2
>> 
>> int main() {
>>   b1();
>> 
>>   return 0;
>> }
>> 
>> The declarations come first, and the compiler is happy. 
>> 
>> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
>> 
>> Some notes about this patch:
>> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
>> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
>> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
>> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
>> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
>> 
>> What do you think?
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
>  - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
>  - Review kbarrett
>  - Review dholmes
>  - Update HotSpot style guide documents
>  - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers
>  - Clean up assembler_<cpu>.inline.hpp
>  - 8267464: Circular-dependency resiliant inline headers

Thanks all for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From stefank at openjdk.java.net  Mon May 31 09:02:32 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 31 May 2021 09:02:32 GMT
Subject: Integrated: 8267464: Circular-dependency resilient inline headers
In-Reply-To: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
References: <j667r5WDHRQS1CakElSEwxsn8VqiByWWz___8s9OQeE=.44ad5587-2502-45cb-b329-d2c24330799f@github.com>
Message-ID: <H9v57pFhdfqtfzMpdJfBS5Ed3hNBQg6hSM3XuNYmGcY=.3f812158-2b34-418e-8172-5d47af7fa8cc@github.com>

On Thu, 20 May 2021 11:55:05 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers.
> 
> This is a small, contrived example to show the problem:
> 
> // a.hpp
> #pragma once
> 
> void a1();
> void a2();
> 
> 
> // a.inline.hpp
> #pragma once
> 
> #include "a.hpp"
> #include "b.inline.hpp"
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> 
> // b.hpp
> #pragma once
> 
> void b1();
> void b2();
> 
> 
> // b.inline.hpp
> #pragma once
> 
> #include "a.inline.hpp"
> #include "b.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> The following code compiles fine:
> 
> // a.cpp
> #include "a.inline.hpp"
> 
> int main() {
>   a1();
> 
>   return 0;
> }
> 
> But the following:
> 
> // b.cpp
> #include "b.inline.hpp"
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> fails with the this error message:
> 
> In file included from b.inline.hpp:3,
>                  from b.cpp:1:
> a.inline.hpp: In function ?void a1()?:
> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1??
> 
> We can see the problem with g++ -E:
> 
> # 1 "a.inline.hpp" 1
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 4 "b.inline.hpp" 2
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> 
> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1().
> 
> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem.
> 
> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file.
> 
> In the example above, b.inline.hpp would become:
> 
> // b.inline.hpp
> #pragma once
> 
> #include "b.hpp"
> #include "a.inline.hpp"
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> and now both a.cpp and b.cpp compiles. The generated output now looks like this:
> 
> # 1 "b.inline.hpp" 1
> # 1 "b.hpp" 1
> 
> void b1();
> void b2();
> 
> # 4 "b.inline.hpp" 2
> # 1 "a.inline.hpp" 1
> 
> # 1 "a.hpp" 1
> 
> void a1();
> void a2();
> 
> # 4 "a.inline.hpp" 2
> 
> inline void a1() {
>   b1();
> }
> 
> inline void a2() {
> }
> 
> # 5 "b.inline.hpp" 2
> 
> inline void b1() {
> }
> 
> inline void b2() {
>   a1();
> }
> 
> # 2 "b.cpp" 2
> 
> int main() {
>   b1();
> 
>   return 0;
> }
> 
> The declarations come first, and the compiler is happy. 
> 
> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of  *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now.
> 
> Some notes about this patch:
> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes.
> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files.
> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted.
> 
> What do you think?

This pull request has now been integrated.

Changeset: 64f0f689
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/64f0f68958a74d4ee34c4b738759fc2278fa8b47
Stats:     490 lines in 242 files changed: 349 ins; 118 del; 23 mod

8267464: Circular-dependency resilient inline headers

Reviewed-by: kbarrett, eosterlund, dholmes, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4127

From weijun at openjdk.java.net  Mon May 31 15:02:57 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:02:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  default behavior reverted to allow

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04-05

  Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 31 15:09:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:09:27 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <TdTmyQQ8Wnh6Ko6yk3xYGN-eN8CCaUiw_W6bh9WbOTc=.8388e5dc-6cf8-4215-be1e-4b98eadb6d4c@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

New commit pushed. The default behavior is now reverted to be equivalent to `-Djava.security.manager=allow`. No warning will be shown when the system property is set to "allow", "disallow", or not set. A new test is added to check these warning messages. Some tests are updated to match the new behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From lancea at openjdk.java.net  Mon May 31 16:24:24 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 31 May 2021 16:24:24 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <95Pzw60HuW83TYfd9Dogs6AdG0GDq0Ajh8McoTvRhJU=.37e0db8a-8670-408f-81cd-b5d30ea724ce@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073