From lmesnik at openjdk.java.net  Tue Jun  1 02:59:19 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 1 Jun 2021 02:59:19 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: <DUd1DaEKdONt-SZsv781GXw8tvK9RfebqRGdnoqoAyc=.3e3fbd51-b3ab-400c-a1fe-3fe0e180aac4@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 async-profiles works with ZGC and data look reasonable.

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

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

From lmesnik at openjdk.java.net  Tue Jun  1 03:03:22 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 1 Jun 2021 03:03:22 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <stwusYKU6iyfkN1VUgpp4imx06ckRQmTKSDLa7l1_yw=.a8cb978a-c4bf-4cc6-b647-706d7d370c98@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
 <stwusYKU6iyfkN1VUgpp4imx06ckRQmTKSDLa7l1_yw=.a8cb978a-c4bf-4cc6-b647-706d7d370c98@github.com>
Message-ID: <B0jwH8HY4yvNGMi-O_jMX1nmLut_HOLQFieEJJSmnHc=.b9668477-36b5-48ae-b812-4290f1413370@github.com>

On Thu, 27 May 2021 23:07:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace
>
> 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.

Let me check with Erik if it makes sense to put more generic comments about the usage of stackwatermark frame processing in RegisterMap, frames etc.  They can't be updated in an arbitrary thread state. It makes sense describe this info in stackwatermarking.

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

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

From eosterlund at openjdk.java.net  Tue Jun  1 04:12:20 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 1 Jun 2021 04:12:20 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <B0jwH8HY4yvNGMi-O_jMX1nmLut_HOLQFieEJJSmnHc=.b9668477-36b5-48ae-b812-4290f1413370@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
 <stwusYKU6iyfkN1VUgpp4imx06ckRQmTKSDLa7l1_yw=.a8cb978a-c4bf-4cc6-b647-706d7d370c98@github.com>
 <B0jwH8HY4yvNGMi-O_jMX1nmLut_HOLQFieEJJSmnHc=.b9668477-36b5-48ae-b812-4290f1413370@github.com>
Message-ID: <0OCkOjLl2iUz5Knd6Y246N_HB9rJGHTOInAjqro49S4=.e88b2d28-4a5f-42e3-885d-3304e3ba096d@github.com>

On Tue, 1 Jun 2021 03:00:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Let me check with Erik if it makes sense to put more generic comments about the usage of stackwatermark frame processing in RegisterMap, frames etc.  They can't be updated in an arbitrary thread state. It makes sense describe this info in stackwatermarking.

You could say something generic like "StackWatermark can only be used when at points where the stack can be parsed by the GC", or something like that.

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

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

From lmesnik at openjdk.java.net  Tue Jun  1 04:26:16 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 1 Jun 2021 04:26:16 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <0OCkOjLl2iUz5Knd6Y246N_HB9rJGHTOInAjqro49S4=.e88b2d28-4a5f-42e3-885d-3304e3ba096d@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
 <stwusYKU6iyfkN1VUgpp4imx06ckRQmTKSDLa7l1_yw=.a8cb978a-c4bf-4cc6-b647-706d7d370c98@github.com>
 <B0jwH8HY4yvNGMi-O_jMX1nmLut_HOLQFieEJJSmnHc=.b9668477-36b5-48ae-b812-4290f1413370@github.com>
 <0OCkOjLl2iUz5Knd6Y246N_HB9rJGHTOInAjqro49S4=.e88b2d28-4a5f-42e3-885d-3304e3ba096d@github.com>
Message-ID: <nS7BCDgDDc1Ofg-hB0h0snTi6FptM5Sy1F4q9BVgG4Q=.7ecd9c51-7564-4545-a237-438e7a361aa8@github.com>

On Tue, 1 Jun 2021 04:09:13 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Let me check with Erik if it makes sense to put more generic comments about the usage of stackwatermark frame processing in RegisterMap, frames etc.  They can't be updated in an arbitrary thread state. It makes sense describe this info in stackwatermarking.
>
>> Let me check with Erik if it makes sense to put more generic comments about the usage of stackwatermark frame processing in RegisterMap, frames etc.  They can't be updated in an arbitrary thread state. It makes sense describe this info in stackwatermarking.
> 
> You could say something generic like "StackWatermark can only be used when at points where the stack can be parsed by the GC", or something like that.

Thank you for your prompt response. I meant that it makes sense to update comments for RegisterMap to mention this. Currently, the doc says how to use it and how to disable update:
"Updating of the RegisterMap can be turned off by instantiating the
//      register map as: RegisterMap map(thread, false);"
But it says nothing about why and how  process_frames should be set.
It might make sense to put this info there so anyone could easily find and read it. I think it is better to put it there rather than in forte.cpp.

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

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

From eosterlund at openjdk.java.net  Tue Jun  1 05:05:24 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 1 Jun 2021 05:05:24 GMT
Subject: RFR: 8265148: StackWatermarkSet being updated during
 AsyncGetCallTrace
In-Reply-To: <nS7BCDgDDc1Ofg-hB0h0snTi6FptM5Sy1F4q9BVgG4Q=.7ecd9c51-7564-4545-a237-438e7a361aa8@github.com>
References: <edV4fRd9w8J61EsX1qLNKdJcf801j9wkFTsG-3UB-E0=.bfa3a199-cb49-4f5b-b9e8-1691be301dd4@github.com>
 <stwusYKU6iyfkN1VUgpp4imx06ckRQmTKSDLa7l1_yw=.a8cb978a-c4bf-4cc6-b647-706d7d370c98@github.com>
 <B0jwH8HY4yvNGMi-O_jMX1nmLut_HOLQFieEJJSmnHc=.b9668477-36b5-48ae-b812-4290f1413370@github.com>
 <0OCkOjLl2iUz5Knd6Y246N_HB9rJGHTOInAjqro49S4=.e88b2d28-4a5f-42e3-885d-3304e3ba096d@github.com>
 <nS7BCDgDDc1Ofg-hB0h0snTi6FptM5Sy1F4q9BVgG4Q=.7ecd9c51-7564-4545-a237-438e7a361aa8@github.com>
Message-ID: <5lUwO4aIv9dQqDNbZ-T_EGzr9ui-Lwj33dbaQuj5lyw=.54a7475e-c352-4463-b2a1-cb92cf600e48@github.com>

On Tue, 1 Jun 2021 04:23:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Thank you for your prompt response. I meant that it makes sense to update comments for RegisterMap to mention this. Currently, the doc says how to use it and how to disable update:
> 
> "Updating of the RegisterMap can be turned off by instantiating the
> 
> //      register map as: RegisterMap map(thread, false);"
> 
> But it says nothing about why and how  process_frames should be set.
> 
> It might make sense to put this info there so anyone could easily find and read it. I think it is better to put it there rather than in forte.cpp.

Yes I agree - that does make sense.

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

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

From alanb at openjdk.java.net  Tue Jun  1 12:50:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 1 Jun 2021 12:50:29 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: <dVFpffOKyZHh8laXoFtu1wOUx8nLCS9d12qsoSUE5Bk=.632c4211-41df-40b4-8e07-ee8c3cb249f5@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

System.setSecurityManagerDirect looks a bit ugly now. Can this be renamed to implSetSecurityManager and avoid the line break in the  middle of the declaration?

The usage of System.err usage in setSecurityManager also needs to be re-examined as this will run arbitrary code when System.err can be changed. To fix this will require capturing the stream at startup (as was done with the illegal access logger). It's okay to integrate with what you have for the first push and we can fix this issue with System.err when the warning message is changed to the intended message.

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

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

From weijun at openjdk.java.net  Tue Jun  1 15:06:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 1 Jun 2021 15:06:41 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v7]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <DSVYh67KJe9RW8wMcOpG0R8F4Jx4HYzwW66XEV-EH1w=.cb0b76eb-c433-4ed1-bf62-e227082768f3@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:

  rename setSecurityManagerDirect to implSetSecurityManager

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/8fd09c39..926e4b9a

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

  Stats: 5 lines in 1 file changed: 0 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 weijun at openjdk.java.net  Tue Jun  1 15:21:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 1 Jun 2021 15:21:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v8]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@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 11 commits:

 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - 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
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

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

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=07
  Stats: 2132 lines in 826 files changed: 1997 ins; 20 del; 115 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 alanb at openjdk.java.net  Tue Jun  1 16:05:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 1 Jun 2021 16:05:29 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v8]
In-Reply-To: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
Message-ID: <M0Mj0BK_4OBlu3dwDgSWnaM8KDpkL0KxAJldFL7q-eY=.31a0aa64-5a69-42df-bf80-09b4e7a3c144@github.com>

On Tue, 1 Jun 2021 15:21:33 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 11 commits:
> 
>  - merge from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - 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
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by alanb (Reviewer).

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

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

From joehw at openjdk.java.net  Tue Jun  1 16:28:27 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 1 Jun 2021 16:28:27 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v8]
In-Reply-To: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
Message-ID: <rwSPwilSFt5efKcqrbureXYq8SmLxHMgrE_psXV-S9A=.87124c9e-112f-4a4e-80de-26bfa32fa995@github.com>

On Tue, 1 Jun 2021 15:21:33 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 11 commits:
> 
>  - merge from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - 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
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by joehw (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Tue Jun  1 17:18:20 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 1 Jun 2021 17:18: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: <CAV5TPeL-T1D6uY1YZflDnhnC9YtVht-USVc88BwyXo=.c8f2db0d-1e6b-4a6c-a1db-5b7b6f724dbd@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 sspitsyn (Reviewer).

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

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

From cjplummer at openjdk.java.net  Tue Jun  1 17:54:19 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 1 Jun 2021 17:54:19 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: <HTJPEdWoyU_XX93SNHQ6gd3LrQoC9FQ5VR_QE6qdtns=.7b1faeb6-1e04-4d4f-b9ce-8b383cbdb9ea@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?

Marked as reviewed by cjplummer (Reviewer).

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

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

From lmesnik at openjdk.java.net  Tue Jun  1 18:09:28 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 1 Jun 2021 18:09:28 GMT
Subject: Integrated: 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: <6wsQ5S6b38LKJaHo7R6aZrmjWgXDVILskv-sRMTT-vc=.3461dbbb-9dda-4d42-8349-c4108c29026c@github.com>

On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace

This pull request has now been integrated.

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

8265148: StackWatermarkSet being updated during AsyncGetCallTrace

Reviewed-by: stefank, eosterlund

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

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

From dcubed at openjdk.java.net  Tue Jun  1 18:55:26 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 18:55:26 GMT
Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function
 headers
In-Reply-To: <a7J2c_Cg-Y69ZGZBuNiUJmJvnEw0PYN84C3JHRaQDhA=.cde93a9d-1644-455b-b4ff-f269c0ec65c4@github.com>
References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com>
 <a7J2c_Cg-Y69ZGZBuNiUJmJvnEw0PYN84C3JHRaQDhA=.cde93a9d-1644-455b-b4ff-f269c0ec65c4@github.com>
Message-ID: <1FMAjSHJcGt2gZuT15gF1iqH2_Cnc3U821a7ZFmcSNw=.249cc22c-e982-4fa2-bd94-3e3ddc818cfd@github.com>

On Mon, 31 May 2021 06:41:29 GMT, Robbin Ehn <rehn 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).

@robehn, @dholmes-ora and @sspitsyn - Thanks for the reviews!

> 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.

That would be an historical question for Robert Field. :-)
Definitely not something I want to deal with in this change.

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

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

From dcubed at openjdk.java.net  Tue Jun  1 18:55:27 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 18:55:27 GMT
Subject: Integrated: 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: <jQfrwzET8BdUkLEDYV18HwBLeIiSgYE_3uZmnWwoJP4=.bacecbfd-567f-4d2a-892e-1a79822f26db@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.

This pull request has now been integrated.

Changeset: 40e4171f
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/40e4171f562da2f6a507efc7ad359e298199ed71
Stats:     91 lines in 3 files changed: 0 ins; 52 del; 39 mod

8264800: cleanup Threads_lock comments in JVM/TI function headers

Reviewed-by: coleenp, rehn, dholmes, sspitsyn

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

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

From dcubed at openjdk.java.net  Tue Jun  1 20:52:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 1 Jun 2021 20:52:40 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
Message-ID: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@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 tested via Mach5 Tier[134567].
> They have also been test by my Stress Kit runs for jdk-17+2[0-4].

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

  Apply @plummercj code review fix from JDK-8265153 to this review also.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4237/files
  - new: https://git.openjdk.java.net/jdk/pull/4237/files/8ec5caed..2ab79a2c

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

  Stats: 23 lines in 11 files changed: 0 ins; 0 del; 23 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 cjplummer at openjdk.java.net  Tue Jun  1 21:01:29 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 1 Jun 2021 21:01:29 GMT
Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java
 fails with connection refused error.
In-Reply-To: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
References: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
Message-ID: <7FgAnGdpSMqyEYLfFy1TWPVjajLKa-BAULbz5RZbHKs=.b049dfbe-263c-4f16-9aae-94adf15794b9@github.com>

On Thu, 27 May 2021 23:00:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> 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

test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java line 51:

> 49:         String cmd = pipe.readln();
> 50:         int exitCode = PASSED;
> 51:         if ("quit".equals(cmd)) {

I don't see how this is an improvement.

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

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

From lmesnik at openjdk.java.net  Tue Jun  1 22:04:52 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 1 Jun 2021 22:04:52 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly
Message-ID: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>

8266337: ThreadTimesClosure doesn't handle exceptions properly

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

Commit messages:
 - 8266337: ThreadTimesClosure doesn't handle exceptions properly

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

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

From amenkov at openjdk.java.net  Tue Jun  1 22:28:28 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 1 Jun 2021 22:28:28 GMT
Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java
 fails with connection refused error.
In-Reply-To: <7FgAnGdpSMqyEYLfFy1TWPVjajLKa-BAULbz5RZbHKs=.b049dfbe-263c-4f16-9aae-94adf15794b9@github.com>
References: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
 <7FgAnGdpSMqyEYLfFy1TWPVjajLKa-BAULbz5RZbHKs=.b049dfbe-263c-4f16-9aae-94adf15794b9@github.com>
Message-ID: <PQkPCx942oIKVSar_TkrqQD_faY_quEETygzYxyR2Ho=.84dc70ef-9f2f-40bc-811c-6abb68bfc483@github.com>

On Tue, 1 Jun 2021 17:56:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> 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
>
> test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java line 51:
> 
>> 49:         String cmd = pipe.readln();
>> 50:         int exitCode = PASSED;
>> 51:         if ("quit".equals(cmd)) {
> 
> I don't see how this is an improvement.

Working on the fix I got null cmd here.
I think "Invalid command received null" failure is clearer than NPE

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

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

From ysuenaga at openjdk.java.net  Tue Jun  1 22:42:28 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 1 Jun 2021 22:42:28 GMT
Subject: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965
In-Reply-To: <HTJPEdWoyU_XX93SNHQ6gd3LrQoC9FQ5VR_QE6qdtns=.7b1faeb6-1e04-4d4f-b9ce-8b383cbdb9ea@github.com>
References: <SEstazl5HPdp9XNAaPGKtXNhdhq4eGocYHFpS7GHuZA=.926a304e-f0b9-43c7-b05c-01b0dd944bcf@github.com>
 <HTJPEdWoyU_XX93SNHQ6gd3LrQoC9FQ5VR_QE6qdtns=.7b1faeb6-1e04-4d4f-b9ce-8b383cbdb9ea@github.com>
Message-ID: <ULBmj_Yxrh1IitgFmpyj3ETN4g2EsKfRmPmuxqqPzhE=.0ac5036e-40cd-49f0-a49b-87cc8c91cf05@github.com>

On Tue, 1 Jun 2021 17:51:24 GMT, Chris Plummer <cjplummer 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?
>
> Marked as reviewed by cjplummer (Reviewer).

Thanks @plummercj for the review!
May I get the review from ZGC folks?

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

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

From dholmes at openjdk.java.net  Tue Jun  1 22:46:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 1 Jun 2021 22:46:29 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly
In-Reply-To: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
Message-ID: <_dj-ctWdVqcFmAgThgQzG-YTnj875WRe8N0gVo1oSGI=.c743c8f8-f6f0-403d-adab-2605adac1012@github.com>

On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8266337: ThreadTimesClosure doesn't handle exceptions properly

Hi Leonid,

This change looks good to me.

Thanks,
David

src/hotspot/share/services/management.cpp line 1708:

> 1706:     Threads::threads_do(&ttc);
> 1707:   }
> 1708:   ttc.do_unlocked(THREAD);

At first I thought this should use CHECK_0 not THREAD so it will return zero when an exception occurs. But this goes straight back to Java code so the exception will propagate and the return value can't be examined.

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

Marked as reviewed by dholmes (Reviewer).

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

From sspitsyn at openjdk.java.net  Tue Jun  1 23:12:31 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 1 Jun 2021 23:12:31 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly
In-Reply-To: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
Message-ID: <P5pWcbf5FAVT3zwU-UV3XOc06FvRTUe8ezxPG65RzwU=.84b18227-1d74-47ed-988f-53e99c109c7f@github.com>

On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8266337: ThreadTimesClosure doesn't handle exceptions properly

Hi Leonid,

This looks good to me.
One thing to consider is to use `os::strdup_check_oom` instead of `os::strdup`.
The os::strdup can return NULL.

Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From lmesnik at openjdk.java.net  Wed Jun  2 01:20:48 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 2 Jun 2021 01:20:48 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly [v2]
In-Reply-To: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
Message-ID: <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>

> 8266337: ThreadTimesClosure doesn't handle exceptions properly

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

  strdup_check_oom is used instead of strdup.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4292/files
  - new: https://git.openjdk.java.net/jdk/pull/4292/files/e1542ddb..15572433

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

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

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

From lmesnik at openjdk.java.net  Wed Jun  2 01:20:48 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 2 Jun 2021 01:20:48 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly
In-Reply-To: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
Message-ID: <fgaB_Gl-1k_7HzlwUYLAo7YnZGOsAZ_AuadthiFEd9Q=.3affbd24-77fc-4451-9b01-2f134192ceee@github.com>

On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8266337: ThreadTimesClosure doesn't handle exceptions properly

Serguei, 

Thanks for the suggestion. It is not exactly part of this bug but is really close. Updated to used strdup_check_oom  instead of strdup.

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

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

From coleenp at openjdk.java.net  Wed Jun  2 02:01:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 2 Jun 2021 02:01:30 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: <D_AM0qROQVqbat1Hu88TE59lnwEfeLixW3IYlkgua18=.8f238372-62a9-4820-913c-b268482b343e@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

This looks good!

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

Marked as reviewed by coleenp (Reviewer).

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

From cjplummer at openjdk.java.net  Wed Jun  2 07:05:31 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 2 Jun 2021 07:05:31 GMT
Subject: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965
In-Reply-To: <ULBmj_Yxrh1IitgFmpyj3ETN4g2EsKfRmPmuxqqPzhE=.0ac5036e-40cd-49f0-a49b-87cc8c91cf05@github.com>
References: <SEstazl5HPdp9XNAaPGKtXNhdhq4eGocYHFpS7GHuZA=.926a304e-f0b9-43c7-b05c-01b0dd944bcf@github.com>
 <HTJPEdWoyU_XX93SNHQ6gd3LrQoC9FQ5VR_QE6qdtns=.7b1faeb6-1e04-4d4f-b9ce-8b383cbdb9ea@github.com>
 <ULBmj_Yxrh1IitgFmpyj3ETN4g2EsKfRmPmuxqqPzhE=.0ac5036e-40cd-49f0-a49b-87cc8c91cf05@github.com>
Message-ID: <AONGqtTBZFrvXutceERQn668MLyJnhYi0JNyebO-RZA=.95b7aca2-a8b2-4c1a-b424-a45d0fd03392@github.com>

On Tue, 1 Jun 2021 22:39:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>  May I get the review from ZGC folks?

The ZGC team won't be doing SA code reviews. I'll have someone else from the svc team do a second review, but keep in mind these reviews are primarily just to make sure the changes won't break anything (other than SA support for ZGC).

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

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

From alanb at openjdk.java.net  Wed Jun  2 08:47:32 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 2 Jun 2021 08:47:32 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: <lFmqzTx5LcP9vagq4s5UiQ0FzZv2MBfaaDataMb5o78=.de180ad5-4b00-4ef1-a4f0-bbed2c850f29@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 the named pipe scenario needs more discussion. For the more simpler case of overwriting an existing file then opt-in in with an option like `-overwrite` might be clearer than `-rewrite`. It's important that we choose the right name because there are several commands that may need to do the same.

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

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

From sgehwolf at openjdk.java.net  Wed Jun  2 09:09:44 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 2 Jun 2021 09:09:44 GMT
Subject: RFR: 8268103: JNI functions incorrectly return a double after
 JDK-8265836
Message-ID: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>

Please review this trivial patch.  Stubs should return `-1` for `jlong` rather than `-1.0` (`double`) on aix/macosx.

Thoughts?

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

Commit messages:
 - 8268103: JNI functions incorrectly return a double after JDK-8265836

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

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

From github.com+7947546+tanghaoth90 at openjdk.java.net  Wed Jun  2 09:54:50 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Wed, 2 Jun 2021 09:54:50 GMT
Subject: RFR: 8268103: JNI functions incorrectly return a double after
 JDK-8265836
In-Reply-To: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
References: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
Message-ID: <Em1ngjJV2nDCUMTeAHAIve72r3Csf4oam5-4dj8CNpk=.e0962a95-b4e6-4c4a-b948-6b875dedff2e@github.com>

On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this trivial patch.  Stubs should return `-1` for `jlong` rather than `-1.0` (`double`) on aix/macosx.
> 
> Thoughts?

LGTM. Thanks!

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

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

From dholmes at openjdk.java.net  Wed Jun  2 10:32:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 10:32:41 GMT
Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
Message-ID: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>

Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).

Affected tests:

- vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/

This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.

Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.

- vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
- vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java

These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.

Testing:
 - local testing of affected test areas
 - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).

Thanks,
David

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

Commit messages:
 - 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes

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

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

From vlivanov at openjdk.java.net  Wed Jun  2 10:32:41 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 2 Jun 2021 10:32:41 GMT
Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
In-Reply-To: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
References: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
Message-ID: <XSppKMXvVgP-BYpRdvICJ-xbpgUxkgBwuMFaMouiJTs=.6aff87bd-1825-4cd3-a331-74e8efecb144@github.com>

On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).
> 
> Affected tests:
> 
> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/
> 
> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.
> 
> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.
> 
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java
> 
> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.
> 
> Testing:
>  - local testing of affected test areas
>  - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).
> 
> Thanks,
> David

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

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

From dholmes at openjdk.java.net  Wed Jun  2 10:32:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 10:32:41 GMT
Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
In-Reply-To: <XSppKMXvVgP-BYpRdvICJ-xbpgUxkgBwuMFaMouiJTs=.6aff87bd-1825-4cd3-a331-74e8efecb144@github.com>
References: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
 <XSppKMXvVgP-BYpRdvICJ-xbpgUxkgBwuMFaMouiJTs=.6aff87bd-1825-4cd3-a331-74e8efecb144@github.com>
Message-ID: <J7y3ksx78rNYKIP0BvKKkl96bULnGXSTJp8Kg5vQJH4=.9cd051c5-9d3b-42bf-892a-6d074e4ea523@github.com>

On Wed, 2 Jun 2021 10:25:38 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).
>> 
>> Affected tests:
>> 
>> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/
>> 
>> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.
>> 
>> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.
>> 
>> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
>> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java
>> 
>> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.
>> 
>> Testing:
>>  - local testing of affected test areas
>>  - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).
>> 
>> Thanks,
>> David
>
> Looks good.

Thanks @iwanowww !

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

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

From rehn at openjdk.java.net  Wed Jun  2 10:39:29 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 2 Jun 2021 10:39:29 GMT
Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
In-Reply-To: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
References: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
Message-ID: <lSv1o3Qj30ojQWAKticWuM_Kb6QGTz_DzfvM1w034H8=.e2f80e5e-4688-49c6-9c72-eedce150af83@github.com>

On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).
> 
> Affected tests:
> 
> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/
> 
> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.
> 
> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.
> 
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java
> 
> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.
> 
> Testing:
>  - local testing of affected test areas
>  - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).
> 
> Thanks,
> David

Seems good!

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

Marked as reviewed by rehn (Reviewer).

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

From david.holmes at oracle.com  Wed Jun  2 10:45:22 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 2 Jun 2021 20:45:22 +1000
Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
In-Reply-To: <lSv1o3Qj30ojQWAKticWuM_Kb6QGTz_DzfvM1w034H8=.e2f80e5e-4688-49c6-9c72-eedce150af83@github.com>
References: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
 <lSv1o3Qj30ojQWAKticWuM_Kb6QGTz_DzfvM1w034H8=.e2f80e5e-4688-49c6-9c72-eedce150af83@github.com>
Message-ID: <ce6c35b0-bb27-a0c8-68d6-98a7e3d3ecac@oracle.com>

On 2/06/2021 8:39 pm, Robbin Ehn wrote:
> On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).
>>
>> Affected tests:
>>
>> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/
>>
>> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.
>>
>> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.
>>
>> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
>> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java
>>
>> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.
>>
>> Testing:
>>   - local testing of affected test areas
>>   - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).
>>
>> Thanks,
>> David
> 
> Seems good!

Thanks Robbin!

David

> -------------
> 
> Marked as reviewed by rehn (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/4302
> 

From dholmes at openjdk.java.net  Wed Jun  2 10:50:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 10:50:26 GMT
Subject: RFR: 8268103: JNI functions incorrectly return a double after
 JDK-8265836
In-Reply-To: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
References: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
Message-ID: <5yE8noyq7DePsxoL58O_yLsbr8K21ls__pwoDNUz1Z8=.49d4fa37-dd80-4fab-b02b-e0fe44e6dc8d@github.com>

On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this trivial patch.  Stubs should return `-1` for `jlong` rather than `-1.0` (`double`) on aix/macosx.
> 
> Thoughts?

Looks good and trivial.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From weijun at openjdk.java.net  Wed Jun  2 12:01:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 12:01:30 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v9]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <HOkSwSOf7m0eP71_pjxacSX3FnXw8CbONP_DbY0mCno=.969b9543-c6d1-4001-afac-d8cb337fd60f@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 14 commits:

 - copyright years
 - merge from master, resolve one conflict
 - Merge branch 'master'
 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - 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
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/19450b99...331389b5

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

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=08
  Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 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  Wed Jun  2 12:01:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 12:01:33 GMT
Subject: Integrated: 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: <PsbFcEhvCahb4zpsvIhOlxvAbJK7DTE3-umT3Nsn5dY=.fe038b5f-dc17-4d4f-a19b-ed8c238c7d58@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.
> 
> 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.

This pull request has now been integrated.

Changeset: 6765f902
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1
Stats:     2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod

8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Co-authored-by: Sean Mullan <mullan at openjdk.org>
Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: erikj, darcy, chegar, naoto, joehw, alanb, mchung, kcr, prr, lancea

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

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

From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net  Wed Jun  2 12:02:39 2021
From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot])
Date: Wed, 2 Jun 2021 12:02:39 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: <Y1hYOjifDkMOGuBqJgy3IjwmGnLm-XxRzkElQODQmkw=.f874c586-4e61-4420-8891-1958fd50dc6b@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

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout 8266459
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

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

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

From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net  Wed Jun  2 12:02:38 2021
From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot])
Date: Wed, 2 Jun 2021 12:02:38 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: <PSyJvVFJ9ZdvF7KLSUwpd2ZUNj_zgTnlnfb894o0s2M=.3d72b382-7e1c-45b4-b704-541e57dfab0e@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

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout 8266459
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

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

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

From sgehwolf at openjdk.java.net  Wed Jun  2 12:21:32 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 2 Jun 2021 12:21:32 GMT
Subject: RFR: 8268103: JNI functions incorrectly return a double after
 JDK-8265836
In-Reply-To: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
References: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
Message-ID: <Qz3qX1Tkwb8DJRXhc_fc6bkbgukLR-gYQpzOlHvm27s=.98147c20-28a9-4749-bc38-7dbe8a2fa369@github.com>

On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this trivial patch.  Stubs should return `-1` for `jlong` rather than `-1.0` (`double`) on aix/macosx.
> 
> Thoughts?

Thanks for the reviews!

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

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

From sgehwolf at openjdk.java.net  Wed Jun  2 12:21:32 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 2 Jun 2021 12:21:32 GMT
Subject: Integrated: 8268103: JNI functions incorrectly return a double after
 JDK-8265836
In-Reply-To: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
References: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
Message-ID: <3NIPQxaFV9KfRRTk4r1hKez24s2FvhS4TmNz_ovJlzQ=.5c269af8-23cc-429a-9814-d527e7c06efe@github.com>

On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this trivial patch.  Stubs should return `-1` for `jlong` rather than `-1.0` (`double`) on aix/macosx.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 2963c9e6
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2963c9e6778b95f5c0fc4298064a21d1e8f31b91
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8268103: JNI functions incorrectly return a double after JDK-8265836

Reviewed-by: dholmes

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

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

From dholmes at openjdk.java.net  Wed Jun  2 12:27:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 12:27:31 GMT
Subject: Integrated: 8268094: Some vmTestbase/nsk tests fail after
 ACC_STRICT/strictfp changes
In-Reply-To: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
References: <ZAmR4rySYvbLLIVM-K4hGzn-ybAbW-F3WHeHORmDDpg=.de5fe435-e2b9-4bcf-a605-4c6c19a39e65@github.com>
Message-ID: <Yv61OAQxwgIsPH1IjRuId9wZHaJ4lE5mNOTpEo10AZ4=.07e36f70-bc65-48fa-9b90-d3c7dfadf757@github.com>

On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+).
> 
> Affected tests:
> 
> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/
> 
> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted.
> 
> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted.
> 
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java
> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java
> 
> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted.
> 
> Testing:
>  - local testing of affected test areas
>  - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks).
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: dc19baca
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dc19baca3363a105a5cc1dbc02cbe3ea65e1209e
Stats:     339 lines in 14 files changed: 0 ins; 326 del; 13 mod

8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes

Reviewed-by: vlivanov, rehn

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

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

From rschmelter at openjdk.java.net  Wed Jun  2 14:04:31 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Wed, 2 Jun 2021 14:04:31 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: <IZseOR_ScbxJBDrLPS6RodMH2HCFh53MIK0vTZFsqf0=.05f2ac77-15c5-41d0-9933-de1d73e02824@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 would rename the option to `-overwrite`, since it has a clear meaning (to replace the old content with new one). 

And to really implement the overwrite semantics, the file should be opened with `O_TRUNC`. Currently `-rewrite` just replaces the start of an already existing file with a the heap dump. If the original file was larger than the heap dump, we have trailing bytes, which would lead to errors when tools try to parse the dump. 

And on Unix it might be a good idea to use O_NOCTTY, so we don't accidentally assign a controlling tty when dumping to a console ('ve never seen actual problems omitting this, but it seems safe to add it).

Even with this changes you can still write to a fifo/tty on Unix or a named pipe on Windows, since O_TRUNC is ignored for these types of files.

And since you already created a CSR, I would propose to close [JDK-8263066](https://bugs.openjdk.java.net/browse/JDK-8263066) and instead try to get this into the mainline.

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

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

From weijun at openjdk.java.net  Wed Jun  2 15:40:55 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:40:55 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v4]
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: <iWLNwxV2CvTVXj57-NbeWHor64Ab3P7461jOk1XxoJ0=.91556668-25eb-40b4-afae-730f9c1d621f@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 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 with a new target base due to a merge or a rebase. The pull request now contains one commit:

  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=03
  Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 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 weijun at openjdk.java.net  Wed Jun  2 15:51:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:51:49 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v3]
In-Reply-To: <way7gZK55c5Z7hEWz3Wqw9QioheO1aw2ZSDMq5UAb58=.01dc300c-85ee-4de7-bef4-eff05fd17bb6@github.com>
References: <way7gZK55c5Z7hEWz3Wqw9QioheO1aw2ZSDMq5UAb58=.01dc300c-85ee-4de7-bef4-eff05fd17bb6@github.com>
Message-ID: <xlA-p91T2mblc1zO5ISPCTzySvZuvll2v60C4bzn2KU=.f16c3e85-dc98-4b36-924d-337406d46019@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 with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8267543: Post JEP 411 refactoring: security

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

Changes: https://git.openjdk.java.net/jdk/pull/4172/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4172&range=02
  Stats: 116 lines in 19 files changed: 37 ins; 36 del; 43 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  Wed Jun  2 15:51:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:51:33 GMT
Subject: Integrated: 8267521: Post JEP 411 refactoring: maximum covering > 50K
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: <zkd_bofYu1MISkzzGFuI8utKnvp_M7M4icu-ws3be7k=.d7621e87-5890-492f-a64a-187e1f9eb9ed@github.com>

On Fri, 21 May 2021 01:52:27 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.

This pull request has now been integrated.

Changeset: 508cec75
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b
Stats:     245 lines in 18 files changed: 140 ins; 39 del; 66 mod

8267521: Post JEP 411 refactoring: maximum covering > 50K

Reviewed-by: dfuchs, prr

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

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

From weijun at openjdk.java.net  Wed Jun  2 15:51:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:51:49 GMT
Subject: Integrated: 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: <slPsCVWy_zYp7_aeWYTHgEboQaOBQiZ3PQj3ngYYiz0=.d22a3da7-61d3-4939-bb7f-c462e9a59e9b@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.
> 
> I'll add a copyright year update commit before integration.

This pull request has now been integrated.

Changeset: 40d23a0c
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/40d23a0c0b955ae4636800be183da7a71665f79f
Stats:     116 lines in 19 files changed: 37 ins; 36 del; 43 mod

8267543: Post JEP 411 refactoring: security

Reviewed-by: mullan

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

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

From akozlov at openjdk.java.net  Wed Jun  2 20:05:56 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 2 Jun 2021 20:05:56 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v3]
In-Reply-To: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
Message-ID: <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@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 two additional commits since the last revision:

 - Fix create_binary_file
 - Rename option to -overwrite

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4183/files
  - new: https://git.openjdk.java.net/jdk/pull/4183/files/7faa6900..8b97a1e4

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

  Stats: 26 lines in 11 files changed: 0 ins; 8 del; 18 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  Wed Jun  2 20:51:46 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 2 Jun 2021 20:51:46 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v3]
In-Reply-To: <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>
Message-ID: <udFvGu0hd6bWw6ySJF-PHgTMaEMPp8dlqMjQzyh2Bkw=.5b41f39a-9ba9-4350-8611-56971136ea08@github.com>

On Wed, 2 Jun 2021 20:05:56 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 two additional commits since the last revision:
> 
>  - Fix create_binary_file
>  - Rename option to -overwrite

I have renamed the option to `-overwrite`. Nice catch about missing O_TRUNC, thanks! A case for the missing O_NOCTTY looks rather special, wouldn't it be a configuration issue?..

SInce JDK-8263066 suggests more enhancements, it may be worth keeping it to track the remaining ones.

@AlanBateman The patch does not do anything special to the named pipe use-case, although makes it possible. Do you suggest removing mentions of the use-case from the CSR? Otherwise, what concerns could I address? 

Thanks!

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

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

From akozlov at openjdk.java.net  Wed Jun  2 20:57:02 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 2 Jun 2021 20:57:02 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
Message-ID: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@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:

  Fix windows flags (although complied fine)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4183/files
  - new: https://git.openjdk.java.net/jdk/pull/4183/files/8b97a1e4..7f19663b

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 sspitsyn at openjdk.java.net  Wed Jun  2 21:14:39 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 2 Jun 2021 21:14:39 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly [v2]
In-Reply-To: <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
 <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
Message-ID: <9iwnQuvgxYP1nJz25GoQDrX-WiNF8BjZwbDJplox470=.1c9e54e7-99f8-4a3e-b470-4c076be1a369@github.com>

On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 8266337: ThreadTimesClosure doesn't handle exceptions properly
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   strdup_check_oom is used instead of strdup.

Leonid,
I'm not convinced yet it is okay to call strdup_check_oom in this management function.
It'd be nice to check if David agreed with this update.
Thanks,
Serguei

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

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

From sspitsyn at openjdk.java.net  Wed Jun  2 21:59:40 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 2 Jun 2021 21:59:40 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly [v2]
In-Reply-To: <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
 <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
Message-ID: <ZI7hCx8hnnvMMr_e7MYNE4nCEYa21lQ5AK6oq4p6Yjk=.3af22f32-97cc-4170-9511-2675c20a9d84@github.com>

On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 8266337: ThreadTimesClosure doesn't handle exceptions properly
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   strdup_check_oom is used instead of strdup.

Leonid,
After some thinking, I'm okay with the update.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From lmesnik at openjdk.java.net  Wed Jun  2 21:59:42 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 2 Jun 2021 21:59:42 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly [v2]
In-Reply-To: <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
 <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
Message-ID: <BYByEnSFCgcVOKJMUmdjMNkpuMMpIOWaeQM6W-OBzu0=.6fa5d37a-3ccd-481e-a486-3c0c0ee6c086@github.com>

On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 8266337: ThreadTimesClosure doesn't handle exceptions properly
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   strdup_check_oom is used instead of strdup.

I believe that it is safer to use strdup_check_oom anywhere except error handling. The plain strdup might cause delayed SEGV hard to diagnose. Might be it makes sense to file another RFE to review strdup usage.

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

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

From dholmes at openjdk.java.net  Thu Jun  3 00:45:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 3 Jun 2021 00:45:36 GMT
Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly [v2]
In-Reply-To: <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
 <Y6EdcWvTQ6Ii96-O_GGxH_lAyZYHOP6QL_jij4vY__k=.ded38ccc-497b-4c16-92d4-3d3724cfb725@github.com>
Message-ID: <AaLXtKJLW9gWLbY4_5bsyu3KNrijVi-JEZsmeXefBeU=.9bc702e7-eff5-4fe5-890a-41a85ed52fd5@github.com>

On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 8266337: ThreadTimesClosure doesn't handle exceptions properly
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   strdup_check_oom is used instead of strdup.

I don't think there is any practical difference between strdup and strdup_check_oom - the chances that we exhaust the C heap just as we hit this call are extremely low, and no matter what we do here the VM is dying if that happens (we may not even have enough memory to call vm_exit_out_of_memory!). The use of strdup_check_oom is at least cleaner as we don't have any issues with not checking the return value from strdup if a static checker looks at this code.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From lmesnik at openjdk.java.net  Thu Jun  3 04:15:39 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 3 Jun 2021 04:15:39 GMT
Subject: Integrated: 8266337: ThreadTimesClosure doesn't handle exceptions
 properly
In-Reply-To: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
References: <fSN9W_R7pYpNTrdPS2N04lr0e7Eza0x5HIDbR7aadg8=.3d1a245b-56aa-4a27-88f9-7c08777a8205@github.com>
Message-ID: <sRCdhpUR6OmolJltpgEYxE3zuRyr30gYxDLQPfMB0CU=.27f1f9e7-dc34-4dba-ab3e-7cf1f85de121@github.com>

On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8266337: ThreadTimesClosure doesn't handle exceptions properly

This pull request has now been integrated.

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

8266337: ThreadTimesClosure doesn't handle exceptions properly

Reviewed-by: dholmes, sspitsyn

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

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

From lmesnik at openjdk.java.net  Thu Jun  3 06:22:53 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 3 Jun 2021 06:22:53 GMT
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash
Message-ID: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>

Fixed a race condition between posting and enabling DynamicCodeGenerated event.

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

Commit messages:
 - 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash

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

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

From rschmelter at openjdk.java.net  Thu Jun  3 13:32:36 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Thu, 3 Jun 2021 13:32:36 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
Message-ID: <gZNkbOjtpmgnX_a6Nd5eVmZUZy1duo09l5SP07xO0xc=.b026afaf-969c-4421-a9bc-898716042730@github.com>

On Wed, 2 Jun 2021 20:57:02 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:
> 
>   Fix windows flags (although complied fine)

Yeah, I tjhink the O_NOCTTY is more a theoretical consideration. I've never seen problems in practice.

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

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

From sspitsyn at openjdk.java.net  Thu Jun  3 16:53:38 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 3 Jun 2021 16:53:38 GMT
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash
In-Reply-To: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
Message-ID: <-6_SJRedB1131iS7_XYwro6x3ANkwoGyo_oG9pDftKA=.3658fe2f-66a3-4424-a679-5d75ce2182d3@github.com>

On Thu, 3 Jun 2021 06:15:28 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Fixed a race condition between posting and enabling DynamicCodeGenerated event.

Hi Leonid,
The fix looks good to me.
Thanks,
Serguei

src/hotspot/share/prims/jvmtiExport.cpp line 2293:

> 2291:   // jvmti thread state.
> 2292:   // The collector and/or state might be NULL if JvmtiDynamicCodeEventCollector has been initialized
> 2293:   // while JVMTI_EVENT_DYNAMIC_CODE_GENERATED was disabled

Could you, reballance this comment a little bit and add a dot at the end?

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

Marked as reviewed by sspitsyn (Reviewer).

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

From lmesnik at openjdk.java.net  Thu Jun  3 17:24:07 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 3 Jun 2021 17:24:07 GMT
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash [v2]
In-Reply-To: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
Message-ID: <Uviyrr8NFm1fRGZzlR6a5kpl4wP-xBZPXaLGU7H50tI=.1794fc6e-3748-436a-9a8f-ed080bf1ecc9@github.com>

> Fixed a race condition between posting and enabling DynamicCodeGenerated event.

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

  fixed comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4331/files
  - new: https://git.openjdk.java.net/jdk/pull/4331/files/4a998eeb..c650f446

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

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

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

From sspitsyn at openjdk.java.net  Thu Jun  3 19:33:05 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 3 Jun 2021 19:33:05 GMT
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash [v2]
In-Reply-To: <Uviyrr8NFm1fRGZzlR6a5kpl4wP-xBZPXaLGU7H50tI=.1794fc6e-3748-436a-9a8f-ed080bf1ecc9@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
 <Uviyrr8NFm1fRGZzlR6a5kpl4wP-xBZPXaLGU7H50tI=.1794fc6e-3748-436a-9a8f-ed080bf1ecc9@github.com>
Message-ID: <hfO29YJI8lyO6WJPy_d_3yLTmGo6jqSR2K0u0K8-Hfk=.63254f8e-24c1-4d8c-bda9-c18082b08165@github.com>

On Thu, 3 Jun 2021 17:24:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed a race condition between posting and enabling DynamicCodeGenerated event.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed comment

Marked as reviewed by sspitsyn (Reviewer).

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

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

From cjplummer at openjdk.java.net  Thu Jun  3 20:34:55 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 3 Jun 2021 20:34:55 GMT
Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java
 fails with connection refused error.
In-Reply-To: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
References: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
Message-ID: <17kf5_XVWb5zKNMjojZW4H0Eyjdscj6qqwse8WkCs9k=.cfd1d58f-85b1-434b-adb4-240942b3276c@github.com>

On Thu, 27 May 2021 23:00:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> 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

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Thu Jun  3 20:34:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 3 Jun 2021 20:34:56 GMT
Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java
 fails with connection refused error.
In-Reply-To: <PQkPCx942oIKVSar_TkrqQD_faY_quEETygzYxyR2Ho=.84dc70ef-9f2f-40bc-811c-6abb68bfc483@github.com>
References: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
 <7FgAnGdpSMqyEYLfFy1TWPVjajLKa-BAULbz5RZbHKs=.b049dfbe-263c-4f16-9aae-94adf15794b9@github.com>
 <PQkPCx942oIKVSar_TkrqQD_faY_quEETygzYxyR2Ho=.84dc70ef-9f2f-40bc-811c-6abb68bfc483@github.com>
Message-ID: <-D9Ddd75nkNEiNOdzirhrO1InHmFjnZd6zUSZJsGCbc=.052b3d29-0daf-4b34-bdc4-ec218e324420@github.com>

On Tue, 1 Jun 2021 22:24:31 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java line 51:
>> 
>>> 49:         String cmd = pipe.readln();
>>> 50:         int exitCode = PASSED;
>>> 51:         if ("quit".equals(cmd)) {
>> 
>> I don't see how this is an improvement.
>
> Working on the fix I got null cmd here.
> I think "Invalid command received null" failure is clearer than NPE

Ok

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

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

From dcubed at openjdk.java.net  Thu Jun  3 21:19:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Jun 2021 21:19:59 GMT
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash [v2]
In-Reply-To: <Uviyrr8NFm1fRGZzlR6a5kpl4wP-xBZPXaLGU7H50tI=.1794fc6e-3748-436a-9a8f-ed080bf1ecc9@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
 <Uviyrr8NFm1fRGZzlR6a5kpl4wP-xBZPXaLGU7H50tI=.1794fc6e-3748-436a-9a8f-ed080bf1ecc9@github.com>
Message-ID: <a-HrVIbbzkf0bNKQ6dWz0h56ThjsFJJk-l-SotKoTOA=.b2d5db5f-7e09-4893-b234-89961a6d9d00@github.com>

On Thu, 3 Jun 2021 17:24:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed a race condition between posting and enabling DynamicCodeGenerated event.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed comment

Thumbs up.

I just have minor comments.

Just curious: what's the execution times for the new test on the Mach5 platforms?

test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp line 27:

> 25: #include <jvmti.h>
> 26: 
> 27: jvmtiEnv* jvmti;

Should this be 'static'?

test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp line 35:

> 33: JNIEXPORT
> 34: void JNICALL Java_DynamicCodeGeneratedTest_changeEventNotificationMode(JNIEnv* jni, jclass cls) {
> 35:   while(true) {

nit - please add space before '('

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

Marked as reviewed by dcubed (Reviewer).

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

From dcubed at openjdk.java.net  Thu Jun  3 21:24:57 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Jun 2021 21:24:57 GMT
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash [v2]
In-Reply-To: <Uviyrr8NFm1fRGZzlR6a5kpl4wP-xBZPXaLGU7H50tI=.1794fc6e-3748-436a-9a8f-ed080bf1ecc9@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
 <Uviyrr8NFm1fRGZzlR6a5kpl4wP-xBZPXaLGU7H50tI=.1794fc6e-3748-436a-9a8f-ed080bf1ecc9@github.com>
Message-ID: <jO55qP-6zM6YQHwaFD4s5bIOGok1L7bjg7jYWrxr1eU=.f9bccd7d-384c-44ba-8feb-44b06519f39e@github.com>

On Thu, 3 Jun 2021 17:24:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed a race condition between posting and enabling DynamicCodeGenerated event.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed comment

test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java line 55:

> 53:                 Reference.reachabilityFence(result);
> 54:             }).start();
> 55:         }

I just noticed no `join()` calls to clean up these threads.
Does this mean we'll have 10,000 thread objects waiting around
until the end of the program?

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

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

From lmesnik at openjdk.java.net  Thu Jun  3 21:33:29 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 3 Jun 2021 21:33:29 GMT
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash [v3]
In-Reply-To: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
Message-ID: <oiCoyTQAlrKHFUn2yDzKDrxljZnvqyrPfSdyBCWYnNM=.d5cb5f41-e950-4088-962a-84627b893ab0@github.com>

> Fixed a race condition between posting and enabling DynamicCodeGenerated event.

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

  updated test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4331/files
  - new: https://git.openjdk.java.net/jdk/pull/4331/files/c650f446..7482d580

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

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

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

From sspitsyn at openjdk.java.net  Thu Jun  3 21:47:58 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 3 Jun 2021 21:47:58 GMT
Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java
 fails with connection refused error.
In-Reply-To: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
References: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
Message-ID: <uCI-Pz_5bIvg8dQCu7hA6NWzhFhsm7ZK7KA1g3nYiHQ=.b926dc29-ef11-463b-884e-9845746c31b4@github.com>

On Thu, 27 May 2021 23:00:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> 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

Hi Alex,
This is nice refactoring. It looks good to me.
The fix has a potential to introduce new regressions.
I hope you run all the impacted tests on all platforms.
Thanks,
Serguei

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java line 275:

> 273:         if (listening) {
> 274:             // listenerThread == null means the test is not updated yet
> 275:             // to start IOPipe listening before launching debuggee.

I like this workaround for non-updated tests. This spot can be simplified after all tests got updated.

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java line 279:

> 277:                 // start listening and accept connection on the current thread
> 278:                 listenerThread = new ListenerThread();
> 279:                 listenerThread.run();

It is not clear, why `listenerThread.run()` is used instead of `listenerThread.start()` as at the line 257.

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

Marked as reviewed by sspitsyn (Reviewer).

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

From dcubed at openjdk.java.net  Thu Jun  3 21:57:55 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Jun 2021 21:57:55 GMT
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash [v3]
In-Reply-To: <oiCoyTQAlrKHFUn2yDzKDrxljZnvqyrPfSdyBCWYnNM=.d5cb5f41-e950-4088-962a-84627b893ab0@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
 <oiCoyTQAlrKHFUn2yDzKDrxljZnvqyrPfSdyBCWYnNM=.d5cb5f41-e950-4088-962a-84627b893ab0@github.com>
Message-ID: <sM0wZsCXMIL7hyoSf4n23y_Dyoo1RkUGTIBggBLc9tE=.fa7ee864-d972-4b22-8b4d-03e793dd7e06@github.com>

On Thu, 3 Jun 2021 21:33:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed a race condition between posting and enabling DynamicCodeGenerated event.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test.

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

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

From lmesnik at openjdk.java.net  Thu Jun  3 22:26:58 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 3 Jun 2021 22:26:58 GMT
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash [v3]
In-Reply-To: <oiCoyTQAlrKHFUn2yDzKDrxljZnvqyrPfSdyBCWYnNM=.d5cb5f41-e950-4088-962a-84627b893ab0@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
 <oiCoyTQAlrKHFUn2yDzKDrxljZnvqyrPfSdyBCWYnNM=.d5cb5f41-e950-4088-962a-84627b893ab0@github.com>
Message-ID: <-7O2hk6F8PtOxkmPc2vO6pp5qIrhi9MzY42vAJCirrQ=.19624775-87f9-453c-92cd-8096aff3dd8d@github.com>

On Thu, 3 Jun 2021 21:33:29 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Fixed a race condition between posting and enabling DynamicCodeGenerated event.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test.

> Just curious: what's the execution times for the new test on the Mach5 platforms?

It takes ~3 seconds to complete the test in Mach5.

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

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

From lmesnik at openjdk.java.net  Thu Jun  3 22:26:59 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 3 Jun 2021 22:26:59 GMT
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash [v2]
In-Reply-To: <jO55qP-6zM6YQHwaFD4s5bIOGok1L7bjg7jYWrxr1eU=.f9bccd7d-384c-44ba-8feb-44b06519f39e@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
 <Uviyrr8NFm1fRGZzlR6a5kpl4wP-xBZPXaLGU7H50tI=.1794fc6e-3748-436a-9a8f-ed080bf1ecc9@github.com>
 <jO55qP-6zM6YQHwaFD4s5bIOGok1L7bjg7jYWrxr1eU=.f9bccd7d-384c-44ba-8feb-44b06519f39e@github.com>
Message-ID: <nDIkFM-h1CdsN7LOIMkrJeKVIVfnwr-t_KVYNbmU0g4=.7744da97-a55a-431f-aa5a-dd6fa0840b6d@github.com>

On Thu, 3 Jun 2021 21:21:45 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed comment
>
> test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java line 55:
> 
>> 53:                 Reference.reachabilityFence(result);
>> 54:             }).start();
>> 55:         }
> 
> I just noticed no `join()` calls to clean up these threads.
> Does this mean we'll have 10,000 thread objects waiting around
> until the end of the program?

Yes, we don't care about thread completion. Just start new threads while the first ones are completed.  I  reduced the number of threads to 2000. It is still enough to reproduce the crash. However, 2,000 thread doesn't harm any system. I checked in Mach5.

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

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

From amenkov at openjdk.java.net  Thu Jun  3 22:45:00 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 3 Jun 2021 22:45:00 GMT
Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java
 fails with connection refused error.
In-Reply-To: <uCI-Pz_5bIvg8dQCu7hA6NWzhFhsm7ZK7KA1g3nYiHQ=.b926dc29-ef11-463b-884e-9845746c31b4@github.com>
References: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
 <uCI-Pz_5bIvg8dQCu7hA6NWzhFhsm7ZK7KA1g3nYiHQ=.b926dc29-ef11-463b-884e-9845746c31b4@github.com>
Message-ID: <ws9nT19cipZNIWSRt_AUpx5o3vH_gVBtY9Ul85Jcgh0=.746faa81-6007-49c7-9b71-142e9bd067ce@github.com>

On Thu, 3 Jun 2021 21:44:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> 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
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java line 275:
> 
>> 273:         if (listening) {
>> 274:             // listenerThread == null means the test is not updated yet
>> 275:             // to start IOPipe listening before launching debuggee.
> 
> I like this workaround for non-updated tests. This spot can be simplified after all tests got updated.

Yes, the plan is to put assert here later.

> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java line 279:
> 
>> 277:                 // start listening and accept connection on the current thread
>> 278:                 listenerThread = new ListenerThread();
>> 279:                 listenerThread.run();
> 
> It is not clear, why `listenerThread.run()` is used instead of `listenerThread.start()` as at the line 257.

This is part of the workaround for non-updated tests - the tests should work the same way they did.
start() would start new thread, so listening starts a bit later and we have more chances to get "connection refused" error.

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

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

From sspitsyn at openjdk.java.net  Fri Jun  4 01:42:55 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 4 Jun 2021 01:42:55 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: <1BX_mRpzZBqOhj_B9a1c4Vd90ZbktO__FWmjSqGTL-M=.4a1e3e49-14b9-465b-8d1f-38c6c7e5f986@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?

Hi Yasumasa,
This looks okay to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From david.holmes at oracle.com  Fri Jun  4 02:21:10 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 4 Jun 2021 12:21:10 +1000
Subject: RFR: 8212155: Race condition when posting dynamic_code_generated
 event leads to JVM crash [v2]
In-Reply-To: <jO55qP-6zM6YQHwaFD4s5bIOGok1L7bjg7jYWrxr1eU=.f9bccd7d-384c-44ba-8feb-44b06519f39e@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
 <Uviyrr8NFm1fRGZzlR6a5kpl4wP-xBZPXaLGU7H50tI=.1794fc6e-3748-436a-9a8f-ed080bf1ecc9@github.com>
 <jO55qP-6zM6YQHwaFD4s5bIOGok1L7bjg7jYWrxr1eU=.f9bccd7d-384c-44ba-8feb-44b06519f39e@github.com>
Message-ID: <ec1713b2-01a3-7c83-1cda-60f1029c9038@oracle.com>

Hi Dan,

On 4/06/2021 7:24 am, Daniel D.Daugherty wrote:
> On Thu, 3 Jun 2021 17:24:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:
> 
>>> Fixed a race condition between posting and enabling DynamicCodeGenerated event.
>>
>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    fixed comment
> 
> test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java line 55:
> 
>> 53:                 Reference.reachabilityFence(result);
>> 54:             }).start();
>> 55:         }
> 
> I just noticed no `join()` calls to clean up these threads.

Java doesn't need a join() to "cleanup threads". The main reason to 
join() threads in a test is to ensure they have terminated before we 
hand control back to jtreg; and if not daemons to ensure we terminate 
more predictably.

Cheers,
David
-----

> Does this mean we'll have 10,000 thread objects waiting around
> until the end of the program?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4331
> 

From cjplummer at openjdk.java.net  Fri Jun  4 03:44:04 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 4 Jun 2021 03:44:04 GMT
Subject: RFR: 8263323: Debug Agent help output includes invalid URL
Message-ID: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>

Rather than embed a URL in the help output, which needs to be updated if the location of docs ever changes, just include a description of the document so it can be looked up. The output now looks like:


$ ./java -agentlib:jdwp=help
               Java Debugger JDWP Agent Library
               --------------------------------

  (See the "Oracle VM Invocation Options" section of the JPDA
   "Connection and Invocation Details" document for more information.)

jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]

Option Name and Value            Description                       Default
---------------------            -----------                       -------
suspend=y|n                      wait on startup?                  y
transport=<name>                 transport spec                    none
...

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

Commit messages:
 - Replace broken URL in help output with name of help document

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

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

From lzang at openjdk.java.net  Fri Jun  4 07:44:28 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 4 Jun 2021 07:44:28 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v26]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <GjdD3H61vbnFKxomlYWQ3BnRy7cjWbUtXD7KfyKmB0A=.a8c40bb6-0cd2-491b-a265-d3add20dc61d@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 35 commits:

 - Merge branch 'master' into par-dump
 - 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
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/3025f059...6aee4a47

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

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=25
  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  Fri Jun  4 07:46:42 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 4 Jun 2021 07:46:42 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v13]
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: <BHg3McCuqbiCRxbCdBmxai-EQjQ3dwwmaVtJfv2AwjM=.6c6b880a-96fd-474f-a87f-20aa7de412ef@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 17 additional commits since the last revision:

 - Merge branch 'master' into sadump-fix
 - 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
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/328afb95...dd665c5e

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/c80a10e0..dd665c5e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=11-12

  Stats: 544290 lines in 4337 files changed: 468501 ins; 63368 del; 12421 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 lmesnik at openjdk.java.net  Fri Jun  4 17:25:07 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 4 Jun 2021 17:25:07 GMT
Subject: Integrated: 8212155: Race condition when posting
 dynamic_code_generated event leads to JVM crash
In-Reply-To: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
References: <jQASV_NIlUzXjVOsS74gdLMPywDJK7Q8tMGmquL388w=.716a99dc-273a-4ed8-a0de-a819b1bef9fb@github.com>
Message-ID: <L36m_ZxNe1OFZoV3PKSF4ei9MaBmB8KfrVgUuUgiF9o=.74317b07-2271-4016-ac13-8c435fbd6bfa@github.com>

On Thu, 3 Jun 2021 06:15:28 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Fixed a race condition between posting and enabling DynamicCodeGenerated event.

This pull request has now been integrated.

Changeset: 64ec8b3e
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/64ec8b3e5c8a8d44c92591710d73b833f13c1500
Stats:     122 lines in 3 files changed: 116 ins; 0 del; 6 mod

8212155: Race condition when posting dynamic_code_generated event leads to JVM crash

Reviewed-by: sspitsyn, dcubed

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

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

From ysuenaga at openjdk.java.net  Sat Jun  5 00:13:04 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 5 Jun 2021 00:13:04 GMT
Subject: Integrated: 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: <mFfPjzkzO1ULcxQWpVGUrJO3mBgnYli4c25QyVkHTSQ=.9733e9a0-026f-4ef0-b5b4-0260635b0468@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?

This pull request has now been integrated.

Changeset: 7e41ca3d
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7e41ca3da820650e16d9ca7f5b188628cd666419
Stats:     799 lines in 23 files changed: 558 ins; 191 del; 50 mod

8266957: SA has not followed JDK-8220587 and JDK-8224965

Reviewed-by: cjplummer, sspitsyn

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

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

From alanb at openjdk.java.net  Sat Jun  5 06:51:58 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 5 Jun 2021 06:51:58 GMT
Subject: RFR: 8263323: Debug Agent help output includes invalid URL
In-Reply-To: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>
References: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>
Message-ID: <HCrrTHm9KDjU87GQ-Ae-pkNtEOL7WKAB6kz4GpENYYI=.0de6829f-7422-4dfc-ab80-0a22a5585e8c@github.com>

On Fri, 4 Jun 2021 03:36:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Rather than embed a URL in the help output, which needs to be updated if the location of docs ever changes, just include a description of the document so it can be looked up. The output now looks like:
> 
> 
> $ ./java -agentlib:jdwp=help
>                Java Debugger JDWP Agent Library
>                --------------------------------
> 
>   (See the "Oracle VM Invocation Options" section of the JPDA
>    "Connection and Invocation Details" document for more information.)
> 
> jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]
> 
> Option Name and Value            Description                       Default
> ---------------------            -----------                       -------
> suspend=y|n                      wait on startup?                  y
> transport=<name>                 transport spec                    none
> ...

src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c line 862:

> 860:  "               --------------------------------\n"
> 861:  "\n"
> 862:  "  (See the \"Oracle VM Invocation Options\" section of the JPDA\n"

I think you can reduce to "Invocation Options" to avoid having "Oracle VM" in the usage output.

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

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

From ysuenaga at openjdk.java.net  Sat Jun  5 08:47:13 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 5 Jun 2021 08:47:13 GMT
Subject: RFR: 8268283: serviceability/sa/TestJmapCore.java failed with zgc on
 linux-aarch64 after JDK-8266957
Message-ID: <MikBk8T8x1-Vw5lPdfDDbtZ43iHY2OyM6zbQoZxY9r0=.32d5eb5f-3197-4585-8f0e-7dd8baa4c66d@github.com>

We still see the problem in TestJmapCore.java even though [JDK-8266957 was fixed](https://github.com/openjdk/jdk/commit/7e41ca3da820650e16d9ca7f5b188628cd666419).

According to JBS, the problem suffers on linux-aarch64 only, and I've not yet reproduce it on Linux x64, so it is difficult to fix quickly. So I added it to ProblemList-zgc.txt .

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

Commit messages:
 - Update issue number
 - 8268283: serviceability/sa/TestJmapCore.java failed with zgc on linux-aarch64 after JDK-8266957

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

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

From dcubed at openjdk.java.net  Sat Jun  5 15:21:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 5 Jun 2021 15:21:06 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
Message-ID: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>

A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

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

Commit messages:
 - 8268286: ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC

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

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

From dcubed at openjdk.java.net  Sat Jun  5 15:51:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 5 Jun 2021 15:51:02 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <UX08aKmG8dBZ1k9N3PtYvssfVNDkTk3sp4DBjugBYAA=.9dae0353-8768-44ba-ab9d-9da29effde3a@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
 <UX08aKmG8dBZ1k9N3PtYvssfVNDkTk3sp4DBjugBYAA=.9dae0353-8768-44ba-ab9d-9da29effde3a@github.com>
Message-ID: <WUi52G6-Botda03dxXpnL6Qm9iSTI1Ziz_oQW8XWfq4=.59ac2118-e00d-44c2-8dd7-b67c217f1805@github.com>

On Sat, 5 Jun 2021 15:47:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs - Thanks for the review!

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

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

From rriggs at openjdk.java.net  Sat Jun  5 15:51:02 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Sat, 5 Jun 2021 15:51:02 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <UX08aKmG8dBZ1k9N3PtYvssfVNDkTk3sp4DBjugBYAA=.9dae0353-8768-44ba-ab9d-9da29effde3a@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

Marked as reviewed by rriggs (Reviewer).

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

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

From dcubed at openjdk.java.net  Sat Jun  5 15:54:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 5 Jun 2021 15:54:01 GMT
Subject: Integrated: 8268286: ProblemList serviceability/sa/TestJmapCore.java
 on linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <06RCOXEMcxl_aEzlj-GWMNda5Zu9Z8wFJ6G729CqWPU=.03a9340d-47db-4493-a9e1-8940dc6542c6@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

This pull request has now been integrated.

Changeset: f768fbf7
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f768fbf7a9df6eae10298ba6bd1b4ae438ca298d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8268286: ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC

Reviewed-by: rriggs

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

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

From clanger at openjdk.java.net  Sat Jun  5 15:54:56 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sat, 5 Jun 2021 15:54:56 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v3]
In-Reply-To: <udFvGu0hd6bWw6ySJF-PHgTMaEMPp8dlqMjQzyh2Bkw=.5b41f39a-9ba9-4350-8611-56971136ea08@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>
 <udFvGu0hd6bWw6ySJF-PHgTMaEMPp8dlqMjQzyh2Bkw=.5b41f39a-9ba9-4350-8611-56971136ea08@github.com>
Message-ID: <D98N8HZJtAS3Lqp9zUXf2fmhv9yPe0wyrHFh7h34YxU=.8667db34-ec6c-4797-9009-ec24af515b0d@github.com>

On Wed, 2 Jun 2021 20:49:10 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> SInce JDK-8263066 suggests more enhancements, it may be worth keeping it to track the remaining ones.

No, the issue we're trying to solve with JDK-8263066 is basically the same as with JDK-8267666, so we'll close it. There's also JDK-8200579 which could be closed then.

> @AlanBateman The patch does not do anything special to the named pipe use-case, although makes it possible. Do you suggest removing mentions of the use-case from the CSR? Otherwise, what concerns could I address?

I would suggest to change the CSR to use "overwrite" but other than that, it seems fine. Let's wait what Alan has to say but that would be my thinking.

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

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

From dcubed at openjdk.java.net  Sat Jun  5 16:07:58 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 5 Jun 2021 16:07:58 GMT
Subject: RFR: 8268283: serviceability/sa/TestJmapCore.java failed with zgc
 on linux-aarch64 after JDK-8266957
In-Reply-To: <MikBk8T8x1-Vw5lPdfDDbtZ43iHY2OyM6zbQoZxY9r0=.32d5eb5f-3197-4585-8f0e-7dd8baa4c66d@github.com>
References: <MikBk8T8x1-Vw5lPdfDDbtZ43iHY2OyM6zbQoZxY9r0=.32d5eb5f-3197-4585-8f0e-7dd8baa4c66d@github.com>
Message-ID: <GXTY7sf3rQswJ3i9R6bb-IXKLsjfeOMWtMXtL6XPxyY=.95fec3eb-7a24-4107-aee3-ae8798080c75@github.com>

On Sat, 5 Jun 2021 08:29:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We still see the problem in TestJmapCore.java even though [JDK-8266957 was fixed](https://github.com/openjdk/jdk/commit/7e41ca3da820650e16d9ca7f5b188628cd666419).
> 
> According to JBS, the problem suffers on linux-aarch64 only, and I've not yet reproduce it on Linux x64, so it is difficult to fix quickly. So I added it to ProblemList-zgc.txt .

@YaSuenag - I added the test to the ProblemList-zgc.txt file using:

    JDK-8268286 ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC
    https://bugs.openjdk.java.net/browse/JDK-8268286

which is a subtask of:

    JDK-8268283 serviceability/sa/TestJmapCore.java failed with zgc on linux-aarch64 after JDK-8266957
    https://bugs.openjdk.java.net/browse/JDK-8268283

That leaves this bug (JDK-8268283) to pursue the problem report by @plummercj .

Please close this PR.

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

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

From akozlov at openjdk.java.net  Sat Jun  5 18:45:58 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sat, 5 Jun 2021 18:45:58 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v3]
In-Reply-To: <D98N8HZJtAS3Lqp9zUXf2fmhv9yPe0wyrHFh7h34YxU=.8667db34-ec6c-4797-9009-ec24af515b0d@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>
 <udFvGu0hd6bWw6ySJF-PHgTMaEMPp8dlqMjQzyh2Bkw=.5b41f39a-9ba9-4350-8611-56971136ea08@github.com>
 <D98N8HZJtAS3Lqp9zUXf2fmhv9yPe0wyrHFh7h34YxU=.8667db34-ec6c-4797-9009-ec24af515b0d@github.com>
Message-ID: <mAoqp1NdXzVBDhrzt687fMRMIDUW_0VKlKH8xFLdS24=.b090b31e-eda5-43c0-bf6c-936a7ae5abe4@github.com>

On Sat, 5 Jun 2021 15:51:49 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> I would suggest to change the CSR to use "overwrite" but other than that, it seems fine.

Right, thanks! Now it is fixed, CSR uses "overwrite".

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

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

From ysuenaga at openjdk.java.net  Sun Jun  6 01:49:03 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 6 Jun 2021 01:49:03 GMT
Subject: Withdrawn: 8268283: serviceability/sa/TestJmapCore.java failed with
 zgc on linux-aarch64 after JDK-8266957
In-Reply-To: <MikBk8T8x1-Vw5lPdfDDbtZ43iHY2OyM6zbQoZxY9r0=.32d5eb5f-3197-4585-8f0e-7dd8baa4c66d@github.com>
References: <MikBk8T8x1-Vw5lPdfDDbtZ43iHY2OyM6zbQoZxY9r0=.32d5eb5f-3197-4585-8f0e-7dd8baa4c66d@github.com>
Message-ID: <zB1_mTDSbfX58XmAjLbjQt6zcTzef-nLNxXIH_5MHl8=.06046c07-dbe0-4355-a8cd-770250c22b47@github.com>

On Sat, 5 Jun 2021 08:29:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We still see the problem in TestJmapCore.java even though [JDK-8266957 was fixed](https://github.com/openjdk/jdk/commit/7e41ca3da820650e16d9ca7f5b188628cd666419).
> 
> According to JBS, the problem suffers on linux-aarch64 only, and I've not yet reproduce it on Linux x64, so it is difficult to fix quickly. So I added it to ProblemList-zgc.txt .

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.java.net  Sun Jun  6 05:34:17 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 6 Jun 2021 05:34:17 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v3]
In-Reply-To: <D98N8HZJtAS3Lqp9zUXf2fmhv9yPe0wyrHFh7h34YxU=.8667db34-ec6c-4797-9009-ec24af515b0d@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <itrSimrg32bLp40_l2H_Q_CtY46GbDzGv31sMj3NVgU=.6fb1ecf3-6944-4550-ac10-3a6999198240@github.com>
 <udFvGu0hd6bWw6ySJF-PHgTMaEMPp8dlqMjQzyh2Bkw=.5b41f39a-9ba9-4350-8611-56971136ea08@github.com>
 <D98N8HZJtAS3Lqp9zUXf2fmhv9yPe0wyrHFh7h34YxU=.8667db34-ec6c-4797-9009-ec24af515b0d@github.com>
Message-ID: <6uEFztVTs7AM8Nw6PaVezGdkLF6qXrnFPzMKGi00I2w=.5d9720e1-92aa-4df9-9b85-e0c3c188166f@github.com>

On Sat, 5 Jun 2021 15:51:49 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> I would suggest to change the CSR to use "overwrite" but other than that, it seems fine. Let's wait what Alan has to say but that would be my thinking.

Using "-overwrite" to opt-in to overwrite an existing file looks good to me.

The CSR still has wording to suggest that the new option is also to support socket/other files. I read the PR as just the overwrite existing file case. If so then maybe those (two) sentences can be changed in the CSR to make it clearer.

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

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

From clanger at openjdk.java.net  Sun Jun  6 06:19:04 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sun, 6 Jun 2021 06:19:04 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
Message-ID: <8JTsTdzmZwZCEuJ7BPBgs1XSRD2OjYC01U8WqUqWJ5k=.3f7100d6-02ee-436e-b0da-dd707ba983d4@github.com>

On Wed, 2 Jun 2021 20:57:02 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:
> 
>   Fix windows flags (although complied fine)

Thanks Alan for commenting on that one.

> The CSR still has wording to suggest that the new option is also to support socket/other files. I read the PR as just the overwrite existing file case. If so then maybe those (two) sentences can be changed in the CSR to make it clearer.

I think it's ok to mention the use-cases like pipe support which is something that'll be enabled by this change. But feel free to remove it. I've marked the CSR as reviewed from my end.

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

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

From akozlov at openjdk.java.net  Sun Jun  6 08:53:19 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 6 Jun 2021 08:53:19 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
Message-ID: <sdYRAoHt318_btf1wW4rP0eMUIIUba9nqDXIa-qQH34=.63c0837e-239f-457c-a44e-b4213c34ccc7@github.com>

On Wed, 2 Jun 2021 20:57:02 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:
> 
>   Fix windows flags (although complied fine)

Thanks for the comments! Indeed, the change is about the "overwrite" option only. The CSR describes why the option is necessary, and sockets and pipes are just examples. I have rephrased CSR to be more explicit about the option, but not examples.

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

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

From clanger at openjdk.java.net  Sun Jun  6 09:36:06 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sun, 6 Jun 2021 09:36:06 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <sdYRAoHt318_btf1wW4rP0eMUIIUba9nqDXIa-qQH34=.63c0837e-239f-457c-a44e-b4213c34ccc7@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
 <sdYRAoHt318_btf1wW4rP0eMUIIUba9nqDXIa-qQH34=.63c0837e-239f-457c-a44e-b4213c34ccc7@github.com>
Message-ID: <aonUhmydCaajEb6bMfsGE6NjhFjrd-9R9j6ZcLQWM8w=.7294fa14-9029-4ff8-b54a-376a67e95d44@github.com>

On Sun, 6 Jun 2021 08:50:22 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Thanks for the comments! Indeed, the change is about the "overwrite" option only. The CSR describes why the option is necessary, and sockets and pipes are just examples. I have rephrased CSR to be more explicit about the option, but not examples.

Perfect, looks good to me.

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

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

From lzang at openjdk.java.net  Mon Jun  7 07:58:26 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 7 Jun 2021 07:58:26 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v27]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <MXonlUa56ZacBQh36BTp_dL0HVej4tUYFx_m7WZhOa8=.12001f9b-58ae-49e9-a1f7-b66c006e5de8@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 36 commits:

 - Merge branch 'master' into par-dump
 - Merge branch 'master' into par-dump
 - 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
 - ... and 26 more: https://git.openjdk.java.net/jdk/compare/908aca29...78c2c763

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

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=26
  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  Mon Jun  7 08:01:54 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 7 Jun 2021 08:01:54 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v14]
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: <pew__FWJ2yL8cHc4dBGF8RBNk8AQbIHpnjOi7z4Ishk=.750d707c-3109-4ab9-be73-8889066b2a05@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 18 additional commits since the last revision:

 - Merge branch 'master' into sadump-fix
 - Merge branch 'master' into sadump-fix
 - 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'
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/619957e3...a87793c3

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/dd665c5e..a87793c3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=12-13

  Stats: 11128 lines in 281 files changed: 8776 ins; 1566 del; 786 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 kevinw at openjdk.java.net  Mon Jun  7 14:25:14 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 7 Jun 2021 14:25:14 GMT
Subject: RFR: 8263323: Debug Agent help output includes invalid URL
In-Reply-To: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>
References: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>
Message-ID: <xOIuH0c1q8X3HbzTc_kI_ZsgkueUxCF6WRTgIrJ-Cx8=.a2cc84e2-2630-4136-bd05-95ebb1ff8094@github.com>

On Fri, 4 Jun 2021 03:36:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Rather than embed a URL in the help output, which needs to be updated if the location of docs ever changes, just include a description of the document so it can be looked up. The output now looks like:
> 
> 
> $ ./java -agentlib:jdwp=help
>                Java Debugger JDWP Agent Library
>                --------------------------------
> 
>   (See the "Oracle VM Invocation Options" section of the JPDA
>    "Connection and Invocation Details" document for more information.)
> 
> jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]
> 
> Option Name and Value            Description                       Default
> ---------------------            -----------                       -------
> suspend=y|n                      wait on startup?                  y
> transport=<name>                 transport spec                    none
> ...

"jpda connection and invocation" got the correct document as the first search engine hit for me.

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

Marked as reviewed by kevinw (Committer).

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

From dcubed at openjdk.java.net  Mon Jun  7 15:20:20 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 7 Jun 2021 15:20:20 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <IQoYzlFmquo9LXX7PA95CmXDXm3xEejGa2VE16LThts=.de8ce845-47ba-4e5a-8f71-cedc18649b16@github.com>

On Tue, 1 Jun 2021 20:52:40 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-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

Ping! Any takers?
@dholmes-ora and @plummercj - You both reviewed the related test work done in:
     JDK-8265153 add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
Any chance you have the cycles for these updates this week?

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 17:58:16 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 17:58:16 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <IQoYzlFmquo9LXX7PA95CmXDXm3xEejGa2VE16LThts=.de8ce845-47ba-4e5a-8f71-cedc18649b16@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
 <IQoYzlFmquo9LXX7PA95CmXDXm3xEejGa2VE16LThts=.de8ce845-47ba-4e5a-8f71-cedc18649b16@github.com>
Message-ID: <u1JZ14zEDXVHpXiI1pvJ-1dlqvbG8dyabGZEnYYIxGE=.1a815a1d-8790-4433-8b85-4f6debc1b89c@github.com>

On Mon, 7 Jun 2021 15:17:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>  @dholmes-ora and @plummercj - You both reviewed the related test work done in:
> JDK-8265153 add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
> Any chance you have the cycles for these updates this week?

Yes. Hopefully in the next day or two.

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

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

From kevinw at openjdk.java.net  Mon Jun  7 19:43:19 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 7 Jun 2021 19:43:19 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: <kLwsmCJmrXnHn1taK_XA1piTECw_IHqH1jZUWtXSnGQ=.595202ce-c719-43ef-9802-ddc4f62b5543@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

Thanks Serguei and Coleen!

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

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

From kevinw at openjdk.java.net  Mon Jun  7 19:43:17 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 7 Jun 2021 19:43:17 GMT
Subject: RFR: 8266967: debug.cpp utility find() should print Java Object
 fields. [v3]
In-Reply-To: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>
References: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>
Message-ID: <tEDlJ7pRLWbvlkTUrZRU0VLM-E1cSk_jLYnGhlXOt9o=.82d316da-9500-4617-9e70-834cf4d854c6@github.com>

> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8266967_objectprint
 - ifdef correction
 - 8266967: debug.cpp utility find() should print Java Object fields.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4011/files
  - new: https://git.openjdk.java.net/jdk/pull/4011/files/f6454294..a1170727

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

  Stats: 578299 lines in 4725 files changed: 494681 ins; 69830 del; 13788 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4011.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4011/head:pull/4011

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

From cjplummer at openjdk.java.net  Mon Jun  7 19:44:26 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 19:44:26 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL
Message-ID: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>

The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.

BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.

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

Commit messages:
 - Update URL for jconsole Users Guide

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

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

From mchung at openjdk.java.net  Mon Jun  7 20:51:17 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 7 Jun 2021 20:51:17 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL
In-Reply-To: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
Message-ID: <0ZjHDZR0S2UVRHFerQeChqWkdSzgum05jH5xZ3G0Kxk=.be66fc29-82ed-471e-bc5b-c38acaa51fe7@github.com>

On Mon, 7 Jun 2021 19:36:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.
> 
> BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.

Hi Chris, 

It has been a while but I think this may intend to link to the User Guide (not the tool reference)
   https://docs.oracle.com/en/java/javase/16/management/using-jconsole.html

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 21:03:18 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 21:03:18 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL
In-Reply-To: <0ZjHDZR0S2UVRHFerQeChqWkdSzgum05jH5xZ3G0Kxk=.be66fc29-82ed-471e-bc5b-c38acaa51fe7@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
 <0ZjHDZR0S2UVRHFerQeChqWkdSzgum05jH5xZ3G0Kxk=.be66fc29-82ed-471e-bc5b-c38acaa51fe7@github.com>
Message-ID: <klyupJ3DHLy06Q2Z1IvTq6ReVG35nXuVT7KQ25mKOS4=.ba1f577a-5c9e-4a5b-9217-172849f5ab32@github.com>

On Mon, 7 Jun 2021 20:48:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Hi Chris,
> 
> It has been a while but I think this may intend to link to the User Guide (not the tool reference)
> https://docs.oracle.com/en/java/javase/16/management/using-jconsole.html

I think you are right. And there is a reference to jconsole.html from using-jconsole.html, so  you can still get to it. I'll make the switch.

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 21:09:15 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 21:09:15 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL
In-Reply-To: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
Message-ID: <OptMWAJwYg3DtTzP-nfABxvJwLbE1n8MlUhfCsebLUY=.7ab5b766-51a4-41fa-83dc-d796a6f093b8@github.com>

On Mon, 7 Jun 2021 19:36:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.
> 
> BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.

...although I'm uncertain how to get to .../management/using-jconsole.html using the "lookup" syntax as was done for getting to jconsole.html. Will need to ask someone on the docs teame.

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

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

From mandy.chung at oracle.com  Mon Jun  7 21:26:40 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 7 Jun 2021 14:26:40 -0700
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL
In-Reply-To: <OptMWAJwYg3DtTzP-nfABxvJwLbE1n8MlUhfCsebLUY=.7ab5b766-51a4-41fa-83dc-d796a6f093b8@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
 <OptMWAJwYg3DtTzP-nfABxvJwLbE1n8MlUhfCsebLUY=.7ab5b766-51a4-41fa-83dc-d796a6f093b8@github.com>
Message-ID: <64b09978-5814-2694-731c-074e774d673e@oracle.com>

Try "using_jconsole"

Mandy

On 6/7/21 2:09 PM, Chris Plummer wrote:
> On Mon, 7 Jun 2021 19:36:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>
>> The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.
>>
>> BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.
> ...although I'm uncertain how to get to .../management/using-jconsole.html using the "lookup" syntax as was done for getting to jconsole.html. Will need to ask someone on the docs teame.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4399

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210607/a8880aea/attachment-0001.htm>

From cjplummer at openjdk.java.net  Mon Jun  7 21:38:22 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 21:38:22 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL
In-Reply-To: <64b09978-5814-2694-731c-074e774d673e@oracle.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
 <64b09978-5814-2694-731c-074e774d673e@oracle.com>
Message-ID: <dmtDh4PSCtW2g5FbGKti5mmb8jl0eNDTChbx8KAucL4=.aba8b803-4675-4212-b0e8-7d1e8a75127a@github.com>

On Mon, 7 Jun 2021 21:28:50 GMT, Mandy Chung <mandy.chung at oracle.com> wrote:

> Try "using_jconsole"

I already did. No luck.

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 21:38:23 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 21:38:23 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL
In-Reply-To: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
Message-ID: <tBtkwVMZJJqu01Kx6LAMT2NkHUecPckIYeKzPpakwPk=.e050051f-1285-41a8-9445-241db34875b7@github.com>

On Mon, 7 Jun 2021 19:36:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.
> 
> BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.

Actually that does work. My URL was using 17, which doesn't exist yet, but it seems to work with 16.

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 21:49:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 21:49:42 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL [v2]
In-Reply-To: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
Message-ID: <Y-S3SRpODKhdf3dIxsj7Y4oMQAr9qF9odk9VXuXs8fI=.e28ab343-8e1f-404f-a057-231cdf3b9179@github.com>

> The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.
> 
> BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.

Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:

 - Fix type from last commit
 - Use URL for users guide instead of command reference

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4399/files
  - new: https://git.openjdk.java.net/jdk/pull/4399/files/f1342735..d29e0ddb

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

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

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

From mchung at openjdk.java.net  Mon Jun  7 21:49:43 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 7 Jun 2021 21:49:43 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL [v2]
In-Reply-To: <Y-S3SRpODKhdf3dIxsj7Y4oMQAr9qF9odk9VXuXs8fI=.e28ab343-8e1f-404f-a057-231cdf3b9179@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
 <Y-S3SRpODKhdf3dIxsj7Y4oMQAr9qF9odk9VXuXs8fI=.e28ab343-8e1f-404f-a057-231cdf3b9179@github.com>
Message-ID: <Ih4vYSG7umvnaeoHDu1p9oQMFYD7TEM6VSU5tPNFRRc=.16bb1771-0d08-4eb6-bba9-6fa70c25f200@github.com>

On Mon, 7 Jun 2021 21:46:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.
>> 
>> BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix type from last commit
>  - Use URL for users guide instead of command reference

Looks good.

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

Marked as reviewed by mchung (Reviewer).

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

From cjplummer at openjdk.java.net  Mon Jun  7 22:13:18 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 22:13:18 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <WdrljZsOmY0L-9_MaCB1mpQ_lR2rIOJe6oTCfnlpIVQ=.cb780d0f-fb89-4eca-a6aa-d009d0dc3d34@github.com>

On Tue, 1 Jun 2021 20:52:40 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-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

test/hotspot/jtreg/runtime/Thread/InterruptAtExit.java line 82:

> 80:                 thread.exitSyncObj.countDown();
> 81:                 while (true) {
> 82:                     thread.interrupt();

I just want to make sure I correctly understand the intent here. You call countDown() to unblock the thread's run() method, and then immediately interrupt the thread to create a race between the thread doing a normal exit and the thread being interrupted before or as it exits.

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 22:22:17 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 22:22:17 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <vPMvlvTwEOFYzBXW8uY7uw5imZ2wPAWFPfPaYkLTN-w=.647dddf8-24d8-4420-9bf5-237edb4e6bfb@github.com>

On Tue, 1 Jun 2021 20:52:40 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-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 88:

> 86:                 thread.exitSyncObj.countDown();
> 87:                 while (true) {
> 88:                     thread.stop();

It seems the main() method of these 6 or so thread tests are identical except for the one Thread API you call at this location. Have you considered refactoring so there is only one copy of all the common code?

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

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

From kevinw at openjdk.java.net  Mon Jun  7 22:29:18 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 7 Jun 2021 22:29:18 GMT
Subject: Integrated: 8266967: debug.cpp utility find() should print Java
 Object fields.
In-Reply-To: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>
References: <KwkJQcR43GvfIO7ajw3vivD42U0wF_7DhT-wuZztfZ0=.098b3eb3-dca3-42aa-a817-ad55394c7479@github.com>
Message-ID: <ijh72JVMnwrw1heJVfUCJyqrGnspnsvBJ1WvGxXaKvU=.89e0ea45-8944-4a0e-a8bd-36fea9930e56@github.com>

On Thu, 13 May 2021 12:12:42 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...

This pull request has now been integrated.

Changeset: 5e557d86
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5e557d8650d81f9f81938892de28a6dd8fea98b0
Stats:     20 lines in 4 files changed: 5 ins; 12 del; 3 mod

8266967: debug.cpp utility find() should print Java Object fields.

Reviewed-by: sspitsyn, coleenp

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 22:42:18 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 22:42:18 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <6g5yT7skh82ZBGp434BBgtvs6dtVt54KAQUKHIlvdZg=.695aae78-2c75-480c-8d16-6ecd75af9065@github.com>

On Tue, 1 Jun 2021 20:52:40 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-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003.java line 105:

> 103:         }
> 104: 
> 105:         System.out.println("Case 2: java.lang.Thread.interrupt()");

Was Case 2 removed because it is covered by runtime/Thread/InterruptAtExit.java

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

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

From cjplummer at openjdk.java.net  Mon Jun  7 23:14:19 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 7 Jun 2021 23:14:19 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <2bB3v2yhqpN450yxDBUw-EufYa5LYk2S0-5POqHOWCE=.5a55bb9b-89d9-45d6-9683-afaa9c472f4c@github.com>

On Tue, 1 Jun 2021 20:52:40 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-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp line 102:

> 100:         /*
> 101:          * Using printf() instead of NSK_DISPLAY1() in this loop
> 102:          * in order to slow down the rate of SuspendThread() calls.

I don't understand the reason for wanting to slow down the rate, nor your reason for removing it.

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

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

From dcubed at openjdk.java.net  Mon Jun  7 23:53:16 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 7 Jun 2021 23:53:16 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <WdrljZsOmY0L-9_MaCB1mpQ_lR2rIOJe6oTCfnlpIVQ=.cb780d0f-fb89-4eca-a6aa-d009d0dc3d34@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
 <WdrljZsOmY0L-9_MaCB1mpQ_lR2rIOJe6oTCfnlpIVQ=.cb780d0f-fb89-4eca-a6aa-d009d0dc3d34@github.com>
Message-ID: <KUaHMvSSDqarKQtc0buxns-LjQlWiC9XZhbXwh0ebKo=.2fd9fa98-8ca2-4f12-a5f1-0dc7902ecfbd@github.com>

On Mon, 7 Jun 2021 22:09:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply @plummercj code review fix from JDK-8265153 to this review also.
>
> test/hotspot/jtreg/runtime/Thread/InterruptAtExit.java line 82:
> 
>> 80:                 thread.exitSyncObj.countDown();
>> 81:                 while (true) {
>> 82:                     thread.interrupt();
> 
> I just want to make sure I correctly understand the intent here. You call countDown() to unblock the thread's run() method, and then immediately interrupt the thread to create a race between the thread doing a normal exit and the thread being interrupted before or as it exits.

That is correct. The intention is to stress the Thread.interrupt() calls
on the exiting thread.

> test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 88:
> 
>> 86:                 thread.exitSyncObj.countDown();
>> 87:                 while (true) {
>> 88:                     thread.stop();
> 
> It seems the main() method of these 6 or so thread tests are identical except for the one Thread API you call at this location. Have you considered refactoring so there is only one copy of all the common code?

Not really. It would be harder to use one of these tests in a standalone
fashion outside of JTREG runs if it depended on another .java file.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003.java line 105:
> 
>> 103:         }
>> 104: 
>> 105:         System.out.println("Case 2: java.lang.Thread.interrupt()");
> 
> Was Case 2 removed because it is covered by runtime/Thread/InterruptAtExit.java

Yes, it seemed like duplicated coverage to me.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp line 102:
> 
>> 100:         /*
>> 101:          * Using printf() instead of NSK_DISPLAY1() in this loop
>> 102:          * in order to slow down the rate of SuspendThread() calls.
> 
> I don't understand the reason for wanting to slow down the rate, nor your reason for removing it.

I couldn't remember why I did that when I wrote the test so
I removed it.

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

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

From sspitsyn at openjdk.java.net  Tue Jun  8 01:47:26 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 8 Jun 2021 01:47:26 GMT
Subject: RFR: JDK-8268241: deprecate JVMTI Heap functions 1.0
Message-ID: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>

The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.

We need to replace this sentence:
"These functions and data types were introduced in the original JVM TI
version 1.0 and have been superseded by more powerful and flexible
versions which:"
with:
"These functions and data types were introduced in the original JVM TI
version 1.0. They are deprecated and will be changed to return an error
in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 

The CSR has been approved:
  https://bugs.openjdk.java.net/browse/JDK-8268242

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

Commit messages:
 - deprecate JVMTI Heap functions 1.0

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

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

From sspitsyn at openjdk.java.net  Tue Jun  8 02:02:38 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 8 Jun 2021 02:02:38 GMT
Subject: RFR: 8268241: deprecate JVMTI Heap functions 1.0 [v2]
In-Reply-To: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
Message-ID: <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>

> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
> 
> We need to replace this sentence:
> "These functions and data types were introduced in the original JVM TI
> version 1.0 and have been superseded by more powerful and flexible
> versions which:"
> with:
> "These functions and data types were introduced in the original JVM TI
> version 1.0. They are deprecated and will be changed to return an error
> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
> 
> The CSR has been approved:
>   https://bugs.openjdk.java.net/browse/JDK-8268242

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

  missed a space in Java SE6

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4406/files
  - new: https://git.openjdk.java.net/jdk/pull/4406/files/cd4b5761..2cd78dfd

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

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

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

From lzang at openjdk.java.net  Tue Jun  8 02:33:17 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 8 Jun 2021 02:33:17 GMT
Subject: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v2]
In-Reply-To: <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
 <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
Message-ID: <kMjjn8tmiGrIYTQ8Xz-0R5eTGcATJSveIrBWT9GOHVw=.d1d136c1-9f0d-4b6e-85e0-dd97a0399d39@github.com>

On Tue, 8 Jun 2021 02:02:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
>> 
>> We need to replace this sentence:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0 and have been superseded by more powerful and flexible
>> versions which:"
>> with:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0. They are deprecated and will be changed to return an error
>> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
>> 
>> The CSR has been approved:
>>   https://bugs.openjdk.java.net/browse/JDK-8268242
>> 
>> The JVM TI Heap functions reflect the requirements of tool vendors during JSR-163. They pre-date concurrent collectors, the built-in heap dump support, and JFR. They are a maintenance burden and there is little evidence that they are used by modern tools (they involve stop-the-world operations and so are not suitable for production systems).
>> 
>> The JVM TI functions to deprecate are:
>>     IterateOverObjectsReachableFromObject
>>     IterateOverReachableObjects
>>     IterateOverHeap
>>     IterateOverInstancesOfClass
>> 
>> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to say that the functions have been superseded. The proposal is to change this to say that the functions are deprecated and will be degraded in a future release.
>> A release note is planned. The release note will detail how to use -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of these functions.
>> 
>> A future CSR will likely degrade these functions so that they return an error to indicate that they are no longer implemented/supported. We also plan to re-examine the newer Heap functions with a view to deprecate them in the future too (this requires a bit more work to understand if there is any real usage, also some adjustments to the JDWP and JDI specs).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed a space in Java SE6

Hi Serguei, 
I am not a reviewer:-), but have 1 minor suggestion:  the year info of copyright in header need to update to 2021.  Thanks.

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

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

From yyang at openjdk.java.net  Tue Jun  8 03:14:26 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 8 Jun 2021 03:14:26 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <TdWCAblzM0aCc-1wo7hH8MG-MoR1nWg8PIHuLzI8Sig=.046467a4-0c3a-4f0c-8836-0d030d651644@github.com>

On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

I have encountered a similar problem before, I've filed a new issue https://bugs.openjdk.java.net/browse/JDK-8268361 for this. You can change your title to "8268361: Fix the infinite loop in next_line", then OpenJDK bot would associate your PR with the corresponding JBS issue.

Best regards,
Yang

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

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

From github.com+1964054+unclenine at openjdk.java.net  Tue Jun  8 03:14:26 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Tue, 8 Jun 2021 03:14:26 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line
Message-ID: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>

If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

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

Commit messages:
 - Fix the dead loop.\nSummary: If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

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

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

From cjplummer at openjdk.java.net  Tue Jun  8 03:58:20 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 8 Jun 2021 03:58:20 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
Message-ID: <MPprUn7AVhUEJ0gPvMqyuvrZ12kOhHOabDbLoRhai8I=.aa8ffee7-5edd-4cc5-97c9-1d24003ce0e8@github.com>

On Tue, 1 Jun 2021 20:52:40 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-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply @plummercj code review fix from JDK-8265153 to this review also.

Marked as reviewed by cjplummer (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Tue Jun  8 04:29:14 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 8 Jun 2021 04:29:14 GMT
Subject: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v2]
In-Reply-To: <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
 <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
Message-ID: <feHjrqKf-pwZblqek-I33p5ELKWbCZVb3uYJhaS-Mxo=.2d6b5699-ea7e-44cf-856c-b0c2c74cc27b@github.com>

On Tue, 8 Jun 2021 02:02:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
>> 
>> We need to replace this sentence:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0 and have been superseded by more powerful and flexible
>> versions which:"
>> with:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0. They are deprecated and will be changed to return an error
>> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
>> 
>> The CSR has been approved:
>>   https://bugs.openjdk.java.net/browse/JDK-8268242
>> 
>> The JVM TI Heap functions reflect the requirements of tool vendors during JSR-163. They pre-date concurrent collectors, the built-in heap dump support, and JFR. They are a maintenance burden and there is little evidence that they are used by modern tools (they involve stop-the-world operations and so are not suitable for production systems).
>> 
>> The JVM TI functions to deprecate are:
>>     IterateOverObjectsReachableFromObject
>>     IterateOverReachableObjects
>>     IterateOverHeap
>>     IterateOverInstancesOfClass
>> 
>> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to say that the functions have been superseded. The proposal is to change this to say that the functions are deprecated and will be degraded in a future release.
>> A release note is planned. The release note will detail how to use -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of these functions.
>> 
>> A future CSR will likely degrade these functions so that they return an error to indicate that they are no longer implemented/supported. We also plan to re-examine the newer Heap functions with a view to deprecate them in the future too (this requires a bit more work to understand if there is any real usage, also some adjustments to the JDWP and JDI specs).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed a space in Java SE6

Thank you for the comment, Lin! I'll update the copyright year before the push.

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

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

From alanb at openjdk.java.net  Tue Jun  8 06:22:19 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Jun 2021 06:22:19 GMT
Subject: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v2]
In-Reply-To: <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
 <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
Message-ID: <yYKro96jQuoZ_T0RV0xXCk9pY7EQZdEa_PEwWaDUaV0=.492e96c8-a418-4135-b753-c15a9fb43c67@github.com>

On Tue, 8 Jun 2021 02:02:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
>> 
>> We need to replace this sentence:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0 and have been superseded by more powerful and flexible
>> versions which:"
>> with:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0. They are deprecated and will be changed to return an error
>> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
>> 
>> The CSR has been approved:
>>   https://bugs.openjdk.java.net/browse/JDK-8268242
>> 
>> The JVM TI Heap functions reflect the requirements of tool vendors during JSR-163. They pre-date concurrent collectors, the built-in heap dump support, and JFR. They are a maintenance burden and there is little evidence that they are used by modern tools (they involve stop-the-world operations and so are not suitable for production systems).
>> 
>> The JVM TI functions to deprecate are:
>>     IterateOverObjectsReachableFromObject
>>     IterateOverReachableObjects
>>     IterateOverHeap
>>     IterateOverInstancesOfClass
>> 
>> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to say that the functions have been superseded. The proposal is to change this to say that the functions are deprecated and will be degraded in a future release.
>> A release note is planned. The release note will detail how to use -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of these functions.
>> 
>> A future CSR will likely degrade these functions so that they return an error to indicate that they are no longer implemented/supported. We also plan to re-examine the newer Heap functions with a view to deprecate them in the future too (this requires a bit more work to understand if there is any real usage, also some adjustments to the JDWP and JDI specs).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed a space in Java SE6

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.java.net  Tue Jun  8 06:28:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Jun 2021 06:28:14 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL [v2]
In-Reply-To: <Y-S3SRpODKhdf3dIxsj7Y4oMQAr9qF9odk9VXuXs8fI=.e28ab343-8e1f-404f-a057-231cdf3b9179@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
 <Y-S3SRpODKhdf3dIxsj7Y4oMQAr9qF9odk9VXuXs8fI=.e28ab343-8e1f-404f-a057-231cdf3b9179@github.com>
Message-ID: <SumKCmMf_nyl4JEPl-jYb5A5ebGJ2V149rXRrNv-Sqs=.f2d62b83-fc49-4dfc-a22a-56ebbf76e4a0@github.com>

On Mon, 7 Jun 2021 21:49:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.
>> 
>> BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix type from last commit
>  - Use URL for users guide instead of command reference

No objection to this change but I think we should create a follow-on issue to drop this link from the About page. That will also avoid needing to periodically test that the link still works.

Update: I see JDK-8268351 is created - good.

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

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

From dholmes at openjdk.java.net  Tue Jun  8 06:43:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Jun 2021 06:43:14 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>

On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

Hi,

This fixes the potential infinite loop, but is it sufficient?

Thanks,
David

src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c line 70:

> 68:     do {
> 69:         c = fgetc(f);
> 70:     } while(c != '\n' && c != EOF);

Style nit: please add space before (

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

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

From dholmes at openjdk.java.net  Tue Jun  8 06:43:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Jun 2021 06:43:15 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
Message-ID: <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>

On Tue, 8 Jun 2021 06:35:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c line 70:
> 
>> 68:     do {
>> 69:         c = fgetc(f);
>> 70:     } while(c != '\n' && c != EOF);
> 
> Style nit: please add space before (

It is not obvious to me that the caller of next_line will handle the fact that we have hit EOF?

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

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

From dholmes at openjdk.java.net  Tue Jun  8 06:52:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Jun 2021 06:52:25 GMT
Subject: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v2]
In-Reply-To: <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
 <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
Message-ID: <WDTAsF5Je4rRkAbn-bzNzWDtxC9Vmvvlsi7cHb23Lb4=.5ba3f596-9630-480b-8f52-dd9750928c1d@github.com>

On Tue, 8 Jun 2021 02:02:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
>> 
>> We need to replace this sentence:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0 and have been superseded by more powerful and flexible
>> versions which:"
>> with:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0. They are deprecated and will be changed to return an error
>> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
>> 
>> The CSR has been approved:
>>   https://bugs.openjdk.java.net/browse/JDK-8268242
>> 
>> The JVM TI Heap functions reflect the requirements of tool vendors during JSR-163. They pre-date concurrent collectors, the built-in heap dump support, and JFR. They are a maintenance burden and there is little evidence that they are used by modern tools (they involve stop-the-world operations and so are not suitable for production systems).
>> 
>> The JVM TI functions to deprecate are:
>>     IterateOverObjectsReachableFromObject
>>     IterateOverReachableObjects
>>     IterateOverHeap
>>     IterateOverInstancesOfClass
>> 
>> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to say that the functions have been superseded. The proposal is to change this to say that the functions are deprecated and will be degraded in a future release.
>> A release note is planned. The release note will detail how to use -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of these functions.
>> 
>> A future CSR will likely degrade these functions so that they return an error to indicate that they are no longer implemented/supported. We also plan to re-examine the newer Heap functions with a view to deprecate them in the future too (this requires a bit more work to understand if there is any real usage, also some adjustments to the JDWP and JDI specs).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed a space in Java SE6

So ... we're logically deprecating these functions by documenting that they are deprecated, but there is no actual deprecation mechanism for JVM TI - correct? JVM TI versioning cannot be used to remove anything, it can only add new functionality.

Thanks,
David

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

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

From alanb at openjdk.java.net  Tue Jun  8 06:59:18 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Jun 2021 06:59:18 GMT
Subject: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v2]
In-Reply-To: <WDTAsF5Je4rRkAbn-bzNzWDtxC9Vmvvlsi7cHb23Lb4=.5ba3f596-9630-480b-8f52-dd9750928c1d@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
 <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
 <WDTAsF5Je4rRkAbn-bzNzWDtxC9Vmvvlsi7cHb23Lb4=.5ba3f596-9630-480b-8f52-dd9750928c1d@github.com>
Message-ID: <rixFpNE8RtuOHPpFne1XMSUOW2S1f1GMz9UIf_uw73c=.3d82002e-d96c-4199-8c20-fa0c0718ceda@github.com>

On Tue, 8 Jun 2021 06:49:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So ... we're logically deprecating these functions by documenting that they are deprecated, but there is no actual deprecation mechanism for JVM TI - correct? JVM TI versioning cannot be used to remove anything, it can only add new functionality.

I don't think it will be possible to remove the functions but they would return an error such as JVMTI_ERROR_UNSUPPORTED in the some future release. An intermediate step might be to emit a warning when the can_tag_objects capability is enabled.

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

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

From cjplummer at openjdk.java.net  Tue Jun  8 07:26:32 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 8 Jun 2021 07:26:32 GMT
Subject: RFR: 8263323: Debug Agent help output includes invalid URL [v2]
In-Reply-To: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>
References: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>
Message-ID: <aF3zHas9pyZvv9LJIVJmxfnnaFQNhyuvnni6TCEjU7c=.c4dc623c-3a39-4d3d-a2c6-2f62e2959d1d@github.com>

> Rather than embed a URL in the help output, which needs to be updated if the location of docs ever changes, just include a description of the document so it can be looked up. The output now looks like:
> 
> 
> $ ./java -agentlib:jdwp=help
>                Java Debugger JDWP Agent Library
>                --------------------------------
> 
>   (See the "Oracle VM Invocation Options" section of the JPDA
>    "Connection and Invocation Details" document for more information.)
> 
> jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]
> 
> Option Name and Value            Description                       Default
> ---------------------            -----------                       -------
> suspend=y|n                      wait on startup?                  y
> transport=<name>                 transport spec                    none
> ...

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

  Change "Oracle VM" to just "VM"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4352/files
  - new: https://git.openjdk.java.net/jdk/pull/4352/files/8e8e6c95..8a2b7fae

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

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

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

From cjplummer at openjdk.java.net  Tue Jun  8 07:39:15 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 8 Jun 2021 07:39:15 GMT
Subject: RFR: 8263323: Debug Agent help output includes invalid URL [v2]
In-Reply-To: <aF3zHas9pyZvv9LJIVJmxfnnaFQNhyuvnni6TCEjU7c=.c4dc623c-3a39-4d3d-a2c6-2f62e2959d1d@github.com>
References: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>
 <aF3zHas9pyZvv9LJIVJmxfnnaFQNhyuvnni6TCEjU7c=.c4dc623c-3a39-4d3d-a2c6-2f62e2959d1d@github.com>
Message-ID: <PndYTxsJ7Ay7FfpfkwE9qGMA6jsiVm5WVqRMH3FoLrM=.a878fbee-6513-41eb-9649-a1960e00aa2f@github.com>

On Tue, 8 Jun 2021 07:26:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Rather than embed a URL in the help output, which needs to be updated if the location of docs ever changes, just include a description of the document so it can be looked up. The output now looks like:
>> 
>> 
>> $ ./java -agentlib:jdwp=help
>>                Java Debugger JDWP Agent Library
>>                --------------------------------
>> 
>>   (See the "Oracle VM Invocation Options" section of the JPDA
>>    "Connection and Invocation Details" document for more information.)
>> 
>> jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]
>> 
>> Option Name and Value            Description                       Default
>> ---------------------            -----------                       -------
>> suspend=y|n                      wait on startup?                  y
>> transport=<name>                 transport spec                    none
>> ...
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change "Oracle VM" to just "VM"

I changed "Oracle VM" to just "VM" in the debug agent help message. I also filed [JDK-8268370](https://bugs.openjdk.java.net/browse/JDK-8268370) to fix the "Oracle VM" references in the conninv.html document.

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

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

From sgehwolf at openjdk.java.net  Tue Jun  8 08:42:15 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 8 Jun 2021 08:42:15 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>

On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?

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

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

From rschmelter at openjdk.java.net  Tue Jun  8 08:53:13 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Tue, 8 Jun 2021 08:53:13 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
Message-ID: <_6WT533IoNW8F1rY3zHVSp1aw0lHdpS5ckUtILKb6Sg=.58078d97-02c5-4fc3-ba5e-393cddb81b7e@github.com>

On Wed, 2 Jun 2021 20:57:02 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:
> 
>   Fix windows flags (although complied fine)

Looks good, thanks for the change.

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

Marked as reviewed by rschmelter (Committer).

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

From alanb at openjdk.java.net  Tue Jun  8 09:06:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Jun 2021 09:06:15 GMT
Subject: RFR: 8263323: Debug Agent help output includes invalid URL [v2]
In-Reply-To: <aF3zHas9pyZvv9LJIVJmxfnnaFQNhyuvnni6TCEjU7c=.c4dc623c-3a39-4d3d-a2c6-2f62e2959d1d@github.com>
References: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>
 <aF3zHas9pyZvv9LJIVJmxfnnaFQNhyuvnni6TCEjU7c=.c4dc623c-3a39-4d3d-a2c6-2f62e2959d1d@github.com>
Message-ID: <3It7_KXh8oX0grBD3XxGIC0z0QMENY_wJw6kdW4DAYo=.0864991c-9f8d-4dcf-a54e-07b67f66e5e9@github.com>

On Tue, 8 Jun 2021 07:26:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Rather than embed a URL in the help output, which needs to be updated if the location of docs ever changes, just include a description of the document so it can be looked up. The output now looks like:
>> 
>> 
>> $ ./java -agentlib:jdwp=help
>>                Java Debugger JDWP Agent Library
>>                --------------------------------
>> 
>>   (See the "Oracle VM Invocation Options" section of the JPDA
>>    "Connection and Invocation Details" document for more information.)
>> 
>> jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]
>> 
>> Option Name and Value            Description                       Default
>> ---------------------            -----------                       -------
>> suspend=y|n                      wait on startup?                  y
>> transport=<name>                 transport spec                    none
>> ...
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change "Oracle VM" to just "VM"

Marked as reviewed by alanb (Reviewer).

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

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

From clanger at openjdk.java.net  Tue Jun  8 13:29:17 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 8 Jun 2021 13:29:17 GMT
Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing
 file [v4]
In-Reply-To: <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
References: <yqGfBSl9G6GKEA86oe5RvMND9FVrr0vTDMVevVF4sH8=.26b1217f-666c-49c2-8166-fcec34b6ff1b@github.com>
 <emEu5FHpSQ098XJgbwFJV2H8rJScihaQZ_q1brZfcvk=.54fa1656-78e7-4c32-8419-4c68117b79bf@github.com>
Message-ID: <WM1V9wNJsEbDOUELs137pndw7OCCLJUrcpe5PnnGRMw=.058faa39-ff0e-4bac-aa60-7d445a971999@github.com>

On Wed, 2 Jun 2021 20:57:02 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:
> 
>   Fix windows flags (although complied fine)

Marked as reviewed by clanger (Reviewer).

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

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

From github.com+1964054+unclenine at openjdk.java.net  Tue Jun  8 15:44:34 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Tue, 8 Jun 2021 15:44:34 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v2]
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <Uvl087fs2EtaHdhrWic3VZt3yMADOypq0zP7Xy9hUpw=.b326aa44-4ffb-4948-82ff-202198c86f43@github.com>

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

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

  8268361: Fix the infinite loop in next_line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4378/files
  - new: https://git.openjdk.java.net/jdk/pull/4378/files/ba53f913..c055e977

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

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

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

From github.com+1964054+unclenine at openjdk.java.net  Tue Jun  8 16:24:18 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Tue, 8 Jun 2021 16:24:18 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v2]
In-Reply-To: <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
 <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>
Message-ID: <MEo4khAi-y8QnCxSFDBc11oQtjEPOQbEdjbnW7OCh8s=.8c4cf2e9-c35e-4a32-a54c-989d47f76ed0@github.com>

On Tue, 8 Jun 2021 06:39:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c line 70:
>> 
>>> 68:     do {
>>> 69:         c = fgetc(f);
>>> 70:     } while(c != '\n' && c != EOF);
>> 
>> Style nit: please add space before (
>
> It is not obvious to me that the caller of next_line will handle the fact that we have hit EOF?

In my case,  it happened in the container environment.
the /proc filesystem of the container is provided by  lxcfs, but a lxcfs bug may make the /proc/stat mount point change, then  the file descriptor is different and fgetc function returns an EOF on error,  But c != '\n' is true and it leads to the  infinit loop.
Below are our flamegraph in the production , it happends on serveral frameworks?micrometer, elasticsearch..?which use the api "sun/management/OperatingSystemImpl.getSystemCpuLoad"
![107140246-bb490f80-695b-11eb-9f62-0116079f4f4a](https://user-images.githubusercontent.com/1964054/121218982-d5690f00-c8b5-11eb-8c1e-e39f2f2bc6a5.jpg)

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

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

From github.com+1964054+unclenine at openjdk.java.net  Tue Jun  8 16:31:20 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Tue, 8 Jun 2021 16:31:20 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>
Message-ID: <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>

On Tue, 8 Jun 2021 08:39:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
> 
> In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?

In my case, it happened in the container environment.
the /proc filesystem of the container is provided by lxcfs, but a lxcfs bug may make the /proc/stat mount point change.
It was caused by a lxcfs-3.1.2 segment fault's exit

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

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

From dcubed at openjdk.java.net  Tue Jun  8 16:45:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 8 Jun 2021 16:45:18 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v2]
In-Reply-To: <u1JZ14zEDXVHpXiI1pvJ-1dlqvbG8dyabGZEnYYIxGE=.1a815a1d-8790-4433-8b85-4f6debc1b89c@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
 <IQoYzlFmquo9LXX7PA95CmXDXm3xEejGa2VE16LThts=.de8ce845-47ba-4e5a-8f71-cedc18649b16@github.com>
 <u1JZ14zEDXVHpXiI1pvJ-1dlqvbG8dyabGZEnYYIxGE=.1a815a1d-8790-4433-8b85-4f6debc1b89c@github.com>
Message-ID: <BYeQjqsUxIbvwbe-95f2zmAj-GHbZL6yBQrteM9f8RM=.e4318e83-dd2e-4489-82bd-2b3235121c14@github.com>

On Mon, 7 Jun 2021 17:55:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Ping! Any takers?
>> @dholmes-ora and @plummercj - You both reviewed the related test work done in:
>>      JDK-8265153 add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
>> Any chance you have the cycles for these updates this week?
>
>>  @dholmes-ora and @plummercj - You both reviewed the related test work done in:
>> JDK-8265153 add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
>> Any chance you have the cycles for these updates this week?
> 
> Yes. Hopefully in the next day or two.

@plummercj  - Thanks for the review!

Any other takers out there?

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

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

From github.com+1964054+unclenine at openjdk.java.net  Tue Jun  8 16:46:16 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Tue, 8 Jun 2021 16:46:16 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v2]
In-Reply-To: <MEo4khAi-y8QnCxSFDBc11oQtjEPOQbEdjbnW7OCh8s=.8c4cf2e9-c35e-4a32-a54c-989d47f76ed0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
 <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>
 <MEo4khAi-y8QnCxSFDBc11oQtjEPOQbEdjbnW7OCh8s=.8c4cf2e9-c35e-4a32-a54c-989d47f76ed0@github.com>
Message-ID: <55ZNjLWzmvlo5e-eH1VKn_xBlfnRbPCKmgqydQn5qss=.813a0710-8cd8-4e92-a585-9f2b455bd798@github.com>

On Tue, 8 Jun 2021 16:21:34 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> It is not obvious to me that the caller of next_line will handle the fact that we have hit EOF?
>
> In my case,  it happened in the container environment.
> the /proc filesystem of the container is provided by  lxcfs, but a lxcfs bug may make the /proc/stat mount point change, then  the file descriptor is different and fgetc function returns an EOF on error,  But c != '\n' is true and it leads to the  infinit loop.
> Below are our flamegraph in the production , it happends on serveral frameworks?micrometer, elasticsearch..?which use the api "sun/management/OperatingSystemImpl.getSystemCpuLoad"
> ![107140246-bb490f80-695b-11eb-9f62-0116079f4f4a](https://user-images.githubusercontent.com/1964054/121218982-d5690f00-c8b5-11eb-8c1e-e39f2f2bc6a5.jpg)

I use  top -Hp $PID command and the thread show 100% cpu usage
![top](https://user-images.githubusercontent.com/1964054/121224786-7ad2b180-c8bb-11eb-8c1b-e32b131d4327.png)
![jtack](https://user-images.githubusercontent.com/1964054/121224813-81612900-c8bb-11eb-80e1-29d15989dc17.png)

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

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

From lzang at openjdk.java.net  Tue Jun  8 16:48:28 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 8 Jun 2021 16:48:28 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v14]
In-Reply-To: <pew__FWJ2yL8cHc4dBGF8RBNk8AQbIHpnjOi7z4Ishk=.750d707c-3109-4ab9-be73-8889066b2a05@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <pew__FWJ2yL8cHc4dBGF8RBNk8AQbIHpnjOi7z4Ishk=.750d707c-3109-4ab9-be73-8889066b2a05@github.com>
Message-ID: <0rAmf0Pt5wFeq9Ua0fqOvtSrq4F79P3TF8pLTqBBxp8=.b92bed72-4ff8-4c04-ad5f-402cc9147c74@github.com>

On Mon, 7 Jun 2021 08:01:54 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 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into sadump-fix
>  - Merge branch 'master' into sadump-fix
>  - 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'
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/a7c4cba0...a87793c3

Dear All, 
         May I ask your help to review this bug fix? IMHO it is better if JDK17 could have it. Thanks!
BRs,
Lin

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

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

From amenkov at openjdk.java.net  Tue Jun  8 17:08:19 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 8 Jun 2021 17:08:19 GMT
Subject: Integrated: 8237388: serviceability/dcmd/framework/VMVersionTest.java
 fails with connection refused error.
In-Reply-To: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
References: <J3x7RsMzO3XDoYpt8TMKPy5Glig7Cb1nN7P0tzEfZ-8=.949e4afc-b9f3-4a1b-9207-0965d0fb8884@github.com>
Message-ID: <w3aZSoInes9znjQzZUO-5jbG3NJ6TQ5lSbvStgEknJA=.43f91095-fca8-4b49-8668-c1cfa2cfc51b@github.com>

On Thu, 27 May 2021 23:00:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: b568e879
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b568e87947a5d7f1d8c20e3e8a8b2b7f77265c8b
Stats:     143 lines in 5 files changed: 74 ins; 51 del; 18 mod

8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error.

Reviewed-by: cjplummer, sspitsyn

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

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

From dcubed at openjdk.java.net  Tue Jun  8 17:17:37 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 8 Jun 2021 17:17:37 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v3]
In-Reply-To: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
Message-ID: <_fTXjBTs6jP2nqPEZHBihukp3zoGo76YRmry-wqufME=.87e63cf6-fc75-482b-803f-cbd65cabcf3d@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 tested via Mach5 Tier[134567].
> They have also been test by my Stress Kit runs for jdk-17+2[0-5].

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

  ProblemList vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java until 8264605 is fixed and vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java until 8266593 is fixed.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4237/files
  - new: https://git.openjdk.java.net/jdk/pull/4237/files/2ab79a2c..5c2633dd

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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 iris at openjdk.java.net  Tue Jun  8 17:37:16 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 8 Jun 2021 17:37:16 GMT
Subject: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v2]
In-Reply-To: <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
 <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
Message-ID: <YieOrrF2dvlxz2SB3KhPhHW4Bx4HpT4h9uqDc3fbnSQ=.3dded29c-7ad0-4cd7-a45e-3a19ab0b7a9c@github.com>

On Tue, 8 Jun 2021 02:02:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
>> 
>> We need to replace this sentence:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0 and have been superseded by more powerful and flexible
>> versions which:"
>> with:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0. They are deprecated and will be changed to return an error
>> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
>> 
>> The CSR has been approved:
>>   https://bugs.openjdk.java.net/browse/JDK-8268242
>> 
>> The JVM TI Heap functions reflect the requirements of tool vendors during JSR-163. They pre-date concurrent collectors, the built-in heap dump support, and JFR. They are a maintenance burden and there is little evidence that they are used by modern tools (they involve stop-the-world operations and so are not suitable for production systems).
>> 
>> The JVM TI functions to deprecate are:
>>     IterateOverObjectsReachableFromObject
>>     IterateOverReachableObjects
>>     IterateOverHeap
>>     IterateOverInstancesOfClass
>> 
>> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to say that the functions have been superseded. The proposal is to change this to say that the functions are deprecated and will be degraded in a future release.
>> A release note is planned. The release note will detail how to use -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of these functions.
>> 
>> A future CSR will likely degrade these functions so that they return an error to indicate that they are no longer implemented/supported. We also plan to re-examine the newer Heap functions with a view to deprecate them in the future too (this requires a bit more work to understand if there is any real usage, also some adjustments to the JDWP and JDI specs).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed a space in Java SE6

Marked as reviewed by iris (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Tue Jun  8 18:26:33 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 8 Jun 2021 18:26:33 GMT
Subject: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v3]
In-Reply-To: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
Message-ID: <jX7xGkugMOCMrAqZg_vTp3Qmrv8rpfISl5MJtIH0gjc=.aaea80c6-d841-4be7-b649-726e4b576cae@github.com>

> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
> 
> We need to replace this sentence:
> "These functions and data types were introduced in the original JVM TI
> version 1.0 and have been superseded by more powerful and flexible
> versions which:"
> with:
> "These functions and data types were introduced in the original JVM TI
> version 1.0. They are deprecated and will be changed to return an error
> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
> 
> The CSR has been approved:
>   https://bugs.openjdk.java.net/browse/JDK-8268242
> 
> The JVM TI Heap functions reflect the requirements of tool vendors during JSR-163. They pre-date concurrent collectors, the built-in heap dump support, and JFR. They are a maintenance burden and there is little evidence that they are used by modern tools (they involve stop-the-world operations and so are not suitable for production systems).
> 
> The JVM TI functions to deprecate are:
>     IterateOverObjectsReachableFromObject
>     IterateOverReachableObjects
>     IterateOverHeap
>     IterateOverInstancesOfClass
> 
> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to say that the functions have been superseded. The proposal is to change this to say that the functions are deprecated and will be degraded in a future release.
> A release note is planned. The release note will detail how to use -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of these functions.
> 
> A future CSR will likely degrade these functions so that they return an error to indicate that they are no longer implemented/supported. We also plan to re-examine the newer Heap functions with a view to deprecate them in the future too (this requires a bit more work to understand if there is any real usage, also some adjustments to the JDWP and JDI specs).

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

  list deprecation of Heap functions 1.0 at end of jvmti.xml

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4406/files
  - new: https://git.openjdk.java.net/jdk/pull/4406/files/2cd78dfd..cb17aea4

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

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

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

From sspitsyn at openjdk.java.net  Tue Jun  8 18:26:34 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 8 Jun 2021 18:26:34 GMT
Subject: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v2]
In-Reply-To: <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
 <3SBlV8InVXMyz_d5LbkX_UeVnx-611K2Nx9cvI4ovBw=.77095387-c268-432b-8960-40f2bcccad67@github.com>
Message-ID: <osHa04PMWUIJGUZgnbfFygAQnvg0goySLies5ROI7W4=.9e29e937-3d6e-4ac2-9d0d-be8090048ce0@github.com>

On Tue, 8 Jun 2021 02:02:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
>> 
>> We need to replace this sentence:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0 and have been superseded by more powerful and flexible
>> versions which:"
>> with:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0. They are deprecated and will be changed to return an error
>> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
>> 
>> The CSR has been approved:
>>   https://bugs.openjdk.java.net/browse/JDK-8268242
>> 
>> The JVM TI Heap functions reflect the requirements of tool vendors during JSR-163. They pre-date concurrent collectors, the built-in heap dump support, and JFR. They are a maintenance burden and there is little evidence that they are used by modern tools (they involve stop-the-world operations and so are not suitable for production systems).
>> 
>> The JVM TI functions to deprecate are:
>>     IterateOverObjectsReachableFromObject
>>     IterateOverReachableObjects
>>     IterateOverHeap
>>     IterateOverInstancesOfClass
>> 
>> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to say that the functions have been superseded. The proposal is to change this to say that the functions are deprecated and will be degraded in a future release.
>> A release note is planned. The release note will detail how to use -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of these functions.
>> 
>> A future CSR will likely degrade these functions so that they return an error to indicate that they are no longer implemented/supported. We also plan to re-examine the newer Heap functions with a view to deprecate them in the future too (this requires a bit more work to understand if there is any real usage, also some adjustments to the JDWP and JDI specs).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed a space in Java SE6

Thanks, Alan and Iris for review and approval!

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

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

From kevinw at openjdk.java.net  Tue Jun  8 18:50:25 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 8 Jun 2021 18:50:25 GMT
Subject: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v3]
In-Reply-To: <jX7xGkugMOCMrAqZg_vTp3Qmrv8rpfISl5MJtIH0gjc=.aaea80c6-d841-4be7-b649-726e4b576cae@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
 <jX7xGkugMOCMrAqZg_vTp3Qmrv8rpfISl5MJtIH0gjc=.aaea80c6-d841-4be7-b649-726e4b576cae@github.com>
Message-ID: <hrqGmBlvpx4DH6tbmGuju9-QxWe700ZqfpvJm1FsUNw=.93287e75-9f2a-41fb-8aff-03f9212ad818@github.com>

On Tue, 8 Jun 2021 18:26:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
>> 
>> We need to replace this sentence:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0 and have been superseded by more powerful and flexible
>> versions which:"
>> with:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0. They are deprecated and will be changed to return an error
>> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
>> 
>> The CSR has been approved:
>>   https://bugs.openjdk.java.net/browse/JDK-8268242
>> 
>> The JVM TI Heap functions reflect the requirements of tool vendors during JSR-163. They pre-date concurrent collectors, the built-in heap dump support, and JFR. They are a maintenance burden and there is little evidence that they are used by modern tools (they involve stop-the-world operations and so are not suitable for production systems).
>> 
>> The JVM TI functions to deprecate are:
>>     IterateOverObjectsReachableFromObject
>>     IterateOverReachableObjects
>>     IterateOverHeap
>>     IterateOverInstancesOfClass
>> 
>> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to say that the functions have been superseded. The proposal is to change this to say that the functions are deprecated and will be degraded in a future release.
>> A release note is planned. The release note will detail how to use -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of these functions.
>> 
>> A future CSR will likely degrade these functions so that they return an error to indicate that they are no longer implemented/supported. We also plan to re-examine the newer Heap functions with a view to deprecate them in the future too (this requires a bit more work to understand if there is any real usage, also some adjustments to the JDWP and JDI specs).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   list deprecation of Heap functions 1.0 at end of jvmti.xml

Marked as reviewed by kevinw (Committer).

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

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

From kevinw at openjdk.java.net  Tue Jun  8 20:51:27 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 8 Jun 2021 20:51:27 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary
Message-ID: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>

Since 8214300, jcmd cannot attach to a Java process in a docker container.

That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.

To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.

For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.

(Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)

Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.

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

Commit messages:
 - AIX implementation.
 - (C) update
 - 8228343: JCMD and attach fail to work across Linux Container boundary

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

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

From sspitsyn at openjdk.java.net  Tue Jun  8 21:16:13 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 8 Jun 2021 21:16:13 GMT
Subject: RFR: 8268241: deprecate JVM TI Heap functions 1.0 [v3]
In-Reply-To: <jX7xGkugMOCMrAqZg_vTp3Qmrv8rpfISl5MJtIH0gjc=.aaea80c6-d841-4be7-b649-726e4b576cae@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
 <jX7xGkugMOCMrAqZg_vTp3Qmrv8rpfISl5MJtIH0gjc=.aaea80c6-d841-4be7-b649-726e4b576cae@github.com>
Message-ID: <67-iCTtgNorZkd-BTgy9Mnwf3YXs86uo9ZL0F4fXI_E=.77ea2214-ebfa-43c6-b9a0-4e6cec24df80@github.com>

On Tue, 8 Jun 2021 18:26:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
>> 
>> We need to replace this sentence:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0 and have been superseded by more powerful and flexible
>> versions which:"
>> with:
>> "These functions and data types were introduced in the original JVM TI
>> version 1.0. They are deprecated and will be changed to return an error
>> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
>> 
>> The CSR has been approved:
>>   https://bugs.openjdk.java.net/browse/JDK-8268242
>> 
>> The JVM TI Heap functions reflect the requirements of tool vendors during JSR-163. They pre-date concurrent collectors, the built-in heap dump support, and JFR. They are a maintenance burden and there is little evidence that they are used by modern tools (they involve stop-the-world operations and so are not suitable for production systems).
>> 
>> The JVM TI functions to deprecate are:
>>     IterateOverObjectsReachableFromObject
>>     IterateOverReachableObjects
>>     IterateOverHeap
>>     IterateOverInstancesOfClass
>> 
>> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to say that the functions have been superseded. The proposal is to change this to say that the functions are deprecated and will be degraded in a future release.
>> A release note is planned. The release note will detail how to use -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of these functions.
>> 
>> A future CSR will likely degrade these functions so that they return an error to indicate that they are no longer implemented/supported. We also plan to re-examine the newer Heap functions with a view to deprecate them in the future too (this requires a bit more work to understand if there is any real usage, also some adjustments to the JDWP and JDI specs).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   list deprecation of Heap functions 1.0 at end of jvmti.xml

Thanks, Kevin, for review, suggestion and approval!

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

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

From cjplummer at openjdk.java.net  Wed Jun  9 00:45:14 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 9 Jun 2021 00:45:14 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL [v2]
In-Reply-To: <Y-S3SRpODKhdf3dIxsj7Y4oMQAr9qF9odk9VXuXs8fI=.e28ab343-8e1f-404f-a057-231cdf3b9179@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
 <Y-S3SRpODKhdf3dIxsj7Y4oMQAr9qF9odk9VXuXs8fI=.e28ab343-8e1f-404f-a057-231cdf3b9179@github.com>
Message-ID: <gplQTjpJO2lPyFKAjIz5d-CghEO1AtIGpxSo-zQ_30U=.f9a6e5c4-c871-4818-931a-a73e5ac35cff@github.com>

On Mon, 7 Jun 2021 21:49:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.
>> 
>> BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix type from last commit
>  - Use URL for users guide instead of command reference

Thanks Mandy!

Can I get one more review please?

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

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

From dholmes at openjdk.java.net  Wed Jun  9 01:15:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Jun 2021 01:15:16 GMT
Subject: RFR: 8263203: jconsole Online User Guide has wrong URL [v2]
In-Reply-To: <Y-S3SRpODKhdf3dIxsj7Y4oMQAr9qF9odk9VXuXs8fI=.e28ab343-8e1f-404f-a057-231cdf3b9179@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
 <Y-S3SRpODKhdf3dIxsj7Y4oMQAr9qF9odk9VXuXs8fI=.e28ab343-8e1f-404f-a057-231cdf3b9179@github.com>
Message-ID: <Y5qWeAR5pJUlVLNybaTtdBtSxblH-0jITAMy8KZvA4s=.7c31ff39-41f9-4fc1-9fa5-9cf508fc62e2@github.com>

On Mon, 7 Jun 2021 21:49:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.
>> 
>> BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix type from last commit
>  - Use URL for users guide instead of command reference

LGTM!

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From mseledtsov at openjdk.java.net  Wed Jun  9 01:18:12 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 9 Jun 2021 01:18:12 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary
In-Reply-To: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
Message-ID: <5k3Ebuk5rpoM-1gWcJYxcInBk4HOv54nDnKYkIiSyGo=.f02d7715-08c0-428d-a945-7ae8c97f449b@github.com>

On Tue, 8 Jun 2021 20:44:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Since 8214300, jcmd cannot attach to a Java process in a docker container.
> 
> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
> 
> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
> 
> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
> 
> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
> 
> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.

I have verified the fix on Linux-x64 (OL 7.9). It works now. Thank you for fixing this.

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

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

From dholmes at openjdk.java.net  Wed Jun  9 01:55:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Jun 2021 01:55:16 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v3]
In-Reply-To: <_fTXjBTs6jP2nqPEZHBihukp3zoGo76YRmry-wqufME=.87e63cf6-fc75-482b-803f-cbd65cabcf3d@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <_fTXjBTs6jP2nqPEZHBihukp3zoGo76YRmry-wqufME=.87e63cf6-fc75-482b-803f-cbd65cabcf3d@github.com>
Message-ID: <9XZwKF1ewPtfgMAoVxuetYqllxp_hJmjhoQRnTR_dxQ=.db6b1c69-7753-4b38-96b8-22d1250940e3@github.com>

On Tue, 8 Jun 2021 17:17:37 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-5].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ProblemList vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java until 8264605 is fixed and vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java until 8266593 is fixed.

Hi Dan,

This all seems okay. Sorry it took so long to get to it.

Note: All the usage() calls are indented incorrectly.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From dholmes at openjdk.java.net  Wed Jun  9 01:55:17 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Jun 2021 01:55:17 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v3]
In-Reply-To: <KUaHMvSSDqarKQtc0buxns-LjQlWiC9XZhbXwh0ebKo=.2fd9fa98-8ca2-4f12-a5f1-0dc7902ecfbd@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <b-aPATN6uTCK5ao4QpuoC9exKasKuZaMZY6M5QEpn-U=.7aa57675-5fad-4b39-aa93-40de1cf97ca5@github.com>
 <WdrljZsOmY0L-9_MaCB1mpQ_lR2rIOJe6oTCfnlpIVQ=.cb780d0f-fb89-4eca-a6aa-d009d0dc3d34@github.com>
 <KUaHMvSSDqarKQtc0buxns-LjQlWiC9XZhbXwh0ebKo=.2fd9fa98-8ca2-4f12-a5f1-0dc7902ecfbd@github.com>
Message-ID: <Y0IZ8vUVUjvB6zUZTDEuyLcq_1-8OVBVrdgSMJeNTkM=.e79ab9fc-9732-44d1-84a2-a4be19e958e9@github.com>

On Mon, 7 Jun 2021 23:50:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp line 102:
>> 
>>> 100:         /*
>>> 101:          * Using printf() instead of NSK_DISPLAY1() in this loop
>>> 102:          * in order to slow down the rate of SuspendThread() calls.
>> 
>> I don't understand the reason for wanting to slow down the rate, nor your reason for removing it.
>
> I couldn't remember why I did that when I wrote the test so
> I removed it.

Maybe to allow the resume to get the thread back into real code before the next suspend hits?

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

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

From sspitsyn at openjdk.java.net  Wed Jun  9 05:42:18 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 9 Jun 2021 05:42:18 GMT
Subject: Integrated: 8268241: deprecate JVM TI Heap functions 1.0
In-Reply-To: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
References: <k1XrldU2i4y_k2hd8k4npYJuPVHKv4yMhUw55RNB8Xo=.eb0052fe-6727-493f-af37-cb8d966f563f@github.com>
Message-ID: <XFy-52-kjABzMxvlKwkzJrQVukgBp3Py_vDNwAzmW0U=.f03ef0c4-3161-4a8b-96eb-d3dc8e4b6dec@github.com>

On Tue, 8 Jun 2021 01:39:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVM TI Heap functions 1.0 were superseded by newer functions in JVM TI 1.2 (Java 6) and should be deprecated so they can be removed in a future release.
> 
> We need to replace this sentence:
> "These functions and data types were introduced in the original JVM TI
> version 1.0 and have been superseded by more powerful and flexible
> versions which:"
> with:
> "These functions and data types were introduced in the original JVM TI
> version 1.0. They are deprecated and will be changed to return an error
> in a future release. They were superseded in JVM TI version 1.2 (Java 6) by more powerful and flexible versions which:" 
> 
> The CSR has been approved:
>   https://bugs.openjdk.java.net/browse/JDK-8268242
> 
> The JVM TI Heap functions reflect the requirements of tool vendors during JSR-163. They pre-date concurrent collectors, the built-in heap dump support, and JFR. They are a maintenance burden and there is little evidence that they are used by modern tools (they involve stop-the-world operations and so are not suitable for production systems).
> 
> The JVM TI functions to deprecate are:
>     IterateOverObjectsReachableFromObject
>     IterateOverReachableObjects
>     IterateOverHeap
>     IterateOverInstancesOfClass
> 
> The "Heap 1.0" section of the JVM TI spec has existing wording in bold to say that the functions have been superseded. The proposal is to change this to say that the functions are deprecated and will be degraded in a future release.
> A release note is planned. The release note will detail how to use -Xlog:jvmti=trace and -XX:TraceJVMTI= to identify any residual usages of these functions.
> 
> A future CSR will likely degrade these functions so that they return an error to indicate that they are no longer implemented/supported. We also plan to re-examine the newer Heap functions with a view to deprecate them in the future too (this requires a bit more work to understand if there is any real usage, also some adjustments to the JDWP and JDI specs).

This pull request has now been integrated.

Changeset: 07108c91
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/07108c916263896fa6c5dbacfedf5b4c2f5bf97a
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8268241: deprecate JVM TI Heap functions 1.0

Reviewed-by: alanb, iris, kevinw

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

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

From sgehwolf at openjdk.java.net  Wed Jun  9 07:32:15 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 9 Jun 2021 07:32:15 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v2]
In-Reply-To: <55ZNjLWzmvlo5e-eH1VKn_xBlfnRbPCKmgqydQn5qss=.813a0710-8cd8-4e92-a585-9f2b455bd798@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
 <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>
 <MEo4khAi-y8QnCxSFDBc11oQtjEPOQbEdjbnW7OCh8s=.8c4cf2e9-c35e-4a32-a54c-989d47f76ed0@github.com>
 <55ZNjLWzmvlo5e-eH1VKn_xBlfnRbPCKmgqydQn5qss=.813a0710-8cd8-4e92-a585-9f2b455bd798@github.com>
Message-ID: <7mLfV22GjOXUNdaFPt1fflgzLBN8rtD_7073Is9v_-k=.8ad5ecf6-088e-4539-9448-0aa390f125af@github.com>

On Tue, 8 Jun 2021 16:43:14 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> In my case,  it happened in the container environment.
>> the /proc filesystem of the container is provided by  lxcfs, but a lxcfs bug may make the /proc/stat mount point change, then  the file descriptor is different and fgetc function returns an EOF on error,  But c != '\n' is true and it leads to the  infinit loop.
>> Below are our flamegraph in the production , it happends on serveral frameworks?micrometer, elasticsearch..?which use the api "sun/management/OperatingSystemImpl.getSystemCpuLoad"
>> ![107140246-bb490f80-695b-11eb-9f62-0116079f4f4a](https://user-images.githubusercontent.com/1964054/121218982-d5690f00-c8b5-11eb-8c1e-e39f2f2bc6a5.jpg)
>
> I use  top -Hp $PID command and the thread show 100% cpu usage
> ![top](https://user-images.githubusercontent.com/1964054/121224786-7ad2b180-c8bb-11eb-8c1b-e32b131d4327.png)
> ![jtack](https://user-images.githubusercontent.com/1964054/121224813-81612900-c8bb-11eb-80e1-29d15989dc17.png)

@UncleNine We should handle the case in the `get_totalticks()` function - which seems to be the only user of `next_line()` - when `next_line()` returns EOF as David said. One way would be to return the 'c' character read in `next_line` and if it's EOF, return -2 in `get_totalticks()`.

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

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

From kevinw at openjdk.java.net  Wed Jun  9 09:18:18 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 9 Jun 2021 09:18:18 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary
In-Reply-To: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
Message-ID: <kWuD1iTPSxGJvX6oNv8vm0AJyXqMjYOfQ4fS5Sk6NTc=.0514a2ae-58e0-4f53-8a0b-146dd16572d6@github.com>

On Tue, 8 Jun 2021 20:44:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Since 8214300, jcmd cannot attach to a Java process in a docker container.
> 
> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
> 
> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
> 
> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
> 
> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
> 
> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.

Thanks Mikhailo for verifying.

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

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

From ysuenaga at openjdk.java.net  Wed Jun  9 10:00:17 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 9 Jun 2021 10:00:17 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary
In-Reply-To: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
Message-ID: <uzJ2dIdiBSID7wrVBk5RyKgYBkqTT9Fzih8zhEa-I-c=.4af31a60-c441-445f-9662-35fe405b4c41@github.com>

On Tue, 8 Jun 2021 20:44:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Since 8214300, jcmd cannot attach to a Java process in a docker container.
> 
> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
> 
> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
> 
> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
> 
> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
> 
> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.

Can we use `/proc/<PID>/root`? According to [manpage](https://man7.org/linux/man-pages/man5/proc.5.html), I think we can access `/` in the container for sure.
This directory is used in `findSocketFile()`.
If it can't be used, you might have to change it too.

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

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

From kevinw at openjdk.java.net  Wed Jun  9 10:24:12 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 9 Jun 2021 10:24:12 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary
In-Reply-To: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
Message-ID: <MCrVoMI26yWEMubOBTCixokvcQRnspqZXcdD6DGJOBA=.0e45ef9f-a1ad-41e6-9c2a-2c886021c52c@github.com>

On Tue, 8 Jun 2021 20:44:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Since 8214300, jcmd cannot attach to a Java process in a docker container.
> 
> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
> 
> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
> 
> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
> 
> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
> 
> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.

Thanks Yasumasa --

> Can we use /proc/<PID>/root? 

root is also a symlink, like cwd, so we can't resolve its canonical location (literally "/") and put a file there, or if our target is in a container it won't see it.  So the problem is not that we can't access /proc/PID/cwd/ but it's that if using the canonical filename, jcmd and its target will resolve them differently.

Maybe it is interesting that we don't use cwd for the socket file, but it's not something I would want to start changing at this time... 8-)

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

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

From kevinw at openjdk.java.net  Wed Jun  9 10:35:12 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 9 Jun 2021 10:35:12 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary
In-Reply-To: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
Message-ID: <AmocR3E1x3vXfA0tyS34bviPIaZ4tihnX-zxk1BWsZM=.2470792d-7f9e-44b1-8d87-59c7b8b35fd2@github.com>

On Tue, 8 Jun 2021 20:44:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Since 8214300, jcmd cannot attach to a Java process in a docker container.
> 
> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
> 
> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
> 
> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
> 
> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
> 
> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.

I do see the manpage section about root, saying "this file is not merely a symbolic link", but it does behave like a regular symlink for me...   Using File getCanonicalFile() on it returns me a literal "/" root directory File.

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

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

From ysuenaga at openjdk.java.net  Wed Jun  9 12:45:13 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 9 Jun 2021 12:45:13 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary
In-Reply-To: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
Message-ID: <EWcSqVE-WpvWFyLEMMSCqENPgw0rHXVkv0UVncqwLUQ=.752d808f-ed32-4d09-825a-47f4151fbf20@github.com>

On Tue, 8 Jun 2021 20:44:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Since 8214300, jcmd cannot attach to a Java process in a docker container.
> 
> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
> 
> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
> 
> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
> 
> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
> 
> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.

Thanks @kevinjwalls ! I thought we can get real location from `/proc/<PID>/root`, however it do not so. I confirmed it on podman. (podman uses overlayfs, and I couldn't find an easy way to access it directly.

Your change almost looks good, but I have only one comment.

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 81:

> 79:             File f = createAttachFile(pid, ns_pid);
> 80:             // Keep a canonical version of File, to delete, in case target process ends and /proc link has gone:
> 81:             File f2 = f.getCanonicalFile();

Do we need to keep `f`? I think we can replace them to `createAttachFile(pid, ns_pid).getCanonicalFile()`.

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

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

From kevinw at openjdk.java.net  Wed Jun  9 13:03:32 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 9 Jun 2021 13:03:32 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary [v2]
In-Reply-To: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
Message-ID: <82ymMBdDKBdtAbC5hyt_BJRfnnotnndsWEnhWJLYsQA=.3c622108-c2f7-43dd-a1f8-b16715efc27d@github.com>

> Since 8214300, jcmd cannot attach to a Java process in a docker container.
> 
> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
> 
> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
> 
> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
> 
> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
> 
> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.

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

  One less File reference.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4418/files
  - new: https://git.openjdk.java.net/jdk/pull/4418/files/b3d76d54..6c023f6f

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

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

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

From kevinw at openjdk.java.net  Wed Jun  9 13:03:34 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 9 Jun 2021 13:03:34 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary [v2]
In-Reply-To: <EWcSqVE-WpvWFyLEMMSCqENPgw0rHXVkv0UVncqwLUQ=.752d808f-ed32-4d09-825a-47f4151fbf20@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
 <EWcSqVE-WpvWFyLEMMSCqENPgw0rHXVkv0UVncqwLUQ=.752d808f-ed32-4d09-825a-47f4151fbf20@github.com>
Message-ID: <dPdUAuF2syIZQgtmTLSWdoXJ4taikxKfWu_Qlzjodgg=.d837f9a7-ac1d-401b-8fef-d108d4e35e5d@github.com>

On Wed, 9 Jun 2021 12:37:19 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   One less File reference.
>
> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 81:
> 
>> 79:             File f = createAttachFile(pid, ns_pid);
>> 80:             // Keep a canonical version of File, to delete, in case target process ends and /proc link has gone:
>> 81:             File f2 = f.getCanonicalFile();
> 
> Do we need to keep `f`? I think we can replace them to `createAttachFile(pid, ns_pid).getCanonicalFile()`.

That's true, we don't really need them both.

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

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

From ysuenaga at openjdk.java.net  Wed Jun  9 13:21:15 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 9 Jun 2021 13:21:15 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary [v2]
In-Reply-To: <82ymMBdDKBdtAbC5hyt_BJRfnnotnndsWEnhWJLYsQA=.3c622108-c2f7-43dd-a1f8-b16715efc27d@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
 <82ymMBdDKBdtAbC5hyt_BJRfnnotnndsWEnhWJLYsQA=.3c622108-c2f7-43dd-a1f8-b16715efc27d@github.com>
Message-ID: <p3rvfsweNa7ApgXRH3jB5mKz1akfl_oQgmEcHLUEoKs=.718493a0-383c-455b-8ce9-5a4eec07ae9f@github.com>

On Wed, 9 Jun 2021 13:03:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Since 8214300, jcmd cannot attach to a Java process in a docker container.
>> 
>> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
>> 
>> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
>> 
>> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
>> 
>> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
>> 
>> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One less File reference.

Marked as reviewed by ysuenaga (Reviewer).

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

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

From kevinw at openjdk.java.net  Wed Jun  9 13:21:16 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 9 Jun 2021 13:21:16 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary [v2]
In-Reply-To: <dPdUAuF2syIZQgtmTLSWdoXJ4taikxKfWu_Qlzjodgg=.d837f9a7-ac1d-401b-8fef-d108d4e35e5d@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
 <EWcSqVE-WpvWFyLEMMSCqENPgw0rHXVkv0UVncqwLUQ=.752d808f-ed32-4d09-825a-47f4151fbf20@github.com>
 <dPdUAuF2syIZQgtmTLSWdoXJ4taikxKfWu_Qlzjodgg=.d837f9a7-ac1d-401b-8fef-d108d4e35e5d@github.com>
Message-ID: <2le_APUgtkJSOhNf5ZRxyRoSpALzUJPbQuvN-k1GRi0=.7e445918-4b90-431e-9811-9f771e50b37e@github.com>

On Wed, 9 Jun 2021 13:00:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 81:
>> 
>>> 79:             File f = createAttachFile(pid, ns_pid);
>>> 80:             // Keep a canonical version of File, to delete, in case target process ends and /proc link has gone:
>>> 81:             File f2 = f.getCanonicalFile();
>> 
>> Do we need to keep `f`? I think we can replace them to `createAttachFile(pid, ns_pid).getCanonicalFile()`.
>
> That's true, we don't really need them both.

Builds and tests OK, thanks.

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

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

From ysuenaga at openjdk.java.net  Wed Jun  9 14:04:13 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 9 Jun 2021 14:04:13 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary [v2]
In-Reply-To: <82ymMBdDKBdtAbC5hyt_BJRfnnotnndsWEnhWJLYsQA=.3c622108-c2f7-43dd-a1f8-b16715efc27d@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
 <82ymMBdDKBdtAbC5hyt_BJRfnnotnndsWEnhWJLYsQA=.3c622108-c2f7-43dd-a1f8-b16715efc27d@github.com>
Message-ID: <a6oRTbB7jAQOKt-eVriZXFblZuJ9p8XRQO0oj0UnUVw=.89c33e54-1ff5-4ef6-abe5-e1f0fa98e9c1@github.com>

On Wed, 9 Jun 2021 13:03:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Since 8214300, jcmd cannot attach to a Java process in a docker container.
>> 
>> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
>> 
>> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
>> 
>> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
>> 
>> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
>> 
>> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One less File reference.

I hope this change happens in 17.

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

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

From github.com+1964054+unclenine at openjdk.java.net  Wed Jun  9 14:09:37 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Wed, 9 Jun 2021 14:09:37 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v3]
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <FUbtXALUOytoD_DmDcmIp77KP60JDs4xQCAUi8nxbQw=.8d0f3842-0f48-4066-8492-44a5a093141a@github.com>

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

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

  8268361: Fix the infinite loop in next_line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4378/files
  - new: https://git.openjdk.java.net/jdk/pull/4378/files/c055e977..3d50b052

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

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

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

From github.com+1964054+unclenine at openjdk.java.net  Wed Jun  9 14:45:36 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Wed, 9 Jun 2021 14:45:36 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v4]
In-Reply-To: <7mLfV22GjOXUNdaFPt1fflgzLBN8rtD_7073Is9v_-k=.8ad5ecf6-088e-4539-9448-0aa390f125af@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
 <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>
 <MEo4khAi-y8QnCxSFDBc11oQtjEPOQbEdjbnW7OCh8s=.8c4cf2e9-c35e-4a32-a54c-989d47f76ed0@github.com>
 <55ZNjLWzmvlo5e-eH1VKn_xBlfnRbPCKmgqydQn5qss=.813a0710-8cd8-4e92-a585-9f2b455bd798@github.com>
 <7mLfV22GjOXUNdaFPt1fflgzLBN8rtD_7073Is9v_-k=.8ad5ecf6-088e-4539-9448-0aa390f125af@github.com>
Message-ID: <-s5oeOAXyHEVZoWYK2aNwMzbH8LmM2TFT1xEC2B6zV0=.8a15d421-58e6-4f29-91c0-31f5e2ca6ad2@github.com>

On Wed, 9 Jun 2021 07:29:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I use  top -Hp $PID command and the thread show 100% cpu usage
>> ![top](https://user-images.githubusercontent.com/1964054/121224786-7ad2b180-c8bb-11eb-8c1b-e32b131d4327.png)
>> ![jtack](https://user-images.githubusercontent.com/1964054/121224813-81612900-c8bb-11eb-80e1-29d15989dc17.png)
>
> @UncleNine We should handle the case in the `get_totalticks()` function - which seems to be the only user of `next_line()` - when `next_line()` returns EOF as David said. One way would be to return the 'c' character read in `next_line` and if it's EOF, return -2 in `get_totalticks()`.

all right, i have updated the code

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

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

From github.com+1964054+unclenine at openjdk.java.net  Wed Jun  9 14:45:35 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Wed, 9 Jun 2021 14:45:35 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v4]
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

UncleNine 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:

  8268361: Fix the infinite loop in next_line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4378/files
  - new: https://git.openjdk.java.net/jdk/pull/4378/files/3d50b052..e4f90ebd

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

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

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

From luhenry at openjdk.java.net  Wed Jun  9 17:25:52 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Wed, 9 Jun 2021 17:25:52 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java stacks
Message-ID: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>

When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.

The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.

# `Prof1`

public class Prof1 {

    public static void main(String[] args) {
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < 1000000; i++) {
            sb.append("ab");
            sb.delete(0, 1);
        }
        System.out.println(sb.length());
    }
}


- Baseline:

Flat Profile (by method):
        (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
        (t  0.5,s  0.2) Prof1::main
        (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
        (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
        (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
        (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
        (t  0.0,s  0.0) java.lang.String::getBytes
        (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
        (t  0.0,s  0.0) java.lang.StringBuilder::delete
        (t  0.2,s  0.0) java.lang.StringBuilder::append
        (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
        (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt

- With `StubRoutinesBlob::FrameParser`:

Flat Profile (by method):
        (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
        (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
        (t 99.8,s  0.2) Prof1::main
        (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
        (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
        (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
        (t 98.8,s  0.0) java.lang.StringBuilder::append
        (t  0.9,s  0.0) java.lang.StringBuilder::delete


# `Prof2`

import java.util.function.Supplier;

public class Prof2 {

    public static void main(String[] args) {
        var rand = new java.util.Random(0);
        Supplier[] suppliers = {
                () -> 0,
                () -> 1,
                () -> 2,
                () -> 3,
        };

        long sum = 0;
        for (int i = 0; i >= 0; i++) {
            sum += (int)suppliers[i % suppliers.length].get();
        }
    }
}


- Baseline:

Flat Profile (by method):
        (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
        (t 39.2,s 35.2) Prof2::main
        (t  1.4,s  1.4) Prof2::lambda$main$3
        (t  1.0,s  1.0) Prof2::lambda$main$2
        (t  0.9,s  0.9) Prof2::lambda$main$1
        (t  0.7,s  0.7) Prof2::lambda$main$0
        (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
        (t  0.0,s  0.0) java.lang.Thread::exit
        (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
        (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
        (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
        (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get


- With `VtableBlob::FrameParser` and `nmethod::FrameParser`:

Flat Profile (by method):
        (t 74.1,s 70.3) Prof2::main
        (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
        (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
        (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
        (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
        (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
        (t  1.2,s  1.2) Prof2::lambda$main$2
        (t  0.9,s  0.9) Prof2::lambda$main$3
        (t  0.9,s  0.9) Prof2::lambda$main$1
        (t  0.7,s  0.7) Prof2::lambda$main$0
        (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]

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

Commit messages:
 - Disable checks in FrameParser when known to be safe
 - Allow AsyncGetCallTrace and JFR to unwind stack from vtable stub
 - Allow AsyncGetCallTrace and JFR to unwind stack from nmethod's prolog
 - JDK-8267985: Allow AsyncGetCallTrace and JFR to walk a stub frame
 - 8268178: Extract sender frame parsing to CodeBlock::FrameParser

Changes: https://git.openjdk.java.net/jdk/pull/4436/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4436&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8178287
  Stats: 1303 lines in 26 files changed: 1057 ins; 166 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4436.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4436/head:pull/4436

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

From sgehwolf at openjdk.java.net  Wed Jun  9 17:38:15 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 9 Jun 2021 17:38:15 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v4]
In-Reply-To: <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
Message-ID: <s_6HegW6p8Bfl0GnqUV2bPcO64rG98pMwVmbbaB45z8=.4b96e863-e5a8-4d5d-bc8e-dd6d87ed8e2e@github.com>

On Wed, 9 Jun 2021 14:45:35 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine 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.

Looks fine to me. Please fix the jcheck (whitespace) issue.

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

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

From sspitsyn at openjdk.java.net  Wed Jun  9 18:36:20 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 9 Jun 2021 18:36:20 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v4]
In-Reply-To: <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
Message-ID: <9XV5_MELiQdZofY1LZqxX1GvxAxa431iclFTH_WqPZk=.a2796991-e01a-4997-9e9c-5532a0a25da5@github.com>

On Wed, 9 Jun 2021 14:45:35 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine 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.

It looks okay to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Wed Jun  9 18:47:19 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 9 Jun 2021 18:47:19 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary [v2]
In-Reply-To: <82ymMBdDKBdtAbC5hyt_BJRfnnotnndsWEnhWJLYsQA=.3c622108-c2f7-43dd-a1f8-b16715efc27d@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
 <82ymMBdDKBdtAbC5hyt_BJRfnnotnndsWEnhWJLYsQA=.3c622108-c2f7-43dd-a1f8-b16715efc27d@github.com>
Message-ID: <czP2sCjEOfRXJ5Hcd5zmHRkhV94gAsY7OG54Iiv3HAw=.972e9b06-788b-458f-8c0b-9d93ef9b8cc8@github.com>

On Wed, 9 Jun 2021 13:03:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Since 8214300, jcmd cannot attach to a Java process in a docker container.
>> 
>> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
>> 
>> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
>> 
>> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
>> 
>> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
>> 
>> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One less File reference.

Hi Kevin,
This looks okay to me.
How do you test it to make sure no regressions are introduced?
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From cjplummer at openjdk.java.net  Wed Jun  9 19:06:18 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 9 Jun 2021 19:06:18 GMT
Subject: Integrated: 8263323: Debug Agent help output includes invalid URL
In-Reply-To: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>
References: <GsofejsOow1iIiomLwb7stiT8bEpCqoAsuVQkmasN8s=.a3573b67-7e14-4110-87cf-ab30210b4897@github.com>
Message-ID: <M9iEllCp6V-GHpv-EKnWN9AOF1AhH2pzGT8gRbxWlRk=.ec3b64b9-a405-4f01-8a46-527fddb4dd5b@github.com>

On Fri, 4 Jun 2021 03:36:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Rather than embed a URL in the help output, which needs to be updated if the location of docs ever changes, just include a description of the document so it can be looked up. The output now looks like:
> 
> 
> $ ./java -agentlib:jdwp=help
>                Java Debugger JDWP Agent Library
>                --------------------------------
> 
>   (See the "Oracle VM Invocation Options" section of the JPDA
>    "Connection and Invocation Details" document for more information.)
> 
> jdwp usage: java -agentlib:jdwp=[help]|[<option>=<value>, ...]
> 
> Option Name and Value            Description                       Default
> ---------------------            -----------                       -------
> suspend=y|n                      wait on startup?                  y
> transport=<name>                 transport spec                    none
> ...

This pull request has now been integrated.

Changeset: 33d34c6b
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/33d34c6b670e83778479a2a11ae23229bf959752
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8263323: Debug Agent help output includes invalid URL

Reviewed-by: kevinw, alanb

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

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

From cjplummer at openjdk.java.net  Wed Jun  9 19:07:18 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 9 Jun 2021 19:07:18 GMT
Subject: Integrated: 8263203: jconsole Online User Guide has wrong URL
In-Reply-To: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
References: <14DyT0smfxR-jDAIEOxENzc7t0cX8oxN6M-zKSPSuao=.ec277636-8e25-40af-8cb4-452869ddb107@github.com>
Message-ID: <IAKMcNxcU9E98-yrPY8HTMOn1QoxVv0E9iE5CvGNhic=.f7c9c8f5-8a4b-4c28-ae69-b986d04e597a@github.com>

On Mon, 7 Jun 2021 19:36:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The URL for the users guide, referenced from both the About dialog and from the "Help -> Online Users Guide" menu item, has not functioned for a few releases due the restructuring of the JDK online docs. This PR fixes the URL. Note I also filed JDK-8268351 to get rid of the URL, but for 17 I prefer to just fix the URL.
> 
> BTW, the change to MANAGE_HOTSPOT_MBEANS_IN_COLON_ is just my editor automatically getting rid of an extra space at the end of the line.

This pull request has now been integrated.

Changeset: bbd0313a
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bbd0313ac12c062f02400342a87c283b7578062a
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

8263203: jconsole Online User Guide has wrong URL

Reviewed-by: mchung, dholmes

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

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

From sspitsyn at openjdk.java.net  Wed Jun  9 19:08:19 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 9 Jun 2021 19:08:19 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks
In-Reply-To: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
Message-ID: <v9lva0LCv61S2vOl-fOiZFzQlYOWDkglILhACCEZ9oM=.ac9e240b-7b7d-4484-a7e1-3c1b6f2a5569@github.com>

On Wed, 9 Jun 2021 17:16:23 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
> 
> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
> 
> # `Prof1`
> 
> public class Prof1 {
> 
>     public static void main(String[] args) {
>         StringBuilder sb = new StringBuilder();
>         for (int i = 0; i < 1000000; i++) {
>             sb.append("ab");
>             sb.delete(0, 1);
>         }
>         System.out.println(sb.length());
>     }
> }
> 
> 
> - Baseline:
> 
> Flat Profile (by method):
>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>         (t  0.5,s  0.2) Prof1::main
>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>         (t  0.0,s  0.0) java.lang.String::getBytes
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
> 
> - With `StubRoutinesBlob::FrameParser`:
> 
> Flat Profile (by method):
>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>         (t 99.8,s  0.2) Prof1::main
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
> 
> 
> # `Prof2`
> 
> import java.util.function.Supplier;
> 
> public class Prof2 {
> 
>     public static void main(String[] args) {
>         var rand = new java.util.Random(0);
>         Supplier[] suppliers = {
>                 () -> 0,
>                 () -> 1,
>                 () -> 2,
>                 () -> 3,
>         };
> 
>         long sum = 0;
>         for (int i = 0; i >= 0; i++) {
>             sum += (int)suppliers[i % suppliers.length].get();
>         }
>     }
> }
> 
> 
> - Baseline:
> 
> Flat Profile (by method):
>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>         (t 39.2,s 35.2) Prof2::main
>         (t  1.4,s  1.4) Prof2::lambda$main$3
>         (t  1.0,s  1.0) Prof2::lambda$main$2
>         (t  0.9,s  0.9) Prof2::lambda$main$1
>         (t  0.7,s  0.7) Prof2::lambda$main$0
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>         (t  0.0,s  0.0) java.lang.Thread::exit
>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
> 
> 
> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
> 
> Flat Profile (by method):
>         (t 74.1,s 70.3) Prof2::main
>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>         (t  1.2,s  1.2) Prof2::lambda$main$2
>         (t  0.9,s  0.9) Prof2::lambda$main$3
>         (t  0.9,s  0.9) Prof2::lambda$main$1
>         (t  0.7,s  0.7) Prof2::lambda$main$0
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]

Hi Ludovic,
Thank you for working on this fix in the AsyncGetCallTrace.
What version of JDK release do you intent to target?
Just wanted to make sure you know the JDK 17 development cycle will be closed tomorrow for P4 bugs and enhancements. The repository will be forked and the RDP 1 phase started.
I doubt the review of your fix will be completed by this time.
So, please, keep in mind your PR will go to 18, not 17.
Thanks,
Serguei

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

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

From cjplummer at openjdk.java.net  Wed Jun  9 19:10:24 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 9 Jun 2021 19:10:24 GMT
Subject: RFR: 8268407: ProblemList sun/tools/jstat/jstatLineCountsX.sh on
 linux-aarch64 due to JDK-8268211
Message-ID: <aSJPEzkzngKw2Qn_nod66gqEXhA71MNqQqWWZIJhwOw=.620aae5b-e694-42bf-b02c-a5a36741b54f@github.com>

8268407: ProblemList sun/tools/jstat/jstatLineCountsX.sh on linux-aarch64 due to JDK-8268211

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

Commit messages:
 - Problemlist jstatLineCounts*.sh tests on linux-aarch64

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

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

From lmesnik at openjdk.java.net  Wed Jun  9 19:18:25 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 9 Jun 2021 19:18:25 GMT
Subject: RFR: 8268223: Problemlist
 vmTestbase/nsk/jdi/HiddenClass/events/events001.java
Message-ID: <ZiuwihWNeilsVSxQHJBoPh989fI2TU3fV12dvSjyqTA=.dfa92023-ecff-4245-9a40-b0c56d5b14b8@github.com>

Exclude vmTestbase/nsk/jdi/HiddenClass/events/events001.java.

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

Commit messages:
 - test excluded

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

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

From kevinw at openjdk.java.net  Wed Jun  9 19:36:14 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 9 Jun 2021 19:36:14 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary [v2]
In-Reply-To: <a6oRTbB7jAQOKt-eVriZXFblZuJ9p8XRQO0oj0UnUVw=.89c33e54-1ff5-4ef6-abe5-e1f0fa98e9c1@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
 <82ymMBdDKBdtAbC5hyt_BJRfnnotnndsWEnhWJLYsQA=.3c622108-c2f7-43dd-a1f8-b16715efc27d@github.com>
 <a6oRTbB7jAQOKt-eVriZXFblZuJ9p8XRQO0oj0UnUVw=.89c33e54-1ff5-4ef6-abe5-e1f0fa98e9c1@github.com>
Message-ID: <QPjaCk-o9kA6PBwxTpzw5xefOMx8AkqwDd9jpd49VoE=.fe5f58b3-dfb7-4115-9bb8-4cac5a96d671@github.com>

On Wed, 9 Jun 2021 14:01:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I hope this change happens in 17.

Yes, I think we can make it!...  Thanks.

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

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

From kevinw at openjdk.java.net  Wed Jun  9 19:36:14 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 9 Jun 2021 19:36:14 GMT
Subject: RFR: 8228343: JCMD and attach fail to work across Linux Container
 boundary [v2]
In-Reply-To: <czP2sCjEOfRXJ5Hcd5zmHRkhV94gAsY7OG54Iiv3HAw=.972e9b06-788b-458f-8c0b-9d93ef9b8cc8@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
 <82ymMBdDKBdtAbC5hyt_BJRfnnotnndsWEnhWJLYsQA=.3c622108-c2f7-43dd-a1f8-b16715efc27d@github.com>
 <czP2sCjEOfRXJ5Hcd5zmHRkhV94gAsY7OG54Iiv3HAw=.972e9b06-788b-458f-8c0b-9d93ef9b8cc8@github.com>
Message-ID: <jib67Yk8VhTqnxWu7IgXEw-BbOhyXGYrl3gY-R1iw6w=.69135bc9-2550-44a4-9f32-6fbdbfcade4b@github.com>

On Wed, 9 Jun 2021 18:44:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Hi Kevin,
> This looks okay to me.
> How do you test it to make sure no regressions are introduced?
> Thanks,
> Serguei

Yes, the bug text here mentions JDK-8195809 which is an effort to create a docker test...  With this fixed, that can go ahead.  The updated test is attached there - I'm not yet sure exactly where it will live, or when it will run, but we do need it...

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

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

From amenkov at openjdk.java.net  Wed Jun  9 20:41:12 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 9 Jun 2021 20:41:12 GMT
Subject: RFR: 8268407: ProblemList sun/tools/jstat/jstatLineCountsX.sh on
 linux-aarch64 due to JDK-8268211
In-Reply-To: <aSJPEzkzngKw2Qn_nod66gqEXhA71MNqQqWWZIJhwOw=.620aae5b-e694-42bf-b02c-a5a36741b54f@github.com>
References: <aSJPEzkzngKw2Qn_nod66gqEXhA71MNqQqWWZIJhwOw=.620aae5b-e694-42bf-b02c-a5a36741b54f@github.com>
Message-ID: <Qg4yeb5ucvWDqvQUlWOhRsyHWa6FRHCoQYEPTF8WuLc=.179bafc6-4a14-47b8-a3d0-774c9c835985@github.com>

On Tue, 8 Jun 2021 21:26:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> 8268407: ProblemList sun/tools/jstat/jstatLineCountsX.sh on linux-aarch64 due to JDK-8268211

Marked as reviewed by amenkov (Reviewer).

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

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

From amenkov at openjdk.java.net  Wed Jun  9 20:44:17 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 9 Jun 2021 20:44:17 GMT
Subject: RFR: 8268223: Problemlist
 vmTestbase/nsk/jdi/HiddenClass/events/events001.java
In-Reply-To: <ZiuwihWNeilsVSxQHJBoPh989fI2TU3fV12dvSjyqTA=.dfa92023-ecff-4245-9a40-b0c56d5b14b8@github.com>
References: <ZiuwihWNeilsVSxQHJBoPh989fI2TU3fV12dvSjyqTA=.dfa92023-ecff-4245-9a40-b0c56d5b14b8@github.com>
Message-ID: <sG7zWzvNVBucJx2CU2G-oojDVCRLOt8Msec7LZ4Qbx0=.a98654a6-a1c0-4702-9476-7271944f3bab@github.com>

On Wed, 9 Jun 2021 19:04:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Exclude vmTestbase/nsk/jdi/HiddenClass/events/events001.java.

Marked as reviewed by amenkov (Reviewer).

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

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

From kevinw at openjdk.java.net  Wed Jun  9 20:49:19 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 9 Jun 2021 20:49:19 GMT
Subject: Integrated: 8228343: JCMD and attach fail to work across Linux
 Container boundary
In-Reply-To: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
References: <3YH1gtKlSUeDmbT9Gc97cFpi7_Z8bD5dFqGCkMoNh88=.2c2c60a8-a0ee-420f-a678-d92a06146f14@github.com>
Message-ID: <1CRNhyTUfN-ry2nS06HINcCGlU4wpyscKbsgAziougk=.ad95cc85-9578-42ee-be79-3040275878f0@github.com>

On Tue, 8 Jun 2021 20:44:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Since 8214300, jcmd cannot attach to a Java process in a docker container.
> 
> That change started using a canonicalized File to create the .attach_pidXXX file.  For a target process in a container, it will follow a symlink that is likely not the same as for the target process.  e.g. follow a symlink to a cwd of / which is not the same directory for the container host, as it is within the container.  Containerized VM never sees the file, never creates the socket file, the attach times out and fails.
> 
> To keep the 8214300 change working for non-container situations, we can keep a canonical version of the attach File to use for deleting.
> 
> For containers there will remain the problem 8214300 describes, although it is unlikely: if you start the attach to a containerized VM,  and it then exits, we can't delete the .attach_pidXXX file.  Neither the /proc/PID/cwd or canonical form are any use.
> 
> (Possibly leaving a .attach_pidXXX file if the target dies in that small window is better than the current situation.)
> 
> Here I'm suggesting the same change on AIX, although I can't build/test that.  I'm expecting it has the same problem, as /proc/pid/cwd is still a symlink.

This pull request has now been integrated.

Changeset: bf29a011
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bf29a0115cc67ed2926b135b6b6ade5ff5ee84f6
Stats:     9 lines in 2 files changed: 2 ins; 2 del; 5 mod

8228343: JCMD and attach fail to work across Linux Container boundary

Reviewed-by: ysuenaga, sspitsyn

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

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

From sspitsyn at openjdk.java.net  Wed Jun  9 22:18:24 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 9 Jun 2021 22:18:24 GMT
Subject: RFR: 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002 failed
 with "Wrong thread "thr1" (...) state after SuspendThread"
Message-ID: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>

The test is intermittently failing because the tested thread thrstat002a is blocked on a monitor in the PrintStream.println(String) when it is expected to be in the RUNNABLE state:
  thrstat002.runningBarrier.unlock(); <= now the thrstat002 state can be checked and suspend issued
  System.out.println("thrstat002a.run after runningBarrier unlock"); <= blocked on the monitor in here

The fix is to move println line to the point before thrstat002.runningBarrier.unlock();
Also, a fflush(0) statement is added to the agent *_checkStatus() function to get output better sync'ed.

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

Commit messages:
 - 8268285: fix failure in test vmTestbase/nsk/jvmti/GetThreadState/thrstat002

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

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

From lmesnik at openjdk.java.net  Wed Jun  9 23:01:15 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 9 Jun 2021 23:01:15 GMT
Subject: RFR: 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002
 failed with "Wrong thread "thr1" (...) state after SuspendThread"
In-Reply-To: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
References: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
Message-ID: <927lxAplsLi9FUAipCYyvF3m0c2qepux1P_xHAm801o=.090b0d6b-b82e-4cd8-b06e-3bab6ee6116e@github.com>

On Wed, 9 Jun 2021 22:11:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test is intermittently failing because the tested thread thrstat002a is blocked on a monitor in the PrintStream.println(String) when it is expected to be in the RUNNABLE state:
>   thrstat002.runningBarrier.unlock(); <= now the thrstat002 state can be checked and suspend issued
>   System.out.println("thrstat002a.run after runningBarrier unlock"); <= blocked on the monitor in here
> 
> The fix is to move println line to the point before thrstat002.runningBarrier.unlock();
> Also, a fflush(0) statement is added to the agent *_checkStatus() function to get output better sync'ed.

Marked as reviewed by lmesnik (Committer).

sorry, added comment by mistake

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

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

From amenkov at openjdk.java.net  Wed Jun  9 23:08:14 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 9 Jun 2021 23:08:14 GMT
Subject: RFR: 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002
 failed with "Wrong thread "thr1" (...) state after SuspendThread"
In-Reply-To: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
References: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
Message-ID: <nFRFTUp-b9HUFqBwyrdyG7ZawIiXyJLgprKLWup3tQ8=.4c6d65d7-f763-4363-86f4-9cb9cffaa589@github.com>

On Wed, 9 Jun 2021 22:11:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test is intermittently failing because the tested thread thrstat002a is blocked on a monitor in the PrintStream.println(String) when it is expected to be in the RUNNABLE state:
>   thrstat002.runningBarrier.unlock(); <= now the thrstat002 state can be checked and suspend issued
>   System.out.println("thrstat002a.run after runningBarrier unlock"); <= blocked on the monitor in here
> 
> The fix is to move println line to the point before thrstat002.runningBarrier.unlock();
> Also, a fflush(0) statement is added to the agent *_checkStatus() function to get output better sync'ed.

Marked as reviewed by amenkov (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Wed Jun  9 23:23:10 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 9 Jun 2021 23:23:10 GMT
Subject: RFR: 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002
 failed with "Wrong thread "thr1" (...) state after SuspendThread"
In-Reply-To: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
References: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
Message-ID: <4lzb7C1fQDUjbfzXwyMeQ2bWJV5jx0G07Q7cfEHHZOc=.a77784c5-1ff1-45da-8643-d7e4026bf4de@github.com>

On Wed, 9 Jun 2021 22:11:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test is intermittently failing because the tested thread thrstat002a is blocked on a monitor in the PrintStream.println(String) when it is expected to be in the RUNNABLE state:
>   thrstat002.runningBarrier.unlock(); <= now the thrstat002 state can be checked and suspend issued
>   System.out.println("thrstat002a.run after runningBarrier unlock"); <= blocked on the monitor in here
> 
> The fix is to move println line to the point before thrstat002.runningBarrier.unlock();
> Also, a fflush(0) statement is added to the agent *_checkStatus() function to get output better sync'ed.

Leonid and Alex, thank you for quick review!

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 00:44:35 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 00:44:35 GMT
Subject: RFR: 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002
 failed with "Wrong thread "thr1" (...) state after SuspendThread" [v2]
In-Reply-To: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
References: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
Message-ID: <oEp9Dn__BxIhHCwBSZyHL7NOslS6H5J4uJVgnTHM_z0=.cd269c0a-26ff-490c-9379-ff9f7dee72a6@github.com>

> The test is intermittently failing because the tested thread thrstat002a is blocked on a monitor in the PrintStream.println(String) when it is expected to be in the RUNNABLE state:
>   thrstat002.runningBarrier.unlock(); <= now the thrstat002 state can be checked and suspend issued
>   System.out.println("thrstat002a.run after runningBarrier unlock"); <= blocked on the monitor in here
> 
> The fix is to move println line to the point before thrstat002.runningBarrier.unlock();
> Also, a fflush(0) statement is added to the agent *_checkStatus() function to get output better sync'ed.

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

  add a warning comment to thrstat002a.run to prevent println's before the while loop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4447/files
  - new: https://git.openjdk.java.net/jdk/pull/4447/files/9d7ed6e5..429079f4

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

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 00:49:38 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 00:49:38 GMT
Subject: RFR: 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002
 failed with "Wrong thread "thr1" (...) state after SuspendThread" [v3]
In-Reply-To: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
References: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
Message-ID: <luEs_oOXhkPrRdSDYmiBqhfHV7kNtOrcD--81HSxBKo=.1a8c6bb9-2948-46c1-b65a-72aefbff0f6e@github.com>

> The test is intermittently failing because the tested thread thrstat002a is blocked on a monitor in the PrintStream.println(String) when it is expected to be in the RUNNABLE state:
>   thrstat002.runningBarrier.unlock(); <= now the thrstat002 state can be checked and suspend issued
>   System.out.println("thrstat002a.run after runningBarrier unlock"); <= blocked on the monitor in here
> 
> The fix is to move println line to the point before thrstat002.runningBarrier.unlock();
> Also, a fflush(0) statement is added to the agent *_checkStatus() function to get output better sync'ed.

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

 - Merge
 - add a warning comment to thrstat002a.run to prevent println's before the while loop
 - 8268285: fix failure in test vmTestbase/nsk/jvmti/GetThreadState/thrstat002

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4447/files
  - new: https://git.openjdk.java.net/jdk/pull/4447/files/429079f4..07bdb421

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

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

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

From cjplummer at openjdk.java.net  Thu Jun 10 02:53:15 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Jun 2021 02:53:15 GMT
Subject: Integrated: 8268407: ProblemList sun/tools/jstat/jstatLineCountsX.sh
 on linux-aarch64 due to JDK-8268211
In-Reply-To: <aSJPEzkzngKw2Qn_nod66gqEXhA71MNqQqWWZIJhwOw=.620aae5b-e694-42bf-b02c-a5a36741b54f@github.com>
References: <aSJPEzkzngKw2Qn_nod66gqEXhA71MNqQqWWZIJhwOw=.620aae5b-e694-42bf-b02c-a5a36741b54f@github.com>
Message-ID: <dHpZWjFaelg9h8SHWTi3q0Afc86ujfjFk9gd8QJVylQ=.ed6b6dc0-fdd5-4fd8-9aff-4388f18bcaca@github.com>

On Tue, 8 Jun 2021 21:26:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> 8268407: ProblemList sun/tools/jstat/jstatLineCountsX.sh on linux-aarch64 due to JDK-8268211

This pull request has now been integrated.

Changeset: f839308e
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f839308efac0f5d8cb7cce165695ef24041fd621
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8268407: ProblemList sun/tools/jstat/jstatLineCountsX.sh on linux-aarch64 due to JDK-8268211

Reviewed-by: amenkov

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

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

From dholmes at openjdk.java.net  Thu Jun 10 02:54:18 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Jun 2021 02:54:18 GMT
Subject: RFR: 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002
 failed with "Wrong thread "thr1" (...) state after SuspendThread" [v3]
In-Reply-To: <luEs_oOXhkPrRdSDYmiBqhfHV7kNtOrcD--81HSxBKo=.1a8c6bb9-2948-46c1-b65a-72aefbff0f6e@github.com>
References: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
 <luEs_oOXhkPrRdSDYmiBqhfHV7kNtOrcD--81HSxBKo=.1a8c6bb9-2948-46c1-b65a-72aefbff0f6e@github.com>
Message-ID: <y4MZqwrY8ukzn4jK3Caz6ieR7UvUdLoTG7FPeYdIW-4=.010e6cbf-5110-424c-b593-6e1a49045c63@github.com>

On Thu, 10 Jun 2021 00:49:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test is intermittently failing because the tested thread thrstat002a is blocked on a monitor in the PrintStream.println(String) when it is expected to be in the RUNNABLE state:
>>   thrstat002.runningBarrier.unlock(); <= now the thrstat002 state can be checked and suspend issued
>>   System.out.println("thrstat002a.run after runningBarrier unlock"); <= blocked on the monitor in here
>> 
>> The fix is to move println line to the point before thrstat002.runningBarrier.unlock();
>> Also, a fflush(0) statement is added to the agent *_checkStatus() function to get output better sync'ed.
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge
>  - add a warning comment to thrstat002a.run to prevent println's before the while loop
>  - 8268285: fix failure in test vmTestbase/nsk/jvmti/GetThreadState/thrstat002

LGTM2 :)

The two adjacent printlns are somewhat redundant (sorry I overlooked that) but harmless.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From dholmes at openjdk.java.net  Thu Jun 10 05:14:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Jun 2021 05:14:15 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v4]
In-Reply-To: <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
Message-ID: <f81moO3cqkO0eW_h7NmNq5pEOrn9_Y79hCsCZyrNnJs=.fa6ef71e-edbf-4051-b562-1b3c2581f7e1@github.com>

On Wed, 9 Jun 2021 14:45:35 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine 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.

This seems better to me now.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From mbaesken at openjdk.java.net  Thu Jun 10 05:47:23 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 10 Jun 2021 05:47:23 GMT
Subject: RFR: JDK-8261873: Windows 32bit build fails in
 DynamicCodeGenerated\libDynamicCodeGenerated.cpp
Message-ID: <p7J1VCWHM-osPLnZ9nojwdCTAD65cJkY0mcCyB6L_2A=.3462423e-6a46-45e3-8682-496e2c8d9ca4@github.com>

Hello, please review this small fix for a build error on 32bit Windows.
Currently we run into 
d:\test\hotspot\jtreg\serviceability\jvmti\DynamicCodeGenerated\libDynamicCodeGenerated.cpp(49): error C2373: 'Agent_OnLoad': redefinition; different type modifiers
d:\jdk-dev-build\support\modules_include\java.base\jvmti.h(51): note: see declaration of 'Agent_OnLoad'

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

Commit messages:
 - JDK-8261873

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 05:49:15 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 05:49:15 GMT
Subject: RFR: 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002
 failed with "Wrong thread "thr1" (...) state after SuspendThread" [v3]
In-Reply-To: <luEs_oOXhkPrRdSDYmiBqhfHV7kNtOrcD--81HSxBKo=.1a8c6bb9-2948-46c1-b65a-72aefbff0f6e@github.com>
References: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
 <luEs_oOXhkPrRdSDYmiBqhfHV7kNtOrcD--81HSxBKo=.1a8c6bb9-2948-46c1-b65a-72aefbff0f6e@github.com>
Message-ID: <bOSs6T9-SiFopsQpiH8XCY6bLeuCkH5rAGCpHyU_DkU=.29e2b8f1-b9ff-40fb-83c9-e6a09096c793@github.com>

On Thu, 10 Jun 2021 00:49:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test is intermittently failing because the tested thread thrstat002a is blocked on a monitor in the PrintStream.println(String) when it is expected to be in the RUNNABLE state:
>>   thrstat002.runningBarrier.unlock(); <= now the thrstat002 state can be checked and suspend issued
>>   System.out.println("thrstat002a.run after runningBarrier unlock"); <= blocked on the monitor in here
>> 
>> The fix is to move println line to the point before thrstat002.runningBarrier.unlock();
>> Also, a fflush(0) statement is added to the agent *_checkStatus() function to get output better sync'ed.
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge
>  - add a warning comment to thrstat002a.run to prevent println's before the while loop
>  - 8268285: fix failure in test vmTestbase/nsk/jvmti/GetThreadState/thrstat002

Thanks, David. Yes, I looked at these two lines and decided it is harmless to keep both.

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 06:01:17 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 06:01:17 GMT
Subject: RFR: 8268223: Problemlist
 vmTestbase/nsk/jdi/HiddenClass/events/events001.java
In-Reply-To: <ZiuwihWNeilsVSxQHJBoPh989fI2TU3fV12dvSjyqTA=.dfa92023-ecff-4245-9a40-b0c56d5b14b8@github.com>
References: <ZiuwihWNeilsVSxQHJBoPh989fI2TU3fV12dvSjyqTA=.dfa92023-ecff-4245-9a40-b0c56d5b14b8@github.com>
Message-ID: <Nxqz1Y7sFeuypBZIEf2NN6YZy23Y4PWuSnA8iFI5lUU=.a42e15d8-ba87-4faf-a131-93278f19c06a@github.com>

On Wed, 9 Jun 2021 19:04:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Exclude vmTestbase/nsk/jdi/HiddenClass/events/events001.java.

Marked as reviewed by sspitsyn (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 06:06:41 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 06:06:41 GMT
Subject: RFR: 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002
 failed with "Wrong thread "thr1" (...) state after SuspendThread" [v4]
In-Reply-To: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
References: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
Message-ID: <whvRFzth3dTlulgvyqC_XVFHtuvMCYNZDlsfEKwg6Zg=.d579de0a-7bf5-433c-b1ad-c1c73c1b42f9@github.com>

> The test is intermittently failing because the tested thread thrstat002a is blocked on a monitor in the PrintStream.println(String) when it is expected to be in the RUNNABLE state:
>   thrstat002.runningBarrier.unlock(); <= now the thrstat002 state can be checked and suspend issued
>   System.out.println("thrstat002a.run after runningBarrier unlock"); <= blocked on the monitor in here
> 
> The fix is to move println line to the point before thrstat002.runningBarrier.unlock();
> Also, a fflush(0) statement is added to the agent *_checkStatus() function to get output better sync'ed.

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

 - Merge
 - Merge
 - add a warning comment to thrstat002a.run to prevent println's before the while loop
 - 8268285: fix failure in test vmTestbase/nsk/jvmti/GetThreadState/thrstat002

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4447/files
  - new: https://git.openjdk.java.net/jdk/pull/4447/files/07bdb421..6ef8ccc6

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

  Stats: 84 lines in 3 files changed: 22 ins; 9 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4447.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4447/head:pull/4447

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

From sspitsyn at openjdk.java.net  Thu Jun 10 06:06:42 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 06:06:42 GMT
Subject: Integrated: 8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002
 failed with "Wrong thread "thr1" (...) state after SuspendThread"
In-Reply-To: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
References: <J7NL9jRDkiPQ3iGWDSOu3nNZrm89s_ECtioJghZfjms=.d144fe50-e17d-4dd1-a029-9f826cc8bbd4@github.com>
Message-ID: <IcoYoux29owZFesSH8a05en6LvWGsqh1xv4P6cvdVAs=.5265b6b3-24cf-42c4-931b-5ed473b99076@github.com>

On Wed, 9 Jun 2021 22:11:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test is intermittently failing because the tested thread thrstat002a is blocked on a monitor in the PrintStream.println(String) when it is expected to be in the RUNNABLE state:
>   thrstat002.runningBarrier.unlock(); <= now the thrstat002 state can be checked and suspend issued
>   System.out.println("thrstat002a.run after runningBarrier unlock"); <= blocked on the monitor in here
> 
> The fix is to move println line to the point before thrstat002.runningBarrier.unlock();
> Also, a fflush(0) statement is added to the agent *_checkStatus() function to get output better sync'ed.

This pull request has now been integrated.

Changeset: dd1cbadc
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dd1cbadc82bcecf718b96c833a5845fde79db061
Stats:     7 lines in 2 files changed: 4 ins; 0 del; 3 mod

8268285: vmTestbase/nsk/jvmti/GetThreadState/thrstat002 failed with "Wrong thread "thr1" (...) state after SuspendThread"

Reviewed-by: lmesnik, amenkov, dholmes

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 06:09:20 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 06:09:20 GMT
Subject: RFR: JDK-8261873: Windows 32bit build fails in
 DynamicCodeGenerated\libDynamicCodeGenerated.cpp
In-Reply-To: <p7J1VCWHM-osPLnZ9nojwdCTAD65cJkY0mcCyB6L_2A=.3462423e-6a46-45e3-8682-496e2c8d9ca4@github.com>
References: <p7J1VCWHM-osPLnZ9nojwdCTAD65cJkY0mcCyB6L_2A=.3462423e-6a46-45e3-8682-496e2c8d9ca4@github.com>
Message-ID: <_dfFCIBkX5KBN42jhq38TdkckoR_q5Aj1FnZ9QO2IfA=.03f14ed8-6c3d-490d-a0f4-5919488e4184@github.com>

On Thu, 10 Jun 2021 05:40:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small fix for a build error on 32bit Windows.
> Currently we run into 
> d:\test\hotspot\jtreg\serviceability\jvmti\DynamicCodeGenerated\libDynamicCodeGenerated.cpp(49): error C2373: 'Agent_OnLoad': redefinition; different type modifiers
> d:\jdk-dev-build\support\modules_include\java.base\jvmti.h(51): note: see declaration of 'Agent_OnLoad'

Hi Matthias,
Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From cjplummer at openjdk.java.net  Thu Jun 10 06:32:14 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Jun 2021 06:32:14 GMT
Subject: RFR: JDK-8261873: Windows 32bit build fails in
 DynamicCodeGenerated\libDynamicCodeGenerated.cpp
In-Reply-To: <p7J1VCWHM-osPLnZ9nojwdCTAD65cJkY0mcCyB6L_2A=.3462423e-6a46-45e3-8682-496e2c8d9ca4@github.com>
References: <p7J1VCWHM-osPLnZ9nojwdCTAD65cJkY0mcCyB6L_2A=.3462423e-6a46-45e3-8682-496e2c8d9ca4@github.com>
Message-ID: <eUENhHYdh8GTdGnSDAZjwPbpH31tUpqv2MUYmBQHc5k=.1b311640-a4e1-4fb8-b312-c278c40ca1ce@github.com>

On Thu, 10 Jun 2021 05:40:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small fix for a build error on 32bit Windows.
> Currently we run into 
> d:\test\hotspot\jtreg\serviceability\jvmti\DynamicCodeGenerated\libDynamicCodeGenerated.cpp(49): error C2373: 'Agent_OnLoad': redefinition; different type modifiers
> d:\jdk-dev-build\support\modules_include\java.base\jvmti.h(51): note: see declaration of 'Agent_OnLoad'

Marked as reviewed by cjplummer (Reviewer).

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 07:33:44 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 07:33:44 GMT
Subject: RFR: 8268531: mark SDTProbesGNULinuxTest as ignoring external VM flags
Message-ID: <yS49iX150Fb_9l67LPHj1XBxuhLTKdaaJcyl6a9YyJk=.19d73c42-a1ec-405b-b758-3425f7eda4cd@github.com>

Hi all,

could you please review this patch that adds `@requires vm.flagless` to `SDTProbesGNULinuxTest` test as it ignores all external VM flags?

Thanks,
-- Igor

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

Commit messages:
 - update copyright year
 - 8268531

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

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

From luhenry at openjdk.java.net  Thu Jun 10 07:50:57 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Thu, 10 Jun 2021 07:50:57 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v2]
In-Reply-To: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
Message-ID: <Sh6SwxGrn3gEhcWLGK_729I4Bjg6wutfT9ssNir0WfU=.046c4e36-53ec-490e-98c2-2d97d99d9159@github.com>

> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
> 
> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
> 
> # `Prof1`
> 
> public class Prof1 {
> 
>     public static void main(String[] args) {
>         StringBuilder sb = new StringBuilder();
>         for (int i = 0; i < 1000000; i++) {
>             sb.append("ab");
>             sb.delete(0, 1);
>         }
>         System.out.println(sb.length());
>     }
> }
> 
> 
> - Baseline:
> 
> Flat Profile (by method):
>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>         (t  0.5,s  0.2) Prof1::main
>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>         (t  0.0,s  0.0) java.lang.String::getBytes
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
> 
> - With `StubRoutinesBlob::FrameParser`:
> 
> Flat Profile (by method):
>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>         (t 99.8,s  0.2) Prof1::main
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
> 
> 
> # `Prof2`
> 
> import java.util.function.Supplier;
> 
> public class Prof2 {
> 
>     public static void main(String[] args) {
>         var rand = new java.util.Random(0);
>         Supplier[] suppliers = {
>                 () -> 0,
>                 () -> 1,
>                 () -> 2,
>                 () -> 3,
>         };
> 
>         long sum = 0;
>         for (int i = 0; i >= 0; i++) {
>             sum += (int)suppliers[i % suppliers.length].get();
>         }
>     }
> }
> 
> 
> - Baseline:
> 
> Flat Profile (by method):
>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>         (t 39.2,s 35.2) Prof2::main
>         (t  1.4,s  1.4) Prof2::lambda$main$3
>         (t  1.0,s  1.0) Prof2::lambda$main$2
>         (t  0.9,s  0.9) Prof2::lambda$main$1
>         (t  0.7,s  0.7) Prof2::lambda$main$0
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>         (t  0.0,s  0.0) java.lang.Thread::exit
>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
> 
> 
> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
> 
> Flat Profile (by method):
>         (t 74.1,s 70.3) Prof2::main
>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>         (t  1.2,s  1.2) Prof2::lambda$main$2
>         (t  0.9,s  0.9) Prof2::lambda$main$3
>         (t  0.9,s  0.9) Prof2::lambda$main$1
>         (t  0.7,s  0.7) Prof2::lambda$main$0
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]

Ludovic Henry 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 five new commits since the last revision:

 - Disable checks in FrameParser when known to be safe
 - Allow AsyncGetCallTrace and JFR to unwind stack from vtable stub
   
   The program is the following:
   
   ```
   import java.util.function.Supplier;
   
   public class Prof2 {
   
       public static void main(String[] args) {
           var rand = new java.util.Random(0);
           Supplier[] suppliers = {
                   () -> 0,
                   () -> 1,
                   () -> 2,
                   () -> 3,
           };
   
           long sum = 0;
           for (int i = 0; i >= 0; i++) {
               sum += (int)suppliers[i % suppliers.length].get();
           }
       }
   }
   ```
   
   The results are as follows:
   
   - Baseline (from previous commit):
   
   Flat Profile (by method):
               (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
               (t 40.3,s 36.1) Prof2::main
               (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
               (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
               (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
               (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
               (t  1.1,s  1.1) Prof2::lambda$main$2
               (t  1.1,s  1.1) Prof2::lambda$main$0
               (t  1.0,s  1.0) Prof2::lambda$main$1
               (t  0.9,s  0.9) Prof2::lambda$main$3
               (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
   
   - With unwind from vtable stub
   
   Flat Profile (by method):
           (t 74.1,s 70.3) Prof2::main
           (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
           (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
           (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
           (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
           (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
           (t  1.2,s  1.2) Prof2::lambda$main$2
           (t  0.9,s  0.9) Prof2::lambda$main$3
           (t  0.9,s  0.9) Prof2::lambda$main$1
           (t  0.7,s  0.7) Prof2::lambda$main$0
           (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
   
   We attribute the vtable stub to the caller and not the callee, which is
   already an improvement from the existing case.
 - Allow AsyncGetCallTrace and JFR to unwind stack from nmethod's prolog
   
   When sampling hits the prolog of a method, Hotspot assumes it's unable
   to parse the frame. This change allows to parse such frame on x86 by
   specializing which instruction it's hitting in the prolog.
   
   The results are as follows:
   
   - Baseline:
   
   Flat Profile (by method):
           (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
           (t 39.2,s 35.2) Prof2::main
           (t  1.4,s  1.4) Prof2::lambda$main$3
           (t  1.0,s  1.0) Prof2::lambda$main$2
           (t  0.9,s  0.9) Prof2::lambda$main$1
           (t  0.7,s  0.7) Prof2::lambda$main$0
           (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
           (t  0.0,s  0.0) java.lang.Thread::exit
           (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
           (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
           (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
           (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
   
   - With incomplete frame parsing:
   
   Flat Profile (by method):
           (t 39.3,s 39.3) AGCT::Unknown Java[ERR=-5]
           (t 40.3,s 36.1) Prof2::main
           (t  6.4,s  5.3) Prof2$$Lambda$28.0x0000000800081000::get
           (t  6.1,s  5.1) Prof2$$Lambda$29.0x0000000800081220::get
           (t  6.0,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
           (t  6.1,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
           (t  1.1,s  1.1) Prof2::lambda$main$2
           (t  1.1,s  1.1) Prof2::lambda$main$0
           (t  1.0,s  1.0) Prof2::lambda$main$1
           (t  0.9,s  0.9) Prof2::lambda$main$3
           (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
           (t  0.0,s  0.0) java.util.Locale::getInstance
           (t  0.0,s  0.0) AGCT::Not walkable Java[ERR=-6]
           (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::loadClassOrNull
           (t  0.0,s  0.0) java.lang.ClassLoader::loadClass
           (t  0.0,s  0.0) sun.net.util.URLUtil::urlNoFragString
           (t  0.0,s  0.0) java.lang.Class::forName0
           (t  0.0,s  0.0) java.util.Locale::initDefault
           (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::loadClass
           (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getLoader
           (t  0.0,s  0.0) jdk.internal.loader.URLClassPath::getResource
           (t  0.0,s  0.0) java.lang.String::toLowerCase
           (t  0.0,s  0.0) sun.launcher.LauncherHelper::loadMainClass
           (t  0.0,s  0.0) sun.launcher.LauncherHelper::checkAndLoadMain
           (t  0.0,s  0.0) java.util.Locale::<clinit>
           (t  0.0,s  0.0) jdk.internal.loader.BuiltinClassLoader::findClassOnClassPathOrNull
           (t  0.0,s  0.0) jdk.internal.loader.ClassLoaders$AppClassLoader::loadClass
           (t  0.0,s  0.0) java.lang.Class::forName
   
   The program is as follows:
   
   ```
   import java.util.function.Supplier;
   
   public class Prof2 {
   
       public static void main(String[] args) {
           var rand = new java.util.Random(0);
           Supplier[] suppliers = {
                   () -> 0,
                   () -> 1,
                   () -> 2,
                   () -> 3,
           };
   
           long sum = 0;
           for (int i = 0; i >= 0; i++) {
               sum += (int)suppliers[i % suppliers.length].get();
           }
       }
   }
   ```
   
   We see that the results are particularely useful in this case as the
   methods are very short (it only returns an integer), and the probability
   of hitting the prolog is then very high.
 - Allow AsyncGetCallTrace and JFR to walk a stub frame
   
   When the signal sent for AsyncGetCallTrace or JFR would land on a stub
   (like arraycopy), it wouldn't be able to detect the sender (caller)
   frame because `_cb->frame_size() == 0`.
   
   Because we fully control how the prolog and epilog of stub code is
   generated, we know there are two cases:
   1. A stack frame is allocated via macroAssembler->enter(), and consists
   in `push rbp; mov rsp, rbp;`.
   2. No stack frames are allocated and rbp is left unchanged and rsp is
   decremented with the `call` instruction that push the return `pc` on the
   stack.
   
   For case 1., we can easily know the sender frame by simply looking at
   rbp, especially since we know that all stubs preserve the frame pointer
   (on x86 at least).
   
   For case 2., we end up returning the sender's sender, but that already
   gives us more information than what we have today.
   
   The results are as follows:
   
   - Baseline:
   
   Flat Profile (by method):
           (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
           (t  0.5,s  0.2) Prof1::main
           (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
           (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
           (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
           (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
           (t  0.0,s  0.0) java.lang.String::getBytes
           (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
           (t  0.0,s  0.0) java.lang.StringBuilder::delete
           (t  0.2,s  0.0) java.lang.StringBuilder::append
           (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
           (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
   
   - With StubRoutinesBlob::FrameParser
   
   Flat Profile (by method):
           (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
           (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
           (t 99.8,s  0.2) Prof1::main
           (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
           (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
           (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
           (t 98.8,s  0.0) java.lang.StringBuilder::append
           (t  0.9,s  0.0) java.lang.StringBuilder::delete
   
   The program is as follows:
   
   ```
   public class Prof1 {
   
       public static void main(String[] args) {
           StringBuilder sb = new StringBuilder();
           for (int i = 0; i < 1000000; i++) {
               sb.append("ab");
               sb.delete(0, 1);
           }
           System.out.println(sb.length());
       }
   }
   ```
   
   We now account for the arraycopy stub which is called by
   AbstractStringBuilder::ensureCapacityInternal. It was previously ignored
   because it would not know how to parse the frame for the arraycopy stub
   and would fall in the AGCT::Unknown Java[ERR=-5] section.
   
   However, it still isn't perfect since it doesn't point to the arraycopy stub
   directly.
 - Extract sender frame parsing to CodeBlock::FrameParser
   
   Whether and how a frame is setup is controlled by the code generator
   for the specific CodeBlock. The CodeBlock is then in the best place to know how
   to parse the sender's frame from the current frame in the given CodeBlock.
   
   This refactoring proposes to extract this parsing out of `frame` and into a
   `CodeBlock::FrameParser`. This FrameParser is then specialized in the relevant
   inherited children of CodeBlock.
   
   This change is to largely facilitate adding new supported cases for JDK-8252417
   like runtime stubs.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4436/files
  - new: https://git.openjdk.java.net/jdk/pull/4436/files/137a0c48..85f218c8

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

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

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

From luhenry at openjdk.java.net  Thu Jun 10 08:01:18 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Thu, 10 Jun 2021 08:01:18 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks
In-Reply-To: <v9lva0LCv61S2vOl-fOiZFzQlYOWDkglILhACCEZ9oM=.ac9e240b-7b7d-4484-a7e1-3c1b6f2a5569@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <v9lva0LCv61S2vOl-fOiZFzQlYOWDkglILhACCEZ9oM=.ac9e240b-7b7d-4484-a7e1-3c1b6f2a5569@github.com>
Message-ID: <_gZbzPT5Ba4EwjKgTRdQ6uMOpIYmyAt-G-4qjCAN0Qw=.ae7a3154-4db7-4489-a5a7-38525a543b4c@github.com>

On Wed, 9 Jun 2021 19:04:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
>> 
>> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
>> 
>> # `Prof1`
>> 
>> public class Prof1 {
>> 
>>     public static void main(String[] args) {
>>         StringBuilder sb = new StringBuilder();
>>         for (int i = 0; i < 1000000; i++) {
>>             sb.append("ab");
>>             sb.delete(0, 1);
>>         }
>>         System.out.println(sb.length());
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>>         (t  0.5,s  0.2) Prof1::main
>>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>>         (t  0.0,s  0.0) java.lang.String::getBytes
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> 
>> - With `StubRoutinesBlob::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>>         (t 99.8,s  0.2) Prof1::main
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
>> 
>> 
>> # `Prof2`
>> 
>> import java.util.function.Supplier;
>> 
>> public class Prof2 {
>> 
>>     public static void main(String[] args) {
>>         var rand = new java.util.Random(0);
>>         Supplier[] suppliers = {
>>                 () -> 0,
>>                 () -> 1,
>>                 () -> 2,
>>                 () -> 3,
>>         };
>> 
>>         long sum = 0;
>>         for (int i = 0; i >= 0; i++) {
>>             sum += (int)suppliers[i % suppliers.length].get();
>>         }
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>>         (t 39.2,s 35.2) Prof2::main
>>         (t  1.4,s  1.4) Prof2::lambda$main$3
>>         (t  1.0,s  1.0) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.Thread::exit
>>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>> 
>> 
>> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 74.1,s 70.3) Prof2::main
>>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>>         (t  1.2,s  1.2) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$3
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>
> Hi Ludovic,
> Thank you for working on this fix in the AsyncGetCallTrace.
> What version of JDK release do you intent to target?
> Just wanted to make sure you know the JDK 17 development cycle will be closed tomorrow for P4 bugs and enhancements. The repository will be forked and the RDP 1 phase started.
> I doubt the review of your fix will be completed by this time.
> So, please, keep in mind your PR will go to 18, not 17.
> Thanks,
> Serguei

@sspitsyn thank you for the reminder. It's perfectly fine for this change to land in JDK 18. We'll see in the future if there is a demand to backport it to JDK 17 and we'll do accordingly.

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 08:02:24 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 08:02:24 GMT
Subject: RFR: 8268530:
 resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java should be run in
 driver mode
Message-ID: <IQxpZ3J-kg2cmuvwgma9Tmb0N79XGw3Wo8xsJnv7TyE=.4d851822-9230-4345-b560-134ed4af3647@github.com>

Hi all,

could you please review this small and test-only change for `resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java` test?

the test's main class just orchestrates execution and hence should be run in a driver mode, the patch also makes small refactoring of the test code: removes redundant imports, simplifies process creation, and adds checks of the exit code.

testing: `resourcehogs/serviceability` tests on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

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

Commit messages:
 - check exit code of jar and GetObjectSizeOverflowAgent processes
 - simply jar process creation
 - cleaned up imports
 - use try-with-resource
 - 8268530

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

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

From mbaesken at openjdk.java.net  Thu Jun 10 08:12:16 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 10 Jun 2021 08:12:16 GMT
Subject: Integrated: JDK-8268463: Windows 32bit build fails in
 DynamicCodeGenerated\libDynamicCodeGenerated.cpp
In-Reply-To: <p7J1VCWHM-osPLnZ9nojwdCTAD65cJkY0mcCyB6L_2A=.3462423e-6a46-45e3-8682-496e2c8d9ca4@github.com>
References: <p7J1VCWHM-osPLnZ9nojwdCTAD65cJkY0mcCyB6L_2A=.3462423e-6a46-45e3-8682-496e2c8d9ca4@github.com>
Message-ID: <-7QOdP79R17BlN3XsSh2AGzGNLIidn6vg51FMHqOD9I=.7d4ce262-fef7-40f8-8791-591262481a0c@github.com>

On Thu, 10 Jun 2021 05:40:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small fix for a build error on 32bit Windows.
> Currently we run into 
> d:\test\hotspot\jtreg\serviceability\jvmti\DynamicCodeGenerated\libDynamicCodeGenerated.cpp(49): error C2373: 'Agent_OnLoad': redefinition; different type modifiers
> d:\jdk-dev-build\support\modules_include\java.base\jvmti.h(51): note: see declaration of 'Agent_OnLoad'

This pull request has now been integrated.

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

8268463: Windows 32bit build fails in DynamicCodeGenerated\libDynamicCodeGenerated.cpp

Reviewed-by: sspitsyn, cjplummer

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 08:37:22 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 08:37:22 GMT
Subject: RFR: 8268536: mark hotspot serviceability/dcmd tests which ignore
 external VM flags
Message-ID: <qITWhB7MDh4MNbcPn5XS2MiRifFEyAq9I018DJr1hn4=.7e1de18f-69f6-4082-a0ca-925e16b3aa6f@github.com>

Hi all,

could you please review the patch which adds `@requires vm.flagless` to `serviceability/dcmd/gc/RunFinalizationTest.java` and `serviceability/dcmd/compiler/CodeHeapAnalyticsParams.java` tests as they completely ignore external vm flags?

Thanks,
-- Igor

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

Commit messages:
 - update copyright year
 - 8268536

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 08:49:26 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 08:49:26 GMT
Subject: RFR: 8268538: mark hotspot serviceability/logging tests which ignore
 external VM flags
Message-ID: <G4W8T_oLYMIlUcLl-9igrYH3bB1Ik86eDlaj7yvrbrs=.086c2345-bb23-4863-8120-329d07d3f032@github.com>

Hi all,

could you please review the patch which adds `@requires vm.flagless` to serviceability/logging` tests that ignore external VM flags?

Thanks,
-- Igor

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

Commit messages:
 - update copyright year
 - 8268538

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:15:21 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:15:21 GMT
Subject: RFR: 8268532: several serviceability/attach tests should be run in
 driver mode
Message-ID: <6E0O-U5bnFGNLr5NDwhnFDTLh1gFbipqon0E_Oz6W7k=.f3d7740a-53c3-4ec8-8a08-dc79e52b8527@github.com>

Hi all,

could you please review this small patch that switches execution mode in 4 `serviceability/attach` tests?
in all instances, the main test classes seem not to do actual testing and just orchestrate execution.

testing: `serviceability/attach` on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

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

Commit messages:
 - one more test
 - copyright year
 - 8268532

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:15:27 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:15:27 GMT
Subject: RFR: 8268534: some serviceability/jvmti tests should be run in driver
 mode
Message-ID: <OHXM8bWeuH67nClDuLiF2euMqS6eB25qvIR9TokbSG8=.ab642894-2992-4881-88fd-9f169cd03a14@github.com>

Hi all,

could you please review this small patch that switches execution mode in 4 `serviceability/jvmti` tests?
in all instances, the main test classes seem not to do actual testing and just orchestrate execution.

testing: `serviceability/jvmti`  on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

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

Commit messages:
 - copyright
 - 8268534

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 09:38:14 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 09:38:14 GMT
Subject: RFR: 8268530:
 resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java should be run in
 driver mode
In-Reply-To: <IQxpZ3J-kg2cmuvwgma9Tmb0N79XGw3Wo8xsJnv7TyE=.4d851822-9230-4345-b560-134ed4af3647@github.com>
References: <IQxpZ3J-kg2cmuvwgma9Tmb0N79XGw3Wo8xsJnv7TyE=.4d851822-9230-4345-b560-134ed4af3647@github.com>
Message-ID: <FuGbrzdI9GaB-V2gP4G5_cPhInBf0-fQDxMikNQLp2k=.01ef2f89-8e9b-4145-977c-a201dd183690@github.com>

On Thu, 10 Jun 2021 07:02:36 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and test-only change for `resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java` test?
> 
> the test's main class just orchestrates execution and hence should be run in a driver mode, the patch also makes small refactoring of the test code: removes redundant imports, simplifies process creation, and adds checks of the exit code.
> 
> testing: `resourcehogs/serviceability` tests on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 09:40:19 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 09:40:19 GMT
Subject: RFR: 8268536: mark hotspot serviceability/dcmd tests which ignore
 external VM flags
In-Reply-To: <qITWhB7MDh4MNbcPn5XS2MiRifFEyAq9I018DJr1hn4=.7e1de18f-69f6-4082-a0ca-925e16b3aa6f@github.com>
References: <qITWhB7MDh4MNbcPn5XS2MiRifFEyAq9I018DJr1hn4=.7e1de18f-69f6-4082-a0ca-925e16b3aa6f@github.com>
Message-ID: <YzJAvCFE_YRotho2NnUdgFntgsSDDcUnkdSJ5TjFoho=.ecac04f9-d1c7-43b0-87af-60f130dace0d@github.com>

On Thu, 10 Jun 2021 08:28:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which adds `@requires vm.flagless` to `serviceability/dcmd/gc/RunFinalizationTest.java` and `serviceability/dcmd/compiler/CodeHeapAnalyticsParams.java` tests as they completely ignore external vm flags?
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 09:43:15 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 09:43:15 GMT
Subject: RFR: 8268538: mark hotspot serviceability/logging tests which
 ignore external VM flags
In-Reply-To: <G4W8T_oLYMIlUcLl-9igrYH3bB1Ik86eDlaj7yvrbrs=.086c2345-bb23-4863-8120-329d07d3f032@github.com>
References: <G4W8T_oLYMIlUcLl-9igrYH3bB1Ik86eDlaj7yvrbrs=.086c2345-bb23-4863-8120-329d07d3f032@github.com>
Message-ID: <DMfLDZmJsWq-CqdKWC9-6AfrNGbShg9m-PRWYWZNBGw=.a51c08a5-77a8-4fa8-8273-7c45ef8bac49@github.com>

On Thu, 10 Jun 2021 08:41:41 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which adds `@requires vm.flagless` to serviceability/logging` tests that ignore external VM flags?
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 09:45:14 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 09:45:14 GMT
Subject: RFR: 8268532: several serviceability/attach tests should be run
 in driver mode
In-Reply-To: <6E0O-U5bnFGNLr5NDwhnFDTLh1gFbipqon0E_Oz6W7k=.f3d7740a-53c3-4ec8-8a08-dc79e52b8527@github.com>
References: <6E0O-U5bnFGNLr5NDwhnFDTLh1gFbipqon0E_Oz6W7k=.f3d7740a-53c3-4ec8-8a08-dc79e52b8527@github.com>
Message-ID: <Nw50YYHXsGVsQbPOxuHLEjZvzGtGg5hQQ_PfsRC6H8E=.18c73ecf-0932-4adb-9114-46fd6e207814@github.com>

On Thu, 10 Jun 2021 08:15:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that switches execution mode in 4 `serviceability/attach` tests?
> in all instances, the main test classes seem not to do actual testing and just orchestrate execution.
> 
> testing: `serviceability/attach` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:46:20 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:46:20 GMT
Subject: RFR: 8268530:
 resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java should be run in
 driver mode
In-Reply-To: <IQxpZ3J-kg2cmuvwgma9Tmb0N79XGw3Wo8xsJnv7TyE=.4d851822-9230-4345-b560-134ed4af3647@github.com>
References: <IQxpZ3J-kg2cmuvwgma9Tmb0N79XGw3Wo8xsJnv7TyE=.4d851822-9230-4345-b560-134ed4af3647@github.com>
Message-ID: <rXJBd6Og_q2RKjOvQ-UGOg8POH7r8GIr56rPvZ4EWRs=.bcc7d572-0388-459b-9a89-d6bbc3e36d44@github.com>

On Thu, 10 Jun 2021 07:02:36 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and test-only change for `resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java` test?
> 
> the test's main class just orchestrates execution and hence should be run in a driver mode, the patch also makes small refactoring of the test code: removes redundant imports, simplifies process creation, and adds checks of the exit code.
> 
> testing: `resourcehogs/serviceability` tests on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Thanks, Serguei!

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:46:21 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:46:21 GMT
Subject: Integrated: 8268530:
 resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java should be run in
 driver mode
In-Reply-To: <IQxpZ3J-kg2cmuvwgma9Tmb0N79XGw3Wo8xsJnv7TyE=.4d851822-9230-4345-b560-134ed4af3647@github.com>
References: <IQxpZ3J-kg2cmuvwgma9Tmb0N79XGw3Wo8xsJnv7TyE=.4d851822-9230-4345-b560-134ed4af3647@github.com>
Message-ID: <3oVPoXSG_4ZwfdNPi88_jRJEPL3uz_HjKpD0hMN37Fw=.5538a48f-fa2a-47d0-a983-2fe0f8ce30ff@github.com>

On Thu, 10 Jun 2021 07:02:36 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and test-only change for `resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java` test?
> 
> the test's main class just orchestrates execution and hence should be run in a driver mode, the patch also makes small refactoring of the test code: removes redundant imports, simplifies process creation, and adds checks of the exit code.
> 
> testing: `resourcehogs/serviceability` tests on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: ae29f9ca
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ae29f9cacdac8bfe7fc1d287edbfb21c81686d4c
Stats:     11 lines in 1 file changed: 1 ins; 4 del; 6 mod

8268530: resourcehogs/serviceability/jvmti/GetObjectSizeOverflow.java should be run in driver mode

Reviewed-by: sspitsyn

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 09:47:12 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 09:47:12 GMT
Subject: RFR: 8268534: some serviceability/jvmti tests should be run in
 driver mode
In-Reply-To: <OHXM8bWeuH67nClDuLiF2euMqS6eB25qvIR9TokbSG8=.ab642894-2992-4881-88fd-9f169cd03a14@github.com>
References: <OHXM8bWeuH67nClDuLiF2euMqS6eB25qvIR9TokbSG8=.ab642894-2992-4881-88fd-9f169cd03a14@github.com>
Message-ID: <W0f32vnAXD0SzyznJLIYyfmUHQdn4bKbJnAH6KVdwVk=.fd0171ef-9014-48bb-bfb3-48bceec7ec59@github.com>

On Thu, 10 Jun 2021 08:14:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that switches execution mode in 4 `serviceability/jvmti` tests?
> in all instances, the main test classes seem not to do actual testing and just orchestrate execution.
> 
> testing: `serviceability/jvmti`  on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:51:24 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:51:24 GMT
Subject: Integrated: 8268536: mark hotspot serviceability/dcmd tests which
 ignore external VM flags
In-Reply-To: <qITWhB7MDh4MNbcPn5XS2MiRifFEyAq9I018DJr1hn4=.7e1de18f-69f6-4082-a0ca-925e16b3aa6f@github.com>
References: <qITWhB7MDh4MNbcPn5XS2MiRifFEyAq9I018DJr1hn4=.7e1de18f-69f6-4082-a0ca-925e16b3aa6f@github.com>
Message-ID: <8YAwyfV_QASR86yN0397sRuN4aK2wdjZePZOFscDu2c=.64185e2c-2ca9-4735-aba1-5bec7262d7cb@github.com>

On Thu, 10 Jun 2021 08:28:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which adds `@requires vm.flagless` to `serviceability/dcmd/gc/RunFinalizationTest.java` and `serviceability/dcmd/compiler/CodeHeapAnalyticsParams.java` tests as they completely ignore external vm flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 05090fc8
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/05090fc8fdef3c02c91cbd79e661f763893580c2
Stats:     4 lines in 2 files changed: 2 ins; 0 del; 2 mod

8268536: mark hotspot serviceability/dcmd tests which ignore external VM flags

Reviewed-by: sspitsyn

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:51:23 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:51:23 GMT
Subject: RFR: 8268536: mark hotspot serviceability/dcmd tests which ignore
 external VM flags
In-Reply-To: <qITWhB7MDh4MNbcPn5XS2MiRifFEyAq9I018DJr1hn4=.7e1de18f-69f6-4082-a0ca-925e16b3aa6f@github.com>
References: <qITWhB7MDh4MNbcPn5XS2MiRifFEyAq9I018DJr1hn4=.7e1de18f-69f6-4082-a0ca-925e16b3aa6f@github.com>
Message-ID: <DzXf5Kfe1grrDrL09GghDdl0LH_APnjQE63EH87fDGE=.b9a0d701-6358-44b9-84bf-463694cdb7ce@github.com>

On Thu, 10 Jun 2021 08:28:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which adds `@requires vm.flagless` to `serviceability/dcmd/gc/RunFinalizationTest.java` and `serviceability/dcmd/compiler/CodeHeapAnalyticsParams.java` tests as they completely ignore external vm flags?
> 
> Thanks,
> -- Igor

Thank you, Serguei.

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:52:19 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:52:19 GMT
Subject: RFR: 8268538: mark hotspot serviceability/logging tests which
 ignore external VM flags
In-Reply-To: <G4W8T_oLYMIlUcLl-9igrYH3bB1Ik86eDlaj7yvrbrs=.086c2345-bb23-4863-8120-329d07d3f032@github.com>
References: <G4W8T_oLYMIlUcLl-9igrYH3bB1Ik86eDlaj7yvrbrs=.086c2345-bb23-4863-8120-329d07d3f032@github.com>
Message-ID: <VZdnSMONaGKibMXNExeS-k7ILMwKdiC4GRtAUIl15IE=.53d1ffda-f67c-457f-9bd9-8ebb00e0ee74@github.com>

On Thu, 10 Jun 2021 08:41:41 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which adds `@requires vm.flagless` to serviceability/logging` tests that ignore external VM flags?
> 
> Thanks,
> -- Igor

Thank you for your reviews, Serguei!

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:52:20 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:52:20 GMT
Subject: Integrated: 8268538: mark hotspot serviceability/logging tests which
 ignore external VM flags
In-Reply-To: <G4W8T_oLYMIlUcLl-9igrYH3bB1Ik86eDlaj7yvrbrs=.086c2345-bb23-4863-8120-329d07d3f032@github.com>
References: <G4W8T_oLYMIlUcLl-9igrYH3bB1Ik86eDlaj7yvrbrs=.086c2345-bb23-4863-8120-329d07d3f032@github.com>
Message-ID: <zkzGiC-GoSYclaXweXiE18ePnmxbX_fE7PDX3YZPqlw=.31be88a1-e6f3-4083-aae0-e322463a349a@github.com>

On Thu, 10 Jun 2021 08:41:41 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which adds `@requires vm.flagless` to serviceability/logging` tests that ignore external VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 964118f7
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/964118f7fd49786cfe60e1144800a02afc0fdb56
Stats:     12 lines in 5 files changed: 6 ins; 1 del; 5 mod

8268538: mark hotspot serviceability/logging tests which ignore external VM flags

Reviewed-by: sspitsyn

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:54:18 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:54:18 GMT
Subject: RFR: 8268532: several serviceability/attach tests should be run
 in driver mode
In-Reply-To: <6E0O-U5bnFGNLr5NDwhnFDTLh1gFbipqon0E_Oz6W7k=.f3d7740a-53c3-4ec8-8a08-dc79e52b8527@github.com>
References: <6E0O-U5bnFGNLr5NDwhnFDTLh1gFbipqon0E_Oz6W7k=.f3d7740a-53c3-4ec8-8a08-dc79e52b8527@github.com>
Message-ID: <-zZ32qTEV-Dl9ebRiiHymDZsWZuLrh6gHJ0yE3QHJ_M=.f387f54a-5bb4-4cb3-a90d-0cfcebccb5f8@github.com>

On Thu, 10 Jun 2021 08:15:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that switches execution mode in 4 `serviceability/attach` tests?
> in all instances, the main test classes seem not to do actual testing and just orchestrate execution.
> 
> testing: `serviceability/attach` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Thanks, Serguei.

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:55:19 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:55:19 GMT
Subject: Integrated: 8268534: some serviceability/jvmti tests should be run in
 driver mode
In-Reply-To: <OHXM8bWeuH67nClDuLiF2euMqS6eB25qvIR9TokbSG8=.ab642894-2992-4881-88fd-9f169cd03a14@github.com>
References: <OHXM8bWeuH67nClDuLiF2euMqS6eB25qvIR9TokbSG8=.ab642894-2992-4881-88fd-9f169cd03a14@github.com>
Message-ID: <Htdnu6rwnHrEUuTOlXpDlm9NXefGLzPLRRFltFDB2S8=.267d6a7c-39c7-4926-8fba-8bd5b1badc1f@github.com>

On Thu, 10 Jun 2021 08:14:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that switches execution mode in 4 `serviceability/jvmti` tests?
> in all instances, the main test classes seem not to do actual testing and just orchestrate execution.
> 
> testing: `serviceability/jvmti`  on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: e0c0b139
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e0c0b139d335cd818468db115dd18f1cedf21675
Stats:     7 lines in 4 files changed: 0 ins; 0 del; 7 mod

8268534: some serviceability/jvmti tests should be run in driver mode

Reviewed-by: sspitsyn

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:54:18 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:54:18 GMT
Subject: Integrated: 8268532: several serviceability/attach tests should be
 run in driver mode
In-Reply-To: <6E0O-U5bnFGNLr5NDwhnFDTLh1gFbipqon0E_Oz6W7k=.f3d7740a-53c3-4ec8-8a08-dc79e52b8527@github.com>
References: <6E0O-U5bnFGNLr5NDwhnFDTLh1gFbipqon0E_Oz6W7k=.f3d7740a-53c3-4ec8-8a08-dc79e52b8527@github.com>
Message-ID: <fjN1yHDiNX9X7Tw-ZFAK6EtEANXJHwxa_4wTgDgu1DI=.d93ae7cd-3497-4b4d-b27b-73609aa511c1@github.com>

On Thu, 10 Jun 2021 08:15:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that switches execution mode in 4 `serviceability/attach` tests?
> in all instances, the main test classes seem not to do actual testing and just orchestrate execution.
> 
> testing: `serviceability/attach` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 92f0b6d4
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/92f0b6d49e5a4dbdd6c95b8d526187adb33aa827
Stats:     8 lines in 4 files changed: 0 ins; 0 del; 8 mod

8268532: several serviceability/attach tests should be run in driver mode

Reviewed-by: sspitsyn

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 09:55:19 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 09:55:19 GMT
Subject: RFR: 8268534: some serviceability/jvmti tests should be run in
 driver mode
In-Reply-To: <OHXM8bWeuH67nClDuLiF2euMqS6eB25qvIR9TokbSG8=.ab642894-2992-4881-88fd-9f169cd03a14@github.com>
References: <OHXM8bWeuH67nClDuLiF2euMqS6eB25qvIR9TokbSG8=.ab642894-2992-4881-88fd-9f169cd03a14@github.com>
Message-ID: <Rw_94JuQajA9Bb2tdmG6jHlKwLsXWSXvYehPb8hc6D8=.3a7aa065-27c9-42cb-ad65-aa05c9adc2ac@github.com>

On Thu, 10 Jun 2021 08:14:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch that switches execution mode in 4 `serviceability/jvmti` tests?
> in all instances, the main test classes seem not to do actual testing and just orchestrate execution.
> 
> testing: `serviceability/jvmti`  on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Thank you, Serguei!

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 10:16:27 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 10:16:27 GMT
Subject: RFR: 8268539: several serviceability/sa tests should be run in driver
 mode
Message-ID: <Rq8W8uOBi7rcLOVkBX-iwOS7IRCs1VoqoTyV8WGdTSY=.0c05fcf4-0a83-4f6d-a71c-3603106362e6@github.com>

Hi all,

could you please review this _test-only_ patch that switches the execution mode of several `serviceability/sa` tests to `driver`? all these tests seem not to perform actual testing, and just organize other JDK executions and validates their outputs.

`ClhsdbDumpclass.java` had to be updated to have access to `./jdk/test/lib/apps/LingeredApp.class` file. Although this also can be fixed by propagating the classpath setting to `javap`, using the path to `.class` file is more clear and relable, and I actually suspect that before `javap` read not the dumped `.class` file, but the one from the test's classpath.

Thanks,
-- Igor

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

Commit messages:
 - use path to .class file in ClhsdbDumpclass
 - update copyright year
 - 8268539

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 10:33:21 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 10:33:21 GMT
Subject: RFR: 8268542: serviceability/logging/TestFullNames.java tests only
 1st test case
Message-ID: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>

Hi all,

could you please review this small fix for `serviceability/logging/TestFullNames.java` test?
from JBS:
> serviceability/logging/TestFullNames.java test contains two test cases: specifying filename w/ and w/o "file=" prefix. yet, the test doesn't remove the file, hence its 2nd test case doesn't really test much.

the patch simply calls `File::delete` inside the loop and verifies that the file doesn't exist at the beginning of each iteration.

testing: `serviceability/logging/TestFullNames.java` on `{linux,windows,macosx}-x64`

Thanks,
-- Igor

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

Commit messages:
 - 8268542

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

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

From github.com+1964054+unclenine at openjdk.java.net  Thu Jun 10 12:28:37 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Thu, 10 Jun 2021 12:28:37 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v5]
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

UncleNine 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:

  8268361: Fix the infinite loop in next_line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4378/files
  - new: https://git.openjdk.java.net/jdk/pull/4378/files/e4f90ebd..f5684062

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

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

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

From dcubed at openjdk.java.net  Thu Jun 10 13:04:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 13:04:40 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v4]
In-Reply-To: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
Message-ID: <uE7hTwBGfRWx8jYnZMJqBYYKM9oC4BRXj9Ej75lDrIY=.146cda56-92d9-4bff-a140-bc510b69256b@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 tested via Mach5 Tier[134567].
> They have also been test by my Stress Kit runs for jdk-17+2[0-5].

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

  dholmes CR - fix indent on usage() calls.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4237/files
  - new: https://git.openjdk.java.net/jdk/pull/4237/files/5c2633dd..2daef5aa

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

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 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 dcubed at openjdk.java.net  Thu Jun 10 13:04:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 13:04:41 GMT
Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based
 to time based [v3]
In-Reply-To: <9XZwKF1ewPtfgMAoVxuetYqllxp_hJmjhoQRnTR_dxQ=.db6b1c69-7753-4b38-96b8-22d1250940e3@github.com>
References: <Xf9OVa-F9q6M9qdqNfNcgC7EW3aWtfsY0pDqYOAMaTA=.b535bfb9-a369-49de-bed1-1679ec3e1668@github.com>
 <_fTXjBTs6jP2nqPEZHBihukp3zoGo76YRmry-wqufME=.87e63cf6-fc75-482b-803f-cbd65cabcf3d@github.com>
 <9XZwKF1ewPtfgMAoVxuetYqllxp_hJmjhoQRnTR_dxQ=.db6b1c69-7753-4b38-96b8-22d1250940e3@github.com>
Message-ID: <39sopRkDtSzPKiMzI3kFh-mGIHrdGtojPLx8C8gzhNY=.9f5a9160-fbb6-416a-8aa0-c1e19be9a0f1@github.com>

On Wed, 9 Jun 2021 01:51:59 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:
>> 
>>   ProblemList vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java until 8264605 is fixed and vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java until 8266593 is fixed.
>
> Hi Dan,
> 
> This all seems okay. Sorry it took so long to get to it.
> 
> Note: All the usage() calls are indented incorrectly.
> 
> Thanks,
> David

@dholmes-ora - Thanks for the review! I fixed the indent on the usage() calls.

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

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

From dcubed at openjdk.java.net  Thu Jun 10 13:12:20 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 13:12:20 GMT
Subject: Integrated: 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: <KnUp14t4H6pX70ZWbauUeetC7oeE5KSunfIp_vy3MEc=.1deb7cf3-652b-4873-8728-1a4fef2c04a7@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-5].

This pull request has now been integrated.

Changeset: f677163b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f677163b8aad13781be51839f27742c2213896d1
Stats:     983 lines in 21 files changed: 398 ins; 291 del; 294 mod

8266130: convert Thread-SMR stress tests from counter based to time based

Reviewed-by: cjplummer, dholmes

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 14:45:55 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 14:45:55 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v5]
In-Reply-To: <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
Message-ID: <auRIymbWi9siOPH6Mb2zdsQqupQiFuMqR7SiHCO_Y3g=.5bf75b4f-909c-4199-b632-3b7c64000883@github.com>

On Thu, 10 Jun 2021 12:28:37 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine 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:
> 
>   8268361: Fix the infinite loop in next_line

Marked as reviewed by sspitsyn (Reviewer).

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 14:46:59 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 14:46:59 GMT
Subject: RFR: 8268542: serviceability/logging/TestFullNames.java tests
 only 1st test case
In-Reply-To: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
References: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
Message-ID: <Q70rU2KzaGcbeBqXmp0fxoC4lTUmR3ut4sWhQy0pKZQ=.10124010-315e-49c5-957a-5622cab91b66@github.com>

On Thu, 10 Jun 2021 10:26:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small fix for `serviceability/logging/TestFullNames.java` test?
> from JBS:
>> serviceability/logging/TestFullNames.java test contains two test cases: specifying filename w/ and w/o "file=" prefix. yet, the test doesn't remove the file, hence its 2nd test case doesn't really test much.
> 
> the patch simply calls `File::delete` inside the loop and verifies that the file doesn't exist at the beginning of each iteration.
> 
> testing: `serviceability/logging/TestFullNames.java` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Thanks, Serguei!

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

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

From sspitsyn at openjdk.java.net  Thu Jun 10 14:46:58 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 14:46:58 GMT
Subject: RFR: 8268542: serviceability/logging/TestFullNames.java tests
 only 1st test case
In-Reply-To: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
References: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
Message-ID: <JumBRr9VSPH6L1QlfefQSasRGWw2i31Rmn_kH-yxboo=.bc809670-08d4-4c86-91b9-e7880f1ecc35@github.com>

On Thu, 10 Jun 2021 10:26:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small fix for `serviceability/logging/TestFullNames.java` test?
> from JBS:
>> serviceability/logging/TestFullNames.java test contains two test cases: specifying filename w/ and w/o "file=" prefix. yet, the test doesn't remove the file, hence its 2nd test case doesn't really test much.
> 
> the patch simply calls `File::delete` inside the loop and verifies that the file doesn't exist at the beginning of each iteration.
> 
> testing: `serviceability/logging/TestFullNames.java` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 14:46:59 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 14:46:59 GMT
Subject: Integrated: 8268542: serviceability/logging/TestFullNames.java tests
 only 1st test case
In-Reply-To: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
References: <_UwAr-Kvbx62S--IDtgcXZwBIBwbJIjyZlSeupMy7YU=.51b4886c-9c6c-4e0a-8f10-880c605cc237@github.com>
Message-ID: <bk0yzoS6M7TqFRncVfx1SVsX89MxsouifgOTRqS-yRg=.be7bbe58-7a6d-41b3-897e-2abef462704b@github.com>

On Thu, 10 Jun 2021 10:26:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small fix for `serviceability/logging/TestFullNames.java` test?
> from JBS:
>> serviceability/logging/TestFullNames.java test contains two test cases: specifying filename w/ and w/o "file=" prefix. yet, the test doesn't remove the file, hence its 2nd test case doesn't really test much.
> 
> the patch simply calls `File::delete` inside the loop and verifies that the file doesn't exist at the beginning of each iteration.
> 
> testing: `serviceability/logging/TestFullNames.java` on `{linux,windows,macosx}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 74007890
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/74007890bb9a3fa3a65683a3f480e399f2b1a0b6
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8268542: serviceability/logging/TestFullNames.java tests only 1st test case

Reviewed-by: sspitsyn

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

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

From sgehwolf at openjdk.java.net  Thu Jun 10 14:53:50 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 10 Jun 2021 14:53:50 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v5]
In-Reply-To: <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
Message-ID: <In8ypWYhiVQ-x8xsFAgGPD_6eaTKcWeZ-jU7ppejNAA=.7da1adb3-54eb-46e9-92d7-91bff18385da@github.com>

On Thu, 10 Jun 2021 12:28:37 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine 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:
> 
>   8268361: Fix the infinite loop in next_line

LGTM. Thanks for your patience!

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

Marked as reviewed by sgehwolf (Reviewer).

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

From sspitsyn at openjdk.java.net  Thu Jun 10 15:44:54 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 15:44:54 GMT
Subject: RFR: 8268539: several serviceability/sa tests should be run in
 driver mode
In-Reply-To: <Rq8W8uOBi7rcLOVkBX-iwOS7IRCs1VoqoTyV8WGdTSY=.0c05fcf4-0a83-4f6d-a71c-3603106362e6@github.com>
References: <Rq8W8uOBi7rcLOVkBX-iwOS7IRCs1VoqoTyV8WGdTSY=.0c05fcf4-0a83-4f6d-a71c-3603106362e6@github.com>
Message-ID: <PJjHmPoYrqsBjmYCP0IRi1goAnzTJhQQKG9gncrBKcg=.53f091f3-de1f-4a46-808b-d94ed99859db@github.com>

On Thu, 10 Jun 2021 10:07:48 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this _test-only_ patch that switches the execution mode of several `serviceability/sa` tests to `driver`? all these tests seem not to perform actual testing, and just organize other JDK executions and validates their outputs.
> 
> `ClhsdbDumpclass.java` had to be updated to have access to `./jdk/test/lib/apps/LingeredApp.class` file. Although this also can be fixed by propagating the classpath setting to `javap`, using the path to `.class` file is more clear and relable, and I actually suspect that before `javap` read not the dumped `.class` file, but the one from the test's classpath.
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

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

From github.com+1964054+unclenine at openjdk.java.net  Thu Jun 10 16:44:09 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Thu, 10 Jun 2021 16:44:09 GMT
Subject: Integrated: 8268361: Fix the infinite loop in next_line
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <QhiomFYy9kvqtflAKLYC5uwL5rO5Ju6KpqO5AiCR43I=.379d2f6f-8aa2-4023-9fce-b48e0242d71b@github.com>

On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

This pull request has now been integrated.

Changeset: 72672277
Author:    UncleNine <ganjianxuan at hotmail.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/72672277e4dddf8e72f1c705cd5f57de40745635
Stats:     15 lines in 1 file changed: 11 ins; 0 del; 4 mod

8268361: Fix the infinite loop in next_line

Reviewed-by: dholmes, sgehwolf, sspitsyn

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 16:49:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 16:49:55 GMT
Subject: Withdrawn: 8268531: mark SDTProbesGNULinuxTest as ignoring external
 VM flags
In-Reply-To: <yS49iX150Fb_9l67LPHj1XBxuhLTKdaaJcyl6a9YyJk=.19d73c42-a1ec-405b-b758-3425f7eda4cd@github.com>
References: <yS49iX150Fb_9l67LPHj1XBxuhLTKdaaJcyl6a9YyJk=.19d73c42-a1ec-405b-b758-3425f7eda4cd@github.com>
Message-ID: <2B4hVGCUH_43R9Y-KmL5VWb5HFkx2u474QQ_8wupMl4=.9af38bb2-d7b3-4666-9dfb-4ea66bbb2b7e@github.com>

On Thu, 10 Jun 2021 07:24:26 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this patch that adds `@requires vm.flagless` to `SDTProbesGNULinuxTest` test as it ignores all external VM flags?
> 
> Thanks,
> -- Igor

This pull request has been closed without being integrated.

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 16:49:55 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 16:49:55 GMT
Subject: RFR: 8268531: mark SDTProbesGNULinuxTest as ignoring external VM
 flags
In-Reply-To: <yS49iX150Fb_9l67LPHj1XBxuhLTKdaaJcyl6a9YyJk=.19d73c42-a1ec-405b-b758-3425f7eda4cd@github.com>
References: <yS49iX150Fb_9l67LPHj1XBxuhLTKdaaJcyl6a9YyJk=.19d73c42-a1ec-405b-b758-3425f7eda4cd@github.com>
Message-ID: <Srg3VTN5zb06etGWXqqF4qrTYozyKvx0yuWj-W4bVA8=.ebe5a5fc-8d50-4161-9b17-9a6b1a43e102@github.com>

On Thu, 10 Jun 2021 07:24:26 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this patch that adds `@requires vm.flagless` to `SDTProbesGNULinuxTest` test as it ignores all external VM flags?
> 
> Thanks,
> -- Igor

closed in favor of openjdk/jdk17#1

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 16:54:13 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 16:54:13 GMT
Subject: [jdk17] RFR: 8268531: mark SDTProbesGNULinuxTest as ignoring external
 VM flags
Message-ID: <C1aC0zk7zqFZf4jdCA-uTCeXa4qon0QrzX8Tq-CfjMM=.6948af6f-ee85-48f4-9785-f52b7ca76362@github.com>

(recreating openjdk/jdk#4453 against jdk17)

Hi all,

could you please review this patch that adds `@requires vm.flagless` to `SDTProbesGNULinuxTest` test as it ignores all external VM flags?

Thanks,
-- Igor

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

Commit messages:
 - update copyright year
 - 8268531

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

PR: https://git.openjdk.java.net/jdk17/pull/1

From dcubed at openjdk.java.net  Thu Jun 10 17:06:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 17:06:59 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <TkqpsyvpwXIwnmpS3wgGhjPxJNp2NW98fENawOLBrqU=.47a263cd-3e5c-4f7b-ba0c-24ac07357eb5@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

This PR is for https://bugs.openjdk.java.net/browse/JDK-8268286 which is a
subtask of https://bugs.openjdk.java.net/browse/JDK-8268283. So the bug
is described by:

    JDK-8268283 serviceability/sa/TestJmapCore.java failed with zgc on linux-aarch64 after JDK-8266957

Hopefully that answers your question.

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 17:08:57 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 17:08:57 GMT
Subject: RFR: 8268539: several serviceability/sa tests should be run in
 driver mode
In-Reply-To: <Rq8W8uOBi7rcLOVkBX-iwOS7IRCs1VoqoTyV8WGdTSY=.0c05fcf4-0a83-4f6d-a71c-3603106362e6@github.com>
References: <Rq8W8uOBi7rcLOVkBX-iwOS7IRCs1VoqoTyV8WGdTSY=.0c05fcf4-0a83-4f6d-a71c-3603106362e6@github.com>
Message-ID: <cwS0dpcngJ7Qbk_12qH5TOKyoGYsd_8bwIcSGe_6pUw=.3439be6a-16ea-4424-a3eb-c86769ed84e6@github.com>

On Thu, 10 Jun 2021 10:07:48 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this _test-only_ patch that switches the execution mode of several `serviceability/sa` tests to `driver`? all these tests seem not to perform actual testing, and just organize other JDK executions and validates their outputs.
> 
> `ClhsdbDumpclass.java` had to be updated to have access to `./jdk/test/lib/apps/LingeredApp.class` file. Although this also can be fixed by propagating the classpath setting to `javap`, using the path to `.class` file is more clear and relable, and I actually suspect that before `javap` read not the dumped `.class` file, but the one from the test's classpath.
> 
> Thanks,
> -- Igor

Thank you, Serguie.

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 17:08:58 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 17:08:58 GMT
Subject: Integrated: 8268539: several serviceability/sa tests should be run in
 driver mode
In-Reply-To: <Rq8W8uOBi7rcLOVkBX-iwOS7IRCs1VoqoTyV8WGdTSY=.0c05fcf4-0a83-4f6d-a71c-3603106362e6@github.com>
References: <Rq8W8uOBi7rcLOVkBX-iwOS7IRCs1VoqoTyV8WGdTSY=.0c05fcf4-0a83-4f6d-a71c-3603106362e6@github.com>
Message-ID: <ILu2NzuiccnOAFSsHwNrbX7SedXjwjVkwvhCIFKip-8=.23dfc0ef-57f6-45aa-b316-20a4fe9c0312@github.com>

On Thu, 10 Jun 2021 10:07:48 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this _test-only_ patch that switches the execution mode of several `serviceability/sa` tests to `driver`? all these tests seem not to perform actual testing, and just organize other JDK executions and validates their outputs.
> 
> `ClhsdbDumpclass.java` had to be updated to have access to `./jdk/test/lib/apps/LingeredApp.class` file. Although this also can be fixed by propagating the classpath setting to `javap`, using the path to `.class` file is more clear and relable, and I actually suspect that before `javap` read not the dumped `.class` file, but the one from the test's classpath.
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 78cb6776
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/78cb6776b6d43b67457993a109719b36ee892d60
Stats:     40 lines in 23 files changed: 0 ins; 0 del; 40 mod

8268539: several serviceability/sa tests should be run in driver mode

Reviewed-by: sspitsyn

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 17:22:37 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 17:22:37 GMT
Subject: [jdk17] Integrated: 8268539: several serviceability/sa tests should
 be run in driver mode
Message-ID: <7QOAeB32Hz1vKTBjaakhRTy2WNmvnFggQIS3PBZgpoE=.8551dc2d-3220-4f40-ade8-17a79668981a@github.com>

8268539: several serviceability/sa tests should be run in driver mode

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

Commit messages:
 - 8268539

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

PR: https://git.openjdk.java.net/jdk17/pull/4

From iignatyev at openjdk.java.net  Thu Jun 10 17:22:38 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 17:22:38 GMT
Subject: [jdk17] Integrated: 8268539: several serviceability/sa tests should
 be run in driver mode
In-Reply-To: <7QOAeB32Hz1vKTBjaakhRTy2WNmvnFggQIS3PBZgpoE=.8551dc2d-3220-4f40-ade8-17a79668981a@github.com>
References: <7QOAeB32Hz1vKTBjaakhRTy2WNmvnFggQIS3PBZgpoE=.8551dc2d-3220-4f40-ade8-17a79668981a@github.com>
Message-ID: <I8XrHvcRHnG-QDUDhpoSCszwCYhD1DbW7m1Iyn1fh24=.58588fe4-212c-4017-a20a-59f67c8bfddb@github.com>

On Thu, 10 Jun 2021 17:11:15 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> 8268539: several serviceability/sa tests should be run in driver mode

This pull request has now been integrated.

Changeset: 5b8c51f5
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/5b8c51f59a5f23930ee43bea30201c1ff88c44cd
Stats:     40 lines in 23 files changed: 0 ins; 0 del; 40 mod

8268539: several serviceability/sa tests should be run in driver mode

Backport-of: 78cb6776b6d43b67457993a109719b36ee892d60

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

PR: https://git.openjdk.java.net/jdk17/pull/4

From lmesnik at openjdk.java.net  Thu Jun 10 17:44:53 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 10 Jun 2021 17:44:53 GMT
Subject: Integrated: 8268223: Problemlist
 vmTestbase/nsk/jdi/HiddenClass/events/events001.java
In-Reply-To: <ZiuwihWNeilsVSxQHJBoPh989fI2TU3fV12dvSjyqTA=.dfa92023-ecff-4245-9a40-b0c56d5b14b8@github.com>
References: <ZiuwihWNeilsVSxQHJBoPh989fI2TU3fV12dvSjyqTA=.dfa92023-ecff-4245-9a40-b0c56d5b14b8@github.com>
Message-ID: <WVfdjAJZo6VJnZWMJQ-6_l3itqapZMEosnLqnh9Yozg=.a815531b-ae68-4daa-a524-6e24aefefc14@github.com>

On Wed, 9 Jun 2021 19:04:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Exclude vmTestbase/nsk/jdi/HiddenClass/events/events001.java.

This pull request has now been integrated.

Changeset: 1e1039a7
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1e1039a7c8bbd745cb23fd91e548dc20ac7d1d9d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8268223: Problemlist vmTestbase/nsk/jdi/HiddenClass/events/events001.java

Reviewed-by: amenkov, sspitsyn

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

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

From cjplummer at openjdk.java.net  Thu Jun 10 17:48:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Jun 2021 17:48:56 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <cDN4dVSUCkFPfQbuKpxZg4xYoD1zdGVnGdX9mxEj6zA=.fe85c7c5-168e-41cd-97e5-c07a879916f9@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

@theRealAph Also, it seems to fail about 25% of the time, so not surprising if you didn't see it fail unless you ran it at least a few times.

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

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

From iignatyev at openjdk.java.net  Thu Jun 10 18:16:27 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 18:16:27 GMT
Subject: [jdk17] RFR: 8268541: mark hotspot serviceability/sa tests which
 ignore external VM flags
Message-ID: <0JMudBx7rHdMvFb4W5XAUH2G7u8L0Cv83uyzCJXwfxA=.afb14361-1f4d-4032-852d-a570cdb1882d@github.com>

Hi all,

could you please review this one-liner that adds `@requires vm.flagless` to `serviceability/sa/TestJhsdbJstackLineNumbers.java` as it ignores external VM flags?

Thanks,
-- Igor

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

Commit messages:
 - 8268541

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

PR: https://git.openjdk.java.net/jdk17/pull/6

From iignatyev at openjdk.java.net  Thu Jun 10 18:26:43 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 18:26:43 GMT
Subject: [jdk17] RFR: 8268563: mark hotspot serviceability/jvmti tests which
 ignore external VM flags
Message-ID: <IekXJ-vx7hpk3VZcVmQMdB24iA4wN2pWjIgSTOZGZis=.4ec6debc-0d05-4d7d-9958-cce3108eab14@github.com>

Hi all,

could you please review this one-liner that adds `@requires vm.flagless` to 6 `serviceability/jvmti` tests that ignore external VM flags?

Thanks,
-- Igor

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

Commit messages:
 - update copyright year
 - 8268563

Changes: https://git.openjdk.java.net/jdk17/pull/7/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=7&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268563
  Stats: 8 lines in 6 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/7.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/7/head:pull/7

PR: https://git.openjdk.java.net/jdk17/pull/7

From iignatyev at openjdk.java.net  Thu Jun 10 18:32:12 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 10 Jun 2021 18:32:12 GMT
Subject: [jdk17] RFR: 8268564: mark hotspot serviceability/attach tests which
 ignore external VM flags
Message-ID: <MmjBcrBBc-QrjY6GKR8Ni_XxUv-eqt1cgfiV8JUUvdI=.04c71097-a1ad-41c6-9a70-d6387fcc61f2@github.com>

Hi all,

could you please review this one-liner that adds `@requires vm.flagless` to 2 `serviceability/attach` tests that ignore external VM flags?

Thanks,
-- Igor

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

Commit messages:
 - 8268564

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

PR: https://git.openjdk.java.net/jdk17/pull/8

From cjplummer at openjdk.java.net  Thu Jun 10 21:29:52 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Jun 2021 21:29:52 GMT
Subject: [jdk17] RFR: 8268564: mark hotspot serviceability/attach tests
 which ignore external VM flags
In-Reply-To: <MmjBcrBBc-QrjY6GKR8Ni_XxUv-eqt1cgfiV8JUUvdI=.04c71097-a1ad-41c6-9a70-d6387fcc61f2@github.com>
References: <MmjBcrBBc-QrjY6GKR8Ni_XxUv-eqt1cgfiV8JUUvdI=.04c71097-a1ad-41c6-9a70-d6387fcc61f2@github.com>
Message-ID: <rrOtXUX8FWok3_fN0tn3hOjws5m_hXxr_N0b235izwg=.b0af73eb-0904-4ae2-a4b7-189eec8e4649@github.com>

On Thu, 10 Jun 2021 18:23:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner that adds `@requires vm.flagless` to 2 `serviceability/attach` tests that ignore external VM flags?
> 
> Thanks,
> -- Igor

Can you explain a bit more how `@requires vm.flagless` works? The way I read it, that would indicate that the test should not be run if any flags are specified. I'm not sure why you would want to do that. I understand that the test itself launches a subprocess without passing on the flags, but I don't see why that would preclude running the test if any flags are specified.

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

PR: https://git.openjdk.java.net/jdk17/pull/8

From dcubed at openjdk.java.net  Thu Jun 10 23:12:12 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 23:12:12 GMT
Subject: Integrated: 8268574: ProblemList tests failing due to
 UseBiasedLocking going away
Message-ID: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>

A trivial fix to ProblemList tests failing due to UseBiasedLocking going away

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

Commit messages:
 - 8268574: ProblemList tests failing due to UseBiasedLocking going away

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

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

From cjplummer at openjdk.java.net  Thu Jun 10 23:12:12 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Jun 2021 23:12:12 GMT
Subject: Integrated: 8268574: ProblemList tests failing due to
 UseBiasedLocking going away
In-Reply-To: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>
References: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>
Message-ID: <C5ebZOvYB0K-ZPyN-7QZkZjA___eXf5wLDbels1_qHo=.63d8e2d2-71a6-417f-afa3-41b7b2058153@github.com>

On Thu, 10 Jun 2021 22:59:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tests failing due to UseBiasedLocking going away

Marked as reviewed by cjplummer (Reviewer).

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

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

From dcubed at openjdk.java.net  Thu Jun 10 23:12:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 23:12:13 GMT
Subject: Integrated: 8268574: ProblemList tests failing due to
 UseBiasedLocking going away
In-Reply-To: <C5ebZOvYB0K-ZPyN-7QZkZjA___eXf5wLDbels1_qHo=.63d8e2d2-71a6-417f-afa3-41b7b2058153@github.com>
References: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>
 <C5ebZOvYB0K-ZPyN-7QZkZjA___eXf5wLDbels1_qHo=.63d8e2d2-71a6-417f-afa3-41b7b2058153@github.com>
Message-ID: <Rye1FjuORu87GCLXOYs1ne1rbDqIdM_QL2hO7FY0OSI=.af8a1922-6537-469b-8fa4-dc57d8adab4a@github.com>

On Thu, 10 Jun 2021 23:06:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A trivial fix to ProblemList tests failing due to UseBiasedLocking going away
>
> Marked as reviewed by cjplummer (Reviewer).

@plummercj - Thanks for the fast review!

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

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

From dcubed at openjdk.java.net  Thu Jun 10 23:12:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Jun 2021 23:12:13 GMT
Subject: Integrated: 8268574: ProblemList tests failing due to
 UseBiasedLocking going away
In-Reply-To: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>
References: <6p04zpap9ZXqdCpyOBqjuyvm3OCq2XQIXSlpcqO2is8=.f10ae69d-7184-4950-906d-d83a8e4382e3@github.com>
Message-ID: <KcVlmv_9F_49363-vyTPcMhlD8gNgM5jKdtVX3ujxrg=.25981c11-3430-40b0-a3b9-d1d6383161d6@github.com>

On Thu, 10 Jun 2021 22:59:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tests failing due to UseBiasedLocking going away

This pull request has now been integrated.

Changeset: 2e900da5
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2e900da5f70105c153500908c693b2601fa30477
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8268574: ProblemList tests failing due to UseBiasedLocking going away

Reviewed-by: cjplummer

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

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

From iignatyev at openjdk.java.net  Fri Jun 11 03:05:54 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 11 Jun 2021 03:05:54 GMT
Subject: [jdk17] RFR: 8268564: mark hotspot serviceability/attach tests
 which ignore external VM flags
In-Reply-To: <rrOtXUX8FWok3_fN0tn3hOjws5m_hXxr_N0b235izwg=.b0af73eb-0904-4ae2-a4b7-189eec8e4649@github.com>
References: <MmjBcrBBc-QrjY6GKR8Ni_XxUv-eqt1cgfiV8JUUvdI=.04c71097-a1ad-41c6-9a70-d6387fcc61f2@github.com>
 <rrOtXUX8FWok3_fN0tn3hOjws5m_hXxr_N0b235izwg=.b0af73eb-0904-4ae2-a4b7-189eec8e4649@github.com>
Message-ID: <WaKkgOxTVShxFCeK1r7CPBXIFQ0Ng0pzMB_M-KOPiVs=.0c8f9de8-5306-4192-890b-dcb73c8c3689@github.com>

On Thu, 10 Jun 2021 21:27:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Can you explain a bit more how `@requires vm.flagless` works? The way I read it, that would indicate that the test should not be run if any flags are specified. I'm not sure why you would want to do that. I understand that the test itself launches a subprocess without passing on the flags, but I don't see why that would preclude running the test if any flags are specified.

Hi Chris,

sure, you have read it correctly -- `@requires vm.flagless` excludes a test from execution if "any" flags are specified. there are two main reasons to do that: a) a test is very sensitive to the testing configuration and nearly any changes to the configuration render the test invalid; b) a test ignores all external flags, hence running it w/ any is a waste and misleading. in the case of this patch (as well as other sub-tasks of [8246500](https://bugs.openjdk.java.net/browse/JDK-8246500)), it's the latter.

you can read more about `vm.flagless` and the motivation in the main-main [bug](https://bugs.openjdk.java.net/browse/JDK-8151707) and/or the original [discussion](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/041981.html) on hotspot-dev.

Cheers,
-- Igor

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

PR: https://git.openjdk.java.net/jdk17/pull/8

From dholmes at openjdk.java.net  Fri Jun 11 05:57:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 05:57:52 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>
 <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>
Message-ID: <Kv8KnBc7lUvbzDI5UI3IBkwPnDaAS4YhCSUFAssV4UM=.d02beb23-121d-4654-8020-7ec24f0d9559@github.com>

On Tue, 8 Jun 2021 16:28:34 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>> 
>> In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?
>
>> > If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>> 
>> In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?
> 
> In my case, it happened in the container environment.
> the /proc filesystem of the container is provided by lxcfs, but a lxcfs bug may make the /proc/stat mount point change.
> It was caused by a lxcfs-3.1.2 segment fault's exit

@UncleNine  please do not force push commits to an open PR as it makes it difficult for reviewers to track the changes. The PR can contain as many commits as you like as it will all be squashed to a single clean commit when integrating. Thanks.

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

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

From stuefe at openjdk.java.net  Fri Jun 11 06:12:54 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Jun 2021 06:12:54 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v5]
In-Reply-To: <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
Message-ID: <E1tsE1XsM61cTlwRahGwdd6WjJuJ8OtlycQxjk5lMkg=.f876d177-de2a-43c8-b38d-44bd4bb4a8c4@github.com>

On Thu, 10 Jun 2021 12:28:37 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine 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:
> 
>   8268361: Fix the infinite loop in next_line

Would it not be better to read the whole content of /proc/stat with a single read() call instead of line by line? I don't think proc fs guarantees any kind of consistency with separate reads.

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

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

From aph at openjdk.java.net  Fri Jun 11 09:00:54 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 11 Jun 2021 09:00:54 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <EnBO1NsLp7njPTkEcS74PHiJD0Yns11Iz4aORoOIR1E=.80b3bd51-f0b8-4137-9ce5-0488e3362169@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

Sort of. I'm trying to understand what can be AArch64-specific about any of this. If it's an AArch64-back-end-specific bug I'd like to know.

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

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

From dcubed at openjdk.java.net  Fri Jun 11 16:24:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Jun 2021 16:24:59 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <sQhvWdLUIgdqQLe0wsiTJlVwdhT5Jutap7d74qy1V6s=.2ebd2b3a-210e-4eab-a1b0-08d7ee8247e7@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

It's only ProblemListed on linux-aarch64 because that's the only place
where we've seen the issue in Mach5. It's just that simple. Doesn't mean
that it won't show up on any other config with enough runs.

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

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

From sspitsyn at openjdk.java.net  Fri Jun 11 17:48:00 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 11 Jun 2021 17:48:00 GMT
Subject: [jdk17] RFR: 8268531: mark SDTProbesGNULinuxTest as ignoring
 external VM flags
In-Reply-To: <C1aC0zk7zqFZf4jdCA-uTCeXa4qon0QrzX8Tq-CfjMM=.6948af6f-ee85-48f4-9785-f52b7ca76362@github.com>
References: <C1aC0zk7zqFZf4jdCA-uTCeXa4qon0QrzX8Tq-CfjMM=.6948af6f-ee85-48f4-9785-f52b7ca76362@github.com>
Message-ID: <iYKHdRRXZII_HZK3rhoAOMkx3lXzXWrV42Si8HeNkG4=.c4f0b065-f3fd-4149-8d48-99ddf9885e33@github.com>

On Thu, 10 Jun 2021 16:46:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> (recreating openjdk/jdk#4453 against jdk17)
> 
> Hi all,
> 
> could you please review this patch that adds `@requires vm.flagless` to `SDTProbesGNULinuxTest` test as it ignores all external VM flags?
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/1

From sspitsyn at openjdk.java.net  Fri Jun 11 17:56:57 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 11 Jun 2021 17:56:57 GMT
Subject: [jdk17] RFR: 8268541: mark hotspot serviceability/sa tests which
 ignore external VM flags
In-Reply-To: <0JMudBx7rHdMvFb4W5XAUH2G7u8L0Cv83uyzCJXwfxA=.afb14361-1f4d-4032-852d-a570cdb1882d@github.com>
References: <0JMudBx7rHdMvFb4W5XAUH2G7u8L0Cv83uyzCJXwfxA=.afb14361-1f4d-4032-852d-a570cdb1882d@github.com>
Message-ID: <PHyNyHE95vS9qHEnFpw4tprCSWPUITiUo_zAWur80Yg=.84bd47e2-ca91-4073-86d0-1d49ba650fc0@github.com>

On Thu, 10 Jun 2021 18:08:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner that adds `@requires vm.flagless` to `serviceability/sa/TestJhsdbJstackLineNumbers.java` as it ignores external VM flags?
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/6

From sspitsyn at openjdk.java.net  Fri Jun 11 18:01:58 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 11 Jun 2021 18:01:58 GMT
Subject: [jdk17] RFR: 8268563: mark hotspot serviceability/jvmti tests
 which ignore external VM flags
In-Reply-To: <IekXJ-vx7hpk3VZcVmQMdB24iA4wN2pWjIgSTOZGZis=.4ec6debc-0d05-4d7d-9958-cce3108eab14@github.com>
References: <IekXJ-vx7hpk3VZcVmQMdB24iA4wN2pWjIgSTOZGZis=.4ec6debc-0d05-4d7d-9958-cce3108eab14@github.com>
Message-ID: <915_PlmUhp_dNQ6KOivCZ7azBxo0OnQGPPk2lAFnZX0=.318c8390-7414-4bb1-bb30-ab6eb66721a8@github.com>

On Thu, 10 Jun 2021 18:19:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner that adds `@requires vm.flagless` to 6 `serviceability/jvmti` tests that ignore external VM flags?
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/7

From sspitsyn at openjdk.java.net  Fri Jun 11 18:02:48 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 11 Jun 2021 18:02:48 GMT
Subject: [jdk17] RFR: 8268564: mark hotspot serviceability/attach tests
 which ignore external VM flags
In-Reply-To: <MmjBcrBBc-QrjY6GKR8Ni_XxUv-eqt1cgfiV8JUUvdI=.04c71097-a1ad-41c6-9a70-d6387fcc61f2@github.com>
References: <MmjBcrBBc-QrjY6GKR8Ni_XxUv-eqt1cgfiV8JUUvdI=.04c71097-a1ad-41c6-9a70-d6387fcc61f2@github.com>
Message-ID: <AzC4bep7fRiYJSQHISjvIQOOhPWv5knBqGLcUGiSI0M=.958097a4-c77b-47be-9229-0fa94a497989@github.com>

On Thu, 10 Jun 2021 18:23:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner that adds `@requires vm.flagless` to 2 `serviceability/attach` tests that ignore external VM flags?
> 
> Thanks,
> -- Igor

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/8

From amenkov at openjdk.java.net  Fri Jun 11 19:46:02 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 11 Jun 2021 19:46:02 GMT
Subject: [jdk17] RFR: 8268433:
 serviceability/dcmd/framework/VMVersionTest.java fails with Unable to send
 object throw not established PipeIO Listener Thread connection
Message-ID: <SWTjfusblemekxL30ESme75xseVIwBxCg1bUdeX0h7o=.a132b9f5-c710-4647-979d-2c13fe67866a@github.com>

The fix adds check that IOPipe is connected before sending "quit" command

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

Commit messages:
 - Added check that IOPipe is connected

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

PR: https://git.openjdk.java.net/jdk17/pull/32

From erikj at openjdk.java.net  Fri Jun 11 20:22:10 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 11 Jun 2021 20:22:10 GMT
Subject: [jdk17] RFR: 8268630: ProblemList
 serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64
In-Reply-To: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>
References: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>
Message-ID: <lBToA8OUmklbNT4w2NlbnoY3KTWs8EtftIJK7kqsvnM=.c7a4123f-761d-4079-925c-bfb58b816c03@github.com>

On Fri, 11 Jun 2021 20:11:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Target is JDK17:
> A trivial fix to ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64.

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/33

From dcubed at openjdk.java.net  Fri Jun 11 20:22:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Jun 2021 20:22:10 GMT
Subject: [jdk17] RFR: 8268630: ProblemList
 serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64
Message-ID: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>

Target is JDK17:
A trivial fix to ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64.

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

Commit messages:
 - 8268630: ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64

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

PR: https://git.openjdk.java.net/jdk17/pull/33

From dcubed at openjdk.java.net  Fri Jun 11 20:27:52 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Jun 2021 20:27:52 GMT
Subject: [jdk17] Integrated: 8268630: ProblemList
 serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64
In-Reply-To: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>
References: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>
Message-ID: <K3BukckOSBOvc9YwKH1hUFK4OB3q7z2iWu5JzbeZ50U=.32f50b87-a11c-4182-87cf-00ea0ffa959d@github.com>

On Fri, 11 Jun 2021 20:11:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Target is JDK17:
> A trivial fix to ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64.

This pull request has now been integrated.

Changeset: 6171ae45
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/6171ae455288a74c4c3dcec6983515db04bdc360
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8268630: ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64

Reviewed-by: erikj

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

PR: https://git.openjdk.java.net/jdk17/pull/33

From dcubed at openjdk.java.net  Fri Jun 11 20:27:51 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 11 Jun 2021 20:27:51 GMT
Subject: [jdk17] RFR: 8268630: ProblemList
 serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64
In-Reply-To: <lBToA8OUmklbNT4w2NlbnoY3KTWs8EtftIJK7kqsvnM=.c7a4123f-761d-4079-925c-bfb58b816c03@github.com>
References: <i8AGksPNre_nezWbJla2PeRYMXeB0sDfsJPy0cWi0dE=.d841a8d0-cb36-4698-a610-31647698f227@github.com>
 <lBToA8OUmklbNT4w2NlbnoY3KTWs8EtftIJK7kqsvnM=.c7a4123f-761d-4079-925c-bfb58b816c03@github.com>
Message-ID: <BO0nwEoQzoQj6S-z85pQ0y5qxNXfxw-NagQsWANkaZk=.d3b295d5-2d3d-4e0f-862d-75adddf3caca@github.com>

On Fri, 11 Jun 2021 20:16:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Target is JDK17:
>> A trivial fix to ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64.
>
> Marked as reviewed by erikj (Reviewer).

@erikj79 - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk17/pull/33

From cjplummer at openjdk.java.net  Fri Jun 11 21:05:50 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 11 Jun 2021 21:05:50 GMT
Subject: RFR: 8268286: ProblemList serviceability/sa/TestJmapCore.java on
 linux-aarch64 with ZGC
In-Reply-To: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
References: <V89ayKg9PPrxE7irGb428QV8TEX5jSqqdBAAiQxFR-g=.042c01a2-7e1e-48e8-aace-f499ce6f9bf9@github.com>
Message-ID: <MrEis4l3FwRX0J6KPUiTttw1HYgVO2Fg83RS5QHVcWY=.899d0f52-17d4-4c34-8505-1feba9383926@github.com>

On Sat, 5 Jun 2021 15:12:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJmapCore.java on linux-aarch64 with ZGC.

This is an SA bug, so it could be an issue with the aarch64 support in SA.

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

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

From sspitsyn at openjdk.java.net  Sat Jun 12 00:40:57 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 12 Jun 2021 00:40:57 GMT
Subject: [jdk17] RFR: 8268433:
 serviceability/dcmd/framework/VMVersionTest.java fails with Unable to send
 object throw not established PipeIO Listener Thread connection
In-Reply-To: <SWTjfusblemekxL30ESme75xseVIwBxCg1bUdeX0h7o=.a132b9f5-c710-4647-979d-2c13fe67866a@github.com>
References: <SWTjfusblemekxL30ESme75xseVIwBxCg1bUdeX0h7o=.a132b9f5-c710-4647-979d-2c13fe67866a@github.com>
Message-ID: <8Uy6lYbc3R5ETXcr4NDbny896AB1zOP5Xq-aXgijQRQ=.c681906a-1e1d-4230-9a47-c49f0500bece@github.com>

On Fri, 11 Jun 2021 19:40:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds check that IOPipe is connected before sending "quit" command

Alex,
It looks okay in general but I wonder if this is racy.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/32

From dcubed at openjdk.java.net  Sat Jun 12 13:56:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 12 Jun 2021 13:56:02 GMT
Subject: Integrated: 8268644: ProblemList
 serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode
Message-ID: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>

A trivial fix to ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode.

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

Commit messages:
 - 8268644: ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode

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

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

From azvegint at openjdk.java.net  Sat Jun 12 13:56:02 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 12 Jun 2021 13:56:02 GMT
Subject: Integrated: 8268644: ProblemList
 serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode
In-Reply-To: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>
References: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>
Message-ID: <4dwImZNFNNS_4ACZiei-NM30OodbKSepiGtGvC9qM6E=.a6a5255c-78c0-4a58-964c-1d53c860d651@github.com>

On Sat, 12 Jun 2021 13:45:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode.

Marked as reviewed by azvegint (Reviewer).

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

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

From dcubed at openjdk.java.net  Sat Jun 12 13:56:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 12 Jun 2021 13:56:02 GMT
Subject: Integrated: 8268644: ProblemList
 serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode
In-Reply-To: <4dwImZNFNNS_4ACZiei-NM30OodbKSepiGtGvC9qM6E=.a6a5255c-78c0-4a58-964c-1d53c860d651@github.com>
References: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>
 <4dwImZNFNNS_4ACZiei-NM30OodbKSepiGtGvC9qM6E=.a6a5255c-78c0-4a58-964c-1d53c860d651@github.com>
Message-ID: <en__U9mtvLfwiQ7ouK6Ub7CbgiGI6x8JkFymA1-zA6Q=.6c9d4c41-b55b-4439-b11e-d6886cb9f58c@github.com>

On Sat, 12 Jun 2021 13:48:51 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode.
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint - Thanks for the fast review!

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

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

From dcubed at openjdk.java.net  Sat Jun 12 13:56:03 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 12 Jun 2021 13:56:03 GMT
Subject: Integrated: 8268644: ProblemList
 serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode
In-Reply-To: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>
References: <pmLFS9kslo7XdnISgVZ0GgW6YvEeZeuUnBayAZPSZeQ=.94dbd1e1-00ae-4913-b9fe-2b0a8582ed83@github.com>
Message-ID: <txcbKEVb7WHs7b4fdfSBpXVjLvODBdcnZ9us80x-Fdc=.c9a271a6-2fbf-487d-aa8b-d39fa9adbf2a@github.com>

On Sat, 12 Jun 2021 13:45:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode.

This pull request has now been integrated.

Changeset: 90c1034c
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/90c1034cd4077e63afc0aad53191a04699a816ce
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8268644: ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode

Reviewed-by: azvegint

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

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

From github.com+1964054+unclenine at openjdk.java.net  Mon Jun 14 14:07:00 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Mon, 14 Jun 2021 14:07:00 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>
 <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>
Message-ID: <RM40ozyMx72Gu1gOh4VjlQxZZcYzXEjPlsWNll-1xco=.104ff07a-7b2c-4558-833e-c32444a3c458@github.com>

On Tue, 8 Jun 2021 16:28:34 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>> 
>> In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?
>
>> > If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>> 
>> In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?
> 
> In my case, it happened in the container environment.
> the /proc filesystem of the container is provided by lxcfs, but a lxcfs bug may make the /proc/stat mount point change.
> It was caused by a lxcfs-3.1.2 segment fault's exit

> @UncleNine please do not force push commits to an open PR as it makes it difficult for reviewers to track the changes. The PR can contain as many commits as you like as it will all be squashed to a single clean commit when integrating. Thanks.

Sorry,

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

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

From github.com+1964054+unclenine at openjdk.java.net  Mon Jun 14 14:07:00 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Mon, 14 Jun 2021 14:07:00 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <RM40ozyMx72Gu1gOh4VjlQxZZcYzXEjPlsWNll-1xco=.104ff07a-7b2c-4558-833e-c32444a3c458@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>
 <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>
 <RM40ozyMx72Gu1gOh4VjlQxZZcYzXEjPlsWNll-1xco=.104ff07a-7b2c-4558-833e-c32444a3c458@github.com>
Message-ID: <NPSNhchp8XP_NVSZXAY7Bg3sL027TbUVPqhYkGt_vP4=.52547659-4297-41dd-9191-d2322e417821@github.com>

On Mon, 14 Jun 2021 14:00:14 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

> @UncleNine please do not force push commits to an open PR as it makes it difficult for reviewers to track the changes. The PR can contain as many commits as you like as it will all be squashed to a single clean commit when integrating. Thanks.

Sorry,

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

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

From github.com+1964054+unclenine at openjdk.java.net  Mon Jun 14 14:14:55 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Mon, 14 Jun 2021 14:14:55 GMT
Subject: RFR: 8268361: Fix the infinite loop in next_line [v5]
In-Reply-To: <E1tsE1XsM61cTlwRahGwdd6WjJuJ8OtlycQxjk5lMkg=.f876d177-de2a-43c8-b38d-44bd4bb4a8c4@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
 <E1tsE1XsM61cTlwRahGwdd6WjJuJ8OtlycQxjk5lMkg=.f876d177-de2a-43c8-b38d-44bd4bb4a8c4@github.com>
Message-ID: <d9HyTfm_vmuR8F3HfrwluRQojY42fZ-QUqtoYkiv1wY=.56d8485a-4628-447f-99f9-9901e479b282@github.com>

On Fri, 11 Jun 2021 06:10:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Would it not be better to read the whole content of /proc/stat with a single read() call instead of line by line? I don't think proc fs guarantees any kind of consistency with separate reads.

yes, so fgetc's return value should need to be checked

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

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

From jwilhelm at openjdk.java.net  Mon Jun 14 14:36:59 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 14 Jun 2021 14:36:59 GMT
Subject: RFR: Merge jdk17
Message-ID: <xzBUEvQWZMw1he1KOtsir6sNOosBxrQ0nBkjLaHKnIo=.5a9dee37-f586-409d-8b8f-6ce915ccf583@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow
 - 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed"
 - 8268630: ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64
 - 8268470: CDS dynamic dump asserts with JFR RecordingStream
 - 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE
 - 8268602: a couple runtime/os tests don't check exit code
 - 8268555: Update HttpClient tests that use ITestContext to jtreg 6+1
 - 8268580: runtime/memory/LargePages/TestLargePagesFlags.java should be run in driver mode
 - 8268565: runtime/records/RedefineRecord.java should be run in driver mode
 - 8268576: jdk/jfr/event/gc/collection/TestSystemGc.java fails
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/74007890...b3185354

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4484/files
  Stats: 786 lines in 57 files changed: 593 ins; 73 del; 120 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4484.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4484/head:pull/4484

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

From dcubed at openjdk.java.net  Mon Jun 14 15:49:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Jun 2021 15:49:59 GMT
Subject: RFR: Merge jdk17
In-Reply-To: <xzBUEvQWZMw1he1KOtsir6sNOosBxrQ0nBkjLaHKnIo=.5a9dee37-f586-409d-8b8f-6ce915ccf583@github.com>
References: <xzBUEvQWZMw1he1KOtsir6sNOosBxrQ0nBkjLaHKnIo=.5a9dee37-f586-409d-8b8f-6ce915ccf583@github.com>
Message-ID: <HLYzWo-BGJJfqVg-xeexnnVVgZVxlUTzty_Sv5PWvrU=.0c79fa3a-2f72-4bf2-8af1-b6c681e2c8c6@github.com>

On Mon, 14 Jun 2021 14:28:33 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

Thumbs up!

Thanks for doing this sync forward.

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

Marked as reviewed by dcubed (Reviewer).

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

From jwilhelm at openjdk.java.net  Mon Jun 14 16:02:24 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 14 Jun 2021 16:02:24 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <xzBUEvQWZMw1he1KOtsir6sNOosBxrQ0nBkjLaHKnIo=.5a9dee37-f586-409d-8b8f-6ce915ccf583@github.com>
References: <xzBUEvQWZMw1he1KOtsir6sNOosBxrQ0nBkjLaHKnIo=.5a9dee37-f586-409d-8b8f-6ce915ccf583@github.com>
Message-ID: <PgUv8SBgRLq9mJpCHnpS3rgcMxMC36vQyyOxr25bQGk=.3f19741c-fdef-4501-ad03-0ca226264927@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson 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.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4484/files
  - new: https://git.openjdk.java.net/jdk/pull/4484/files/b3185354..b3185354

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

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

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

From dfuchs at openjdk.java.net  Mon Jun 14 16:02:28 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 14 Jun 2021 16:02:28 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <PgUv8SBgRLq9mJpCHnpS3rgcMxMC36vQyyOxr25bQGk=.3f19741c-fdef-4501-ad03-0ca226264927@github.com>
References: <xzBUEvQWZMw1he1KOtsir6sNOosBxrQ0nBkjLaHKnIo=.5a9dee37-f586-409d-8b8f-6ce915ccf583@github.com>
 <PgUv8SBgRLq9mJpCHnpS3rgcMxMC36vQyyOxr25bQGk=.3f19741c-fdef-4501-ad03-0ca226264927@github.com>
Message-ID: <2daAOoP8hnt5nqsZJasI5g1_QUovwyTwY3JutixTGik=.0bf9118f-8348-4f28-ba59-220c51a8732e@github.com>

On Mon, 14 Jun 2021 15:58:15 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Forwardport JDK 17 -> JDK 18
>
> Jesper Wilhelmsson 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.

Looked at this two changesets and they were fine.
 - 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already
 - 8268555: Update HttpClient tests that use ITestContext to jtreg 6+1

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

Marked as reviewed by dfuchs (Reviewer).

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

From jwilhelm at openjdk.java.net  Mon Jun 14 16:02:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 14 Jun 2021 16:02:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <xzBUEvQWZMw1he1KOtsir6sNOosBxrQ0nBkjLaHKnIo=.5a9dee37-f586-409d-8b8f-6ce915ccf583@github.com>
References: <xzBUEvQWZMw1he1KOtsir6sNOosBxrQ0nBkjLaHKnIo=.5a9dee37-f586-409d-8b8f-6ce915ccf583@github.com>
Message-ID: <E4cVFMOlxACexGd8nBq-64INq5sSrQVZ5vLMHjds68E=.717bd1b9-107f-44f6-b046-5412ee7359e2@github.com>

On Mon, 14 Jun 2021 14:28:33 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 17295b1b
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/17295b1bb02b2121978f1459b2e75c5e1031e7ea
Stats:     721 lines in 30 files changed: 573 ins; 73 del; 75 mod

Merge

Reviewed-by: dcubed

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

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

From cjplummer at openjdk.java.net  Tue Jun 15 05:58:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 15 Jun 2021 05:58:08 GMT
Subject: [jdk17] RFR: 8268723: Problem list SA core file tests on OSX when
 using ZGC
Message-ID: <j7GIOv46h1onDEi0sH0WinvUxrex-WzeyuxWJbcJf7k=.7b7f8783-3baf-41fd-99fc-de6ff0478c6f@github.com>

See CR for details. I also relocated AdaptiveBlocking001.java in the list so it is not mixed in with SA tests, and removed serviceability/sa/TestHeapDumpForLargeArray.java since it was moved to the resorucehogs directly long ago, and there is already separate entry that reflects the new location.

Note this is being pushed to JDK17.

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

Commit messages:
 - Problem list SA core file tests on OSX when using ZGC

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

PR: https://git.openjdk.java.net/jdk17/pull/50

From dholmes at openjdk.java.net  Tue Jun 15 06:20:47 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Jun 2021 06:20:47 GMT
Subject: [jdk17] RFR: 8268723: Problem list SA core file tests on OSX when
 using ZGC
In-Reply-To: <j7GIOv46h1onDEi0sH0WinvUxrex-WzeyuxWJbcJf7k=.7b7f8783-3baf-41fd-99fc-de6ff0478c6f@github.com>
References: <j7GIOv46h1onDEi0sH0WinvUxrex-WzeyuxWJbcJf7k=.7b7f8783-3baf-41fd-99fc-de6ff0478c6f@github.com>
Message-ID: <tA_U4scRlDrKqNNcT1Z0zxNuH1fhnUltU4sJQVAgBAs=.ebb96ff8-bbb8-4b95-aa16-fd6fb95005e0@github.com>

On Tue, 15 Jun 2021 02:42:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for details. I also relocated AdaptiveBlocking001.java in the list so it is not mixed in with SA tests, and removed serviceability/sa/TestHeapDumpForLargeArray.java since it was moved to the resorucehogs directly long ago, and there is already separate entry that reflects the new location.
> 
> Note this is being pushed to JDK17.

LGTM.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/50

From github.com+10835776+stsypanov at openjdk.java.net  Tue Jun 15 12:22:50 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 15 Jun 2021 12:22:50 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable
Message-ID: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>

In some JDK classes there's still the following hashCode() implementation:

long objNum;

public int hashCode() {
    return (int) objNum;
}

This outdated expression should be replaced with Long.hashCode(long) as it

- uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).

- does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.

See https://stackoverflow.com/a/4045083

This is related to https://github.com/openjdk/jdk/pull/4309

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

Commit messages:
 - 8268764: Use Long.hashCode() instead of int-cast where applicable

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

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

From dcubed at openjdk.java.net  Tue Jun 15 16:11:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 16:11:39 GMT
Subject: [jdk17] RFR: 8268723: Problem list SA core file tests on OSX when
 using ZGC
In-Reply-To: <j7GIOv46h1onDEi0sH0WinvUxrex-WzeyuxWJbcJf7k=.7b7f8783-3baf-41fd-99fc-de6ff0478c6f@github.com>
References: <j7GIOv46h1onDEi0sH0WinvUxrex-WzeyuxWJbcJf7k=.7b7f8783-3baf-41fd-99fc-de6ff0478c6f@github.com>
Message-ID: <ApGo9jkh-Ovko-mkHSgC5ftUSFWhxD3CRp2xBAoHSug=.4254ddf8-3364-481c-9a15-dab4f78d2569@github.com>

On Tue, 15 Jun 2021 02:42:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for details. I also relocated AdaptiveBlocking001.java in the list so it is not mixed in with SA tests, and removed serviceability/sa/TestHeapDumpForLargeArray.java since it was moved to the resorucehogs directly long ago, and there is already separate entry that reflects the new location.
> 
> Note this is being pushed to JDK17.

Thumbs up.

I noticed that runtime/ErrorHandling/CreateCoredumpOnCrash.java is
not in this list. That's okay, but I think we've seen failures related to that
test also. Is that test going to be handled with a different bug?

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/50

From sspitsyn at openjdk.java.net  Tue Jun 15 17:01:42 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 15 Jun 2021 17:01:42 GMT
Subject: [jdk17] RFR: 8268723: Problem list SA core file tests on OSX when
 using ZGC
In-Reply-To: <j7GIOv46h1onDEi0sH0WinvUxrex-WzeyuxWJbcJf7k=.7b7f8783-3baf-41fd-99fc-de6ff0478c6f@github.com>
References: <j7GIOv46h1onDEi0sH0WinvUxrex-WzeyuxWJbcJf7k=.7b7f8783-3baf-41fd-99fc-de6ff0478c6f@github.com>
Message-ID: <WOgKVfeOfDCFfDUC1DTDNEvtGAHDxLXGIxRNhOAqVt8=.f817be91-c019-4c17-901f-4cba830bc479@github.com>

On Tue, 15 Jun 2021 02:42:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for details. I also relocated AdaptiveBlocking001.java in the list so it is not mixed in with SA tests, and removed serviceability/sa/TestHeapDumpForLargeArray.java since it was moved to the resorucehogs directly long ago, and there is already separate entry that reflects the new location.
> 
> Note this is being pushed to JDK17.

Marked as reviewed by sspitsyn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/50

From cjplummer at openjdk.java.net  Tue Jun 15 17:01:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 15 Jun 2021 17:01:43 GMT
Subject: [jdk17] RFR: 8268723: Problem list SA core file tests on OSX when
 using ZGC
In-Reply-To: <ApGo9jkh-Ovko-mkHSgC5ftUSFWhxD3CRp2xBAoHSug=.4254ddf8-3364-481c-9a15-dab4f78d2569@github.com>
References: <j7GIOv46h1onDEi0sH0WinvUxrex-WzeyuxWJbcJf7k=.7b7f8783-3baf-41fd-99fc-de6ff0478c6f@github.com>
 <ApGo9jkh-Ovko-mkHSgC5ftUSFWhxD3CRp2xBAoHSug=.4254ddf8-3364-481c-9a15-dab4f78d2569@github.com>
Message-ID: <rw9jBN3ZPrh6EdtCIWQ_EMdWahBvLEoowubSsIQHDIg=.9bf51a04-b0ed-4fa1-8b95-6bae8d861dea@github.com>

On Tue, 15 Jun 2021 16:08:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> I noticed that runtime/ErrorHandling/CreateCoredumpOnCrash.java is
> not in this list. That's okay, but I think we've seen failures related to that
> test also. Is that test going to be handled with a different bug?

That test doesn't use ZGC on the spawned process that the core is created for, even when the test is run with -XX:+UseZGC. We've seen it fail in the past only after an OSX 11 host has already been put in a bad state, and refuses to produce a core file successfully for any test, I believe even ones that crash.

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

PR: https://git.openjdk.java.net/jdk17/pull/50

From ddong at openjdk.java.net  Tue Jun 15 17:29:51 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 15 Jun 2021 17:29:51 GMT
Subject: RFR: 8268780: Use 'print_cr' instead of 'print' for the message
 'eliminated <owner is scalar replaced>'
Message-ID: <eFocfddqLBaCvBfiUXNMvg5b9ag6hWeV_jKEyeF_8H0=.6cd32d13-f874-4988-802c-68e6f9b2d824@github.com>

Hi,

Cound I have a review of this small fix that adds a line feed for the message 'eliminated <owner is scalar replaced>'.

When we run the following code and run `jstack <pid>`


    public static void main(String[] args) {
        for (int i = 0; i < 200000000; i++) {
            try {
                test();
            } catch (Exception e) {
            }
        }
    }

    private static void test() throws Exception {
        Object obj = new Object();
        synchronized (obj) {
            throw new Exception();
        }
    }


We could find that a frame that does not wrap properly.

"main" #1 prio=5 os_prio=0 cpu=53202.88ms elapsed=54.10s tid=0x00007f8c2c022550 nid=0x4743 runnable  [0x00007f8c35ac2000]
   java.lang.Thread.State: RUNNABLE
        at java.lang.Throwable.fillInStackTrace(java.base at 17-internal/Native Method)
        at java.lang.Throwable.fillInStackTrace(java.base at 17-internal/Throwable.java:798)
        - locked <0x00000000f3b00340> (a java.lang.Exception)
        at java.lang.Throwable.<init>(java.base at 17-internal/Throwable.java:256)
        at java.lang.Exception.<init>(java.base at 17-internal/Exception.java:55)
        at Test.test(Test.java:14)
        - eliminated <owner is scalar replaced> (a java.lang.Object)    at Test.main(Test.java:5)


Also, I noticed that this message has a correct line feed in the implementation of JavaVFrame.java.

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

Commit messages:
 - 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated <owner is scalar replaced>'

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

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

From cjplummer at openjdk.java.net  Tue Jun 15 18:32:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 15 Jun 2021 18:32:42 GMT
Subject: RFR: 8268780: Use 'print_cr' instead of 'print' for the message
 'eliminated <owner is scalar replaced>'
In-Reply-To: <eFocfddqLBaCvBfiUXNMvg5b9ag6hWeV_jKEyeF_8H0=.6cd32d13-f874-4988-802c-68e6f9b2d824@github.com>
References: <eFocfddqLBaCvBfiUXNMvg5b9ag6hWeV_jKEyeF_8H0=.6cd32d13-f874-4988-802c-68e6f9b2d824@github.com>
Message-ID: <q5ladhU_zcLGvdz6cdGnF29j-N6-OUgINQ9WpE8GxOQ=.bc89b8d0-c545-4ef9-b54a-651e86434fd7@github.com>

On Tue, 15 Jun 2021 17:19:26 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Cound I have a review of this small fix that adds a line feed for the message 'eliminated <owner is scalar replaced>'.
> 
> When we run the following code and run `jstack <pid>`
> 
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 200000000; i++) {
>             try {
>                 test();
>             } catch (Exception e) {
>             }
>         }
>     }
> 
>     private static void test() throws Exception {
>         Object obj = new Object();
>         synchronized (obj) {
>             throw new Exception();
>         }
>     }
> 
> 
> We could find that a frame that does not wrap properly.
> 
> "main" #1 prio=5 os_prio=0 cpu=53202.88ms elapsed=54.10s tid=0x00007f8c2c022550 nid=0x4743 runnable  [0x00007f8c35ac2000]
>    java.lang.Thread.State: RUNNABLE
>         at java.lang.Throwable.fillInStackTrace(java.base at 17-internal/Native Method)
>         at java.lang.Throwable.fillInStackTrace(java.base at 17-internal/Throwable.java:798)
>         - locked <0x00000000f3b00340> (a java.lang.Exception)
>         at java.lang.Throwable.<init>(java.base at 17-internal/Throwable.java:256)
>         at java.lang.Exception.<init>(java.base at 17-internal/Exception.java:55)
>         at Test.test(Test.java:14)
>         - eliminated <owner is scalar replaced> (a java.lang.Object)    at Test.main(Test.java:5)
> 
> 
> Also, I noticed that this message has a correct line feed in the implementation of JavaVFrame.java.

Marked as reviewed by cjplummer (Reviewer).

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

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

From zgu at openjdk.java.net  Tue Jun 15 18:40:47 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 15 Jun 2021 18:40:47 GMT
Subject: RFR: 8268780: Use 'print_cr' instead of 'print' for the message
 'eliminated <owner is scalar replaced>'
In-Reply-To: <eFocfddqLBaCvBfiUXNMvg5b9ag6hWeV_jKEyeF_8H0=.6cd32d13-f874-4988-802c-68e6f9b2d824@github.com>
References: <eFocfddqLBaCvBfiUXNMvg5b9ag6hWeV_jKEyeF_8H0=.6cd32d13-f874-4988-802c-68e6f9b2d824@github.com>
Message-ID: <2GJdbs9vA92HgK37Fi8ZVFW_TNYssEH5huPlpisOcNg=.b682b429-d15b-4cb4-9bcd-7689d9aeb9a4@github.com>

On Tue, 15 Jun 2021 17:19:26 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Cound I have a review of this small fix that adds a line feed for the message 'eliminated <owner is scalar replaced>'.
> 
> When we run the following code and run `jstack <pid>`
> 
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 200000000; i++) {
>             try {
>                 test();
>             } catch (Exception e) {
>             }
>         }
>     }
> 
>     private static void test() throws Exception {
>         Object obj = new Object();
>         synchronized (obj) {
>             throw new Exception();
>         }
>     }
> 
> 
> We could find that a frame that does not wrap properly.
> 
> "main" #1 prio=5 os_prio=0 cpu=53202.88ms elapsed=54.10s tid=0x00007f8c2c022550 nid=0x4743 runnable  [0x00007f8c35ac2000]
>    java.lang.Thread.State: RUNNABLE
>         at java.lang.Throwable.fillInStackTrace(java.base at 17-internal/Native Method)
>         at java.lang.Throwable.fillInStackTrace(java.base at 17-internal/Throwable.java:798)
>         - locked <0x00000000f3b00340> (a java.lang.Exception)
>         at java.lang.Throwable.<init>(java.base at 17-internal/Throwable.java:256)
>         at java.lang.Exception.<init>(java.base at 17-internal/Exception.java:55)
>         at Test.test(Test.java:14)
>         - eliminated <owner is scalar replaced> (a java.lang.Object)    at Test.main(Test.java:5)
> 
> 
> Also, I noticed that this message has a correct line feed in the implementation of JavaVFrame.java.

Looks good and trivial

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

Marked as reviewed by zgu (Reviewer).

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

From cjplummer at openjdk.java.net  Tue Jun 15 19:02:45 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 15 Jun 2021 19:02:45 GMT
Subject: [jdk17] Integrated: 8268723: Problem list SA core file tests on OSX
 when using ZGC
In-Reply-To: <j7GIOv46h1onDEi0sH0WinvUxrex-WzeyuxWJbcJf7k=.7b7f8783-3baf-41fd-99fc-de6ff0478c6f@github.com>
References: <j7GIOv46h1onDEi0sH0WinvUxrex-WzeyuxWJbcJf7k=.7b7f8783-3baf-41fd-99fc-de6ff0478c6f@github.com>
Message-ID: <7Unp0cbv12F1QUf6oR_kZZYwa0MjwlJyKRxRgHftcbc=.3834c6f2-979d-4c3b-830c-9af2941dce01@github.com>

On Tue, 15 Jun 2021 02:42:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for details. I also relocated AdaptiveBlocking001.java in the list so it is not mixed in with SA tests, and removed serviceability/sa/TestHeapDumpForLargeArray.java since it was moved to the resorucehogs directly long ago, and there is already separate entry that reflects the new location.
> 
> Note this is being pushed to JDK17.

This pull request has now been integrated.

Changeset: fe7a44de
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/fe7a44de63f19921e373ff336be26f9165ac6977
Stats:     10 lines in 1 file changed: 7 ins; 0 del; 3 mod

8268723: Problem list SA core file tests on OSX when using ZGC

Reviewed-by: dholmes, dcubed, sspitsyn

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

PR: https://git.openjdk.java.net/jdk17/pull/50

From dcubed at openjdk.java.net  Tue Jun 15 19:04:54 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 19:04:54 GMT
Subject: RFR: 8268780: Use 'print_cr' instead of 'print' for the message
 'eliminated <owner is scalar replaced>'
In-Reply-To: <eFocfddqLBaCvBfiUXNMvg5b9ag6hWeV_jKEyeF_8H0=.6cd32d13-f874-4988-802c-68e6f9b2d824@github.com>
References: <eFocfddqLBaCvBfiUXNMvg5b9ag6hWeV_jKEyeF_8H0=.6cd32d13-f874-4988-802c-68e6f9b2d824@github.com>
Message-ID: <-rG5KW7myyYsTcle_m3nl9TIiLEsxGzCSBMgCtk-Qiw=.6b94d4f0-e7b9-41b2-93c0-fd4a87d70ef5@github.com>

On Tue, 15 Jun 2021 17:19:26 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Cound I have a review of this small fix that adds a line feed for the message 'eliminated <owner is scalar replaced>'.
> 
> When we run the following code and run `jstack <pid>`
> 
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 200000000; i++) {
>             try {
>                 test();
>             } catch (Exception e) {
>             }
>         }
>     }
> 
>     private static void test() throws Exception {
>         Object obj = new Object();
>         synchronized (obj) {
>             throw new Exception();
>         }
>     }
> 
> 
> We could find that a frame that does not wrap properly.
> 
> "main" #1 prio=5 os_prio=0 cpu=53202.88ms elapsed=54.10s tid=0x00007f8c2c022550 nid=0x4743 runnable  [0x00007f8c35ac2000]
>    java.lang.Thread.State: RUNNABLE
>         at java.lang.Throwable.fillInStackTrace(java.base at 17-internal/Native Method)
>         at java.lang.Throwable.fillInStackTrace(java.base at 17-internal/Throwable.java:798)
>         - locked <0x00000000f3b00340> (a java.lang.Exception)
>         at java.lang.Throwable.<init>(java.base at 17-internal/Throwable.java:256)
>         at java.lang.Exception.<init>(java.base at 17-internal/Exception.java:55)
>         at Test.test(Test.java:14)
>         - eliminated <owner is scalar replaced> (a java.lang.Object)    at Test.main(Test.java:5)
> 
> 
> Also, I noticed that this message has a correct line feed in the implementation of JavaVFrame.java.

Marked as reviewed by dcubed (Reviewer).

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

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

From dcubed at openjdk.java.net  Tue Jun 15 21:52:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 21:52:00 GMT
Subject: [jdk17] Integrated: 8268830: ProblemList 3
 serviceability/dcmd/framework tests with ZGC on win-x64
Message-ID: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>

A trivial fix to ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64.

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

Commit messages:
 - Fix broken lines in new entries.
 - 8268830: ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64

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

PR: https://git.openjdk.java.net/jdk17/pull/66

From kbarrett at openjdk.java.net  Tue Jun 15 21:52:00 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 15 Jun 2021 21:52:00 GMT
Subject: [jdk17] Integrated: 8268830: ProblemList 3
 serviceability/dcmd/framework tests with ZGC on win-x64
In-Reply-To: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>
References: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>
Message-ID: <Zd8aOXl5c2yQGhNrIM8wV06yVx9eGhJAB7uAoGmY2C8=.69e77951-9def-409e-8dd7-6b93ed6989bd@github.com>

On Tue, 15 Jun 2021 21:38:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64.

Changes requested by kbarrett (Reviewer).

Looks good.

test/hotspot/jtreg/ProblemList-zgc.txt line 46:

> 44: serviceability/dcmd/framework/HelpTest.java                   8268433 windows-x64
> 45: serviceability/dcmd/framework/InvalidCommandTest.java         8268433 windows-x6
> 46: 4

"4" on it's own line x 2

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

PR: https://git.openjdk.java.net/jdk17/pull/66Marked as reviewed by kbarrett (Reviewer).

From dcubed at openjdk.java.net  Tue Jun 15 21:52:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 21:52:01 GMT
Subject: [jdk17] Integrated: 8268830: ProblemList 3
 serviceability/dcmd/framework tests with ZGC on win-x64
In-Reply-To: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>
References: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>
Message-ID: <yj00v84b9kJeIlu0EkYQyMrAeoEO3a_m5CFOTJonJDM=.d28d4e51-13d2-48f0-a729-36dd67c81b5c@github.com>

On Tue, 15 Jun 2021 21:38:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64.

This pull request has now been integrated.

Changeset: 10068c1b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/10068c1bace0ea650bda3e2234a44cbf401afc7d
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8268830: ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64

Reviewed-by: kbarrett

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

PR: https://git.openjdk.java.net/jdk17/pull/66

From dcubed at openjdk.java.net  Tue Jun 15 21:52:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Jun 2021 21:52:00 GMT
Subject: [jdk17] Integrated: 8268830: ProblemList 3
 serviceability/dcmd/framework tests with ZGC on win-x64
In-Reply-To: <Zd8aOXl5c2yQGhNrIM8wV06yVx9eGhJAB7uAoGmY2C8=.69e77951-9def-409e-8dd7-6b93ed6989bd@github.com>
References: <639cOsQBaO5dKf_9NxaW2tFF046YKUyhaQG9iW1Es4M=.b0412070-b82f-4bf4-826a-01b6252a66f2@github.com>
 <Zd8aOXl5c2yQGhNrIM8wV06yVx9eGhJAB7uAoGmY2C8=.69e77951-9def-409e-8dd7-6b93ed6989bd@github.com>
Message-ID: <0MxgjXppM4IkFEWHRsw5ODPpMt3TeGFz5svrUFsJ_zo=.87ff3e84-f4a1-4d1d-b86f-1da7dd63e5b0@github.com>

On Tue, 15 Jun 2021 21:41:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> A trivial fix to ProblemList 3 serviceability/dcmd/framework tests with ZGC on win-x64.
>
> Changes requested by kbarrett (Reviewer).

@kimbarrett - Thanks for catching that! Made my terminal wider... :-)
Fixed.

> Looks good.

@kimbarrett - Thanks for both reviews!

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

PR: https://git.openjdk.java.net/jdk17/pull/66

From ddong at openjdk.java.net  Wed Jun 16 02:11:35 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 16 Jun 2021 02:11:35 GMT
Subject: Integrated: 8268780: Use 'print_cr' instead of 'print' for the
 message 'eliminated <owner is scalar replaced>'
In-Reply-To: <eFocfddqLBaCvBfiUXNMvg5b9ag6hWeV_jKEyeF_8H0=.6cd32d13-f874-4988-802c-68e6f9b2d824@github.com>
References: <eFocfddqLBaCvBfiUXNMvg5b9ag6hWeV_jKEyeF_8H0=.6cd32d13-f874-4988-802c-68e6f9b2d824@github.com>
Message-ID: <a_npuOBZiMsb72RcdPuj47Ye4bRrYNAr0G_G2RJn7QU=.6522d380-b130-4067-a413-1969820834ba@github.com>

On Tue, 15 Jun 2021 17:19:26 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Cound I have a review of this small fix that adds a line feed for the message 'eliminated <owner is scalar replaced>'.
> 
> When we run the following code and run `jstack <pid>`
> 
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 200000000; i++) {
>             try {
>                 test();
>             } catch (Exception e) {
>             }
>         }
>     }
> 
>     private static void test() throws Exception {
>         Object obj = new Object();
>         synchronized (obj) {
>             throw new Exception();
>         }
>     }
> 
> 
> We could find that a frame that does not wrap properly.
> 
> "main" #1 prio=5 os_prio=0 cpu=53202.88ms elapsed=54.10s tid=0x00007f8c2c022550 nid=0x4743 runnable  [0x00007f8c35ac2000]
>    java.lang.Thread.State: RUNNABLE
>         at java.lang.Throwable.fillInStackTrace(java.base at 17-internal/Native Method)
>         at java.lang.Throwable.fillInStackTrace(java.base at 17-internal/Throwable.java:798)
>         - locked <0x00000000f3b00340> (a java.lang.Exception)
>         at java.lang.Throwable.<init>(java.base at 17-internal/Throwable.java:256)
>         at java.lang.Exception.<init>(java.base at 17-internal/Exception.java:55)
>         at Test.test(Test.java:14)
>         - eliminated <owner is scalar replaced> (a java.lang.Object)    at Test.main(Test.java:5)
> 
> 
> Also, I noticed that this message has a correct line feed in the implementation of JavaVFrame.java.

This pull request has now been integrated.

Changeset: 48d45628
Author:    Denghui Dong <ddong at openjdk.org>
Committer: Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/48d456281ea73e22eaaae6a082bb43610647d660
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8268780: Use 'print_cr' instead of 'print' for the message 'eliminated <owner is scalar replaced>'

Reviewed-by: cjplummer, zgu, dcubed

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

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

From ddong at openjdk.java.net  Wed Jun 16 03:39:47 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 16 Jun 2021 03:39:47 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump
Message-ID: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>

Hi,

Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.

`jstack` is a very common command, even in the production environment.

In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

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

Commit messages:
 - 8268857: Merge three vm operations in thread_dump

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

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

From dholmes at openjdk.java.net  Wed Jun 16 04:11:39 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Jun 2021 04:11:39 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <CgEd4bONXJ1b5F8QALmCMFV2XwXCpEsBCvcvfaSAQpA=.032cec79-087c-4da8-864c-1fc1afda006d@github.com>

On Wed, 16 Jun 2021 03:33:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Sorry but I do not agree with this change. I understand your rationale but you have overlooked that by combining these three safepoint operations you have created a much longer safepoint pause which may lock out other more important safepoint operations, and you may also be holding the HeapLock across this extended safepoint.

The operations that you have coalesced are not considered time critical but can themselves be very time consuming e.g deadlock detection.

David

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

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

From ysuenaga at openjdk.java.net  Wed Jun 16 05:39:39 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 16 Jun 2021 05:39:39 GMT
Subject: [jdk17] RFR: 8268863: ProblemList
 serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC
Message-ID: <-sOR0fJ8cXnCTs92ZigFJDLGctyfGeRZbCxv_UkmheE=.872159ac-00ec-4cdd-843f-365f6749c62e@github.com>

In order to reduce the noise in the JDK17 CI, I'm ProblemListing serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC.

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

Commit messages:
 - 8268863: ProblemList serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC

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

PR: https://git.openjdk.java.net/jdk17/pull/72

From yyang at openjdk.java.net  Wed Jun 16 08:25:51 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 16 Jun 2021 08:25:51 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
Message-ID: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>

After JDK-8265518, it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

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

Commit messages:
 - use checkIndex globally

Changes: https://git.openjdk.java.net/jdk/pull/4507/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268698
  Stats: 206 lines in 34 files changed: 31 ins; 111 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

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

From coleenp at openjdk.java.net  Wed Jun 16 13:01:46 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 13:01:46 GMT
Subject: RFR: 8264941: Remove CodeCache::mark_for_evol_deoptimization() method
Message-ID: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>

This change removes the mark_for_evol_deoptimization method and removes the flag that all dependencies are recorded.  Before the change to walk the entire nmethod looking for "old" (redefined) methods with metadata_do(), we used to find methods in the code cache to deoptimize based on evol_method dependencies.  If the dependencies weren't yet recorded, we had to deoptimize all of the methods.  A long time ago, we had a customer who was unhappy with the pause for this when they had late attach.  Now we don't have this problem.
The evol_method dependencies are still used by the compiler to check for old methods during compilation.  I didn't change this but it might be something someone who knows the compiler better can do differently and remove these dependencies too.
Tested with tier1-6.

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

Commit messages:
 - 8264941: Remove CodeCache::mark_for_evol_deoptimization() method

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

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

From coleenp at openjdk.java.net  Wed Jun 16 13:10:35 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 13:10:35 GMT
Subject: RFR: 8264941: Remove CodeCache::mark_for_evol_deoptimization()
 method
In-Reply-To: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
References: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
Message-ID: <IIKCgUYFmG7rbzS2ptn3S4YHbIPrzlt3jKOPjTBlur0=.a2e17674-05b8-4255-be63-fccde52a3bd8@github.com>

On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the mark_for_evol_deoptimization method and removes the flag that all dependencies are recorded.  Before the change to walk the entire nmethod looking for "old" (redefined) methods with metadata_do(), we used to find methods in the code cache to deoptimize based on evol_method dependencies.  If the dependencies weren't yet recorded, we had to deoptimize all of the methods.  A long time ago, we had a customer who was unhappy with the pause for this when they had late attach.  Now we don't have this problem.
> The evol_method dependencies are still used by the compiler to check for old methods during compilation.  I didn't change this but it might be something someone who knows the compiler better can do differently and remove these dependencies too.
> Tested with tier1-6.

Hi @iwanowww can you have a look?

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

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

From github.com+42899633+eastig at openjdk.java.net  Wed Jun 16 13:13:32 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 16 Jun 2021 13:13:32 GMT
Subject: RFR: 8264941: Remove CodeCache::mark_for_evol_deoptimization()
 method
In-Reply-To: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
References: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
Message-ID: <EGbKz1VarGKV7bJFyTIm1vaSGBu9j4OI6DWfhFQCh4Y=.db97e89c-e5fb-413a-947f-ee034b8b30d2@github.com>

On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the mark_for_evol_deoptimization method and removes the flag that all dependencies are recorded.  Before the change to walk the entire nmethod looking for "old" (redefined) methods with metadata_do(), we used to find methods in the code cache to deoptimize based on evol_method dependencies.  If the dependencies weren't yet recorded, we had to deoptimize all of the methods.  A long time ago, we had a customer who was unhappy with the pause for this when they had late attach.  Now we don't have this problem.
> The evol_method dependencies are still used by the compiler to check for old methods during compilation.  I didn't change this but it might be something someone who knows the compiler better can do differently and remove these dependencies too.
> Tested with tier1-6.

LGTM

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

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

From coleenp at openjdk.java.net  Wed Jun 16 14:18:35 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Jun 2021 14:18:35 GMT
Subject: RFR: 8264941: Remove CodeCache::mark_for_evol_deoptimization()
 method
In-Reply-To: <EGbKz1VarGKV7bJFyTIm1vaSGBu9j4OI6DWfhFQCh4Y=.db97e89c-e5fb-413a-947f-ee034b8b30d2@github.com>
References: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
 <EGbKz1VarGKV7bJFyTIm1vaSGBu9j4OI6DWfhFQCh4Y=.db97e89c-e5fb-413a-947f-ee034b8b30d2@github.com>
Message-ID: <Rhz5eK_ON1vu55ze-CHASomcj_LjXGoturu75598ohE=.d22cad2a-e3d6-49ff-a28d-7370f86256e3@github.com>

On Wed, 16 Jun 2021 13:10:55 GMT, Evgeny Astigeevich <github.com+42899633+eastig at openjdk.org> wrote:

>> This change removes the mark_for_evol_deoptimization method and removes the flag that all dependencies are recorded.  Before the change to walk the entire nmethod looking for "old" (redefined) methods with metadata_do(), we used to find methods in the code cache to deoptimize based on evol_method dependencies.  If the dependencies weren't yet recorded, we had to deoptimize all of the methods.  A long time ago, we had a customer who was unhappy with the pause for this when they had late attach.  Now we don't have this problem.
>> The evol_method dependencies are still used by the compiler to check for old methods during compilation.  I didn't change this but it might be something someone who knows the compiler better can do differently and remove these dependencies too.
>> Tested with tier1-6.
>
> LGTM

Thanks @eastig .

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

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

From dcubed at openjdk.java.net  Wed Jun 16 15:23:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Jun 2021 15:23:34 GMT
Subject: [jdk17] RFR: 8268863: ProblemList
 serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC
In-Reply-To: <-sOR0fJ8cXnCTs92ZigFJDLGctyfGeRZbCxv_UkmheE=.872159ac-00ec-4cdd-843f-365f6749c62e@github.com>
References: <-sOR0fJ8cXnCTs92ZigFJDLGctyfGeRZbCxv_UkmheE=.872159ac-00ec-4cdd-843f-365f6749c62e@github.com>
Message-ID: <vimsfHUp7k8bF-b6LqIOG-ChPBAH-oISFKKirXMSdns=.4b466653-0914-4735-b3ce-8b399613c0ee@github.com>

On Wed, 16 Jun 2021 05:32:51 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In order to reduce the noise in the JDK17 CI, I'm ProblemListing serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC.

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/72

From ckozak at ckozak.net  Wed Jun 16 19:12:26 2021
From: ckozak at ckozak.net (Carter Kozak)
Date: Wed, 16 Jun 2021 15:12:26 -0400
Subject: Monitoring Java Safepoint Time in JDK16+
Message-ID: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>

As java 16 and beyond lock down access to internal components by default, it can be difficult to produce Prometheus-style metrics describing application safepoints. I?ve been monitoring these metrics so that I can be alerted when an application spends more than ~10% of time in safepoints for some duration, because it means that something has gone wrong: Most often GC spirals, however excessive thread dumps, deadlock checks, etc can contribute. This has been one of the most meaningful tools in my arsenal to detect general JVM badness, however there doesn?t seem to be a way to access the data in newer JREs without allowing access to internal components.

Previously I was able to use something along these lines, which required legacy sun.management component access.

sun.management.HotspotRuntimeMBean hotspotRuntimeManagementBean = sun.management.ManagementFactoryHelper.getHotspotRuntimeMBean();
long totalSafepointTimeMillis = hotspotRuntimeManagementBean.getTotalSafepointTime();

Before I get ahead of myself, I?d like to confirm that I haven?t missed a supported pathway to access safepoint time. If my read is correct and there?s no way to access this information from inside the running JVM, would it be a a reasonable addition to the public API?

Thanks,
Carter Kozak

From erik.gahlin at oracle.com  Wed Jun 16 19:44:37 2021
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 16 Jun 2021 19:44:37 +0000
Subject: Monitoring Java Safepoint Time in JDK16+
In-Reply-To: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
References: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
Message-ID: <13332419-F805-4952-B6E8-F581F3C42143@oracle.com>

It's possible to access safepoint information using JFR, for example:

try (RecordingStream r = new RecordingStream()) {
  r.enable("jdk.SafepointBegin");
  r.enable("jdk.SafepointEnd");
  r.onEvent("jdk.SafepointBegin", e -> System.out.println("begin: " + e.getEndTime()));
  r.onEvent("jdk.SafepointEnd", e -> System.out.println("end: " + e.getEndTime()));
  r.start();
}

Erik

On 2021-06-16, 21:12, "serviceability-dev on behalf of Carter Kozak" <serviceability-dev-retn at openjdk.java.net on behalf of ckozak at ckozak.net> wrote:

    As java 16 and beyond lock down access to internal components by default, it can be difficult to produce Prometheus-style metrics describing application safepoints. I?ve been monitoring these metrics so that I can be alerted when an application spends more than ~10% of time in safepoints for some duration, because it means that something has gone wrong: Most often GC spirals, however excessive thread dumps, deadlock checks, etc can contribute. This has been one of the most meaningful tools in my arsenal to detect general JVM badness, however there doesn?t seem to be a way to access the data in newer JREs without allowing access to internal components.
    
    Previously I was able to use something along these lines, which required legacy sun.management component access.
    
    sun.management.HotspotRuntimeMBean hotspotRuntimeManagementBean = sun.management.ManagementFactoryHelper.getHotspotRuntimeMBean();
    long totalSafepointTimeMillis = hotspotRuntimeManagementBean.getTotalSafepointTime();
    
    Before I get ahead of myself, I?d like to confirm that I haven?t missed a supported pathway to access safepoint time. If my read is correct and there?s no way to access this information from inside the running JVM, would it be a a reasonable addition to the public API?
    
    Thanks,
    Carter Kozak
    


From amenkov at openjdk.java.net  Wed Jun 16 20:40:14 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 16 Jun 2021 20:40:14 GMT
Subject: [jdk17] RFR: 8268433:
 serviceability/dcmd/framework/VMVersionTest.java fails with Unable to send
 object throw not established PipeIO Listener Thread connection
In-Reply-To: <SWTjfusblemekxL30ESme75xseVIwBxCg1bUdeX0h7o=.a132b9f5-c710-4647-979d-2c13fe67866a@github.com>
References: <SWTjfusblemekxL30ESme75xseVIwBxCg1bUdeX0h7o=.a132b9f5-c710-4647-979d-2c13fe67866a@github.com>
Message-ID: <mD1xxthb6rk_QQo50hsYqwF-mexNmNVp6dGUTD6DCV8=.63292f5f-d16f-4cab-aba9-87fb32e5e7a9@github.com>

On Fri, 11 Jun 2021 19:40:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds check that IOPipe is connected before sending "quit" command

The tests are problem-listed in jdk17 and I have problems with testing windows+zgc builds
Closing this PR and going to continue in jdk18

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

PR: https://git.openjdk.java.net/jdk17/pull/32

From amenkov at openjdk.java.net  Wed Jun 16 20:40:15 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 16 Jun 2021 20:40:15 GMT
Subject: [jdk17] Withdrawn: 8268433:
 serviceability/dcmd/framework/VMVersionTest.java fails with Unable to send
 object throw not established PipeIO Listener Thread connection
In-Reply-To: <SWTjfusblemekxL30ESme75xseVIwBxCg1bUdeX0h7o=.a132b9f5-c710-4647-979d-2c13fe67866a@github.com>
References: <SWTjfusblemekxL30ESme75xseVIwBxCg1bUdeX0h7o=.a132b9f5-c710-4647-979d-2c13fe67866a@github.com>
Message-ID: <ki1vQv0sLi440rAau-Ve0fwvnDiDrZDMpPSFJQKP9y4=.cc2f26fd-6adf-4c5b-94b3-cb87cee2d32c@github.com>

On Fri, 11 Jun 2021 19:40:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds check that IOPipe is connected before sending "quit" command

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk17/pull/32

From ckozak at ckozak.net  Wed Jun 16 22:26:46 2021
From: ckozak at ckozak.net (Carter Kozak)
Date: Wed, 16 Jun 2021 18:26:46 -0400
Subject: Monitoring Java Safepoint Time in JDK16+
In-Reply-To: <13332419-F805-4952-B6E8-F581F3C42143@oracle.com>
References: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
 <13332419-F805-4952-B6E8-F581F3C42143@oracle.com>
Message-ID: <bd65baf1-693d-4d8f-a599-b15341766d64@www.fastmail.com>

Thanks, Erik.

Is there any chance you could point me toward the documentation for the jdk.Safepoint* events? It's difficult to tell at a glance if the sum of the differences between the safepoint begin and end times is equivalent to hotspotRuntimeManagementBean.getTotalSafepointTime(). Does that include the sync time (which appears to have its own SafepointStateSynchronization event)? I don't understand what beginSafepointEvent.getDuration() means in this context, is sync time included only in the safepoint sync event, duration of the SafepointBegin event, or time between begin and end event end times?

In logging framework code we've found that converting between time objects and numeric values doesn't always (on some jres ever?) optimize away Instant allocations. The default JFR configuration appears to set time thresholds for safepoint events which I'd expect reduces overhead, but would prevent us from accumulating data when there are frequent, quick safepoints. Otherwise the cost is likely to be much greater than the old approach.
In a similar vein, is there any way for us to accumulate this data without dedicating an entire OS thread to the RecordingStream?

Sorry for the barrage of questions, I appreciate your help!
Carter Kozak

On Wed, Jun 16, 2021, at 15:44, Erik Gahlin wrote:
> It's possible to access safepoint information using JFR, for example:
> 
> try (RecordingStream r = new RecordingStream()) {
>   r.enable("jdk.SafepointBegin");
>   r.enable("jdk.SafepointEnd");
>   r.onEvent("jdk.SafepointBegin", e -> System.out.println("begin: " + e.getEndTime()));
>   r.onEvent("jdk.SafepointEnd", e -> System.out.println("end: " + e.getEndTime()));
>   r.start();
> }
> 
> Erik
> 
> On 2021-06-16, 21:12, "serviceability-dev on behalf of Carter Kozak" <serviceability-dev-retn at openjdk.java.net <mailto:serviceability-dev-retn%40openjdk.java.net> on behalf of ckozak at ckozak.net <mailto:ckozak%40ckozak.net>> wrote:
> 
>     As java 16 and beyond lock down access to internal components by default, it can be difficult to produce Prometheus-style metrics describing application safepoints. I?ve been monitoring these metrics so that I can be alerted when an application spends more than ~10% of time in safepoints for some duration, because it means that something has gone wrong: Most often GC spirals, however excessive thread dumps, deadlock checks, etc can contribute. This has been one of the most meaningful tools in my arsenal to detect general JVM badness, however there doesn?t seem to be a way to access the data in newer JREs without allowing access to internal components.
>     
>     Previously I was able to use something along these lines, which required legacy sun.management component access.
>     
>     sun.management.HotspotRuntimeMBean hotspotRuntimeManagementBean = sun.management.ManagementFactoryHelper.getHotspotRuntimeMBean();
>     long totalSafepointTimeMillis = hotspotRuntimeManagementBean.getTotalSafepointTime();
>     
>     Before I get ahead of myself, I?d like to confirm that I haven?t missed a supported pathway to access safepoint time. If my read is correct and there?s no way to access this information from inside the running JVM, would it be a a reasonable addition to the public API?
>     
>     Thanks,
>     Carter Kozak
>     
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210616/a44857a5/attachment-0001.htm>

From ysuenaga at openjdk.java.net  Wed Jun 16 23:25:16 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 16 Jun 2021 23:25:16 GMT
Subject: [jdk17] Integrated: 8268863: ProblemList
 serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC
In-Reply-To: <-sOR0fJ8cXnCTs92ZigFJDLGctyfGeRZbCxv_UkmheE=.872159ac-00ec-4cdd-843f-365f6749c62e@github.com>
References: <-sOR0fJ8cXnCTs92ZigFJDLGctyfGeRZbCxv_UkmheE=.872159ac-00ec-4cdd-843f-365f6749c62e@github.com>
Message-ID: <9DuY5K_ibdQN0KQz3paPu24FcXt5Im8z5FeG-hRTNJs=.71dc61ea-d13a-456d-b11a-234003a8aae6@github.com>

On Wed, 16 Jun 2021 05:32:51 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In order to reduce the noise in the JDK17 CI, I'm ProblemListing serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC.

This pull request has now been integrated.

Changeset: ee03bc6d
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/ee03bc6d0aad4b0d07bbe792c8cc77f986c617e1
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8268863: ProblemList serviceability/sa/TestJmapCoreMetaspace.java on linux-x64 with ZGC

Reviewed-by: dcubed

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

PR: https://git.openjdk.java.net/jdk17/pull/72

From david.holmes at oracle.com  Thu Jun 17 01:39:56 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 17 Jun 2021 11:39:56 +1000
Subject: Monitoring Java Safepoint Time in JDK16+
In-Reply-To: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
References: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
Message-ID: <8740f0b6-7036-a2ba-0d57-5065a8930103@oracle.com>

Hi Carter,

On 17/06/2021 5:12 am, Carter Kozak wrote:
> As java 16 and beyond lock down access to internal components by default, it can be difficult to produce Prometheus-style metrics describing application safepoints. I?ve been monitoring these metrics so that I can be alerted when an application spends more than ~10% of time in safepoints for some duration, because it means that something has gone wrong: Most often GC spirals, however excessive thread dumps, deadlock checks, etc can contribute. This has been one of the most meaningful tools in my arsenal to detect general JVM badness, however there doesn?t seem to be a way to access the data in newer JREs without allowing access to internal components.
> 
> Previously I was able to use something along these lines, which required legacy sun.management component access.
> 
> sun.management.HotspotRuntimeMBean hotspotRuntimeManagementBean = sun.management.ManagementFactoryHelper.getHotspotRuntimeMBean();
> long totalSafepointTimeMillis = hotspotRuntimeManagementBean.getTotalSafepointTime();

In what way does this no longer work? We have a test in 
jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java that 
uses this API and doesn't seem to need to do anything to allow access. ??

Cheers,
David
-----

> Before I get ahead of myself, I?d like to confirm that I haven?t missed a supported pathway to access safepoint time. If my read is correct and there?s no way to access this information from inside the running JVM, would it be a a reasonable addition to the public API?
> 
> Thanks,
> Carter Kozak
> 

From dholmes at openjdk.java.net  Thu Jun 17 01:54:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Jun 2021 01:54:09 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <0Kkr7Ka5KRp5WD0axZwvexYA5cP8Z8rvUyk42Jp8hmA=.cde62503-a9eb-4c1f-b6d4-82e61616e32f@github.com>

On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang <yyang at openjdk.org> wrote:

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

I skimmed through all these and the changes seem fine in principal.
I have two mild concerns:

1. How does this change the class initialization order on VM startup?
2. Do any tests need adjusting due to potential changes in the exact message used by the IndexOutOfBoundsException?

Thanks,
David

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

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

From ddong at openjdk.java.net  Thu Jun 17 02:35:19 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 17 Jun 2021 02:35:19 GMT
Subject: Withdrawn: 8268857: Merge three vm operations in thread_dump
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <obsmGPzcA1Gf7dFPJJtQXA4Y2M4T6-Ta6UeWC9SIQgU=.9f7cda78-c922-4197-ae22-0533798650c0@github.com>

On Wed, 16 Jun 2021 03:33:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

This pull request has been closed without being integrated.

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

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

From ddong at openjdk.java.net  Thu Jun 17 02:35:18 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 17 Jun 2021 02:35:18 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump
In-Reply-To: <CgEd4bONXJ1b5F8QALmCMFV2XwXCpEsBCvcvfaSAQpA=.032cec79-087c-4da8-864c-1fc1afda006d@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <CgEd4bONXJ1b5F8QALmCMFV2XwXCpEsBCvcvfaSAQpA=.032cec79-087c-4da8-864c-1fc1afda006d@github.com>
Message-ID: <VhVEvG0D9Kz4D9bhvVZ5F60zUaKY1H7rqXUc9q8BksQ=.cb95334d-b68e-4098-adc9-b303458d1808@github.com>

On Wed, 16 Jun 2021 04:08:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but I do not agree with this change. I understand your rationale but you have overlooked that by combining these three safepoint operations you have created a much longer safepoint pause which may lock out other more important safepoint operations, and you may also be holding the HeapLock across this extended safepoint.
> 
> The operations that you have coalesced are not considered time critical but can themselves be very time consuming e.g deadlock detection.
> 
> David

Hi David,

Thanks for the comment.

I still think it's redundant to enter three safepoint, which may lead to inconsistent results between 'PrintThreads' and 'FindDeadlocks'. But this patch does cause the problem you said

I will reopen it once I have a better solution.

Thanks,
Denghui

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

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

From yyang at openjdk.java.net  Thu Jun 17 03:35:13 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 17 Jun 2021 03:35:13 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <0Kkr7Ka5KRp5WD0axZwvexYA5cP8Z8rvUyk42Jp8hmA=.cde62503-a9eb-4c1f-b6d4-82e61616e32f@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <0Kkr7Ka5KRp5WD0axZwvexYA5cP8Z8rvUyk42Jp8hmA=.cde62503-a9eb-4c1f-b6d4-82e61616e32f@github.com>
Message-ID: <4yPb1iqPV0JAYphfov1jMn-bLr8NjA3e3EJDi6_Qg-E=.39756447-7617-4e72-aeaa-e0dd5ad0b64c@github.com>

On Thu, 17 Jun 2021 01:51:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I skimmed through all these and the changes seem fine in principal.
> I have two mild concerns:
> 
> 1. How does this change the class initialization order on VM startup?
> 2. Do any tests need adjusting due to potential changes in the exact message used by the IndexOutOfBoundsException?
> 
> Thanks,
> David

Hi David, your concerns are reasonable. I think this change would not affect the class initialization order, because regardless of whether the patch is applied or not, `java -Xlog:class+load -version` prints identical class initialization order(for j.l.Objects and jdk.internal.util.Preconditions) as far as I can see. [class_load.log](https://github.com/openjdk/jdk/files/6667168/class_load.log). And tier1 tests are all passed w/o any modifications.

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

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

From stuefe at openjdk.java.net  Thu Jun 17 04:20:12 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 17 Jun 2021 04:20:12 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <xrESicFFOhQe62MT45h9T3CH_Pe62Z61Es6XC3C8DNc=.4a72dcc0-0528-4575-9811-78d44a0b21e2@github.com>

On Wed, 16 Jun 2021 03:33:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

It would be nice to have this fixed though. Maybe adding a guaranteed timeout to these operations would help.

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

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

From Alan.Bateman at oracle.com  Thu Jun 17 05:15:04 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 17 Jun 2021 06:15:04 +0100
Subject: Monitoring Java Safepoint Time in JDK16+
In-Reply-To: <8740f0b6-7036-a2ba-0d57-5065a8930103@oracle.com>
References: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
 <8740f0b6-7036-a2ba-0d57-5065a8930103@oracle.com>
Message-ID: <4c4be2ca-211b-be9b-79dc-20669d0f37e8@oracle.com>

On 17/06/2021 02:39, David Holmes wrote:
>
> In what way does this no longer work? We have a test in 
> jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java that 
> uses this API and doesn't seem to need to do anything to allow access. ??
That test is compiled/run with `--add-exports 
java.management/sun.management=ALL-UNNAMED`, just not immediately 
obvious because the TEST.properties with the config for jtreg is in the 
parent directory (it applies to tests in that directory and all 
sub-directories). Carter would have need the equivalent to compile with 
JDK 9+ and to run with JDK 16+.

-Alan.

From ddong at openjdk.java.net  Thu Jun 17 05:15:36 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 17 Jun 2021 05:15:36 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v2]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <3hM_tItjj51zsVQIrYIE7_3sR8j5A2ijdxKNbHmla_w=.f87dde43-a467-41cf-8bb0-e8a40b8d5d2b@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Denghui Dong has updated the pull request incrementally with three additional commits since the last revision:

 - update
 - remove useless comment
 - remove VM_PrintJNI

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/82a35b85..56cd2a8b

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

  Stats: 38 lines in 5 files changed: 4 ins; 28 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4504.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4504/head:pull/4504

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

From dholmes at openjdk.java.net  Thu Jun 17 05:19:11 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Jun 2021 05:19:11 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>

On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang <yyang at openjdk.org> wrote:

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Class loading order is different to class initialization order.

There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them.  If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.

Thanks,
David

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

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

From david.holmes at oracle.com  Thu Jun 17 05:59:17 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 17 Jun 2021 15:59:17 +1000
Subject: Monitoring Java Safepoint Time in JDK16+
In-Reply-To: <4c4be2ca-211b-be9b-79dc-20669d0f37e8@oracle.com>
References: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
 <8740f0b6-7036-a2ba-0d57-5065a8930103@oracle.com>
 <4c4be2ca-211b-be9b-79dc-20669d0f37e8@oracle.com>
Message-ID: <f2fdced8-2ab3-3ee1-8e32-8d11d909491b@oracle.com>

On 17/06/2021 3:15 pm, Alan Bateman wrote:
> On 17/06/2021 02:39, David Holmes wrote:
>>
>> In what way does this no longer work? We have a test in 
>> jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java that 
>> uses this API and doesn't seem to need to do anything to allow access. ??
> That test is compiled/run with `--add-exports 
> java.management/sun.management=ALL-UNNAMED`, just not immediately 
> obvious because the TEST.properties with the config for jtreg is in the 
> parent directory (it applies to tests in that directory and all 
> sub-directories). Carter would have need the equivalent to compile with 
> JDK 9+ and to run with JDK 16+.

Ah! Thanks Alan!

David
-----

> -Alan.

From dholmes at openjdk.java.net  Thu Jun 17 06:11:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Jun 2021 06:11:07 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v2]
In-Reply-To: <3hM_tItjj51zsVQIrYIE7_3sR8j5A2ijdxKNbHmla_w=.f87dde43-a467-41cf-8bb0-e8a40b8d5d2b@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <3hM_tItjj51zsVQIrYIE7_3sR8j5A2ijdxKNbHmla_w=.f87dde43-a467-41cf-8bb0-e8a40b8d5d2b@github.com>
Message-ID: <RXTD2jCmFgLI7qyvvTtmtMIiqQEmeGc3bVqfQGHpBto=.c4734e08-59d7-4eb3-8af9-65805c870407@github.com>

On Thu, 17 Jun 2021 05:15:36 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update
>  - remove useless comment
>  - remove VM_PrintJNI

So the PR is open again but I see no substantive changes that address my concerns. I don't see how there can be any fix here when the desired goal is one safepoint and the problem is that one safepoint may be far too long. And I don't see any way to force a timeout in a VM operation, or anything it calls.

I realize there can be a discrepancy between the sets of threads involved, but I think that is just the trade-off we have to make for this diagnostic tool.

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

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

From stuefe at openjdk.java.net  Thu Jun 17 06:41:33 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 17 Jun 2021 06:41:33 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap
Message-ID: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>

The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.

This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.

The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.

This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.

Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
- when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
- as a stop gap measure it allows to release pressure from a high footprint scenario.

Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.

I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.

If this finds agreement, I will file a CSR.

=========

This patch:

- introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
- includes a (rather basic) test
- the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
- I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.

=========

Example:

A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:



thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
                   ^^^^^^^^


We execute the new trim command via jcmd:


thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
18770:
Attempting trim...
Done.
Virtual size before: 28849744k, after: 28849724k, (-20k)
RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
Swap before: 0k, after: 0k, (0k)


It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:


thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
                   ^^^^^^^


When the VM is started with -Xlog:os, this is also logged:


[139,068s][info][os] malloc_trim:
[139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
RSS before: 8685896k, after: 920740k, (-7765156k)
Swap before: 0k, after: 0k, (0k)

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

Commit messages:
 - start

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

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

From sgehwolf at openjdk.java.net  Thu Jun 17 08:34:11 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 17 Jun 2021 08:34:11 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap
In-Reply-To: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
Message-ID: <5EdNrljfk5N4trdLY5AaHPYbp1kx5ZMZmrMEW_wyc90=.c57a2937-8447-41c9-ace4-a2b72a3e05be@github.com>

On Wed, 16 Jun 2021 12:57:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
> 
> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
> 
> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
> 
> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
> 
> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
> - as a stop gap measure it allows to release pressure from a high footprint scenario.
> 
> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
> 
> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
> 
> If this finds agreement, I will file a CSR.
> 
> =========
> 
> This patch:
> 
> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
> - includes a (rather basic) test
> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
> 
> =========
> 
> Example:
> 
> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
> 
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>                    ^^^^^^^^
> 
> 
> We execute the new trim command via jcmd:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
> 18770:
> Attempting trim...
> Done.
> Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
> Swap before: 0k, after: 0k, (0k)
> 
> 
> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>                    ^^^^^^^
> 
> 
> When the VM is started with -Xlog:os, this is also logged:
> 
> 
> [139,068s][info][os] malloc_trim:
> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)
> Swap before: 0k, after: 0k, (0k)

src/hotspot/os/linux/os_linux.hpp line 186:

> 184:     ssize_t rssanon;    // resident set size
> 185:     ssize_t rssfile;    // resident set size
> 186:     ssize_t rssshmem;   // resident set size

Are these comments intionally the same for all three? Seems weird.

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

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

From stuefe at openjdk.java.net  Thu Jun 17 08:37:12 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 17 Jun 2021 08:37:12 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap
In-Reply-To: <5EdNrljfk5N4trdLY5AaHPYbp1kx5ZMZmrMEW_wyc90=.c57a2937-8447-41c9-ace4-a2b72a3e05be@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <5EdNrljfk5N4trdLY5AaHPYbp1kx5ZMZmrMEW_wyc90=.c57a2937-8447-41c9-ace4-a2b72a3e05be@github.com>
Message-ID: <rxSSCthgxDB888_mNkLAv8Ryc93jI_Ompo5dQwldhmI=.912cea66-18b5-414f-a57e-dfac5e3d29e2@github.com>

On Thu, 17 Jun 2021 08:25:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> src/hotspot/os/linux/os_linux.hpp line 186:
> 
>> 184:     ssize_t rssanon;    // resident set size
>> 185:     ssize_t rssfile;    // resident set size
>> 186:     ssize_t rssshmem;   // resident set size
> 
> Are these comments intionally the same for all three? Seems weird.

Nope, copy paste error. Thanks for catching.

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

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

From stuefe at openjdk.java.net  Thu Jun 17 08:53:55 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 17 Jun 2021 08:53:55 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
Message-ID: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>

> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
> 
> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
> 
> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
> 
> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
> 
> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
> - as a stop gap measure it allows to release pressure from a high footprint scenario.
> 
> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
> 
> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
> 
> If this finds agreement, I will file a CSR.
> 
> =========
> 
> This patch:
> 
> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
> - includes a (rather basic) test
> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
> 
> =========
> 
> Example:
> 
> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
> 
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>                    ^^^^^^^^
> 
> 
> We execute the new trim command via jcmd:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
> 18770:
> Attempting trim...
> Done.
> Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
> Swap before: 0k, after: 0k, (0k)
> 
> 
> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>                    ^^^^^^^
> 
> 
> When the VM is started with -Xlog:os, this is also logged:
> 
> 
> [139,068s][info][os] malloc_trim:
> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)
> Swap before: 0k, after: 0k, (0k)

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

  Feedback Severin; renamed query function

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4510/files
  - new: https://git.openjdk.java.net/jdk/pull/4510/files/97d71ea7..a48791e4

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

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

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

From alanb at openjdk.java.net  Thu Jun 17 10:28:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 17 Jun 2021 10:28:15 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <b9rwgIGQ-3rspQK3fJVPIuS2wMzJ287W2rky8nh9pyQ=.18276bc3-fab8-4fef-8409-166503b01dd6@github.com>

On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang <yyang at openjdk.org> wrote:

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

I looked through the changes in java.base and only spotted one case where a different (and more specific) exception is thrown.

The changes to to files in java.util.zip lead to annoying long lines so would be good to fix all those.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 471:

> 469:      */
> 470:     public int offsetByCodePoints(int index, int codePointOffset) {
> 471:         checkOffset(index, count);

String.offsetByCodePoints is specified to throw IOOBE. checkOffset may throw the more specific StringIndexOutOfBoundsException. That's a compatible change but I worry that we might want to throw the less specific exception in the further because code. I only mention is because there have been cases in java.lang where IOOBE was specified and AIOOBE by the implementation and it has been problematic to touch the implementation as a result.

src/java.base/share/classes/java/util/Base64.java line 934:

> 932:             if (closed)
> 933:                 throw new IOException("Stream is closed");
> 934:             Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException());

You might to split this really long line to avoid inconsistent line length in this source file.

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

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

From alanb at openjdk.java.net  Thu Jun 17 10:50:13 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 17 Jun 2021 10:50:13 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
Message-ID: <bXG7stDIdAjy7t4JZNmD_-vL0PwWdm-0K1quvA9KJRk=.f8a8564c-9a43-4a1a-8976-66e0b90e990c@github.com>

On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.

It would be good to run tier 1-3. Off hand I can't think of any tests that are dependent on the exception message, I think I'm more concerned about changing behavior (once you throw a more specific IOOBE is some of the very core classes then it's hard to change it because libraries get dependent on the more specific exception).

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

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

From jbachorik at openjdk.java.net  Thu Jun 17 11:17:12 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Thu, 17 Jun 2021 11:17:12 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v2]
In-Reply-To: <Sh6SwxGrn3gEhcWLGK_729I4Bjg6wutfT9ssNir0WfU=.046c4e36-53ec-490e-98c2-2d97d99d9159@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <Sh6SwxGrn3gEhcWLGK_729I4Bjg6wutfT9ssNir0WfU=.046c4e36-53ec-490e-98c2-2d97d99d9159@github.com>
Message-ID: <BQyYkpOKI0TxiTHMEjBLkw8IhQaJmyz3_ogQDHA8hdk=.6442c614-db74-430e-adf9-340ab3aaf0bc@github.com>

On Thu, 10 Jun 2021 07:50:57 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
>> 
>> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
>> 
>> # `Prof1`
>> 
>> public class Prof1 {
>> 
>>     public static void main(String[] args) {
>>         StringBuilder sb = new StringBuilder();
>>         for (int i = 0; i < 1000000; i++) {
>>             sb.append("ab");
>>             sb.delete(0, 1);
>>         }
>>         System.out.println(sb.length());
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>>         (t  0.5,s  0.2) Prof1::main
>>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>>         (t  0.0,s  0.0) java.lang.String::getBytes
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> 
>> - With `StubRoutinesBlob::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>>         (t 99.8,s  0.2) Prof1::main
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
>> 
>> 
>> # `Prof2`
>> 
>> import java.util.function.Supplier;
>> 
>> public class Prof2 {
>> 
>>     public static void main(String[] args) {
>>         var rand = new java.util.Random(0);
>>         Supplier[] suppliers = {
>>                 () -> 0,
>>                 () -> 1,
>>                 () -> 2,
>>                 () -> 3,
>>         };
>> 
>>         long sum = 0;
>>         for (int i = 0; i >= 0; i++) {
>>             sum += (int)suppliers[i % suppliers.length].get();
>>         }
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>>         (t 39.2,s 35.2) Prof2::main
>>         (t  1.4,s  1.4) Prof2::lambda$main$3
>>         (t  1.0,s  1.0) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.Thread::exit
>>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>> 
>> 
>> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 74.1,s 70.3) Prof2::main
>>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>>         (t  1.2,s  1.2) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$3
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>
> Ludovic Henry 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.

I have done a sanity check to make sure that the code was not functionally modified while moving around.
No problems found there.

src/hotspot/cpu/aarch64/codeBlob_aarch64.cpp line 47:

> 45: 
> 46:   if (check && !_cb->is_frame_complete_at(pc)) {
> 47:     if (_cb->is_adapter_blob()) {

Please, update the comment at L41-44 to correspond to the modified condition,

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

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

From david.holmes at oracle.com  Thu Jun 17 12:25:07 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 17 Jun 2021 22:25:07 +1000
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <bXG7stDIdAjy7t4JZNmD_-vL0PwWdm-0K1quvA9KJRk=.f8a8564c-9a43-4a1a-8976-66e0b90e990c@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
 <bXG7stDIdAjy7t4JZNmD_-vL0PwWdm-0K1quvA9KJRk=.f8a8564c-9a43-4a1a-8976-66e0b90e990c@github.com>
Message-ID: <59f05d6a-66a7-129c-4897-e45b4dd564ab@oracle.com>

On 17/06/2021 8:50 pm, Alan Bateman wrote:
> On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.
> 
> It would be good to run tier 1-3. Off hand I can't think of any tests that are dependent on the exception message, I think I'm more concerned about changing behavior (once you throw a more specific IOOBE is some of the very core classes then it's hard to change it because libraries get dependent on the more specific exception).

tiers 1-3 on Linux-x64 passed okay.

Any change to the exact type of exception thrown should be affirmed 
through a CSR request.

Cheers,
David

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

From ckozak at ckozak.net  Thu Jun 17 13:44:43 2021
From: ckozak at ckozak.net (Carter Kozak)
Date: Thu, 17 Jun 2021 09:44:43 -0400
Subject: Monitoring Java Safepoint Time in JDK16+
In-Reply-To: <f2fdced8-2ab3-3ee1-8e32-8d11d909491b@oracle.com>
References: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
 <8740f0b6-7036-a2ba-0d57-5065a8930103@oracle.com>
 <4c4be2ca-211b-be9b-79dc-20669d0f37e8@oracle.com>
 <f2fdced8-2ab3-3ee1-8e32-8d11d909491b@oracle.com>
Message-ID: <cfd898c4-1bc0-4832-ba85-1fb617f6bb22@www.fastmail.com>

On 17/06/2021 3:15 pm, Alan Bateman wrote:
> On 17/06/2021 02:39, David Holmes wrote:
>> In what way does this no longer work? We have a test in
>> jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java that
>> uses this API and doesn't seem to need to do anything to allow access. ??
> That test is compiled/run with `--add-exports
> java.management/sun.management=ALL-UNNAMED`, just not immediately
> obvious because the TEST.properties with the config for jtreg is in the
> parent directory (it applies to tests in that directory and all
> sub-directories). Carter would have need the equivalent to compile with
> JDK 9+ and to run with JDK 16+.

Thanks for the clarification! The trouble is that I maintain a microservice framework/library which produces metrics, however I don't have access to provide java arguments in most cases. I'd prefer to avoid requiring additional manual action from my users when they upgrade to the next java LTS, especially given we don't want to get into the habit of opening additional modules after the fact. This is useful information as a break-glass measure, and something I can work with, but I'd like to work toward an end state in which there's an exposed public API to capture safepoint metrics. The JFR event stream may be that mechanism, although I'm not sure the overhead/tradeoffs make sense as a replacement given we're already aggregating safepoint time elsewhere in memory.

Thanks,
Carter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210617/9e35c0b6/attachment.htm>

From ddong at openjdk.java.net  Thu Jun 17 15:32:01 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Thu, 17 Jun 2021 15:32:01 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v3]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Denghui Dong has updated the pull request incrementally with two additional commits since the last revision:

 - add cutoff support for find_deadlocks_at_safepoint
 - remove useless field '_is_deadlock'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/56cd2a8b..42faa20b

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

  Stats: 53 lines in 4 files changed: 36 ins; 8 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4504.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4504/head:pull/4504

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

From psandoz at openjdk.java.net  Thu Jun 17 15:48:32 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 17 Jun 2021 15:48:32 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <b9rwgIGQ-3rspQK3fJVPIuS2wMzJ287W2rky8nh9pyQ=.18276bc3-fab8-4fef-8409-166503b01dd6@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <b9rwgIGQ-3rspQK3fJVPIuS2wMzJ287W2rky8nh9pyQ=.18276bc3-fab8-4fef-8409-166503b01dd6@github.com>
Message-ID: <3vZDbR7Mvc1q5evU7jG0IkHSoL9gJArATqeUDPnZxfw=.256faaf6-8f80-4e36-8ccf-555c1fd63d2a@github.com>

On Thu, 17 Jun 2021 10:21:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> src/java.base/share/classes/java/util/Base64.java line 934:
> 
>> 932:             if (closed)
>> 933:                 throw new IOException("Stream is closed");
>> 934:             Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException());
> 
> You might want to split this really long line too, to avoid inconsistent line length in this source file.

I would suggest factoring out `(xa, xb) -> new ArrayIndexOutOfBoundsException()` as a reusable component on `Preconditions`, and maybe even supplying an exception message (since it is rather useful, and way better than no message).

See the usages of `Preconditions.outOfBoundsExceptionFormatter` (where there just happens to be many repeated cases of supplying AIOOBE with a message, that could also be consolidated, separate fix perhaps).

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

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

From kvn at openjdk.java.net  Thu Jun 17 16:57:31 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 17 Jun 2021 16:57:31 GMT
Subject: RFR: 8264941: Remove CodeCache::mark_for_evol_deoptimization()
 method
In-Reply-To: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
References: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
Message-ID: <Ef56DkVi7VhtI5c1KHdYtvPY8l4Xp67nPQRwTTn3Q-s=.7957d9dd-3356-4495-9bac-85ccc0dc63c1@github.com>

On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the mark_for_evol_deoptimization method and removes the flag that all dependencies are recorded.  Before the change to walk the entire nmethod looking for "old" (redefined) methods with metadata_do(), we used to find methods in the code cache to deoptimize based on evol_method dependencies.  If the dependencies weren't yet recorded, we had to deoptimize all of the methods.  A long time ago, we had a customer who was unhappy with the pause for this when they had late attach.  Now we don't have this problem.
> The evol_method dependencies are still used by the compiler to check for old methods during compilation.  I didn't change this but it might be something someone who knows the compiler better can do differently and remove these dependencies too.
> Tested with tier1-6.

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From dcubed at openjdk.java.net  Thu Jun 17 17:00:33 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Jun 2021 17:00:33 GMT
Subject: [jdk17] RFR: 8268433:
 serviceability/dcmd/framework/VMVersionTest.java fails with Unable to send
 object throw not established PipeIO Listener Thread connection
In-Reply-To: <SWTjfusblemekxL30ESme75xseVIwBxCg1bUdeX0h7o=.a132b9f5-c710-4647-979d-2c13fe67866a@github.com>
References: <SWTjfusblemekxL30ESme75xseVIwBxCg1bUdeX0h7o=.a132b9f5-c710-4647-979d-2c13fe67866a@github.com>
Message-ID: <huOtcxUiyu1Pfxc9lMlGwFVUydNDjEMt0A5aToUq4mY=.48850b14-00aa-40dd-9c1c-f5a8094e1596@github.com>

On Fri, 11 Jun 2021 19:40:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds check that IOPipe is connected before sending "quit" command

ProblemListings that are integrated in JDK17 will get sync'ed forward to JDK18.
The thing to do is remove the test from the ProblemList in your PR so that your
test jobs execute your modified test. I don't know whether you think this test
should be fixed in JDK17 or not, but, in any case, you'll (eventually) have to update
the ProblemList in JDK18 also.

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

PR: https://git.openjdk.java.net/jdk17/pull/32

From vlivanov at openjdk.java.net  Thu Jun 17 21:08:30 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 17 Jun 2021 21:08:30 GMT
Subject: RFR: 8264941: Remove CodeCache::mark_for_evol_deoptimization()
 method
In-Reply-To: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
References: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
Message-ID: <xk56ohDFhgnqffuCBxG1AEviJGIMclrq3w9NU2qiFQI=.0e56347f-453c-4300-bc23-39b210db98f1@github.com>

On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the mark_for_evol_deoptimization method and removes the flag that all dependencies are recorded.  Before the change to walk the entire nmethod looking for "old" (redefined) methods with metadata_do(), we used to find methods in the code cache to deoptimize based on evol_method dependencies.  If the dependencies weren't yet recorded, we had to deoptimize all of the methods.  A long time ago, we had a customer who was unhappy with the pause for this when they had late attach.  Now we don't have this problem.
> The evol_method dependencies are still used by the compiler to check for old methods during compilation.  I didn't change this but it might be something someone who knows the compiler better can do differently and remove these dependencies too.
> Tested with tier1-6.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

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

From david.holmes at oracle.com  Thu Jun 17 21:44:40 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Jun 2021 07:44:40 +1000
Subject: Monitoring Java Safepoint Time in JDK16+
In-Reply-To: <cfd898c4-1bc0-4832-ba85-1fb617f6bb22@www.fastmail.com>
References: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
 <8740f0b6-7036-a2ba-0d57-5065a8930103@oracle.com>
 <4c4be2ca-211b-be9b-79dc-20669d0f37e8@oracle.com>
 <f2fdced8-2ab3-3ee1-8e32-8d11d909491b@oracle.com>
 <cfd898c4-1bc0-4832-ba85-1fb617f6bb22@www.fastmail.com>
Message-ID: <049908d0-e930-a61d-59be-8b7a7989e1f9@oracle.com>

On 17/06/2021 11:44 pm, Carter Kozak wrote:
> On 17/06/2021 3:15 pm, Alan Bateman wrote:
>  > On 17/06/2021 02:39, David Holmes wrote:
>  >> In what way does this no longer work? We have a test in
>  >> jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java that
>  >> uses this API and doesn't seem to need to do anything to allow 
> access. ??
>  > That test is compiled/run with `--add-exports
>  > java.management/sun.management=ALL-UNNAMED 
> <http://java.management/sun.management=ALL-UNNAMED>`, just not immediately
>  > obvious because the TEST.properties with the config for jtreg is in the
>  > parent directory (it applies to tests in that directory and all
>  > sub-directories). Carter would have need the equivalent to compile with
>  > JDK 9+ and to run with JDK 16+.
> 
> Thanks for the clarification! The trouble is that I maintain a 
> microservice framework/library which produces metrics, however I don't 
> have access to provide java arguments in most cases. I'd prefer to avoid 
> requiring additional manual action from my users when they upgrade to 
> the next java LTS, especially given we don't want to get into the habit 
> of opening additional modules after the fact. This is useful information 
> as a break-glass measure, and something I can work with, but I'd like to 
> work toward an end state in which there's an exposed public API to 
> capture safepoint metrics. The JFR event stream may be that mechanism, 
> although I'm not sure the overhead/tradeoffs make sense as a replacement 
> given we're already aggregating safepoint time elsewhere in memory.

I must admit I'm a bit confused about these implementation-specific 
MBeans. They are implementation-specific, so no part of the primary 
java.management namespace, but they are provided so that they can be 
used - so shutting them behind the modular doors (so to speak) really 
doesn't make much sense to me.

David
-----

> Thanks,
> Carter
> 
> 

From dholmes at openjdk.java.net  Thu Jun 17 23:15:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Jun 2021 23:15:25 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v3]
In-Reply-To: <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>
Message-ID: <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>

On Thu, 17 Jun 2021 15:32:01 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add cutoff support for find_deadlocks_at_safepoint
>  - remove useless field '_is_deadlock'

Sorry still not a fan even with the hacked in deadline support for find_deadlocks. It is too arbitrary - you have no idea what constitutes a reasonable deadline, nor by how much you may overshoot that deadline.

David

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

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

From ddong at openjdk.java.net  Fri Jun 18 02:29:25 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 02:29:25 GMT
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v3]
In-Reply-To: <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>
 <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>
Message-ID: <tBn8E4Fi3YBPEgmNfngIVp66iEOpjqQp83dNM4Iyyhg=.e57a2613-c30f-41f2-8835-d168f4a81b81@github.com>

On Thu, 17 Jun 2021 23:12:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry still not a fan even with the hacked in deadline support for find_deadlocks. It is too arbitrary - you have no idea what constitutes a reasonable deadline, nor by how much you may overshoot that deadline.
> 
> David

Hi David,

Thanks for the comment.

Yes, there is no good way to determine a suitable deadline.

I intend to temporarily give up the idea of combining VM_FindDeadlocks into VM_ExtendedPrintThreads.

But I think we can at least merge `VM_PrintJNI` and `VM_PrintThreads`, because the implementation of `VM_PrintJNI` is very fast. What do you think?

Denghui

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

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

From david.holmes at oracle.com  Fri Jun 18 03:20:37 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Jun 2021 13:20:37 +1000
Subject: RFR: 8268857: Merge three vm operations in thread_dump [v3]
In-Reply-To: <tBn8E4Fi3YBPEgmNfngIVp66iEOpjqQp83dNM4Iyyhg=.e57a2613-c30f-41f2-8835-d168f4a81b81@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>
 <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>
 <tBn8E4Fi3YBPEgmNfngIVp66iEOpjqQp83dNM4Iyyhg=.e57a2613-c30f-41f2-8835-d168f4a81b81@github.com>
Message-ID: <d6336655-520d-04f7-17dc-4f25335e4c16@oracle.com>

On 18/06/2021 12:29 pm, Denghui Dong wrote:
> On Thu, 17 Jun 2021 23:12:04 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Sorry still not a fan even with the hacked in deadline support for find_deadlocks. It is too arbitrary - you have no idea what constitutes a reasonable deadline, nor by how much you may overshoot that deadline.
>>
>> David
> 
> Hi David,
> 
> Thanks for the comment.
> 
> Yes, there is no good way to determine a suitable deadline.
> 
> I intend to temporarily give up the idea of combining VM_FindDeadlocks into VM_ExtendedPrintThreads.
> 
> But I think we can at least merge `VM_PrintJNI` and `VM_PrintThreads`, because the implementation of `VM_PrintJNI` is very fast. What do you think?

Yes that seems fine in terms of lengthening the safepoint.

Thanks,
David
-----

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

From ddong at openjdk.java.net  Fri Jun 18 05:51:54 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 05:51:54 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v4]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <XPYkVnhOiPDmbZL2NoOZZQniQaZI-A1Rfk8V0OeuSoM=.8057d194-cab0-400d-b81b-4248a71ddf0e@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

Denghui Dong 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:

  update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/42faa20b..01a0308d

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

  Stats: 67 lines in 7 files changed: 12 ins; 42 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4504.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4504/head:pull/4504

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

From yyang at openjdk.java.net  Fri Jun 18 05:54:05 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 05:54:05 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: <b9rwgIGQ-3rspQK3fJVPIuS2wMzJ287W2rky8nh9pyQ=.18276bc3-fab8-4fef-8409-166503b01dd6@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <b9rwgIGQ-3rspQK3fJVPIuS2wMzJ287W2rky8nh9pyQ=.18276bc3-fab8-4fef-8409-166503b01dd6@github.com>
Message-ID: <LgtjJm8e3_oYuPnzvfatnqriZ_LRwUqLiUqyCWNXE8k=.d75fb601-a19d-4fe2-870f-49393b52ed8a@github.com>

On Thu, 17 Jun 2021 10:19:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore IndexOfOufBoundsException; split exception line
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 471:
> 
>> 469:      */
>> 470:     public int offsetByCodePoints(int index, int codePointOffset) {
>> 471:         checkOffset(index, count);
> 
> String.offsetByCodePoints is specified to throw IOOBE. checkOffset may throw the more specific StringIndexOutOfBoundsException. That's a compatible change but I worry that we might want to throw the less specific exception in the future. I only mention it because there have been cases in java.lang where IOOBE was specified and AIOOBE by the implementation and it has been problematic to touch the implementation as a result.

Yes, changing the type of thrown exception may break something. And as David said, this also requires a CSR approval, which is a relatively long process, so I restored the original code.

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

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

From yyang at openjdk.java.net  Fri Jun 18 05:54:01 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 05:54:01 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <urCq8J9b5y8YFa3MjVMEShSDEEl07GmF_nTyFBE2nig=.1668471c-d068-4b60-80c4-956631e36661@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

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

  restore IndexOfOufBoundsException; split exception line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/593bf995..ec0a4d44

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

  Stats: 30 lines in 8 files changed: 15 ins; 2 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

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

From ddong at openjdk.java.net  Fri Jun 18 06:08:48 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 06:08:48 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v5]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <7WMt3oxWuLYri_5031dtWRMZ9KQgCT_IKKjf6oSd61w=.b9fee416-2ce6-4cf2-aa7f-cc34af0d233f@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

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

  polish

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/01a0308d..bec65ddb

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

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

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

From yyang at openjdk.java.net  Fri Jun 18 06:10:27 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 06:10:27 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: <urCq8J9b5y8YFa3MjVMEShSDEEl07GmF_nTyFBE2nig=.1668471c-d068-4b60-80c4-956631e36661@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <urCq8J9b5y8YFa3MjVMEShSDEEl07GmF_nTyFBE2nig=.1668471c-d068-4b60-80c4-956631e36661@github.com>
Message-ID: <SMTp7RdNxju301tZ40NsowYCw94iZNPM8PkyXqxgku4=.648a6cb4-3b3f-4fb9-9b4d-ef10496aabdd@github.com>

On Fri, 18 Jun 2021 05:54:01 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore IndexOfOufBoundsException; split exception line

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [serviceability-dev](mailto:serviceability-dev at mail.openjdk.java.net):_
> 
> On 17/06/2021 8:50 pm, Alan Bateman wrote:
> 
> > On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes <dholmes at openjdk.org> wrote:
> > > There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.
> > 
> > 
> > It would be good to run tier 1-3. Off hand I can't think of any tests that are dependent on the exception message, I think I'm more concerned about changing behavior (once you throw a more specific IOOBE is some of the very core classes then it's hard to change it because libraries get dependent on the more specific exception).
> 
> tiers 1-3 on Linux-x64 passed okay.
> 
> Any change to the exact type of exception thrown should be affirmed
> through a CSR request.
> 
> Cheers,
> David

Thank you David for running these tests!

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

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

From yyang at openjdk.java.net  Fri Jun 18 06:10:27 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 06:10:27 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: <3vZDbR7Mvc1q5evU7jG0IkHSoL9gJArATqeUDPnZxfw=.256faaf6-8f80-4e36-8ccf-555c1fd63d2a@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <b9rwgIGQ-3rspQK3fJVPIuS2wMzJ287W2rky8nh9pyQ=.18276bc3-fab8-4fef-8409-166503b01dd6@github.com>
 <3vZDbR7Mvc1q5evU7jG0IkHSoL9gJArATqeUDPnZxfw=.256faaf6-8f80-4e36-8ccf-555c1fd63d2a@github.com>
Message-ID: <_doEJsq2BCo-Bkj8aoB6EemEkhPS-eTcr_Zq8NIf0qM=.012d8685-d7eb-4133-bdf7-9366ee394004@github.com>

On Thu, 17 Jun 2021 15:45:47 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Base64.java line 934:
>> 
>>> 932:             if (closed)
>>> 933:                 throw new IOException("Stream is closed");
>>> 934:             Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException());
>> 
>> You might want to split this really long line too, to avoid inconsistent line length in this source file.
>
> I would suggest factoring out `(xa, xb) -> new ArrayIndexOutOfBoundsException()` as a reusable component on `Preconditions`, and maybe even supplying an exception message (since it is rather useful, and way better than no message).
> 
> See the usages of `Preconditions.outOfBoundsExceptionFormatter` (where there just happens to be many repeated cases of supplying AIOOBE with a message, that could also be consolidated, separate fix perhaps).

Ok, I've replaced

Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException());

with 

Preconditions.checkFromIndexSize(len, off, b.length,
    Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new));


----

I am curious about the motivations of current APIs:

public static <X extends RuntimeException>
int checkIndex(int index, int length,
               BiFunction<String, List<Number>, X> oobef) {
    if (index < 0 || index >= length)
        throw outOfBoundsCheckIndex(oobef, index, length);
    return index;
}

Are they over-engineered? When I checked all checkIndex-like patterns in the whole jdk codebase, I found that in most cases, providing an API that accepts custom exception should be enough for scalability:

int checkIndex(int index, int length, IndexOutOfBoundException iooe) {
    if (index < 0 || index >= length)
        throw iooe;
    return index;
}

In addition to the ease-of-use problem, there is another problem with the current API design.

Some methods in j.l.String are good replacement candidates for Preconditions.check{Index,...}:

https://github.com/openjdk/jdk/blob/a051e735cda0d5ee5cb6ce0738aa549a7319a28c/src/java.base/share/classes/java/lang/String.java#L4558-L4604

But we **can not** do such replacement after my practice.

The third parameter of Preconditions.checkIndex is a BiFunction, which can be passed a lambda as its argument. The generated lambda method exercises many other codes like MethodHandles, j.l.Package, etc, eventually it called j.l.String.checkIndex itself, so if we replace j.l.String.checkIndex with `Preconditions.checkIndex(a,b,(x1,x2)->....)`, a StackOverflowError would occur at VM startup. 

If there is an API that accepts user-defined exceptions, I think we can apply Preconditions in more places.

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

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

From dholmes at openjdk.java.net  Fri Jun 18 06:27:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 18 Jun 2021 06:27:26 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v5]
In-Reply-To: <7WMt3oxWuLYri_5031dtWRMZ9KQgCT_IKKjf6oSd61w=.b9fee416-2ce6-4cf2-aa7f-cc34af0d233f@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <7WMt3oxWuLYri_5031dtWRMZ9KQgCT_IKKjf6oSd61w=.b9fee416-2ce6-4cf2-aa7f-cc34af0d233f@github.com>
Message-ID: <mif25qZxdkgaRq7v1m0Q_HSaUlSHbcKBFA3v0zVzdg4=.639bdff7-63e0-47f3-b487-51782554f924@github.com>

On Fri, 18 Jun 2021 06:08:48 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   polish

This looks much better. A few minor code changes requested - and possibly a big simplification.

Thanks,
David

src/hotspot/share/runtime/os.cpp line 402:

> 400:         // the output stream (e.g. tty->flush()) after output.  See 4803766.
> 401:         // Each module also prints an extra carriage return after its output.
> 402:         VM_PrintThreads op(tty, PrintConcurrentLocks, false, true);

Please comment what the false/true arguments mean e.g.

... false /* no extended info */, true /* print JNI handle info */);

src/hotspot/share/runtime/vmOperation.hpp line 112:

> 110:   template(JFROldObject)                          \
> 111:   template(JvmtiPostObjectFree)                   \
> 112:   template(ExtendedPrintThreads)

This change is not needed now.

src/hotspot/share/runtime/vmOperations.hpp line 146:

> 144:   bool _print_concurrent_locks;
> 145:   bool _print_extended_info;
> 146:   bool _print_jni;

Please call this _print_jni_handle_info and update parameter names accordingly.

Though it seems we never pass false here and so always print the JNI handle info, in which case we can get rid of the field and the parameter.

src/hotspot/share/runtime/vmOperations.hpp line 150:

> 148:   VM_PrintThreads()
> 149:     : _out(tty), _print_concurrent_locks(PrintConcurrentLocks), _print_extended_info(false), _print_jni(false)
> 150:   {}

This no-arg constructor is unused now.

src/hotspot/share/runtime/vmOperations.hpp line 151:

> 149:     : _out(tty), _print_concurrent_locks(PrintConcurrentLocks), _print_extended_info(false), _print_jni(false)
> 150:   {}
> 151:   VM_PrintThreads(outputStream* out, bool print_concurrent_locks, bool print_extended_info, bool print_jni = false)

As far as I can see you don't rely on the default parameter value so it is not needed.

src/hotspot/share/services/attachListener.cpp line 187:

> 185: 
> 186:   // thread stacks and JNI global handles
> 187:   VM_PrintThreads op1(out, print_concurrent_locks, print_extended_info, true);

Please comment what the true argument means.

src/hotspot/share/services/diagnosticCommand.cpp line 538:

> 536: void ThreadDumpDCmd::execute(DCmdSource source, TRAPS) {
> 537:   // thread stacks and JNI global handles
> 538:   VM_PrintThreads op1(output(), _locks.value(), _extended.value(), true);

Please comment what the true argument means.

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

Changes requested by dholmes (Reviewer).

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

From Alan.Bateman at oracle.com  Fri Jun 18 06:35:48 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 18 Jun 2021 07:35:48 +0100
Subject: Monitoring Java Safepoint Time in JDK16+
In-Reply-To: <049908d0-e930-a61d-59be-8b7a7989e1f9@oracle.com>
References: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
 <8740f0b6-7036-a2ba-0d57-5065a8930103@oracle.com>
 <4c4be2ca-211b-be9b-79dc-20669d0f37e8@oracle.com>
 <f2fdced8-2ab3-3ee1-8e32-8d11d909491b@oracle.com>
 <cfd898c4-1bc0-4832-ba85-1fb617f6bb22@www.fastmail.com>
 <049908d0-e930-a61d-59be-8b7a7989e1f9@oracle.com>
Message-ID: <05910f1a-ca46-3663-03f7-dae0add42aab@oracle.com>

On 17/06/2021 22:44, David Holmes wrote:
>
> I must admit I'm a bit confused about these implementation-specific 
> MBeans. They are implementation-specific, so no part of the primary 
> java.management namespace, but they are provided so that they can be 
> used - so shutting them behind the modular doors (so to speak) really 
> doesn't make much sense to me.
The JDK-specific MBeans are in the com.sun.management package, exported 
by the jdk.management module.? The sun.management.* classes have always 
been JDK-internal implementation classes and were never mean to be used 
directly by code outside of the JDK. Directly referencing these classes 
would have been a warning at compile prior with JDK 8 and older. It 
changed an error at compile time in JDK 9.

-Alan

From ddong at openjdk.java.net  Fri Jun 18 06:46:01 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 06:46:01 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v6]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <LFHDL0U6xGKZuTj0KkSNQ7ngoMMgJZ9y4oWX2_Scis4=.a6a4d9f9-1fbe-4bc7-9176-5306d6e8ea66@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

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

  update according to the comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/bec65ddb..c9a65726

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

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

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

From david.holmes at oracle.com  Fri Jun 18 06:47:35 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Jun 2021 16:47:35 +1000
Subject: Monitoring Java Safepoint Time in JDK16+
In-Reply-To: <05910f1a-ca46-3663-03f7-dae0add42aab@oracle.com>
References: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
 <8740f0b6-7036-a2ba-0d57-5065a8930103@oracle.com>
 <4c4be2ca-211b-be9b-79dc-20669d0f37e8@oracle.com>
 <f2fdced8-2ab3-3ee1-8e32-8d11d909491b@oracle.com>
 <cfd898c4-1bc0-4832-ba85-1fb617f6bb22@www.fastmail.com>
 <049908d0-e930-a61d-59be-8b7a7989e1f9@oracle.com>
 <05910f1a-ca46-3663-03f7-dae0add42aab@oracle.com>
Message-ID: <a7a6050f-a657-3a2d-7918-79b582853829@oracle.com>

On 18/06/2021 4:35 pm, Alan Bateman wrote:
> On 17/06/2021 22:44, David Holmes wrote:
>>
>> I must admit I'm a bit confused about these implementation-specific 
>> MBeans. They are implementation-specific, so no part of the primary 
>> java.management namespace, but they are provided so that they can be 
>> used - so shutting them behind the modular doors (so to speak) really 
>> doesn't make much sense to me.
> The JDK-specific MBeans are in the com.sun.management package, exported 
> by the jdk.management module.? The sun.management.* classes have always 
> been JDK-internal implementation classes and were never mean to be used 
> directly by code outside of the JDK. Directly referencing these classes 
> would have been a warning at compile prior with JDK 8 and older. It 
> changed an error at compile time in JDK 9.

Ah! I now see:

    /**
      * This method is for testing only.
      */
     public static synchronized HotspotRuntimeMBean 
getHotspotRuntimeMBean() {
         if (hsRuntimeMBean == null) {
             hsRuntimeMBean = new HotspotRuntime(jvm);
         }
         return hsRuntimeMBean;
     }

in sun.management.ManagementFactoryHelper. So it seems there is no 
actual _use_ of these platform-specific MBeans even within the JDK. So 
their existence seems somewhat pointless.

Cheers,
David


> -Alan

From ddong at openjdk.java.net  Fri Jun 18 06:51:57 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 06:51:57 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v5]
In-Reply-To: <mif25qZxdkgaRq7v1m0Q_HSaUlSHbcKBFA3v0zVzdg4=.639bdff7-63e0-47f3-b487-51782554f924@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <7WMt3oxWuLYri_5031dtWRMZ9KQgCT_IKKjf6oSd61w=.b9fee416-2ce6-4cf2-aa7f-cc34af0d233f@github.com>
 <mif25qZxdkgaRq7v1m0Q_HSaUlSHbcKBFA3v0zVzdg4=.639bdff7-63e0-47f3-b487-51782554f924@github.com>
Message-ID: <XrNsDu43EJ9n8i0e1h1G2vQeen4qWtQejC9TvmW5S-8=.b8b7eb1b-9a43-49f5-a0f8-4b32313d22df@github.com>

On Fri, 18 Jun 2021 06:17:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   polish
>
> src/hotspot/share/runtime/os.cpp line 402:
> 
>> 400:         // the output stream (e.g. tty->flush()) after output.  See 4803766.
>> 401:         // Each module also prints an extra carriage return after its output.
>> 402:         VM_PrintThreads op(tty, PrintConcurrentLocks, false, true);
> 
> Please comment what the false/true arguments mean e.g.
> 
> ... false /* no extended info */, true /* print JNI handle info */);

fixed.

> src/hotspot/share/runtime/vmOperation.hpp line 112:
> 
>> 110:   template(JFROldObject)                          \
>> 111:   template(JvmtiPostObjectFree)                   \
>> 112:   template(ExtendedPrintThreads)
> 
> This change is not needed now.

fixed.

> src/hotspot/share/runtime/vmOperations.hpp line 146:
> 
>> 144:   bool _print_concurrent_locks;
>> 145:   bool _print_extended_info;
>> 146:   bool _print_jni;
> 
> Please call this _print_jni_handle_info and update parameter names accordingly.
> 
> Though it seems we never pass false here and so always print the JNI handle info, in which case we can get rid of the field and the parameter.

fixed.

> src/hotspot/share/runtime/vmOperations.hpp line 150:
> 
>> 148:   VM_PrintThreads()
>> 149:     : _out(tty), _print_concurrent_locks(PrintConcurrentLocks), _print_extended_info(false), _print_jni(false)
>> 150:   {}
> 
> This no-arg constructor is unused now.

the no-arg  constructor is used by JVM_DumpAllStacks now.

> src/hotspot/share/runtime/vmOperations.hpp line 151:
> 
>> 149:     : _out(tty), _print_concurrent_locks(PrintConcurrentLocks), _print_extended_info(false), _print_jni(false)
>> 150:   {}
>> 151:   VM_PrintThreads(outputStream* out, bool print_concurrent_locks, bool print_extended_info, bool print_jni = false)
> 
> As far as I can see you don't rely on the default parameter value so it is not needed.

fixed

> src/hotspot/share/services/attachListener.cpp line 187:
> 
>> 185: 
>> 186:   // thread stacks and JNI global handles
>> 187:   VM_PrintThreads op1(out, print_concurrent_locks, print_extended_info, true);
> 
> Please comment what the true argument means.

fixed

> src/hotspot/share/services/diagnosticCommand.cpp line 538:
> 
>> 536: void ThreadDumpDCmd::execute(DCmdSource source, TRAPS) {
>> 537:   // thread stacks and JNI global handles
>> 538:   VM_PrintThreads op1(output(), _locks.value(), _extended.value(), true);
> 
> Please comment what the true argument means.

fixed

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

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

From ddong at openjdk.java.net  Fri Jun 18 06:51:53 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 06:51:53 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v7]
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

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

  update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4504/files
  - new: https://git.openjdk.java.net/jdk/pull/4504/files/c9a65726..a9c0e177

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

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

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

From dholmes at openjdk.java.net  Fri Jun 18 07:08:32 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 18 Jun 2021 07:08:32 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v7]
In-Reply-To: <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
Message-ID: <9nOWHRzKTIgWLo9nXfWvk6oGUAc53E5lIyzpIGZoOT8=.7f6a388a-cf48-4a5a-898d-37d847cb9d09@github.com>

On Fri, 18 Jun 2021 06:51:53 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Nothing further from me.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From ddong at openjdk.java.net  Fri Jun 18 07:15:25 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Fri, 18 Jun 2021 07:15:25 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v3]
In-Reply-To: <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <dnoP2Axs2jrYbROD7KAQ3VDOgX0YtxWlHqCnVKRVUL8=.14cf6a43-4fe6-4c52-a691-268870937f35@github.com>
 <C6SD9lk5R7AWy6_XMvLgzYvWagGPYWfAtu81XcWfeG0=.4e52e956-ab7e-486d-90af-304ffb4e6add@github.com>
Message-ID: <juZ67rdmi-gAVR_j-CaFo_UysKETFfR9s9TOpBPDot0=.94647ed4-819c-49fb-b618-c2c27c93780a@github.com>

On Thu, 17 Jun 2021 23:12:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Denghui Dong 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.
>
> Sorry still not a fan even with the hacked in deadline support for find_deadlocks. It is too arbitrary - you have no idea what constitutes a reasonable deadline, nor by how much you may overshoot that deadline.
> 
> David

@dholmes-ora 
Thank you!

@tstuefe Could you help review this change?

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

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

From luhenry at openjdk.java.net  Fri Jun 18 08:56:32 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Fri, 18 Jun 2021 08:56:32 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v3]
In-Reply-To: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
Message-ID: <jfohRNi3z8LnjHcxEzmJNhuO7nKKEtBY5bhR-8uycVI=.b410939d-7166-4ea7-a046-c8ca8f2dcc93@github.com>

> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
> 
> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
> 
> # `Prof1`
> 
> public class Prof1 {
> 
>     public static void main(String[] args) {
>         StringBuilder sb = new StringBuilder();
>         for (int i = 0; i < 1000000; i++) {
>             sb.append("ab");
>             sb.delete(0, 1);
>         }
>         System.out.println(sb.length());
>     }
> }
> 
> 
> - Baseline:
> 
> Flat Profile (by method):
>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>         (t  0.5,s  0.2) Prof1::main
>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>         (t  0.0,s  0.0) java.lang.String::getBytes
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
> 
> - With `StubRoutinesBlob::FrameParser`:
> 
> Flat Profile (by method):
>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>         (t 99.8,s  0.2) Prof1::main
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
> 
> 
> # `Prof2`
> 
> import java.util.function.Supplier;
> 
> public class Prof2 {
> 
>     public static void main(String[] args) {
>         var rand = new java.util.Random(0);
>         Supplier[] suppliers = {
>                 () -> 0,
>                 () -> 1,
>                 () -> 2,
>                 () -> 3,
>         };
> 
>         long sum = 0;
>         for (int i = 0; i >= 0; i++) {
>             sum += (int)suppliers[i % suppliers.length].get();
>         }
>     }
> }
> 
> 
> - Baseline:
> 
> Flat Profile (by method):
>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>         (t 39.2,s 35.2) Prof2::main
>         (t  1.4,s  1.4) Prof2::lambda$main$3
>         (t  1.0,s  1.0) Prof2::lambda$main$2
>         (t  0.9,s  0.9) Prof2::lambda$main$1
>         (t  0.7,s  0.7) Prof2::lambda$main$0
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>         (t  0.0,s  0.0) java.lang.Thread::exit
>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
> 
> 
> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
> 
> Flat Profile (by method):
>         (t 74.1,s 70.3) Prof2::main
>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>         (t  1.2,s  1.2) Prof2::lambda$main$2
>         (t  0.9,s  0.9) Prof2::lambda$main$3
>         (t  0.9,s  0.9) Prof2::lambda$main$1
>         (t  0.7,s  0.7) Prof2::lambda$main$0
>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]

Ludovic Henry 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/4436/files
  - new: https://git.openjdk.java.net/jdk/pull/4436/files/85f218c8..b1d8611c

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

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

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

From iignatyev at openjdk.java.net  Fri Jun 18 10:03:33 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:03:33 GMT
Subject: [jdk17] RFR: 8268563: mark hotspot serviceability/jvmti tests
 which ignore external VM flags
In-Reply-To: <IekXJ-vx7hpk3VZcVmQMdB24iA4wN2pWjIgSTOZGZis=.4ec6debc-0d05-4d7d-9958-cce3108eab14@github.com>
References: <IekXJ-vx7hpk3VZcVmQMdB24iA4wN2pWjIgSTOZGZis=.4ec6debc-0d05-4d7d-9958-cce3108eab14@github.com>
Message-ID: <7Lk3cgM85rmQJ-goy50oC6KqHNayZh1eoeoNy2oRozA=.51dee096-988f-4bc9-b10d-b54534417917@github.com>

On Thu, 10 Jun 2021 18:19:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner that adds `@requires vm.flagless` to 6 `serviceability/jvmti` tests that ignore external VM flags?
> 
> Thanks,
> -- Igor

Serguei, thank you for your review.

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

PR: https://git.openjdk.java.net/jdk17/pull/7

From iignatyev at openjdk.java.net  Fri Jun 18 10:04:30 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:04:30 GMT
Subject: [jdk17] RFR: 8268531: mark SDTProbesGNULinuxTest as ignoring
 external VM flags
In-Reply-To: <C1aC0zk7zqFZf4jdCA-uTCeXa4qon0QrzX8Tq-CfjMM=.6948af6f-ee85-48f4-9785-f52b7ca76362@github.com>
References: <C1aC0zk7zqFZf4jdCA-uTCeXa4qon0QrzX8Tq-CfjMM=.6948af6f-ee85-48f4-9785-f52b7ca76362@github.com>
Message-ID: <KI-Nt52ZblyHr0xzCkdYjq4nWCu1gnQv5edHSb0YxV0=.72d065b7-d462-4243-98fd-8a963b6e2b41@github.com>

On Thu, 10 Jun 2021 16:46:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> (recreating openjdk/jdk#4453 against jdk17)
> 
> Hi all,
> 
> could you please review this patch that adds `@requires vm.flagless` to `SDTProbesGNULinuxTest` test as it ignores all external VM flags?
> 
> Thanks,
> -- Igor

Serguei, thank you for the review.

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

PR: https://git.openjdk.java.net/jdk17/pull/1

From iignatyev at openjdk.java.net  Fri Jun 18 10:03:32 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:03:32 GMT
Subject: [jdk17] RFR: 8268541: mark hotspot serviceability/sa tests which
 ignore external VM flags
In-Reply-To: <0JMudBx7rHdMvFb4W5XAUH2G7u8L0Cv83uyzCJXwfxA=.afb14361-1f4d-4032-852d-a570cdb1882d@github.com>
References: <0JMudBx7rHdMvFb4W5XAUH2G7u8L0Cv83uyzCJXwfxA=.afb14361-1f4d-4032-852d-a570cdb1882d@github.com>
Message-ID: <kN3eX3uT2-13lFbSkLJ7jqhXHECz8Md60kfx54wtBO4=.d10d2e7f-8b07-435c-ba19-2af349221ec0@github.com>

On Thu, 10 Jun 2021 18:08:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner that adds `@requires vm.flagless` to `serviceability/sa/TestJhsdbJstackLineNumbers.java` as it ignores external VM flags?
> 
> Thanks,
> -- Igor

thank you, Serguei.

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

PR: https://git.openjdk.java.net/jdk17/pull/6

From iignatyev at openjdk.java.net  Fri Jun 18 10:05:29 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:05:29 GMT
Subject: [jdk17] RFR: 8268564: mark hotspot serviceability/attach tests
 which ignore external VM flags
In-Reply-To: <MmjBcrBBc-QrjY6GKR8Ni_XxUv-eqt1cgfiV8JUUvdI=.04c71097-a1ad-41c6-9a70-d6387fcc61f2@github.com>
References: <MmjBcrBBc-QrjY6GKR8Ni_XxUv-eqt1cgfiV8JUUvdI=.04c71097-a1ad-41c6-9a70-d6387fcc61f2@github.com>
Message-ID: <VMOEwzYwjozsCCSLh3rSbIacjFzOWu_Y-jlYisPkXUU=.46fd7221-fcaf-4604-a0be-52645687cc1e@github.com>

On Thu, 10 Jun 2021 18:23:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner that adds `@requires vm.flagless` to 2 `serviceability/attach` tests that ignore external VM flags?
> 
> Thanks,
> -- Igor

Thank you, Serguei.

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

PR: https://git.openjdk.java.net/jdk17/pull/8

From iignatyev at openjdk.java.net  Fri Jun 18 10:06:30 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:06:30 GMT
Subject: [jdk17] Integrated: 8268563: mark hotspot serviceability/jvmti tests
 which ignore external VM flags
In-Reply-To: <IekXJ-vx7hpk3VZcVmQMdB24iA4wN2pWjIgSTOZGZis=.4ec6debc-0d05-4d7d-9958-cce3108eab14@github.com>
References: <IekXJ-vx7hpk3VZcVmQMdB24iA4wN2pWjIgSTOZGZis=.4ec6debc-0d05-4d7d-9958-cce3108eab14@github.com>
Message-ID: <bwJbcSbQzK8q91mnJW0l0UhEUMKCrl4ixwKI-wZBSNs=.40467fc8-3a7f-4e66-a1f2-ac0e1f22a1a7@github.com>

On Thu, 10 Jun 2021 18:19:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner that adds `@requires vm.flagless` to 6 `serviceability/jvmti` tests that ignore external VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 5b198986
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/5b198986cef4fa0e77d02136212ecc01ec9b22c0
Stats:     8 lines in 6 files changed: 6 ins; 0 del; 2 mod

8268563: mark hotspot serviceability/jvmti tests which ignore external VM flags

Reviewed-by: sspitsyn

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

PR: https://git.openjdk.java.net/jdk17/pull/7

From iignatyev at openjdk.java.net  Fri Jun 18 10:09:29 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:09:29 GMT
Subject: [jdk17] Integrated: 8268531: mark SDTProbesGNULinuxTest as ignoring
 external VM flags
In-Reply-To: <C1aC0zk7zqFZf4jdCA-uTCeXa4qon0QrzX8Tq-CfjMM=.6948af6f-ee85-48f4-9785-f52b7ca76362@github.com>
References: <C1aC0zk7zqFZf4jdCA-uTCeXa4qon0QrzX8Tq-CfjMM=.6948af6f-ee85-48f4-9785-f52b7ca76362@github.com>
Message-ID: <GIVHZPgluvoAZQiPcD4aR2sUx2dRMr3YJxahk5pAeRQ=.1ba531e9-0c57-4212-a50b-0a79405a96a3@github.com>

On Thu, 10 Jun 2021 16:46:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> (recreating openjdk/jdk#4453 against jdk17)
> 
> Hi all,
> 
> could you please review this patch that adds `@requires vm.flagless` to `SDTProbesGNULinuxTest` test as it ignores all external VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: f83c6b8a
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/f83c6b8a6a92a37197a3b83ba093f26e820c4ac9
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8268531: mark SDTProbesGNULinuxTest as ignoring external VM flags

Reviewed-by: sspitsyn

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

PR: https://git.openjdk.java.net/jdk17/pull/1

From iignatyev at openjdk.java.net  Fri Jun 18 10:07:30 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:07:30 GMT
Subject: [jdk17] Integrated: 8268541: mark hotspot serviceability/sa tests
 which ignore external VM flags
In-Reply-To: <0JMudBx7rHdMvFb4W5XAUH2G7u8L0Cv83uyzCJXwfxA=.afb14361-1f4d-4032-852d-a570cdb1882d@github.com>
References: <0JMudBx7rHdMvFb4W5XAUH2G7u8L0Cv83uyzCJXwfxA=.afb14361-1f4d-4032-852d-a570cdb1882d@github.com>
Message-ID: <CSHkdNgYranBLFKAAR9AO1thHd7jKU8nPivUx8dcHc4=.eda4e42b-91c0-4960-8789-d3f390ac8a76@github.com>

On Thu, 10 Jun 2021 18:08:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner that adds `@requires vm.flagless` to `serviceability/sa/TestJhsdbJstackLineNumbers.java` as it ignores external VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 8366c693
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/8366c6936eaad411082ec6a9e569da07c5f3f0cd
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8268541: mark hotspot serviceability/sa tests which ignore external VM flags

Reviewed-by: sspitsyn

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

PR: https://git.openjdk.java.net/jdk17/pull/6

From iignatyev at openjdk.java.net  Fri Jun 18 10:09:30 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 18 Jun 2021 10:09:30 GMT
Subject: [jdk17] Integrated: 8268564: mark hotspot serviceability/attach tests
 which ignore external VM flags
In-Reply-To: <MmjBcrBBc-QrjY6GKR8Ni_XxUv-eqt1cgfiV8JUUvdI=.04c71097-a1ad-41c6-9a70-d6387fcc61f2@github.com>
References: <MmjBcrBBc-QrjY6GKR8Ni_XxUv-eqt1cgfiV8JUUvdI=.04c71097-a1ad-41c6-9a70-d6387fcc61f2@github.com>
Message-ID: <_-SAK9KFoZMJhUSgFaDviXD29zKvj-S37KzK1i2r3Hg=.38539979-9126-49f2-882a-3b802987dc1a@github.com>

On Thu, 10 Jun 2021 18:23:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this one-liner that adds `@requires vm.flagless` to 2 `serviceability/attach` tests that ignore external VM flags?
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 21abcc4a
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/21abcc4a5a539644be93726436ed4454ad9aaf18
Stats:     4 lines in 2 files changed: 3 ins; 1 del; 0 mod

8268564: mark hotspot serviceability/attach tests which ignore external VM flags

Reviewed-by: sspitsyn

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

PR: https://git.openjdk.java.net/jdk17/pull/8

From ckozak at ckozak.net  Fri Jun 18 14:56:26 2021
From: ckozak at ckozak.net (Carter Kozak)
Date: Fri, 18 Jun 2021 10:56:26 -0400
Subject: Monitoring Java Safepoint Time in JDK16+
In-Reply-To: <a7a6050f-a657-3a2d-7918-79b582853829@oracle.com>
References: <3a27154f-af21-417b-999d-380fed437db8@www.fastmail.com>
 <8740f0b6-7036-a2ba-0d57-5065a8930103@oracle.com>
 <4c4be2ca-211b-be9b-79dc-20669d0f37e8@oracle.com>
 <f2fdced8-2ab3-3ee1-8e32-8d11d909491b@oracle.com>
 <cfd898c4-1bc0-4832-ba85-1fb617f6bb22@www.fastmail.com>
 <049908d0-e930-a61d-59be-8b7a7989e1f9@oracle.com>
 <05910f1a-ca46-3663-03f7-dae0add42aab@oracle.com>
 <a7a6050f-a657-3a2d-7918-79b582853829@oracle.com>
Message-ID: <dfa63b57-6c25-4ab4-88f3-0d80cee4a6e8@www.fastmail.com>

On Fri, Jun 18, 2021, at 02:47, David Holmes wrote:
> On 18/06/2021 4:35 pm, Alan Bateman wrote:
> > On 17/06/2021 22:44, David Holmes wrote:
> >>
> >> I must admit I'm a bit confused about these implementation-specific 
> >> MBeans. They are implementation-specific, so no part of the primary 
> >> java.management namespace, but they are provided so that they can be 
> >> used - so shutting them behind the modular doors (so to speak) really 
> >> doesn't make much sense to me.
> > The JDK-specific MBeans are in the com.sun.management package, exported 
> > by the jdk.management module.  The sun.management.* classes have always 
> > been JDK-internal implementation classes and were never mean to be used 
> > directly by code outside of the JDK. Directly referencing these classes 
> > would have been a warning at compile prior with JDK 8 and older. It 
> > changed an error at compile time in JDK 9.
> 
> Ah! I now see:
> 
>     /**
>       * This method is for testing only.
>       */
>      public static synchronized HotspotRuntimeMBean 
> getHotspotRuntimeMBean() {
>          if (hsRuntimeMBean == null) {
>              hsRuntimeMBean = new HotspotRuntime(jvm);
>          }
>          return hsRuntimeMBean;
>      }
> 
> in sun.management.ManagementFactoryHelper. So it seems there is no 
> actual _use_ of these platform-specific MBeans even within the JDK. So 
> their existence seems somewhat pointless.
> 
> Cheers,
> David
> 
> 
> > -Alan
> 

I think we've accurately described the problem, and why this mechanism cannot be relied upon in newer Java releases.
Do we also agree that the information it exposes is useful, and should be provided by the JVM in an accessible way?

While the current bean is implementation-specific, safepoints are a core concept required to understand java performance, much like the existing (exported) java.lang.management.GarbageCollectorMXBean information. Perhaps it would be reasonable to spec out a new java.lang.management.SafepointMXBean?

This is a relatively common use-case based on a quick github search (unfortunately it's difficult to sift out the hits across old openjdk repository copies).
https://github.com/apache/pulsar/blob/master/pulsar-common/src/main/java/org/apache/pulsar/common/stats/JvmDefaultGCMetricsLogger.java
https://github.com/CorfuDB/CorfuDB/blob/master/common/src/main/java/org/corfudb/common/metrics/micrometer/JVMMetrics.java
https://github.com/criteo/garmadon/blob/master/jvm-statistics/src/main/java/com/criteo/hadoop/garmadon/jvm/statistics/SafepointStatistics.java
https://github.com/palantir/jvm-diagnostics/blob/develop/jvm-diagnostics/src/main/java/com/palantir/jvm/diagnostics/JvmDiagnostics.java
https://github.com/prometheus/client_java/issues/576

Thanks,
Carter Kozak

From cjplummer at openjdk.java.net  Fri Jun 18 17:49:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 18 Jun 2021 17:49:42 GMT
Subject: [jdk17] RFR: 8264775: ClhsdbFindPC still fails with
 java.lang.RuntimeException: 'In java stack' missing from stdout/stderr
Message-ID: <-Xu-6Qu82BtI2RCnY7qOWUWPnoKeztiNhxM3b50V3Xw=.83a58c24-5ef6-447c-9903-8030437dfbc3@github.com>

Since a stack address can point to a hotspot object, findpc of a stack address should allow for "Is of type..." to be the result, rather than requiring it to be "In java stack". The implementation of findpc checks if the address is a hotspot object before checking if it is the stack, which seems to be what you would want.

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

Commit messages:
 - Allow findpc of a stack address to return "Is of type..."

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

PR: https://git.openjdk.java.net/jdk17/pull/101

From psandoz at openjdk.java.net  Fri Jun 18 18:23:33 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 18 Jun 2021 18:23:33 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: <urCq8J9b5y8YFa3MjVMEShSDEEl07GmF_nTyFBE2nig=.1668471c-d068-4b60-80c4-956631e36661@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <urCq8J9b5y8YFa3MjVMEShSDEEl07GmF_nTyFBE2nig=.1668471c-d068-4b60-80c4-956631e36661@github.com>
Message-ID: <ECoTAn59bB-b0bXeOQTDSyVi9vN_vYcndh2C8vvd6p8=.85b4f797-76db-4687-ac64-b2684523b616@github.com>

On Fri, 18 Jun 2021 05:54:01 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore IndexOfOufBoundsException; split exception line

@kahatlen for cases earlier in VM startup you need to avoid method references and lambda expressions. See the implementation of `outOfBoundsExceptionFormatter`, and see the usage in `VarHandle` for two examples.

Custom exception formaters should ideally be constants held in static final fields.

I think the API complexity comes down to whether it is necessary to preserve existing exception messages or not when converting existing code to use the precondition methods. The API is designed to do that and composes reasonably well for default exception messages with a non-default exceptions. We could argue (i would!) it is preferable to have a consistent exception messages for index out of bounds exceptions, thereby we could collapse and simplify, but this is sometimes considered a change in behaviour.

src/java.base/share/classes/java/util/Base64.java line 935:

> 933:                 throw new IOException("Stream is closed");
> 934:             Preconditions.checkFromIndexSize(len, off, b.length,
> 935:                 Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new));

`outOfBoundsExceptionFormatter` will allocate. Store the result of `Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new))` in a public static final on `Preconditions`, and replace the method ref with a inner class (thereby making it usable earlier at VM startup.

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

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

From dcubed at openjdk.java.net  Fri Jun 18 19:01:30 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Jun 2021 19:01:30 GMT
Subject: [jdk17] RFR: 8264775: ClhsdbFindPC still fails with
 java.lang.RuntimeException: 'In java stack' missing from stdout/stderr
In-Reply-To: <-Xu-6Qu82BtI2RCnY7qOWUWPnoKeztiNhxM3b50V3Xw=.83a58c24-5ef6-447c-9903-8030437dfbc3@github.com>
References: <-Xu-6Qu82BtI2RCnY7qOWUWPnoKeztiNhxM3b50V3Xw=.83a58c24-5ef6-447c-9903-8030437dfbc3@github.com>
Message-ID: <JIj9Haw35tM_vdwPrG-urBWnxQfWeeILANqulURmw4I=.cca13851-d853-4aec-9aff-b6b6c0b9f532@github.com>

On Fri, 18 Jun 2021 17:42:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Since a stack address can point to a hotspot object, findpc of a stack address should allow for "Is of type..." to be the result, rather than requiring it to be "In java stack". The implementation of findpc checks if the address is a hotspot object before checking if it is the stack, which seems to be what you would want.

The new expression will match the failures that happened yesterday.

Thumbs up! I think this is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/101

From daniel.daugherty at oracle.com  Fri Jun 18 19:57:21 2021
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Fri, 18 Jun 2021 15:57:21 -0400
Subject: Information about possible JDB enhancements
In-Reply-To: <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net>
References: <e3956f34-67dc-90ef-e67d-eed27f6a7ece@gmail.com>
 <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net>
Message-ID: <0ed99a75-bd7a-4d5d-e535-2b67dfc8ea4b@oracle.com>

Forwarding to serviceability-dev at ...

Dan


On 6/18/21 3:31 PM, Jakob Cornell wrote:
> Hi all,
>
> I'm hoping to become an OpenJDK contributor in order to make some 
> enhancements to JDB, which is my go-to tool for Java debugging. As an 
> example, JDB currently ignores empty commands, and I hope to make a 
> change so that entering an empty command results in the previous 
> command being rerun (as users coming from GDB will expect).? I would 
> also be interested in investigating implementation of conditional 
> breakpoints, assuming JDI supports this (I'm not familiar with it).
>
> I get the sense that these changes may not be priorities for the 
> OpenJDK development community (or perhaps may not even be desired), 
> and so I'm writing to try to get a sense of whether I'd be able to 
> find someone willing to sponsor changes like these.? If the answer is 
> no then I shouldn't bother to look into creating patches.? Can anybody 
> speak to the feasability of this?? Also, is there a more targeted 
> mailing list I should use?
>
> Thanks,
> Jakob


From amenkov at openjdk.java.net  Fri Jun 18 20:28:47 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 18 Jun 2021 20:28:47 GMT
Subject: RFR: 8268433: serviceability/dcmd/framework/VMVersionTest.java fails
 with Unable to send object throw not established PipeIO Listener Thread
 connection
Message-ID: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>

Main logic of the tests is:

TestProcessLauncher t = ...;
try {
    t.launch();
    .. perform testing ...
} finally {
   t.quit();
}

We have some problem with the tests, but the exception from TestProcessLauncher.quit() masks it.
The failures are very intermittent, so need to fix this excption to get more information about real error.

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

Commit messages:
 - IOPipe.quit should check if the pipe is connected

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

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

From cjplummer at openjdk.java.net  Fri Jun 18 20:30:36 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 18 Jun 2021 20:30:36 GMT
Subject: [jdk17] RFR: 8264775: ClhsdbFindPC still fails with
 java.lang.RuntimeException: 'In java stack' missing from stdout/stderr
In-Reply-To: <-Xu-6Qu82BtI2RCnY7qOWUWPnoKeztiNhxM3b50V3Xw=.83a58c24-5ef6-447c-9903-8030437dfbc3@github.com>
References: <-Xu-6Qu82BtI2RCnY7qOWUWPnoKeztiNhxM3b50V3Xw=.83a58c24-5ef6-447c-9903-8030437dfbc3@github.com>
Message-ID: <0q34z0sNTOHRc0iXG6OSP7wwtJnrW73nwVeuMPxkWz8=.69760728-7bef-4c50-8e8b-0b6cdc0c89d5@github.com>

On Fri, 18 Jun 2021 17:42:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Since a stack address can point to a hotspot object, findpc of a stack address should allow for "Is of type..." to be the result, rather than requiring it to be "In java stack". The implementation of findpc checks if the address is a hotspot object before checking if it is the stack, which seems to be what you would want.

Thanks Dan!

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

PR: https://git.openjdk.java.net/jdk17/pull/101

From cjplummer at openjdk.java.net  Fri Jun 18 20:30:36 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 18 Jun 2021 20:30:36 GMT
Subject: [jdk17] Integrated: 8264775: ClhsdbFindPC still fails with
 java.lang.RuntimeException: 'In java stack' missing from stdout/stderr
In-Reply-To: <-Xu-6Qu82BtI2RCnY7qOWUWPnoKeztiNhxM3b50V3Xw=.83a58c24-5ef6-447c-9903-8030437dfbc3@github.com>
References: <-Xu-6Qu82BtI2RCnY7qOWUWPnoKeztiNhxM3b50V3Xw=.83a58c24-5ef6-447c-9903-8030437dfbc3@github.com>
Message-ID: <QtVoINVPD1SC_DWFQFIk7Q3k6C0dPhxPZ3SXvrgsOyQ=.259fd821-e16a-4fb8-89e5-4bc78ea339b4@github.com>

On Fri, 18 Jun 2021 17:42:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Since a stack address can point to a hotspot object, findpc of a stack address should allow for "Is of type..." to be the result, rather than requiring it to be "In java stack". The implementation of findpc checks if the address is a hotspot object before checking if it is the stack, which seems to be what you would want.

This pull request has now been integrated.

Changeset: 8caeca00
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/8caeca003e621dd523eb27ef7e7fea0765ceacb6
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8264775: ClhsdbFindPC still fails with java.lang.RuntimeException: 'In java stack' missing from stdout/stderr

Reviewed-by: dcubed

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

PR: https://git.openjdk.java.net/jdk17/pull/101

From chris.plummer at oracle.com  Fri Jun 18 20:49:44 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 18 Jun 2021 13:49:44 -0700
Subject: Information about possible JDB enhancements
In-Reply-To: <0ed99a75-bd7a-4d5d-e535-2b67dfc8ea4b@oracle.com>
References: <e3956f34-67dc-90ef-e67d-eed27f6a7ece@gmail.com>
 <230063e5-25b8-b14e-c61d-ed74b85d6e06@jcornell.net>
 <0ed99a75-bd7a-4d5d-e535-2b67dfc8ea4b@oracle.com>
Message-ID: <f30c39f0-3454-d98d-6472-d9e8b2bd678e@oracle.com>

Hi Jakob,

You are correct in assuming that in general jdb is low priority. We 
mostly rely on it for testing jdi (there are quite a few jdb tests we 
maintain mainly for this purpose), and also for doing some targeted 
experimenting that might not be quite as easy to do with a full IDE. We 
do welcome bug fixes and enhancements, but we need to weigh their cost 
w.r.t. the time it takes to understand and review the changes, and also 
consider the risk of breaking something. I don't see an issue with a 
simple change like your empty command handling suggestion as being a 
problem. However, conditional breakpoints seems like a stretch. It's not 
a JDI feature, so will likely take quite a bit of work to support in 
jdb. I don't see this as something we'd want to spend time on, but 
others might disagree. Certainly it's open to discussion.

BTW, it looks like conditional expressions were at one point a 
consideration for JDWP (and therefore could have been leveraged by JDI). 
If you look in the EventRequest.set in the JDWP spec:

https://docs.oracle.com/javase/10/docs/specs/jdwp/jdwp-protocol.html#JDWP_EventRequest_Set

You'll find that modkind 2 is the filter for "Conditional on 
expression". However, the argument type is exprID, which is not defined 
anywhere, and the spec just says "For the future". The debug agent 
actually accepts the filter and saves it along with the exprID, but when 
it comes time to apply filters, it just ignores it:

 ??????????? case JDWP_REQUEST_MODIFIER(Conditional):
/***
 ??????????????? if (...? filter->u.Conditional.exprID ...) {
 ??????????????????? return JNI_FALSE;
 ??????????????? }
***/
 ??????????????? break;


thanks,

Chris

On 6/18/21 12:57 PM, daniel.daugherty at oracle.com wrote:
> Forwarding to serviceability-dev at ...
>
> Dan
>
>
> On 6/18/21 3:31 PM, Jakob Cornell wrote:
>> Hi all,
>>
>> I'm hoping to become an OpenJDK contributor in order to make some 
>> enhancements to JDB, which is my go-to tool for Java debugging. As an 
>> example, JDB currently ignores empty commands, and I hope to make a 
>> change so that entering an empty command results in the previous 
>> command being rerun (as users coming from GDB will expect).? I would 
>> also be interested in investigating implementation of conditional 
>> breakpoints, assuming JDI supports this (I'm not familiar with it).
>>
>> I get the sense that these changes may not be priorities for the 
>> OpenJDK development community (or perhaps may not even be desired), 
>> and so I'm writing to try to get a sense of whether I'd be able to 
>> find someone willing to sponsor changes like these.? If the answer is 
>> no then I shouldn't bother to look into creating patches.? Can 
>> anybody speak to the feasability of this?? Also, is there a more 
>> targeted mailing list I should use?
>>
>> Thanks,
>> Jakob
>



From jwilhelm at openjdk.java.net  Fri Jun 18 22:26:34 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 22:26:34 GMT
Subject: RFR: Merge jdk17
Message-ID: <HNBw5ZohOBE8HmVj0a1kOYJyIUASdOFm6botE6KjJms=.f3b04f59-148a-409a-8c63-e9fc6bf17e76@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8268316: Typo in JFR jdk.Deserialization event
 - 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
 - 8264775: ClhsdbFindPC still fails with java.lang.RuntimeException: 'In java stack' missing from stdout/stderr
 - 8265073: XML transformation and indentation when using xml:space
 - 8269025: jsig/Testjsig.java doesn't check exit code
 - 8266518: Refactor and expand scatter/gather tests
 - 8268903: JFR: RecordingStream::dump is missing @since
 - 8265369: [macos-aarch64] java/net/MulticastSocket/Promiscuous.java failed with "SocketException: Cannot allocate memory"
 - 8268564: mark hotspot serviceability/attach tests which ignore external VM flags
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/8f2456e5...ed622f4b

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4533/files
  Stats: 12229 lines in 119 files changed: 6768 ins; 5337 del; 124 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4533.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4533/head:pull/4533

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

From duke at openjdk.java.net  Fri Jun 18 22:46:38 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 18 Jun 2021 22:46:38 GMT
Subject: Withdrawn: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes
In-Reply-To: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
References: <xR4nXrmL9ePkpnu7hQAGKnumx3Sj6etkEggopu59sgw=.49c280c5-54e6-4b79-a546-2330d65db63b@github.com>
Message-ID: <yqx3mDAwWdg3UJmUetf75TQPohIIi5voVeZbl02c-2c=.0ed0c605-02c7-479d-b527-0877828bde17@github.com>

On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.

This pull request has been closed without being integrated.

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

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

From amenkov at openjdk.java.net  Fri Jun 18 23:06:05 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 18 Jun 2021 23:06:05 GMT
Subject: RFR: 8236212: CompiledMethodLoad and CompiledMethodUnload events can
 be posted in START phase
Message-ID: <vwjM2u7Fg5ieFljLYRusBLiTKkpNSAJBVE3vqEg6Qhs=.9fa0cd3d-21c2-4fc6-aa3d-c9c82a53973b@github.com>

Accordingly the spec CompiledMethodLoad/CompiledMethodUnload events may be sent in the start and live phases.
VM implementation send them only in the live phase, but tests should expect them in the start phase too

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

Commit messages:
 - Updated tests to allow CompiledMethodLoad/Unload event to be sent in start phase

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

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

From jwilhelm at openjdk.java.net  Fri Jun 18 23:08:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 23:08:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <HNBw5ZohOBE8HmVj0a1kOYJyIUASdOFm6botE6KjJms=.f3b04f59-148a-409a-8c63-e9fc6bf17e76@github.com>
References: <HNBw5ZohOBE8HmVj0a1kOYJyIUASdOFm6botE6KjJms=.f3b04f59-148a-409a-8c63-e9fc6bf17e76@github.com>
Message-ID: <sfBb2JNQud0H7xd1dVAyRkfvvCelWmST6lOie1oilvc=.f33a435c-cca2-4d5a-a584-15288d4b2537@github.com>

> Forwardport JDK 17 -> JDK 18

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

 - Merge
 - 8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header
   
   Co-authored-by: Chris Cole <chris at sageembedded.com>
   Reviewed-by: dsamersoff
 - 8268964: Remove unused ReferenceProcessorAtomicMutator
   
   Reviewed-by: tschatzl, pliden
 - 8268900: com/sun/net/httpserver/Headers.java: Fix indentation and whitespace
   
   Reviewed-by: dfuchs, chegar, michaelm
 - Merge
 - 8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired
   
   Reviewed-by: xuelei
 - 8267189: Remove duplicated unregistered classes from dynamic archive
   
   Reviewed-by: ccheung, minqi
 - 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
   
   Reviewed-by: dholmes, phh
 - 8268556: Use bitmap for storing regions that failed evacuation
   
   Reviewed-by: kbarrett, iwalulya, sjohanss
 - 8268294: Reusing HttpClient in a WebSocket.Listener hangs.
   
   Reviewed-by: dfuchs
 - ... and 36 more: https://git.openjdk.java.net/jdk/compare/b8f073be...ed622f4b

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

Changes: https://git.openjdk.java.net/jdk/pull/4533/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4533&range=01
  Stats: 8681 lines in 159 files changed: 7992 ins; 386 del; 303 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4533.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4533/head:pull/4533

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

From jwilhelm at openjdk.java.net  Fri Jun 18 23:08:36 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 23:08:36 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <HNBw5ZohOBE8HmVj0a1kOYJyIUASdOFm6botE6KjJms=.f3b04f59-148a-409a-8c63-e9fc6bf17e76@github.com>
References: <HNBw5ZohOBE8HmVj0a1kOYJyIUASdOFm6botE6KjJms=.f3b04f59-148a-409a-8c63-e9fc6bf17e76@github.com>
Message-ID: <2lNbBvRChZKSawaU5THoDLfbazhJcqIyt1V_Ew-3kNY=.f7fb1cfd-ecda-4fd3-874d-311a6d8362b9@github.com>

On Fri, 18 Jun 2021 22:17:41 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: b7d78a5b
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b7d78a5b661e2b00f271298db3b6cc873cf754e7
Stats:     12229 lines in 119 files changed: 6768 ins; 5337 del; 124 mod

Merge

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

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

From yyang at openjdk.java.net  Mon Jun 21 03:25:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 03:25:00 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v3]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <LCM4zvAZHFnslmYNn5aBl2nXygcjkxyX5Iu6_V63ysk=.2bc99187-fecd-4c0e-9233-b471eb8f829e@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

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

  new Preconditions.IOOBE_FORMATTER

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/ec0a4d44..c1dd2f76

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

  Stats: 129 lines in 13 files changed: 43 ins; 40 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

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

From yyang at openjdk.java.net  Mon Jun 21 03:25:04 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 03:25:04 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: <ECoTAn59bB-b0bXeOQTDSyVi9vN_vYcndh2C8vvd6p8=.85b4f797-76db-4687-ac64-b2684523b616@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <urCq8J9b5y8YFa3MjVMEShSDEEl07GmF_nTyFBE2nig=.1668471c-d068-4b60-80c4-956631e36661@github.com>
 <ECoTAn59bB-b0bXeOQTDSyVi9vN_vYcndh2C8vvd6p8=.85b4f797-76db-4687-ac64-b2684523b616@github.com>
Message-ID: <wpp54vkFbTewLMmNQC74XrGtbAePWMi4kE7jXWGLJ6E=.33f83012-2e99-472f-a152-ad62b026b9b5@github.com>

On Fri, 18 Jun 2021 18:03:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore IndexOfOufBoundsException; split exception line
>
> src/java.base/share/classes/java/util/Base64.java line 935:
> 
>> 933:                 throw new IOException("Stream is closed");
>> 934:             Preconditions.checkFromIndexSize(len, off, b.length,
>> 935:                 Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new));
> 
> `outOfBoundsExceptionFormatter` will allocate. Store the result of `Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new))` in a public static final on `Preconditions`, and replace the method ref with a inner class (thereby making it usable earlier at VM startup.

Thanks for the clarification! Fixed.

This incremental change does many stuff:
- Create inner classes and public static final fields within Preconditions
- Use Preconditions.check* in j.l.String
- Use Preconditions.*IOOBE_FORMATTER in java.util.zip.* classes
- Use Preconditions.*IOOBE_FORMATTER in java.util.Base64
- Use Preconditions.*IOOBE_FORMATTER in X-VarHandle.java.template and X-VarHandleByteArrayView.java.template
- Use Preconditions.*IOOBE_FORMATTER in sun.security.provider.DigestBase
- Use Preconditions.*IOOBE_FORMATTER in sun.security.util.ArrayUtil

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

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

From yyang at openjdk.java.net  Mon Jun 21 04:17:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 04:17:00 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v4]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <XJ2hGOA6iO1yvKyI88LtZ2ATbvwEClnTuHdz-V2ZjOY=.17a5e6bb-1b92-451b-894c-620efad3ee66@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

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

  format

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/c1dd2f76..154989a0

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

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

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

From yyang at openjdk.java.net  Mon Jun 21 04:46:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 04:46:00 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v5]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <LXIzK8MQvBiQno2abwX5NJfoxAhAt_2pOtf0x1mAveE=.f8815e4e-156f-43d7-8833-62cef60fedb7@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

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

  more replacements

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/154989a0..c8b2106e

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

  Stats: 59 lines in 8 files changed: 11 ins; 37 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

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

From yyang at openjdk.java.net  Mon Jun 21 05:17:09 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 05:17:09 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <ep_6o8H_fydBJ-oPSWLUve7j-1oiExUbotgjUkys1nM=.7b32370d-cba4-4d32-9520-2e9b59f06982@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

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

  more replacement 2

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/c8b2106e..3a8875ec

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

  Stats: 32 lines in 2 files changed: 1 ins; 20 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

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

From david.holmes at oracle.com  Mon Jun 21 06:21:43 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Jun 2021 16:21:43 +1000
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap
In-Reply-To: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
Message-ID: <550e9971-7b9d-f480-b5d5-792ff91f8fbe@oracle.com>

Hi Thomas,

On 17/06/2021 4:41 pm, Thomas Stuefe wrote:
> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
> 
> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
> 
> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
> 
> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
> 
> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
> - as a stop gap measure it allows to release pressure from a high footprint scenario.
> 
> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
> 
> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.

Is it perhaps worthwhile trying to generalize this to a jcmd to request 
an attempt to release system resources and then each platform can do 
whatever may be available to assist in that - including doing nothing, 
or in this case trimming the glibc heap ?

Thanks,
David
-----

> If this finds agreement, I will file a CSR.
> 
> =========
> 
> This patch:
> 
> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
> - includes a (rather basic) test
> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
> 
> =========
> 
> Example:
> 
> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
> 
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>                     ^^^^^^^^
> 
> 
> We execute the new trim command via jcmd:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
> 18770:
> Attempting trim...
> Done.
> Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
> Swap before: 0k, after: 0k, (0k)
> 
> 
> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>                     ^^^^^^^
> 
> 
> When the VM is started with -Xlog:os, this is also logged:
> 
> 
> [139,068s][info][os] malloc_trim:
> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)
> Swap before: 0k, after: 0k, (0k)
> 
> -------------
> 
> Commit messages:
>   - start
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4510/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8268893
>    Stats: 237 lines in 6 files changed: 212 ins; 7 del; 18 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4510.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4510/head:pull/4510
> 
> PR: https://git.openjdk.java.net/jdk/pull/4510
> 

From stuefe at openjdk.java.net  Mon Jun 21 07:10:26 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 21 Jun 2021 07:10:26 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
Message-ID: <3w036PFQz_qIY9WLpwc-vfeAx3kTclEKVpaRboas75M=.bab4028c-d836-4561-9877-e4acdad5cdda@github.com>

On Thu, 17 Jun 2021 08:53:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Severin; renamed query function

Hi David,

thanks for looking into this!

> Is it perhaps worthwhile trying to generalize this to a jcmd to request
> an attempt to release system resources and then each platform can do
> whatever may be available to assist in that - including doing nothing,
> or in this case trimming the glibc heap ?
> 

I thought about this too. It would certainly make the jcmd look nicer. 

But I think that this would be one of the cases where the supporter needs to know the details of what the command does under the hood, so by hiding the complexity behind the platform nothing is gained; you need to know what happens to gauge the influence it has on the system (eg performance loss by dropping caches) and to analyze the precise after-effects. I

I am undecided on this. I will ask around offline.

..Thomas

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

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

From simonis at openjdk.java.net  Mon Jun 21 09:18:31 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 21 Jun 2021 09:18:31 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
Message-ID: <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>

On Thu, 17 Jun 2021 08:53:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Severin; renamed query function

I like this little new diagnostic command which I think can be quite useful in specific situations.

However, in contrast to other reviewers, I'd rather keep this simple and Glibc specific instead of extending it to a more general but mostly empty command.

I'd therefore propose to rename this command to `glibc_trim_heap` to make it evident from the command name already that it is Glibc-specific.

Besides that, just cosmetic changes and suggestions.

src/hotspot/os/linux/os_linux.cpp line 2142:

> 2140: bool os::Linux::query_process_memory_info(os::Linux::meminfo_t* info) {
> 2141:   FILE* f = ::fopen("/proc/self/status", "r");
> 2142:   const int num_values = 8;

Refactoring of `os::Linux::print_process_memory_info` looks good. But now that you've already created `os::Linux::meminfo_t` anyway I'd suggest to make `num_values == sizeof(os::Linux::meminfo_t)/sizeof(ssize_t)`.

src/hotspot/os/linux/trimCHeapDCmd.cpp line 43:

> 41:   os::Linux::meminfo_t info2;
> 42:   bool have_info1 = os::Linux::query_process_memory_info(&info1);
> 43: 

os::Linux::meminfo_t info1;
  os::Linux::meminfo_t info2;
  // Query memory before...
  bool have_info1 = os::Linux::query_process_memory_info(&info1);

Looks better to me :)

src/hotspot/os/linux/trimCHeapDCmd.cpp line 64:

> 62:       ss_report.print_cr("Swap before: " SSIZE_FORMAT "k, after: " SSIZE_FORMAT "k, (" SSIZE_FORMAT "k)",
> 63:                          info1.vmswap, info2.vmswap, (info2.vmswap - info1.vmswap));
> 64:     }

In the unusual case that `(have_info1 && have_info2)==true` but there was still nothing printed (i.e. `info1.vmsize == -1 || info2.vmsize == -1` etc.), you should still print out `"No details available."`.

src/hotspot/share/services/diagnosticCommand.cpp line 99:

> 97:   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<HeapInfoDCmd>(full_export, true, false));
> 98:   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<FinalizerInfoDCmd>(full_export, true, false));
> 99:   LINUX_ONLY(DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<TrimCLibcHeapDCmd>(full_export, true, false));)

Not sure if the commands are really sorted and if order is important here. Otherwise you could add the new command a few lines later where there already exists an `#ifdef LINUX` section:


#ifdef LINUX
  DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<PerfMapDCmd>(full_export, true, false));
  DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<TrimCLibcHeapDCmd>(full_export, true, false));
#endif // LINUX

test/hotspot/jtreg/serviceability/dcmd/vm/TrimLibcHeapTest.java line 46:

> 44:         output.reportDiagnosticSummary();
> 45:         output.shouldMatch("(Done|Not available)");
> 46:     }

Maybe also add something like:

if (output.firstMatch("Done") != null) {
  output.shouldMatch("(Virtual size before|RSS before|Swap before|No details available)");
}

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

Changes requested by simonis (Reviewer).

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

From stuefe at openjdk.java.net  Mon Jun 21 09:58:32 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 21 Jun 2021 09:58:32 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
 <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>
Message-ID: <fz_W7O0zXVWJkJMyhR0sUP8WO8wAdybXtbazf5fMUF8=.26e70614-9961-4679-a02c-0e68b2f39617@github.com>

On Mon, 21 Jun 2021 09:15:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> I like this little new diagnostic command which I think can be quite useful in specific situations.
> 

Thanks a lot Volker!

> However, in contrast to other reviewers, I'd rather keep this simple and Glibc specific instead of extending it to a more general but mostly empty command.

Yes, that was my thought too. Lets wait for @dholmes-ora to chime in, whether we can all agree on a glibc specific variant. I also preferred that one. 

> 
> I'd therefore propose to rename this command to `glibc_trim_heap` to make it evident from the command name already that it is Glibc-specific.
> 
> Besides that, just cosmetic changes and suggestions.

All of which make sense, I'll work them in.

Thanks!

..Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/4510

From david.holmes at oracle.com  Mon Jun 21 12:11:41 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Jun 2021 22:11:41 +1000
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <fz_W7O0zXVWJkJMyhR0sUP8WO8wAdybXtbazf5fMUF8=.26e70614-9961-4679-a02c-0e68b2f39617@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
 <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>
 <fz_W7O0zXVWJkJMyhR0sUP8WO8wAdybXtbazf5fMUF8=.26e70614-9961-4679-a02c-0e68b2f39617@github.com>
Message-ID: <e3c82bde-9daf-8440-59f0-6d5c96cb4fcf@oracle.com>

On 21/06/2021 7:58 pm, Thomas Stuefe wrote:
> On Mon, 21 Jun 2021 09:15:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:
> 
>> I like this little new diagnostic command which I think can be quite useful in specific situations.
>>
> 
> Thanks a lot Volker!
> 
>> However, in contrast to other reviewers, I'd rather keep this simple and Glibc specific instead of extending it to a more general but mostly empty command.
> 
> Yes, that was my thought too. Lets wait for @dholmes-ora to chime in, whether we can all agree on a glibc specific variant. I also preferred that one.

I don't totally oppose the specialised variant, but it certainly isn't 
my ideal solution. Not sure if we already have platform specific dcmds? 
This will need a CSR request anyway.

Cheers,
David

>>
>> I'd therefore propose to rename this command to `glibc_trim_heap` to make it evident from the command name already that it is Glibc-specific.
>>
>> Besides that, just cosmetic changes and suggestions.
> 
> All of which make sense, I'll work them in.
> 
> Thanks!
> 
> ..Thomas
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4510
> 

From stuefe at openjdk.java.net  Mon Jun 21 12:29:30 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 21 Jun 2021 12:29:30 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
Message-ID: <5VXQj2nuY6vuYZ7SE1DT2_-ZbcFYI7XKr_I_LcwyFnc=.34ce0ea1-53bc-413b-beb4-1344fd22a0c1@github.com>

On Thu, 17 Jun 2021 08:53:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Severin; renamed query function

> _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 21/06/2021 7:58 pm, Thomas Stuefe wrote:
> 
> > On Mon, 21 Jun 2021 09:15:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:
> > > I like this little new diagnostic command which I think can be quite useful in specific situations.
> > 
> > 
> > Thanks a lot Volker!
> > > However, in contrast to other reviewers, I'd rather keep this simple and Glibc specific instead of extending it to a more general but mostly empty command.
> > 
> > 
> > Yes, that was my thought too. Lets wait for @dholmes-ora to chime in, whether we can all agree on a glibc specific variant. I also preferred that one.
> 
> I don't totally oppose the specialised variant, but it certainly isn't
> my ideal solution. Not sure if we already have platform specific dcmds?
> This will need a CSR request anyway.
> 
> Cheers,
> David

I'll prepare the CSR and bring it to review.

Cheers, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From coleenp at openjdk.java.net  Mon Jun 21 13:03:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 21 Jun 2021 13:03:32 GMT
Subject: RFR: 8264941: Remove CodeCache::mark_for_evol_deoptimization()
 method
In-Reply-To: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
References: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
Message-ID: <OHn1txktoPkOLKvMswmlwRo5oeg4EvtCqFZeJGF13o8=.5b0d8d83-a8df-416d-9a4b-8ea00dedc222@github.com>

On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the mark_for_evol_deoptimization method and removes the flag that all dependencies are recorded.  Before the change to walk the entire nmethod looking for "old" (redefined) methods with metadata_do(), we used to find methods in the code cache to deoptimize based on evol_method dependencies.  If the dependencies weren't yet recorded, we had to deoptimize all of the methods.  A long time ago, we had a customer who was unhappy with the pause for this when they had late attach.  Now we don't have this problem.
> The evol_method dependencies are still used by the compiler to check for old methods during compilation.  I didn't change this but it might be something someone who knows the compiler better can do differently and remove these dependencies too.
> Tested with tier1-6.

Thank you both Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4509

From coleenp at openjdk.java.net  Mon Jun 21 15:16:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 21 Jun 2021 15:16:41 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be 'jint'
Message-ID: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>

I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

-------------

Commit messages:
 - 8256306: ObjectMonitor::_contentions field should not be 'jint'

Changes: https://git.openjdk.java.net/jdk/pull/3980/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3980&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256306
  Stats: 27 lines in 5 files changed: 1 ins; 0 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3980.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3980/head:pull/3980

PR: https://git.openjdk.java.net/jdk/pull/3980

From simonis at openjdk.java.net  Mon Jun 21 15:27:32 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 21 Jun 2021 15:27:32 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <5VXQj2nuY6vuYZ7SE1DT2_-ZbcFYI7XKr_I_LcwyFnc=.34ce0ea1-53bc-413b-beb4-1344fd22a0c1@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
 <5VXQj2nuY6vuYZ7SE1DT2_-ZbcFYI7XKr_I_LcwyFnc=.34ce0ea1-53bc-413b-beb4-1344fd22a0c1@github.com>
Message-ID: <6EK1VCEXEziiI-GfZocHjcO1uAUDnEsLF11rAky6o74=.dfbe3e0e-f544-4073-b81b-df908c0b121d@github.com>

On Mon, 21 Jun 2021 12:26:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> _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 21/06/2021 7:58 pm, Thomas Stuefe wrote:
> 
> > On Mon, 21 Jun 2021 09:15:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:
> > > I like this little new diagnostic command which I think can be quite useful in specific situations.
> > 
> > 
> > Thanks a lot Volker!
> > > However, in contrast to other reviewers, I'd rather keep this simple and Glibc specific instead of extending it to a more general but mostly empty command.
> > 
> > 
> > Yes, that was my thought too. Lets wait for @dholmes-ora to chime in, whether we can all agree on a glibc specific variant. I also preferred that one.
> 
> I don't totally oppose the specialised variant, but it certainly isn't
> my ideal solution. Not sure if we already have platform specific dcmds?

Yes, we have. E.g.:

#ifdef LINUX
class PerfMapDCmd : public DCmd {
public:
  PerfMapDCmd(outputStream* output, bool heap) : DCmd(output, heap) {}
  static const char* name() {
    return "Compiler.perfmap";
  }
  static const char* description() {
    return "Write map file for Linux perf tool.";
  }
...


> This will need a CSR request anyway.
> 
> Cheers,
> David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From sspitsyn at openjdk.java.net  Mon Jun 21 18:54:34 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 21 Jun 2021 18:54:34 GMT
Subject: RFR: 8264941: Remove CodeCache::mark_for_evol_deoptimization()
 method
In-Reply-To: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
References: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
Message-ID: <AekpA3aCndo-EGMKkgU9Yk517drCBYWLeYfkwgAUtjg=.99ebba51-d498-4ea6-97e3-0ee9d284eae0@github.com>

On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the mark_for_evol_deoptimization method and removes the flag that all dependencies are recorded.  Before the change to walk the entire nmethod looking for "old" (redefined) methods with metadata_do(), we used to find methods in the code cache to deoptimize based on evol_method dependencies.  If the dependencies weren't yet recorded, we had to deoptimize all of the methods.  A long time ago, we had a customer who was unhappy with the pause for this when they had late attach.  Now we don't have this problem.
> The evol_method dependencies are still used by the compiler to check for old methods during compilation.  I didn't change this but it might be something someone who knows the compiler better can do differently and remove these dependencies too.
> Tested with tier1-6.

Marked as reviewed by sspitsyn (Reviewer).

Hi Coleen,
LGTM.
Thanks,
Serguei

-------------

PR: https://git.openjdk.java.net/jdk/pull/4509Marked as reviewed by sspitsyn (Reviewer).

From psandoz at openjdk.java.net  Mon Jun 21 21:02:30 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 21 Jun 2021 21:02:30 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: <ep_6o8H_fydBJ-oPSWLUve7j-1oiExUbotgjUkys1nM=.7b32370d-cba4-4d32-9520-2e9b59f06982@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <ep_6o8H_fydBJ-oPSWLUve7j-1oiExUbotgjUkys1nM=.7b32370d-cba4-4d32-9520-2e9b59f06982@github.com>
Message-ID: <yUvE83550X7kQ8lwiCiXUlBe6dAvezHwWzrzsLZqUY4=.375c18e1-cb63-42cf-8462-12189b237b61@github.com>

On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more replacement 2

All the updates to the check* methods look ok (requires some careful looking!).

I cannot recall what others said about the change in exception messages. @jddarcy any advice here?

src/java.base/share/classes/jdk/internal/util/Preconditions.java line 78:

> 76:             = Preconditions.outOfBoundsExceptionFormatter(new StringIndexOutOfBoundsExceptionProducer());
> 77: 
> 78:     public static final BiFunction<String, List<Number>, StringIndexOutOfBoundsException> AIOOBE_FORMATTER

Using incorrect exception type. Suggest you embed as inner class rather than separate declaration, since they are only used in one place.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From dholmes at openjdk.java.net  Tue Jun 22 00:02:37 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Jun 2021 00:02:37 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
Message-ID: <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>

On Tue, 11 May 2021 15:01:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

Looks fine apart from use of INT32_MIN instead of INT_MIN.

Thanks,
David

src/hotspot/share/runtime/objectMonitor.cpp line 548:

> 546:     set_owner_from(NULL, DEFLATER_MARKER);
> 547:     assert(contentions() >= 0, "must be non-negative: contentions=%d", contentions());
> 548:     _contentions = INT32_MIN; // minimum negative int

INT_MIN (unless you want to change the type to int32_t)

src/hotspot/share/runtime/objectMonitor.cpp line 575:

> 573:     // Make a zero contentions field negative to force any contending threads
> 574:     // to retry. This is the second part of the async deflation dance.
> 575:     if (Atomic::cmpxchg(&_contentions, (int)0, INT32_MIN) != 0) {

INT_MIN

Do we really need the cast on 0?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3980

From gli at openjdk.java.net  Tue Jun 22 01:22:46 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Jun 2021 01:22:46 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions
Message-ID: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>

Hi all,

Considering the consistency of `JavaThread` and other threads, such as WorkerThread and CompilerThread, `JavaThread` could use a method named `cast` to replace the method `Thread::as_Java_thread()`. It can reduce the Thread's knowledge about the subtypes.

This patch removes two methods, `JavaThread* Thread::as_Java_thread()` and `const JavaThread* Thread::as_Java_thread() const`, of the class `Thread` and adds two static methods, `JavaThread* cast(Thread* t)` and `const JavaThread* cast(const Thread* t)`, to the class `JavaThread`. Correspondingly, the code of the method `JavaThread::current()` need to be adjusted and many places where the method `Thread::as_Java_thread()` is used need to use `JavaThread::cast` instead.

Test:
tier1 passed locally.

Thanks for taking the time to review.

Best Regards,
-- Guoxiong

-------------

Commit messages:
 - 8268368: Adopt cast notation for JavaThread conversions

Changes: https://git.openjdk.java.net/jdk/pull/4546/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4546&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268368
  Stats: 159 lines in 64 files changed: 13 ins; 19 del; 127 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4546.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4546/head:pull/4546

PR: https://git.openjdk.java.net/jdk/pull/4546

From dholmes at openjdk.java.net  Tue Jun 22 02:02:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Jun 2021 02:02:28 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions
In-Reply-To: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
Message-ID: <3jEWcoPqG9EMr-wmTMV66lnEqEZBbwR45E5gmwZhbOk=.0cbbc64d-07ac-4667-9037-b136c279188c@github.com>

On Tue, 22 Jun 2021 01:11:30 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Considering the consistency of `JavaThread` and other threads, such as WorkerThread and CompilerThread, `JavaThread` could use a method named `cast` to replace the method `Thread::as_Java_thread()`. It can reduce the Thread's knowledge about the subtypes.
> 
> This patch removes two methods, `JavaThread* Thread::as_Java_thread()` and `const JavaThread* Thread::as_Java_thread() const`, of the class `Thread` and adds two static methods, `JavaThread* cast(Thread* t)` and `const JavaThread* cast(const Thread* t)`, to the class `JavaThread`. Correspondingly, the code of the method `JavaThread::current()` need to be adjusted and many places where the method `Thread::as_Java_thread()` is used need to use `JavaThread::cast` instead.
> 
> Test:
> tier1 passed locally.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Hi Guoxiong,

Thanks for picking up this enhancement request.

I wasn't sure if this would be worth the churn/disruption to the source code, but I think it is ok and preferable to use the cast notation.

The changes look good except for one mistake flagged below.

Note you need at least two reviewers before integrating this.

Thanks,
David

src/hotspot/share/gc/z/zFuture.inline.hpp line 49:

> 47:   // Wait for notification
> 48:   Thread* const thread = Thread::current();
> 49:   if (JavaThread::cast(thread)) {

This is wrong - we still need the is_Java_thread() query; and cast is not a boolean operator.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4546

From yyang at openjdk.java.net  Tue Jun 22 02:39:01 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 22 Jun 2021 02:39:01 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v7]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <AhUPDb2Ol-_bVIwBnESmNgtC0l8bnh5bPJK3d5CAchI=.839562bb-2c25-4ad2-9c7d-8035bd627728@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  correct exception type; use anonymous inner classes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/3a8875ec..2330ee38

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=05-06

  Stats: 21 lines in 1 file changed: 0 ins; 9 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Tue Jun 22 02:39:04 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 22 Jun 2021 02:39:04 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: <yUvE83550X7kQ8lwiCiXUlBe6dAvezHwWzrzsLZqUY4=.375c18e1-cb63-42cf-8462-12189b237b61@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <ep_6o8H_fydBJ-oPSWLUve7j-1oiExUbotgjUkys1nM=.7b32370d-cba4-4d32-9520-2e9b59f06982@github.com>
 <yUvE83550X7kQ8lwiCiXUlBe6dAvezHwWzrzsLZqUY4=.375c18e1-cb63-42cf-8462-12189b237b61@github.com>
Message-ID: <JCvHGPJBJYT8-9gOl8lqF13iIy1A58Exk9WzvFHI_xg=.9a40b258-93e4-4626-9420-742ebe935b4f@github.com>

On Mon, 21 Jun 2021 20:49:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more replacement 2
>
> src/java.base/share/classes/jdk/internal/util/Preconditions.java line 78:
> 
>> 76:             = Preconditions.outOfBoundsExceptionFormatter(new StringIndexOutOfBoundsExceptionProducer());
>> 77: 
>> 78:     public static final BiFunction<String, List<Number>, StringIndexOutOfBoundsException> AIOOBE_FORMATTER
> 
> Using incorrect exception type. Suggest you embed as inner class rather than separate declaration, since they are only used in one place.

Fixed.

FYI: Current exception message looks like this:

Exception in thread "main" java.lang.StringIndexOutOfBoundsException: Range [3, 1) out of bounds for length 6
	at CheckIndex$StringIndexOutOfBoundsExceptionProducer.apply(CheckIndex.java:77)
	at CheckIndex$StringIndexOutOfBoundsExceptionProducer.apply(CheckIndex.java:72)
	at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:159)
	at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:156)
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:62)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Preconditions.java:76)
	at java.base/jdk.internal.util.Preconditions.checkFromToIndex(Preconditions.java:295)
	at CheckIndex.main(CheckIndex.java:110)

I think now it expresses more exception information than before(and more consistent).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Tue Jun 22 03:01:35 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 22 Jun 2021 03:01:35 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v7]
In-Reply-To: <AhUPDb2Ol-_bVIwBnESmNgtC0l8bnh5bPJK3d5CAchI=.839562bb-2c25-4ad2-9c7d-8035bd627728@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <AhUPDb2Ol-_bVIwBnESmNgtC0l8bnh5bPJK3d5CAchI=.839562bb-2c25-4ad2-9c7d-8035bd627728@github.com>
Message-ID: <8yRvKCvVqdLlGk-r_rwdTrdqHGYArdV1gaZwVj48TQY=.60035c0c-06b2-4f5f-99f9-029a3317f1b0@github.com>

On Tue, 22 Jun 2021 02:39:01 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct exception type; use anonymous inner classes

I found that after solving the problem that Preconditions cannot be used during the VM startup, a series of functions such as String.checkIndex/checkOffset/.. can also be harmlessly replaced, but this changeset is somewhat large and may overwrite the previous review progress. If it will confuse the current review progress for reviewers involving in this PR, I'd like to file a new PR to do this change later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From stuefe at openjdk.java.net  Tue Jun 22 04:16:32 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 22 Jun 2021 04:16:32 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
Message-ID: <zOXHOnYTbK_2ZUHoW8j1TYqTR_0d2sxW9SX--Qjtp9Y=.a26d9a8d-07c4-4336-a2b2-87b538be379d@github.com>

On Tue, 11 May 2021 15:01:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

LGTM

src/hotspot/share/runtime/objectMonitor.hpp line 244:

> 242:     int cnts = contentions(); // read once
> 243:     if (cnts > 0) {
> 244:       ret_code |= intptr_t(cnts);

I know it has nothing to do with your patch, but I am just curious. IIUC this is a strange way of saying "if A!=0 || B!=0 || C!=0..." . Is this for performance reasons? Also, why the "if (cnts > 0)", would that not be superfluous?

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3980

From gli at openjdk.java.net  Tue Jun 22 07:17:00 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Jun 2021 07:17:00 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v2]
In-Reply-To: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
Message-ID: <7Q4mj03cn9mF86H_Cr44sWib8Za6dZyindyQUaVAl40=.c2422fbd-4ba8-46e3-818a-c3139d930d0f@github.com>

> Hi all,
> 
> Considering the consistency of `JavaThread` and other threads, such as WorkerThread and CompilerThread, `JavaThread` could use a method named `cast` to replace the method `Thread::as_Java_thread()`. It can reduce the Thread's knowledge about the subtypes.
> 
> This patch removes two methods, `JavaThread* Thread::as_Java_thread()` and `const JavaThread* Thread::as_Java_thread() const`, of the class `Thread` and adds two static methods, `JavaThread* cast(Thread* t)` and `const JavaThread* cast(const Thread* t)`, to the class `JavaThread`. Correspondingly, the code of the method `JavaThread::current()` need to be adjusted and many places where the method `Thread::as_Java_thread()` is used need to use `JavaThread::cast` instead.
> 
> Test:
> tier1 passed locally.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Fix incorrect use of the method cast

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4546/files
  - new: https://git.openjdk.java.net/jdk/pull/4546/files/3c9f6dbe..259730be

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4546&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4546&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4546.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4546/head:pull/4546

PR: https://git.openjdk.java.net/jdk/pull/4546

From gli at openjdk.java.net  Tue Jun 22 07:24:29 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Jun 2021 07:24:29 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v2]
In-Reply-To: <3jEWcoPqG9EMr-wmTMV66lnEqEZBbwR45E5gmwZhbOk=.0cbbc64d-07ac-4667-9037-b136c279188c@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
 <3jEWcoPqG9EMr-wmTMV66lnEqEZBbwR45E5gmwZhbOk=.0cbbc64d-07ac-4667-9037-b136c279188c@github.com>
Message-ID: <W-nzPs3PvhuZHqZa0oQMB-L52yOGqV6NpQXEO9IATjo=.66bc6d8d-5c9b-45ac-a7f8-e651d634fc2f@github.com>

On Tue, 22 Jun 2021 01:59:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect use of the method cast
>
> Hi Guoxiong,
> 
> Thanks for picking up this enhancement request.
> 
> I wasn't sure if this would be worth the churn/disruption to the source code, but I think it is ok and preferable to use the cast notation.
> 
> The changes look good except for one mistake flagged below.
> 
> Note you need at least two reviewers before integrating this.
> 
> Thanks,
> David

@dholmes-ora Thanks for your review. I updated the code just now.

I am surprised that the `tier1` (locally and the `Pre-submit tests`) can't find the mistake you pointed out.
Maybe we can improve the `tier1` or the `Pre-submit tests` in the future.

> src/hotspot/share/gc/z/zFuture.inline.hpp line 49:
> 
>> 47:   // Wait for notification
>> 48:   Thread* const thread = Thread::current();
>> 49:   if (JavaThread::cast(thread)) {
> 
> This is wrong - we still need the is_Java_thread() query; and cast is not a boolean operator.

Fixed. It's a wrong use of the method `cast`. Thanks for finding it. I re-read my patch to avoid the similar mistake.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4546

From simonis at openjdk.java.net  Tue Jun 22 07:39:29 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 22 Jun 2021 07:39:29 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
Message-ID: <MIfqqo5mQ9wHPGoM7-wFoV2hNe6sRy66ez1kdZKKqW8=.c443757d-eb32-427a-b72d-5dd2079c1429@github.com>

On Thu, 17 Jun 2021 08:53:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Severin; renamed query function

src/hotspot/os/linux/trimCHeapDCmd.cpp line 70:

> 68:   _output->print_raw(ss_report.base());
> 69:   log_info(os)("malloc_trim: ");
> 70:   log_info(os)("%s", ss_report.base());

Might also make sense to put this into a single log line like `log_info(os)("malloc_trim:\n%s", ss_report.base());` to get something like:

[139,068s][info][os] malloc_trim:
Virtual size before: 28849744k, after: 28849724k, (-20k)
RSS before: 8685896k, after: 920740k, (-7765156k)
Swap before: 0k, after: 0k, (0k)

instead of:

[139,068s][info][os] malloc_trim:
[139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
RSS before: 8685896k, after: 920740k, (-7765156k)
Swap before: 0k, after: 0k, (0k)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From ddong at openjdk.java.net  Tue Jun 22 08:31:31 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 22 Jun 2021 08:31:31 GMT
Subject: Integrated: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle
In-Reply-To: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
Message-ID: <bQBWTWtje17X_t_Ou4sC7Dr-xVu0GUrsRyyFwJL-Zbk=.def46a68-fb1e-4834-8d6a-5da356dde986@github.com>

On Wed, 16 Jun 2021 03:33:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
> 
> `jstack` is a very common command, even in the production environment.
> 
> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.

This pull request has now been integrated.

Changeset: 1f0ea7c3
Author:    Denghui Dong <ddong at openjdk.org>
Committer: Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1f0ea7c3d62221405de982ba484c0ee985fa9d7b
Stats:     51 lines in 8 files changed: 5 ins; 33 del; 13 mod

8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From sspitsyn at openjdk.java.net  Tue Jun 22 10:13:26 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 22 Jun 2021 10:13:26 GMT
Subject: RFR: 8268433: serviceability/dcmd/framework/VMVersionTest.java
 fails with Unable to send object throw not established PipeIO Listener Thread
 connection
In-Reply-To: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
References: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
Message-ID: <JfpYb8ec-F0Nk6q7pdXkOKFJR3KNKZsupNrPX1eGzfo=.e41e19ef-71f1-4239-807a-f05c029dd3c4@github.com>

On Fri, 18 Jun 2021 20:20:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Main logic of the tests is:
> 
> TestProcessLauncher t = ...;
> try {
>     t.launch();
>     .. perform testing ...
> } finally {
>    t.quit();
> }
> 
> We have some problem with the tests, but the exception from TestProcessLauncher.quit() masks it.
> The failures are very intermittent, so need to fix this excption to get more information about real error.

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4532

From gli at openjdk.java.net  Tue Jun 22 10:13:27 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Jun 2021 10:13:27 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v2]
In-Reply-To: <W-nzPs3PvhuZHqZa0oQMB-L52yOGqV6NpQXEO9IATjo=.66bc6d8d-5c9b-45ac-a7f8-e651d634fc2f@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
 <3jEWcoPqG9EMr-wmTMV66lnEqEZBbwR45E5gmwZhbOk=.0cbbc64d-07ac-4667-9037-b136c279188c@github.com>
 <W-nzPs3PvhuZHqZa0oQMB-L52yOGqV6NpQXEO9IATjo=.66bc6d8d-5c9b-45ac-a7f8-e651d634fc2f@github.com>
Message-ID: <d436cGcsnnyT-cVRNPieSkNBH93B5i73I-EqKp9SCjc=.bd6426e0-c38d-42b6-a52c-4897258fa73f@github.com>

On Tue, 22 Jun 2021 07:21:29 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Maybe we can improve the tier1 or the Pre-submit tests in the future.

I meant to improve the test coverage.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4546

From stefank at openjdk.java.net  Tue Jun 22 10:24:31 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 22 Jun 2021 10:24:31 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v2]
In-Reply-To: <7Q4mj03cn9mF86H_Cr44sWib8Za6dZyindyQUaVAl40=.c2422fbd-4ba8-46e3-818a-c3139d930d0f@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
 <7Q4mj03cn9mF86H_Cr44sWib8Za6dZyindyQUaVAl40=.c2422fbd-4ba8-46e3-818a-c3139d930d0f@github.com>
Message-ID: <bZeQpiuAL8rQ9f4GD98yYcbB3KTuI2y3nKBlwVfZb90=.049d0a5e-ca98-40ce-bcd6-b25b1c5f5300@github.com>

On Tue, 22 Jun 2021 07:17:00 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> Considering the consistency of `JavaThread` and other threads, such as WorkerThread and CompilerThread, `JavaThread` could use a method named `cast` to replace the method `Thread::as_Java_thread()`. It can reduce the Thread's knowledge about the subtypes.
>> 
>> This patch removes two methods, `JavaThread* Thread::as_Java_thread()` and `const JavaThread* Thread::as_Java_thread() const`, of the class `Thread` and adds two static methods, `JavaThread* cast(Thread* t)` and `const JavaThread* cast(const Thread* t)`, to the class `JavaThread`. Correspondingly, the code of the method `JavaThread::current()` need to be adjusted and many places where the method `Thread::as_Java_thread()` is used need to use `JavaThread::cast` instead.
>> 
>> Test:
>> tier1 passed locally.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix incorrect use of the method cast

Marked as reviewed by stefank (Reviewer).

src/hotspot/share/runtime/thread.hpp line 1432:

> 1430:     assert(t->is_Java_thread(), "incorrect cast to const JavaThread");
> 1431:     return static_cast<const JavaThread*>(t);
> 1432:   }

Now that you've written the code in-place, you could  remove the `inline` specifier.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4546

From sspitsyn at openjdk.java.net  Tue Jun 22 10:43:25 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 22 Jun 2021 10:43:25 GMT
Subject: RFR: 8236212: CompiledMethodLoad and CompiledMethodUnload events
 can be posted in START phase
In-Reply-To: <vwjM2u7Fg5ieFljLYRusBLiTKkpNSAJBVE3vqEg6Qhs=.9fa0cd3d-21c2-4fc6-aa3d-c9c82a53973b@github.com>
References: <vwjM2u7Fg5ieFljLYRusBLiTKkpNSAJBVE3vqEg6Qhs=.9fa0cd3d-21c2-4fc6-aa3d-c9c82a53973b@github.com>
Message-ID: <g9jty0simBCcEEh726ZM58cEqD819wShkpb0hZ62668=.be88fdc2-b4f6-45ac-a05a-699f0180e8a7@github.com>

On Fri, 18 Jun 2021 22:57:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Accordingly the spec CompiledMethodLoad/CompiledMethodUnload events may be sent in the start and live phases.
> VM implementation send them only in the live phase, but tests should expect them in the start phase too

Hi Alex,
This looks good to me.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4535

From gli at openjdk.java.net  Tue Jun 22 10:53:06 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Jun 2021 10:53:06 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v3]
In-Reply-To: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
Message-ID: <6cHOFbz1wh819kKFRB-yKKniSrwGL-oNF4iiJqZrh1s=.0974ec65-e8ee-4609-b999-c44acadb58cb@github.com>

> Hi all,
> 
> Considering the consistency of `JavaThread` and other threads, such as WorkerThread and CompilerThread, `JavaThread` could use a method named `cast` to replace the method `Thread::as_Java_thread()`. It can reduce the Thread's knowledge about the subtypes.
> 
> This patch removes two methods, `JavaThread* Thread::as_Java_thread()` and `const JavaThread* Thread::as_Java_thread() const`, of the class `Thread` and adds two static methods, `JavaThread* cast(Thread* t)` and `const JavaThread* cast(const Thread* t)`, to the class `JavaThread`. Correspondingly, the code of the method `JavaThread::current()` need to be adjusted and many places where the method `Thread::as_Java_thread()` is used need to use `JavaThread::cast` instead.
> 
> Test:
> tier1 passed locally.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Remove inline specifier

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4546/files
  - new: https://git.openjdk.java.net/jdk/pull/4546/files/259730be..c0347b6c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4546&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4546&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4546.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4546/head:pull/4546

PR: https://git.openjdk.java.net/jdk/pull/4546

From gli at openjdk.java.net  Tue Jun 22 10:56:25 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Jun 2021 10:56:25 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v2]
In-Reply-To: <bZeQpiuAL8rQ9f4GD98yYcbB3KTuI2y3nKBlwVfZb90=.049d0a5e-ca98-40ce-bcd6-b25b1c5f5300@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
 <7Q4mj03cn9mF86H_Cr44sWib8Za6dZyindyQUaVAl40=.c2422fbd-4ba8-46e3-818a-c3139d930d0f@github.com>
 <bZeQpiuAL8rQ9f4GD98yYcbB3KTuI2y3nKBlwVfZb90=.049d0a5e-ca98-40ce-bcd6-b25b1c5f5300@github.com>
Message-ID: <qjqv2MmKu-RQ_tVcwU4wIVkCZZwYpKBNTC4BYO7BugQ=.115b38ac-407a-4c68-9769-63311c879902@github.com>

On Tue, 22 Jun 2021 10:21:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect use of the method cast
>
> src/hotspot/share/runtime/thread.hpp line 1432:
> 
>> 1430:     assert(t->is_Java_thread(), "incorrect cast to const JavaThread");
>> 1431:     return static_cast<const JavaThread*>(t);
>> 1432:   }
> 
> Now that you've written the code in-place, you could  remove the `inline` specifier.

Fixed. Thanks @stefank for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4546

From david.holmes at oracle.com  Tue Jun 22 11:20:43 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Jun 2021 21:20:43 +1000
Subject: Integrated: 8268857: Merge VM_PrintJNI and VM_PrintThreads and
 remove the unused field 'is_deadlock' of DeadlockCycle
In-Reply-To: <bQBWTWtje17X_t_Ou4sC7Dr-xVu0GUrsRyyFwJL-Zbk=.def46a68-fb1e-4834-8d6a-5da356dde986@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <bQBWTWtje17X_t_Ou4sC7Dr-xVu0GUrsRyyFwJL-Zbk=.def46a68-fb1e-4834-8d6a-5da356dde986@github.com>
Message-ID: <12a4cc5e-aa57-ab73-37a3-c0fcc656d9d0@oracle.com>

Hi,

Please note that hotspot changes require two reviews before integrating 
(unless a trivial change).

David


On 22/06/2021 6:31 pm, Denghui Dong wrote:
> On Wed, 16 Jun 2021 03:33:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:
> 
>> Hi,
>>
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>>
>> `jstack` is a very common command, even in the production environment.
>>
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
> 
> This pull request has now been integrated.
> 
> Changeset: 1f0ea7c3
> Author:    Denghui Dong <ddong at openjdk.org>
> Committer: Yi Yang <yyang at openjdk.org>
> URL:       https://git.openjdk.java.net/jdk/commit/1f0ea7c3d62221405de982ba484c0ee985fa9d7b
> Stats:     51 lines in 8 files changed: 5 ins; 33 del; 13 mod
> 
> 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle
> 
> Reviewed-by: dholmes
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4504
> 

From david.holmes at oracle.com  Tue Jun 22 11:33:57 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Jun 2021 21:33:57 +1000
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v2]
In-Reply-To: <W-nzPs3PvhuZHqZa0oQMB-L52yOGqV6NpQXEO9IATjo=.66bc6d8d-5c9b-45ac-a7f8-e651d634fc2f@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
 <3jEWcoPqG9EMr-wmTMV66lnEqEZBbwR45E5gmwZhbOk=.0cbbc64d-07ac-4667-9037-b136c279188c@github.com>
 <W-nzPs3PvhuZHqZa0oQMB-L52yOGqV6NpQXEO9IATjo=.66bc6d8d-5c9b-45ac-a7f8-e651d634fc2f@github.com>
Message-ID: <77ae4ca8-47eb-12b2-96e4-743adb0d3987@oracle.com>

On 22/06/2021 5:24 pm, Guoxiong Li wrote:
> On Tue, 22 Jun 2021 01:59:17 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Fix incorrect use of the method cast
>>
>> Hi Guoxiong,
>>
>> Thanks for picking up this enhancement request.
>>
>> I wasn't sure if this would be worth the churn/disruption to the source code, but I think it is ok and preferable to use the cast notation.
>>
>> The changes look good except for one mistake flagged below.
>>
>> Note you need at least two reviewers before integrating this.
>>
>> Thanks,
>> David
> 
> @dholmes-ora Thanks for your review. I updated the code just now.
> 
> I am surprised that the `tier1` (locally and the `Pre-submit tests`) can't find the mistake you pointed out.
> Maybe we can improve the `tier1` or the `Pre-submit tests` in the future.

The error is in ZGC code and ZGC is not tested in tier-1 or pre-submit.

Cheers,
David

>> src/hotspot/share/gc/z/zFuture.inline.hpp line 49:
>>
>>> 47:   // Wait for notification
>>> 48:   Thread* const thread = Thread::current();
>>> 49:   if (JavaThread::cast(thread)) {
>>
>> This is wrong - we still need the is_Java_thread() query; and cast is not a boolean operator.
> 
> Fixed. It's a wrong use of the method `cast`. Thanks for finding it. I re-read my patch to avoid the similar mistake.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4546
> 

From dholmes at openjdk.java.net  Tue Jun 22 11:37:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Jun 2021 11:37:28 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v3]
In-Reply-To: <6cHOFbz1wh819kKFRB-yKKniSrwGL-oNF4iiJqZrh1s=.0974ec65-e8ee-4609-b999-c44acadb58cb@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
 <6cHOFbz1wh819kKFRB-yKKniSrwGL-oNF4iiJqZrh1s=.0974ec65-e8ee-4609-b999-c44acadb58cb@github.com>
Message-ID: <LeZwgoIE5g581pUjKV-aUViWTmQukBdtwfhMLNEm9SQ=.44849ea6-1eb6-4a4b-9d2e-ac9f88221d40@github.com>

On Tue, 22 Jun 2021 10:53:06 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> Considering the consistency of `JavaThread` and other threads, such as WorkerThread and CompilerThread, `JavaThread` could use a method named `cast` to replace the method `Thread::as_Java_thread()`. It can reduce the Thread's knowledge about the subtypes.
>> 
>> This patch removes two methods, `JavaThread* Thread::as_Java_thread()` and `const JavaThread* Thread::as_Java_thread() const`, of the class `Thread` and adds two static methods, `JavaThread* cast(Thread* t)` and `const JavaThread* cast(const Thread* t)`, to the class `JavaThread`. Correspondingly, the code of the method `JavaThread::current()` need to be adjusted and many places where the method `Thread::as_Java_thread()` is used need to use `JavaThread::cast` instead.
>> 
>> Test:
>> tier1 passed locally.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove inline specifier

Updates look fine.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4546

From ddong at openjdk.java.net  Tue Jun 22 11:45:31 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 22 Jun 2021 11:45:31 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v7]
In-Reply-To: <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
Message-ID: <S9NEFwpHrHzzOep8i-7hvzxJuVh5d9Pxgk62KAIgOI4=.d048f552-6450-443b-9148-347ad7efdf8a@github.com>

On Fri, 18 Jun 2021 06:51:53 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [serviceability-dev](mailto:serviceability-dev at mail.openjdk.java.net):_
> 
> Hi,
> 
> Please note that hotspot changes require two reviews before integrating
> (unless a trivial change).
> 
> David
> 
> On 22/06/2021 6:31 pm, Denghui Dong wrote:

Sorry about this,  I will be more aware next time.

Denghui.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From gli at openjdk.java.net  Tue Jun 22 12:10:30 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Jun 2021 12:10:30 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v3]
In-Reply-To: <LeZwgoIE5g581pUjKV-aUViWTmQukBdtwfhMLNEm9SQ=.44849ea6-1eb6-4a4b-9d2e-ac9f88221d40@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
 <6cHOFbz1wh819kKFRB-yKKniSrwGL-oNF4iiJqZrh1s=.0974ec65-e8ee-4609-b999-c44acadb58cb@github.com>
 <LeZwgoIE5g581pUjKV-aUViWTmQukBdtwfhMLNEm9SQ=.44849ea6-1eb6-4a4b-9d2e-ac9f88221d40@github.com>
Message-ID: <nf1EnCCg8HkxDHSMFx5m26FjP4V4m0uIUo3G1EbQgCs=.1b9edda7-a3cb-4ad4-a4eb-c795dd2cf515@github.com>

On Tue, 22 Jun 2021 11:34:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove inline specifier
>
> Updates look fine.
> 
> Thanks,
> David

@dholmes-ora @stefank Thanks for your reviews. Could I get your help to sponsor this patch?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4546

From gli at openjdk.java.net  Tue Jun 22 12:10:30 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Jun 2021 12:10:30 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions
In-Reply-To: <77ae4ca8-47eb-12b2-96e4-743adb0d3987@oracle.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
 <77ae4ca8-47eb-12b2-96e4-743adb0d3987@oracle.com>
Message-ID: <Howj32VFsWF-OsCGRmTumotjsqoKv3ZFwKgCFvc4zLE=.75dc4216-1c16-43a9-b0d7-050b2f405722@github.com>

On Tue, 22 Jun 2021 11:36:02 GMT, David Holmes <david.holmes at oracle.com> wrote:

> The error is in ZGC code and ZGC is not tested in tier-1 or pre-submit.

Got it. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4546

From dholmes at openjdk.java.net  Tue Jun 22 12:59:35 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Jun 2021 12:59:35 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v3]
In-Reply-To: <6cHOFbz1wh819kKFRB-yKKniSrwGL-oNF4iiJqZrh1s=.0974ec65-e8ee-4609-b999-c44acadb58cb@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
 <6cHOFbz1wh819kKFRB-yKKniSrwGL-oNF4iiJqZrh1s=.0974ec65-e8ee-4609-b999-c44acadb58cb@github.com>
Message-ID: <JdMLc7YwF4pdq6Y-eccSQ3f8qSR1mQk-kpB2b_SIqj4=.857d1350-074b-4a84-9242-67b634f14d53@github.com>

On Tue, 22 Jun 2021 10:53:06 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> Considering the consistency of `JavaThread` and other threads, such as WorkerThread and CompilerThread, `JavaThread` could use a method named `cast` to replace the method `Thread::as_Java_thread()`. It can reduce the Thread's knowledge about the subtypes.
>> 
>> This patch removes two methods, `JavaThread* Thread::as_Java_thread()` and `const JavaThread* Thread::as_Java_thread() const`, of the class `Thread` and adds two static methods, `JavaThread* cast(Thread* t)` and `const JavaThread* cast(const Thread* t)`, to the class `JavaThread`. Correspondingly, the code of the method `JavaThread::current()` need to be adjusted and many places where the method `Thread::as_Java_thread()` is used need to use `JavaThread::cast` instead.
>> 
>> Test:
>> tier1 passed locally.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove inline specifier

I can sponsor, but as per hotspot integration guidelines we should wait at least 24 hours to give people in different timezones a chance to comment.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4546

From gli at openjdk.java.net  Tue Jun 22 13:03:32 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Jun 2021 13:03:32 GMT
Subject: RFR: 8268368: Adopt cast notation for JavaThread conversions [v3]
In-Reply-To: <JdMLc7YwF4pdq6Y-eccSQ3f8qSR1mQk-kpB2b_SIqj4=.857d1350-074b-4a84-9242-67b634f14d53@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
 <6cHOFbz1wh819kKFRB-yKKniSrwGL-oNF4iiJqZrh1s=.0974ec65-e8ee-4609-b999-c44acadb58cb@github.com>
 <JdMLc7YwF4pdq6Y-eccSQ3f8qSR1mQk-kpB2b_SIqj4=.857d1350-074b-4a84-9242-67b634f14d53@github.com>
Message-ID: <VG9IWP7bq0Ms_CeTPhlE6471KjZH1eUgkc0A1Z4Iy-Q=.daacd74c-f42b-4bf9-aa71-58ac9f1a6edd@github.com>

On Tue, 22 Jun 2021 12:56:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I can sponsor, but as per hotspot integration guidelines we should wait at least 24 hours to give people in different timezones a chance to comment.

Got it. Thanks a lot!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4546

From dcubed at openjdk.java.net  Tue Jun 22 14:07:35 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 22 Jun 2021 14:07:35 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v7]
In-Reply-To: <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
Message-ID: <nUB1_-2wnpJWo3mEbgRSewonyTyuI0SA3GlSLpAOcIY=.93613c5a-895d-4a15-9c1c-8191cb903e87@github.com>

On Fri, 18 Jun 2021 06:51:53 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

This PR should also have waiting for a review from the Serviceability team.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From coleenp at openjdk.java.net  Tue Jun 22 14:56:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 14:56:32 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <zOXHOnYTbK_2ZUHoW8j1TYqTR_0d2sxW9SX--Qjtp9Y=.a26d9a8d-07c4-4336-a2b2-87b538be379d@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <zOXHOnYTbK_2ZUHoW8j1TYqTR_0d2sxW9SX--Qjtp9Y=.a26d9a8d-07c4-4336-a2b2-87b538be379d@github.com>
Message-ID: <VzFCZDPtNTlDYXmbzL0f5EL1is8wUp7KCMSw2W3pKcw=.2cc12d3e-dcc0-4417-b82a-800828a56174@github.com>

On Tue, 22 Jun 2021 04:09:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> src/hotspot/share/runtime/objectMonitor.hpp line 244:
> 
>> 242:     int cnts = contentions(); // read once
>> 243:     if (cnts > 0) {
>> 244:       ret_code |= intptr_t(cnts);
> 
> I know it has nothing to do with your patch, but I am just curious. IIUC this is a strange way of saying "if A!=0 || B!=0 || C!=0..." . Is this for performance reasons? Also, why the "if (cnts > 0)", would that not be superfluous?

I think this code exists like this from when is_busy returned an uintptr_t.  It should be nicely rewritten with if != 0s now and likely would have better performance.  I won't do it with this change because these fields are volatile and I think should have Atomic::loads, which would lead to a lot of discussion that should happen independently.  I'll file an RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From dcubed at openjdk.java.net  Tue Jun 22 15:50:32 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 22 Jun 2021 15:50:32 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
Message-ID: <p8tU9Nge_Qtgxwi-SjDFcXOoQgwT7jBPSgsDdauGvnM=.90e5bc2e-9c0e-4e78-9074-b0701982f7b9@github.com>

On Tue, 11 May 2021 15:01:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

Changes requested by dcubed (Reviewer).

src/hotspot/share/runtime/objectMonitor.hpp line 151:

> 149:   #define DEFLATER_MARKER reinterpret_cast<void*>(-1)
> 150:   void* volatile _owner;            // pointer to owning thread OR BasicLock
> 151:   volatile uintptr_t _previous_owner_tid;  // thread id of the previous owner of the monitor

Since you are changing the type for `_previous_owner_tid`, you also
need to change the `DEFINE_PAD_MINUS_SIZE` below:


  DEFINE_PAD_MINUS_SIZE(1, OM_CACHE_LINE_SIZE, sizeof(void* volatile) +
                        sizeof(volatile uintptr_t));

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From dcubed at openjdk.java.net  Tue Jun 22 15:50:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 22 Jun 2021 15:50:34 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>
Message-ID: <4UYewAilWk6FSZCLNoXOnrRrxrT_6wJoLKB4P1xHn9M=.637c7157-9dd5-4e24-8c3d-95c890471c67@github.com>

On Mon, 21 Jun 2021 23:56:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 575:
> 
>> 573:     // Make a zero contentions field negative to force any contending threads
>> 574:     // to retry. This is the second part of the async deflation dance.
>> 575:     if (Atomic::cmpxchg(&_contentions, (int)0, INT32_MIN) != 0) {
> 
> INT_MIN
> 
> Do we really need the cast on 0?

The original cast of `(jint)0` was to get the right `cmpxchg()` selected.
I _think_ that with the switch to INT32_MIN, a regular `0` instead of `(int)0`
should compile.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From coleenp at openjdk.java.net  Tue Jun 22 16:00:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 16:00:33 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>
Message-ID: <6EHUis07nR1ZMpj3PrWeuE4HVX_4g6TNjdMtqGwm7vw=.53576f80-f0df-41d9-8102-5466652f6f99@github.com>

On Mon, 21 Jun 2021 23:55:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 548:
> 
>> 546:     set_owner_from(NULL, DEFLATER_MARKER);
>> 547:     assert(contentions() >= 0, "must be non-negative: contentions=%d", contentions());
>> 548:     _contentions = INT32_MIN; // minimum negative int
> 
> INT_MIN (unless you want to change the type to int32_t)

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From coleenp at openjdk.java.net  Tue Jun 22 16:00:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 16:00:33 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <4UYewAilWk6FSZCLNoXOnrRrxrT_6wJoLKB4P1xHn9M=.637c7157-9dd5-4e24-8c3d-95c890471c67@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <MUl_73tF1GTMp2sFWZ9SaTj5VS1Dt338FHN8Aq4U8sI=.f9a08fea-e660-441d-8440-d0d74cf91778@github.com>
 <4UYewAilWk6FSZCLNoXOnrRrxrT_6wJoLKB4P1xHn9M=.637c7157-9dd5-4e24-8c3d-95c890471c67@github.com>
Message-ID: <Wy8PgeGaureaDmKkg6As1besz18mEKQMYt5XArHL1UU=.f027be5f-b0cd-42b9-b011-03ec9e2c88f6@github.com>

On Tue, 22 Jun 2021 15:43:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 575:
>> 
>>> 573:     // Make a zero contentions field negative to force any contending threads
>>> 574:     // to retry. This is the second part of the async deflation dance.
>>> 575:     if (Atomic::cmpxchg(&_contentions, (int)0, INT32_MIN) != 0) {
>> 
>> INT_MIN
>> 
>> Do we really need the cast on 0?
>
> The original cast of `(jint)0` was to get the right `cmpxchg()` selected.
> I _think_ that with the switch to INT32_MIN, a regular `0` instead of `(int)0`
> should compile.

Yes, changing to INT_MIN is more correct and I don't need the cast to int now for zero.  Recompiling on all platforms, including the picky ones for verification.  Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From coleenp at openjdk.java.net  Tue Jun 22 16:00:34 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 16:00:34 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <p8tU9Nge_Qtgxwi-SjDFcXOoQgwT7jBPSgsDdauGvnM=.90e5bc2e-9c0e-4e78-9074-b0701982f7b9@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <p8tU9Nge_Qtgxwi-SjDFcXOoQgwT7jBPSgsDdauGvnM=.90e5bc2e-9c0e-4e78-9074-b0701982f7b9@github.com>
Message-ID: <t5naKSkUBGPqWs3fKhVcdNHkjHj4AzmpDGZgM6_2BSM=.8df057cd-bec4-49da-a60c-c1fa484c9f04@github.com>

On Tue, 22 Jun 2021 15:45:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> src/hotspot/share/runtime/objectMonitor.hpp line 151:
> 
>> 149:   #define DEFLATER_MARKER reinterpret_cast<void*>(-1)
>> 150:   void* volatile _owner;            // pointer to owning thread OR BasicLock
>> 151:   volatile uintptr_t _previous_owner_tid;  // thread id of the previous owner of the monitor
> 
> Since you are changing the type for `_previous_owner_tid`, you also
> need to change the `DEFINE_PAD_MINUS_SIZE` below:
> 
> 
>   DEFINE_PAD_MINUS_SIZE(1, OM_CACHE_LINE_SIZE, sizeof(void* volatile) +
>                         sizeof(volatile uintptr_t));

Okay, yes, thank you for pointing this out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From coleenp at openjdk.java.net  Tue Jun 22 16:12:34 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 16:12:34 GMT
Subject: Integrated: 8264941: Remove CodeCache::mark_for_evol_deoptimization()
 method
In-Reply-To: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
References: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
Message-ID: <bDMuOO7SjhZt43P44FBOhz1yQFi8M1y4benESY5IbSk=.7f9f7635-68b7-4514-92c1-6ee596337fc6@github.com>

On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the mark_for_evol_deoptimization method and removes the flag that all dependencies are recorded.  Before the change to walk the entire nmethod looking for "old" (redefined) methods with metadata_do(), we used to find methods in the code cache to deoptimize based on evol_method dependencies.  If the dependencies weren't yet recorded, we had to deoptimize all of the methods.  A long time ago, we had a customer who was unhappy with the pause for this when they had late attach.  Now we don't have this problem.
> The evol_method dependencies are still used by the compiler to check for old methods during compilation.  I didn't change this but it might be something someone who knows the compiler better can do differently and remove these dependencies too.
> Tested with tier1-6.

This pull request has now been integrated.

Changeset: 33c23a1c
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/33c23a1cf2aa81551eee4a2acf271edf573558aa
Stats:     78 lines in 7 files changed: 0 ins; 73 del; 5 mod

8264941: Remove CodeCache::mark_for_evol_deoptimization() method

Reviewed-by: kvn, vlivanov, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4509

From coleenp at openjdk.java.net  Tue Jun 22 16:12:34 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 16:12:34 GMT
Subject: RFR: 8264941: Remove CodeCache::mark_for_evol_deoptimization()
 method
In-Reply-To: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
References: <r73HPnW2mdFqO95bBy3-SWZ4o7Vso-eHH0lDjiOaHxI=.b6ee712f-c326-43f6-923e-3e332e8bbe73@github.com>
Message-ID: <qJgMrXTHOqvvGnn4WGECBSp12UEkavk8WPQQIVTZHf0=.58bc3ab3-3725-4fa4-9982-3b7ba0bc93f4@github.com>

On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the mark_for_evol_deoptimization method and removes the flag that all dependencies are recorded.  Before the change to walk the entire nmethod looking for "old" (redefined) methods with metadata_do(), we used to find methods in the code cache to deoptimize based on evol_method dependencies.  If the dependencies weren't yet recorded, we had to deoptimize all of the methods.  A long time ago, we had a customer who was unhappy with the pause for this when they had late attach.  Now we don't have this problem.
> The evol_method dependencies are still used by the compiler to check for old methods during compilation.  I didn't change this but it might be something someone who knows the compiler better can do differently and remove these dependencies too.
> Tested with tier1-6.

Thanks Serguei.  Thanks for the code reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4509

From psandoz at openjdk.java.net  Tue Jun 22 17:57:27 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 22 Jun 2021 17:57:27 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v7]
In-Reply-To: <8yRvKCvVqdLlGk-r_rwdTrdqHGYArdV1gaZwVj48TQY=.60035c0c-06b2-4f5f-99f9-029a3317f1b0@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <AhUPDb2Ol-_bVIwBnESmNgtC0l8bnh5bPJK3d5CAchI=.839562bb-2c25-4ad2-9c7d-8035bd627728@github.com>
 <8yRvKCvVqdLlGk-r_rwdTrdqHGYArdV1gaZwVj48TQY=.60035c0c-06b2-4f5f-99f9-029a3317f1b0@github.com>
Message-ID: <KAoAj28AyBWJ8kPjvzVgLCz5oxBvkwLHpNTpqUbQlp4=.9d569c91-04c4-48dd-bcbd-22815dee79e9@github.com>

On Tue, 22 Jun 2021 02:58:28 GMT, Yi Yang <yyang at openjdk.org> wrote:

> I found that after solving the problem that Preconditions cannot be used during the VM startup, a series of functions such as String.checkIndex/checkOffset/.. can also be harmlessly replaced, but this changeset is somewhat large and may overwrite the previous review progress. If it will confuse the current review progress for reviewers involving in this PR, I'd like to file a new PR to do this change later.

Yes, I think that helps to review. It's often easier, review-wise, to have separate PRs for specific areas, rather than keep expanding an existing PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From coleenp at openjdk.java.net  Tue Jun 22 21:07:04 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 22 Jun 2021 21:07:04 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint' [v2]
In-Reply-To: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
Message-ID: <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>

> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix INT32_MIN and cache padding.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3980/files
  - new: https://git.openjdk.java.net/jdk/pull/3980/files/7c287908..07138653

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3980&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3980&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3980.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3980/head:pull/3980

PR: https://git.openjdk.java.net/jdk/pull/3980

From amenkov at openjdk.java.net  Tue Jun 22 21:09:55 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 22 Jun 2021 21:09:55 GMT
Subject: RFR: 8260540: serviceability/jdwp/AllModulesCommandTest.java failed
 with "Debuggee error: 'ERROR: transport error 202: bind failed: Address
 already in use'"
Message-ID: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>

Updated AllModulesCommandTest to use dynamic port launching debuggee.
Parsing debuggee listening address functionality is required in several tests (and we have other tests which need to be fixed the same way), so moved the code to new class in jdk.test.lib

-------------

Commit messages:
 - JDK-8260540

Changes: https://git.openjdk.java.net/jdk/pull/4560/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4560&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260540
  Stats: 121 lines in 7 files changed: 62 ins; 33 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4560/head:pull/4560

PR: https://git.openjdk.java.net/jdk/pull/4560

From dcubed at openjdk.java.net  Tue Jun 22 21:25:26 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 22 Jun 2021 21:25:26 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint' [v2]
In-Reply-To: <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
Message-ID: <skhQvqNE-MotIH7raAjFRvlxAOtfiqobJLAuZRaICdE=.dca17f44-4231-45d9-86f1-ee14ea9ae5cc@github.com>

On Tue, 22 Jun 2021 21:07:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix INT32_MIN and cache padding.

Re-reviewed v01 incremental. Thumbs up!

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3980

From dholmes at openjdk.java.net  Tue Jun 22 23:53:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Jun 2021 23:53:27 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint' [v2]
In-Reply-To: <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
Message-ID: <p2LwhNhbrfHu1eTgbp1qsFCveY0iF_NSmDcgD82azP0=.94baa733-6b8e-4156-bd3f-f16fd22d4a8f@github.com>

On Tue, 22 Jun 2021 21:07:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix INT32_MIN and cache padding.

Looks good!

Good catch on the padding @dcubed-ojdk !

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3980

From jwilhelm at openjdk.java.net  Wed Jun 23 00:31:30 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 00:31:30 GMT
Subject: RFR: Merge jdk17
Message-ID: <c-xCNav0z49r3RUKgdrJllTW1YnPDH0rGaZsXG2eTLU=.4ce1b446-530c-46ba-a62b-38d7f005e129@github.com>

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"
 - 8267652: c2 loop unrolling by 8 results in reading memory past array
 - 8267399: C2: java/text/Normalizer/ConformanceTest.java test failed with assertion
 - 8268888: Upstream 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken
 - 8268524: nmethod::post_compiled_method_load_event racingly called on zombie
 - 8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec
 - 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling
 - 8268349: Provide clear run-time warnings about Security Manager deprecation
 - 8268293: VectorAPI cast operation on mask and shuffle is broken
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/0c693e2f...7bf4b35f

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4562/files
  Stats: 1931 lines in 60 files changed: 653 ins; 1061 del; 217 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4562/head:pull/4562

PR: https://git.openjdk.java.net/jdk/pull/4562

From coleenp at openjdk.java.net  Wed Jun 23 01:04:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 01:04:41 GMT
Subject: RFR: 8269188: [BACKOUT] Remove
 CodeCache::mark_for_evol_deoptimization() method
Message-ID: <qht8r5J7kHi5zeMxtkmxKJzTQ6ObJApmcuX_YdfJmNE=.0bad75f5-5e39-4aa2-b03b-48e145a73066@github.com>

This reverts commit 33c23a1cf2aa81551eee4a2acf271edf573558aa.

Building locally.

See bug for details.

-------------

Commit messages:
 - Revert "8264941: Remove CodeCache::mark_for_evol_deoptimization() method"

Changes: https://git.openjdk.java.net/jdk/pull/4563/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4563&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269188
  Stats: 78 lines in 7 files changed: 73 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4563.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4563/head:pull/4563

PR: https://git.openjdk.java.net/jdk/pull/4563

From jwilhelm at openjdk.java.net  Wed Jun 23 01:09:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 01:09:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <c-xCNav0z49r3RUKgdrJllTW1YnPDH0rGaZsXG2eTLU=.4ce1b446-530c-46ba-a62b-38d7f005e129@github.com>
References: <c-xCNav0z49r3RUKgdrJllTW1YnPDH0rGaZsXG2eTLU=.4ce1b446-530c-46ba-a62b-38d7f005e129@github.com>
Message-ID: <NbdTjf2NZnjjDjD-x4TWIlmUN2a8IW8dcpEPi-ZHgRM=.d4440330-1f27-4e00-8693-313e4ac47617@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge
 - 8268290: Improve LockFreeQueue<> utility
   
   Reviewed-by: iwalulya, tschatzl
 - 8264941: Remove CodeCache::mark_for_evol_deoptimization() method
   
   Reviewed-by: kvn, vlivanov, sspitsyn
 - 8269031: linux x86_64 check for binutils 2.25 or higher after 8265783
   
   Reviewed-by: ihse, erikj
 - 8267657: Add missing PrintC1Statistics before incrementing counters
   
   Reviewed-by: iveresov
 - 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle
   
   Reviewed-by: dholmes
 - 8269077: TestSystemGC uses "require vm.gc.G1" for large pages subtest
   
   Reviewed-by: tschatzl, kbarrett
 - Merge
 - 8268458: Add verification type for evacuation failures
   
   Reviewed-by: kbarrett, iwalulya
 - 8268952: Automatically update heap sizes in G1MonitoringScope
   
   Reviewed-by: kbarrett, iwalulya
 - ... and 49 more: https://git.openjdk.java.net/jdk/compare/35e4c272...7bf4b35f

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4562/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4562&range=01
  Stats: 16267 lines in 261 files changed: 13210 ins; 2433 del; 624 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4562/head:pull/4562

PR: https://git.openjdk.java.net/jdk/pull/4562

From jwilhelm at openjdk.java.net  Wed Jun 23 01:09:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 01:09:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <c-xCNav0z49r3RUKgdrJllTW1YnPDH0rGaZsXG2eTLU=.4ce1b446-530c-46ba-a62b-38d7f005e129@github.com>
References: <c-xCNav0z49r3RUKgdrJllTW1YnPDH0rGaZsXG2eTLU=.4ce1b446-530c-46ba-a62b-38d7f005e129@github.com>
Message-ID: <_z9pXnmkit5l3vbQ1LT3mAP67fTQ2wh8P8g7ScaZVGw=.91f3374b-1abd-416d-a80b-d0a540f6889e@github.com>

On Wed, 23 Jun 2021 00:21:57 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: b6cfca8a
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b6cfca8a89810c7ed63ebc34ed9855b66ebcb5d9
Stats:     1931 lines in 60 files changed: 653 ins; 1061 del; 217 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4562

From gli at openjdk.java.net  Wed Jun 23 02:24:37 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 23 Jun 2021 02:24:37 GMT
Subject: Integrated: 8268368: Adopt cast notation for JavaThread conversions
In-Reply-To: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
References: <iIk3dMkhhrk2qZWueVD3DLM18wDtsnbKCYZIU32Dwgk=.f4abb1c3-999a-47a3-90cd-e793e3e73a3a@github.com>
Message-ID: <ZKgwufF4OhpFXsOQ_cnQ-ovMX96nJCObKvNKse4jC_I=.ecf57121-36ac-4afd-9c63-9a8d3b11ecab@github.com>

On Tue, 22 Jun 2021 01:11:30 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Considering the consistency of `JavaThread` and other threads, such as WorkerThread and CompilerThread, `JavaThread` could use a method named `cast` to replace the method `Thread::as_Java_thread()`. It can reduce the Thread's knowledge about the subtypes.
> 
> This patch removes two methods, `JavaThread* Thread::as_Java_thread()` and `const JavaThread* Thread::as_Java_thread() const`, of the class `Thread` and adds two static methods, `JavaThread* cast(Thread* t)` and `const JavaThread* cast(const Thread* t)`, to the class `JavaThread`. Correspondingly, the code of the method `JavaThread::current()` need to be adjusted and many places where the method `Thread::as_Java_thread()` is used need to use `JavaThread::cast` instead.
> 
> Test:
> tier1 passed locally.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: cd678a38
Author:    Guoxiong Li <gli at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cd678a383f7b23ea40132b207ddfc041394ba4c1
Stats:     158 lines in 64 files changed: 13 ins; 19 del; 126 mod

8268368: Adopt cast notation for JavaThread conversions

Reviewed-by: dholmes, stefank

-------------

PR: https://git.openjdk.java.net/jdk/pull/4546

From yyang at openjdk.java.net  Wed Jun 23 03:54:55 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 23 Jun 2021 03:54:55 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  tests rely on IOOBE exception message

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/2330ee38..ab1b509d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=06-07

  Stats: 104 lines in 2 files changed: 18 ins; 2 del; 84 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From dholmes at openjdk.java.net  Wed Jun 23 07:10:25 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 23 Jun 2021 07:10:25 GMT
Subject: RFR: 8269188: [BACKOUT] Remove
 CodeCache::mark_for_evol_deoptimization() method
In-Reply-To: <qht8r5J7kHi5zeMxtkmxKJzTQ6ObJApmcuX_YdfJmNE=.0bad75f5-5e39-4aa2-b03b-48e145a73066@github.com>
References: <qht8r5J7kHi5zeMxtkmxKJzTQ6ObJApmcuX_YdfJmNE=.0bad75f5-5e39-4aa2-b03b-48e145a73066@github.com>
Message-ID: <YOP41abHLz9fZj9ZZm0yVoKuZUIu1J47rR8vRgMR5cg=.bf95b26c-da18-4474-b32a-c35c3ad30dfb@github.com>

On Wed, 23 Jun 2021 00:57:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This reverts commit 33c23a1cf2aa81551eee4a2acf271edf573558aa.
> 
> Built locally linux-x64-debug and ran vmTestbase/nsk/jvmti tests.
> 
> See bug for details.

Looks like an accurate backout.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4563

From sspitsyn at openjdk.java.net  Wed Jun 23 09:45:29 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 23 Jun 2021 09:45:29 GMT
Subject: RFR: 8269188: [BACKOUT] Remove
 CodeCache::mark_for_evol_deoptimization() method
In-Reply-To: <qht8r5J7kHi5zeMxtkmxKJzTQ6ObJApmcuX_YdfJmNE=.0bad75f5-5e39-4aa2-b03b-48e145a73066@github.com>
References: <qht8r5J7kHi5zeMxtkmxKJzTQ6ObJApmcuX_YdfJmNE=.0bad75f5-5e39-4aa2-b03b-48e145a73066@github.com>
Message-ID: <PdcQcSGAdrFlmDj_SFAeku5l8pGZE3oEKWxsmaz4xVk=.3410b384-420f-4d8b-a2f9-8895309633d4@github.com>

On Wed, 23 Jun 2021 00:57:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This reverts commit 33c23a1cf2aa81551eee4a2acf271edf573558aa.
> 
> Built locally linux-x64-debug and ran vmTestbase/nsk/jvmti tests.
> 
> See bug for details.

Hi Coleen,
This looks as correct backout to me too.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4563

From pconcannon at openjdk.java.net  Wed Jun 23 12:15:11 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 23 Jun 2021 12:15:11 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation
Message-ID: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>

Hi,

Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?

In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.

As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.

Kind regards,
Patrick

-------------

Commit messages:
 - 8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation

Changes: https://git.openjdk.java.net/jdk/pull/4574/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4574&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253119
  Stats: 11046 lines in 78 files changed: 137 ins; 10836 del; 73 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4574/head:pull/4574

PR: https://git.openjdk.java.net/jdk/pull/4574

From alanb at openjdk.java.net  Wed Jun 23 12:21:26 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 23 Jun 2021 12:21:26 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation
In-Reply-To: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
Message-ID: <JdTFDH3rHo0FlPoQ5aUnvdtXp-569xKfYUeOSyVekfY=.5fdbeb9c-656b-4aea-a2e2-1577f4bcbb95@github.com>

On Wed, 23 Jun 2021 12:06:41 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
> 
> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
> 
> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
> 
> Kind regards,
> Patrick

Good cleanup, just a few nits in the changes to the NioSocketImpl impl, I didn't spot any other issues.

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 69:

> 67:  * This implementation attempts to be compatible with legacy PlainSocketImpl
> 68:  * (removed in JDK18), including behavior and exceptions that are not specified by
> 69:  * SocketImpl.

Maybe we should just drop this sentence and not attempt to replace it.

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 647:

> 645:             // set the address field to the given host address to keep
> 646:             // compatibility with SocketImpl. When binding to 0.0.0.0
> 647:             // then the actual local address will be ::0 when IPv6 is enabled.

I don't think "SocketImpl" works here. Maybe replace "keep compatibility with PlainSocketImpl" with "to maintain long standing behavior".

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From stefan.karlsson at oracle.com  Wed Jun 23 13:09:56 2021
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 23 Jun 2021 15:09:56 +0200
Subject: libjdwp crash while debugging application ran on OpenJDK 16
In-Reply-To: <CACcnpz3boY=fc8MwzVG==wT7w++kg6xhe3xLSRSZdt8MuH00ug@mail.gmail.com>
References: <CACcnpz3boY=fc8MwzVG==wT7w++kg6xhe3xLSRSZdt8MuH00ug@mail.gmail.com>
Message-ID: <6d07afc1-ce8c-f0a5-7b8b-bf1b8357ed4b@oracle.com>

Hi Simeon,

On 2021-06-23 12:39, S A wrote:
> Hi all,
>
> my colleagues recently ran into a crash in libjdwp, when measuring
> performance with OpenJDK 17 (early access build). The same crash was
> observed with OpenJDK 16.0.1, but not with OpenJDK 15.
>
> We are hoping to get a fix for the crash, before the official OpenJDK 17
> release. We've opened a RHEL bugzilla ticket for this (
> https://bugzilla.redhat.com/show_bug.cgi?id=1972529), but we expect this
> won't be enough to resolve the crash before the release.
>
> What would the appropriate medium be to report the problem? I assume this
> mailing list is not the right place, but I don't know how to otherwise
> reach out to OpenJDK developers and maintainers (other than via RHEL
> support/bugzilla, which is often a slow process).

The hs_err crash files usually states where to report the bugs. 
Oracle-built binaries say:
# If you would like to submit a bug report, please visit:
#?? https://bugreport.java.com/bugreport/crash.jsp

I think serviceability-dev would be the be the correct mailing list. 
I'll bcc away jdk-dev and will move this to serviceablity-dev.

I wonder if this could be caused by calling commonRef_unpin on a ref 
that is not "pinned"? Specifically, look at the updated weakenNode:

static jweak
weakenNode(JNIEnv *env, RefNode *node)
{
 ??? if (node->strongCount == 1) {
...
 ??????? return weakRef;
 ??? } else {
 ??????? node->strongCount--;
 ??????? return node->ref;
 ??? }
}

if strongCount is 0, this will underflow and then delete node will take 
the wrong path:

if (node->strongCount != 0) {
 ? JNI_FUNC_PTR(env,DeleteGlobalRef)(env, node->ref);
} else {
 ? JNI_FUNC_PTR(env,DeleteWeakGlobalRef)(env, node->ref);
}

The previous version of weakenNode looked like this:

static jweak
weakenNode(JNIEnv *env, RefNode *node)
{
 ??? if (node->isStrong) {
...
 ??????? return weakRef;
 ??? } else {
 ??????? return node->ref;
 ??? }
}

so a unbalanced unpin call would previously not fail in the same way.

StefanK

>
> Sorry for the noise on the mailing list.
>
> Best regards,
> Simeon
>
> *Extra infos and background:*
>
> We would like to move to OpenJDK 17, in order to use Shenandoah GC.
> Shenandoah GC shows promising results for our product, though only with the
> fix for https://bugs.openjdk.java.net/browse/JDK-8254315. We would not be
> able to switch (or even evaluate the switch properly) until the crash is
> resolved.
>
> Unfortunately we have no reproducer outside of our product, and our
> reproducer is quite complex. Trivial use cases of debugging OpenJDK 16 with
> Eclipse (we base our product on Eclipse) do not run into a crash.
>
> A fast debug build for OpenJDK 16 reports an assertion fail as follows:
>
> #  Internal Error
> (/tmp/jep2604_fastdebug_jdk16/jdk16/src/hotspot/share/runtime/jniHandles.cpp:148),
> pid=81289, tid=56880
> #  assert(!is_jweak(handle)) failed: wrong method for detroying jweak
> #
> # JRE version: OpenJDK Runtime Environment (16.0) (fastdebug build
> 16-internal+0-adhoc.sandreev.jdk16)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug
> 16-internal+0-adhoc.sandreev.jdk16, mixed mode, tiered, compressed oops, g1
> gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x1043cb4]  JNIHandles::destroy_global(_jobject*)+0x224
> ...
> Stack: [0x00007ffe3c4f5000,0x00007ffe3c5f6000],  sp=0x00007ffe3c5f4be0,
>   free space=1022k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1043cb4]  JNIHandles::destroy_global(_jobject*)+0x224
> V  [libjvm.so+0xfafd9f]  jni_DeleteGlobalRef+0x10f
> C  [libjdwp.so+0xf11a]  deleteNode+0x7a
> C  [libjdwp.so+0xf71f]  commonRef_reset+0x6f
> C  [libjdwp.so+0x10dec]  debugInit_reset+0x6c
> C  [libjdwp.so+0x270a2]  acceptThread+0xa2
> V  [libjvm.so+0x127c054]  JvmtiAgentThread::call_start_function()+0x1d4
> V  [libjvm.so+0x1a51e9a]  JavaThread::thread_main_inner()+0x5ba
> V  [libjvm.so+0x1a589e0]  Thread::call_run()+0x100
> V  [libjvm.so+0x15fbd26]  thread_native_entry(Thread*)+0x116
>
> Going through the stack trace, looking for related changes, I've not been
> able to reproduce the crash with this commit reverted:
> https://github.com/openjdk/jdk/commit/79f1dfb8d3941377da77e73f7bbab93baef29b8e


From alanb at openjdk.java.net  Wed Jun 23 13:12:31 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 23 Jun 2021 13:12:31 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation
In-Reply-To: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
Message-ID: <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>

On Wed, 23 Jun 2021 12:06:41 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
> 
> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
> 
> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
> 
> Kind regards,
> Patrick

I assume DatagramSocket L1043-L1049 (declaration/init of USE_PLAINDATAGRAMSOCKET) can be removed too.

src/java.base/share/classes/java/net/DatagramSocket.java line 1405:

> 1403:                 // create legacy DatagramSocket delegate
> 1404:                 DatagramSocketImpl impl = factory.createDatagramSocketImpl();
> 1405:                 Objects.requireNonNull(impl);

I assume this Objects.requireNonNull is not needed or maybe you want to detect a buggy factory rather than in the the constructor?

src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c line 269:

> 267: 
> 268: /*
> 269:  * Below Adapted from PlainSocketImpl.c (removed in JDK18), win32 version 1.18.

I think we'll need decide whether to keep this comment or not, I would be tempted to re-write it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From dfuchs at openjdk.java.net  Wed Jun 23 14:22:38 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 23 Jun 2021 14:22:38 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation
In-Reply-To: <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
Message-ID: <LW8h9nm9ZSwyjK4k-KQegZKgMFpTV5r2KSHHttNUjd8=.2611d502-8f18-4db8-99cb-2a41e4d62378@github.com>

On Wed, 23 Jun 2021 13:05:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>> 
>> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
>> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
>> 
>> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
>> 
>> Kind regards,
>> Patrick
>
> src/java.base/share/classes/java/net/DatagramSocket.java line 1405:
> 
>> 1403:                 // create legacy DatagramSocket delegate
>> 1404:                 DatagramSocketImpl impl = factory.createDatagramSocketImpl();
>> 1405:                 Objects.requireNonNull(impl);
> 
> I assume this Objects.requireNonNull is not needed or maybe you want to detect a buggy factory rather than in the the constructor?

Yes - the constructor would throw NPE - but there's no need to call this constructor if `impl` is null here - it's better to fail early.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From coleenp at openjdk.java.net  Wed Jun 23 14:29:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 14:29:33 GMT
Subject: RFR: 8269188: [BACKOUT] Remove
 CodeCache::mark_for_evol_deoptimization() method
In-Reply-To: <qht8r5J7kHi5zeMxtkmxKJzTQ6ObJApmcuX_YdfJmNE=.0bad75f5-5e39-4aa2-b03b-48e145a73066@github.com>
References: <qht8r5J7kHi5zeMxtkmxKJzTQ6ObJApmcuX_YdfJmNE=.0bad75f5-5e39-4aa2-b03b-48e145a73066@github.com>
Message-ID: <rxpn6WHVf54G8rm06y5sEgJT0T4kggAlH5UVYhKxh8Q=.78a4a8b6-129a-4b69-819e-1668afbc7a96@github.com>

On Wed, 23 Jun 2021 00:57:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This reverts commit 33c23a1cf2aa81551eee4a2acf271edf573558aa.
> 
> Built locally linux-x64-debug and ran vmTestbase/nsk/jvmti tests.
> 
> See bug for details.

Thanks David and Serguei.  git had no problem with the revert.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4563

From coleenp at openjdk.java.net  Wed Jun 23 14:29:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 14:29:33 GMT
Subject: Integrated: 8269188: [BACKOUT] Remove
 CodeCache::mark_for_evol_deoptimization() method
In-Reply-To: <qht8r5J7kHi5zeMxtkmxKJzTQ6ObJApmcuX_YdfJmNE=.0bad75f5-5e39-4aa2-b03b-48e145a73066@github.com>
References: <qht8r5J7kHi5zeMxtkmxKJzTQ6ObJApmcuX_YdfJmNE=.0bad75f5-5e39-4aa2-b03b-48e145a73066@github.com>
Message-ID: <ftTBKGPxbauNVk5nHCtkQKALiDsyWfO--viwwObnKTQ=.b4457bb8-ef37-4b8f-904d-fb8d49c3ccb3@github.com>

On Wed, 23 Jun 2021 00:57:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This reverts commit 33c23a1cf2aa81551eee4a2acf271edf573558aa.
> 
> Built locally linux-x64-debug and ran vmTestbase/nsk/jvmti tests.
> 
> See bug for details.

This pull request has now been integrated.

Changeset: 52d5d1b3
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/52d5d1b3617731bf312aa5813bf7e78ca4dacb00
Stats:     78 lines in 7 files changed: 73 ins; 0 del; 5 mod

8269188: [BACKOUT] Remove CodeCache::mark_for_evol_deoptimization() method

Reviewed-by: dholmes, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4563

From coleenp at openjdk.java.net  Wed Jun 23 14:30:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 14:30:33 GMT
Subject: Integrated: 8256306: ObjectMonitor::_contentions field should not be
 'jint'
In-Reply-To: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
Message-ID: <FORz0i1lFFXwraT4fLaCT1H2ljlMI-4y1BPJfq531Js=.a7ea8d35-ae8b-4dab-bf0d-f24cd446666e@github.com>

On Tue, 11 May 2021 15:01:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.

This pull request has now been integrated.

Changeset: f3ba2690
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f3ba2690c5b34673ebf6836c87e45477e1ff91c3
Stats:     28 lines in 5 files changed: 1 ins; 0 del; 27 mod

8256306: ObjectMonitor::_contentions field should not be 'jint'

Reviewed-by: dholmes, stuefe, dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From coleenp at openjdk.java.net  Wed Jun 23 14:30:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 14:30:32 GMT
Subject: RFR: 8256306: ObjectMonitor::_contentions field should not be
 'jint' [v2]
In-Reply-To: <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
References: <8lLopoJj6EDrjOY7ca0TJKrNO40ldbSSsYrDgSWQlvE=.97583fd8-f3f6-424f-a896-8c24d0d1a844@github.com>
 <bofUhYoSacTbU_XB1FHyB5_97_DL9kxt6sq72WOwO1c=.67af33c7-e0b1-4403-8108-bf3cc10a4351@github.com>
Message-ID: <pQCOTRq1qqv1EB-RZjIgTLnbGCHYy_kKu0iC8s7AKug=.a6ec6f54-dffa-434a-be9d-3d2a16fc27ce@github.com>

On Tue, 22 Jun 2021 21:07:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I changed the _contentions and _waiters fields from jint to int and ran tests tier1-3.  Tested tier1 with linux, mac, windows platforms. Also changed the _previous_owner_tid to unintptr_t from jlong, since that's what the cast did.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix INT32_MIN and cache padding.

Thank you David, Dan and Thomas.  There are a few other jlongs hanging around in that file, but that's for another day.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3980

From alanb at openjdk.java.net  Wed Jun 23 14:35:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 23 Jun 2021 14:35:29 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation
In-Reply-To: <LW8h9nm9ZSwyjK4k-KQegZKgMFpTV5r2KSHHttNUjd8=.2611d502-8f18-4db8-99cb-2a41e4d62378@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
 <LW8h9nm9ZSwyjK4k-KQegZKgMFpTV5r2KSHHttNUjd8=.2611d502-8f18-4db8-99cb-2a41e4d62378@github.com>
Message-ID: <t8XY5rbqva5dxvDcjncITTcDfeznMzmvquDXPYMiFFw=.0034afdb-e667-4f97-85ea-02d34990d4b5@github.com>

On Wed, 23 Jun 2021 14:19:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/DatagramSocket.java line 1405:
>> 
>>> 1403:                 // create legacy DatagramSocket delegate
>>> 1404:                 DatagramSocketImpl impl = factory.createDatagramSocketImpl();
>>> 1405:                 Objects.requireNonNull(impl);
>> 
>> I assume this Objects.requireNonNull is not needed or maybe you want to detect a buggy factory rather than in the the constructor?
>
> Yes - the constructor would throw NPE - but there's no need to call this constructor if `impl` is null here - it's better to fail early.

This is probably a case where the spec needs say that an error (maybe an unspecified error) is thrown if the custom factory's createDatagramSocketImpl returns null. We can create a separate issue for that as it's probably existed forever.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From dfuchs at openjdk.java.net  Wed Jun 23 15:06:37 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 23 Jun 2021 15:06:37 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation
In-Reply-To: <t8XY5rbqva5dxvDcjncITTcDfeznMzmvquDXPYMiFFw=.0034afdb-e667-4f97-85ea-02d34990d4b5@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
 <LW8h9nm9ZSwyjK4k-KQegZKgMFpTV5r2KSHHttNUjd8=.2611d502-8f18-4db8-99cb-2a41e4d62378@github.com>
 <t8XY5rbqva5dxvDcjncITTcDfeznMzmvquDXPYMiFFw=.0034afdb-e667-4f97-85ea-02d34990d4b5@github.com>
Message-ID: <KO_g07q53b3ROAqROlRsV1D9u4b0z6f3gOqyc1O3NQI=.271fe570-2d45-4e83-b5b7-97284009b020@github.com>

On Wed, 23 Jun 2021 14:32:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yes - the constructor would throw NPE - but there's no need to call this constructor if `impl` is null here - it's better to fail early.
>
> This is probably a case where the spec needs say that an error (maybe an unspecified error) is thrown if the custom factory's createDatagramSocketImpl returns null. We can create a separate issue for that as it's probably existed forever.

@AlanBateman 

`protected DatagramSocket(DatagramSocketImpl  impl)` throws NPE if `impl` is `null`.
(this is covered by the blanket statement for NPE)

Do we really need to specify anything else since the global `setDatagramSocketImplFactory` method has been deprecated? I mean - though we still support it at the moment, using a `DatagramSocketImplFactory` is not recommended, and hopefully only old legacy code would be using that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From alanb at openjdk.java.net  Wed Jun 23 15:12:27 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 23 Jun 2021 15:12:27 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation
In-Reply-To: <KO_g07q53b3ROAqROlRsV1D9u4b0z6f3gOqyc1O3NQI=.271fe570-2d45-4e83-b5b7-97284009b020@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
 <LW8h9nm9ZSwyjK4k-KQegZKgMFpTV5r2KSHHttNUjd8=.2611d502-8f18-4db8-99cb-2a41e4d62378@github.com>
 <t8XY5rbqva5dxvDcjncITTcDfeznMzmvquDXPYMiFFw=.0034afdb-e667-4f97-85ea-02d34990d4b5@github.com>
 <KO_g07q53b3ROAqROlRsV1D9u4b0z6f3gOqyc1O3NQI=.271fe570-2d45-4e83-b5b7-97284009b020@github.com>
Message-ID: <C0_qehGuP6IUynXRu6HgODw3aY8hBwjY9eZX_WaOdlk=.344a36ee-d48f-4e53-9005-1e6ac2a19386@github.com>

On Wed, 23 Jun 2021 15:01:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is probably a case where the spec needs say that an error (maybe an unspecified error) is thrown if the custom factory's createDatagramSocketImpl returns null. We can create a separate issue for that as it's probably existed forever.
>
> @AlanBateman 
> 
> `protected DatagramSocket(DatagramSocketImpl  impl)` throws NPE if `impl` is `null`.
> (this is covered by the blanket statement for NPE)
> 
> Do we really need to specify anything else since the global `setDatagramSocketImplFactory` method has been deprecated? I mean - though we still support it at the moment, using a `DatagramSocketImplFactory` is not recommended, and hopefully only old legacy code would be using that.

Creating an issue to update DatagramSocketImplFactory.createDatagramSocketImpl to say that returning null leads to undefined behavior or DatagramSocket constructors throwing an error is fine, I wasn't suggesting we have to fix it here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From coleenp at openjdk.java.net  Wed Jun 23 17:34:55 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 17:34:55 GMT
Subject: RFR: 8269186: [REDO] Remove CodeCache::mark_for_evol_deoptimization()
 method
Message-ID: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>

This is somewhat trivial change to remove CodeCache::mark_for_evol_deoptimization() and its calling method, and nothing else this time.
Ran vmTestbase/nsk/jvmti tests.

-------------

Commit messages:
 - 8269186: [REDO] Remove CodeCache::mark_for_evol_deoptimization() method

Changes: https://git.openjdk.java.net/jdk/pull/4575/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4575&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269186
  Stats: 24 lines in 4 files changed: 0 ins; 23 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4575.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4575/head:pull/4575

PR: https://git.openjdk.java.net/jdk/pull/4575

From hseigel at openjdk.java.net  Wed Jun 23 18:10:27 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 23 Jun 2021 18:10:27 GMT
Subject: RFR: 8269186: [REDO] Remove
 CodeCache::mark_for_evol_deoptimization() method
In-Reply-To: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>
References: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>
Message-ID: <lAvEIWPogB0W8sVf0-aL0bXeUxiUqr7UWTJm_Eqrls4=.72e4ca4d-0a43-44b9-95c7-603ac453b44b@github.com>

On Wed, 23 Jun 2021 17:27:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is somewhat trivial change to remove CodeCache::mark_for_evol_deoptimization() and its calling method, and nothing else this time.
> Ran vmTestbase/nsk/jvmti tests.

LGTM
Thanks, Harold

-------------

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4575

From lfoltan at openjdk.java.net  Wed Jun 23 18:39:28 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Wed, 23 Jun 2021 18:39:28 GMT
Subject: RFR: 8269186: [REDO] Remove
 CodeCache::mark_for_evol_deoptimization() method
In-Reply-To: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>
References: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>
Message-ID: <JD7l8t9bcZFaKyRnYe7NOtmwDsg8jee1744JxQFMlys=.4e694c1a-0729-46fe-bb25-e4dc701cee19@github.com>

On Wed, 23 Jun 2021 17:27:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is somewhat trivial change to remove CodeCache::mark_for_evol_deoptimization() and its calling method, and nothing else this time.
> Ran vmTestbase/nsk/jvmti tests.

LGTM.

Thanks,
Lois

-------------

Marked as reviewed by lfoltan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4575

From rkennke at redhat.com  Wed Jun 23 19:21:24 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 23 Jun 2021 21:21:24 +0200
Subject: libjdwp crash while debugging application ran on OpenJDK 16
In-Reply-To: <6d07afc1-ce8c-f0a5-7b8b-bf1b8357ed4b@oracle.com>
References: <CACcnpz3boY=fc8MwzVG==wT7w++kg6xhe3xLSRSZdt8MuH00ug@mail.gmail.com>
 <6d07afc1-ce8c-f0a5-7b8b-bf1b8357ed4b@oracle.com>
Message-ID: <8b9bdb34-3a4b-b7f6-7d3d-cff6757b323d@redhat.com>

Hi Simon,

>> my colleagues recently ran into a crash in libjdwp, when measuring
>> performance with OpenJDK 17 (early access build). The same crash was
>> observed with OpenJDK 16.0.1, but not with OpenJDK 15.
>>
>> We are hoping to get a fix for the crash, before the official OpenJDK 17
>> release. We've opened a RHEL bugzilla ticket for this (
>> https://bugzilla.redhat.com/show_bug.cgi?id=1972529), but we expect this
>> won't be enough to resolve the crash before the release.
>>

> I wonder if this could be caused by calling commonRef_unpin on a ref 
> that is not "pinned"? Specifically, look at the updated weakenNode:
> 
> static jweak
> weakenNode(JNIEnv *env, RefNode *node)
> {
>  ??? if (node->strongCount == 1) {
> ...
>  ??????? return weakRef;
>  ??? } else {
>  ??????? node->strongCount--;
>  ??????? return node->ref;
>  ??? }
> }
> 
> if strongCount is 0, this will underflow and then delete node will take 
> the wrong path:
> 
> if (node->strongCount != 0) {
>  ? JNI_FUNC_PTR(env,DeleteGlobalRef)(env, node->ref);
> } else {
>  ? JNI_FUNC_PTR(env,DeleteWeakGlobalRef)(env, node->ref);
> }
> 
> The previous version of weakenNode looked like this:
> 
> static jweak
> weakenNode(JNIEnv *env, RefNode *node)
> {
>  ??? if (node->isStrong) {
> ...
>  ??????? return weakRef;
>  ??? } else {
>  ??????? return node->ref;
>  ??? }
> }
> 
> so a unbalanced unpin call would previously not fail in the same way.

Thank, Stefan, this seems like a plausible cause for the problem. It 
seems to me that unbalanced pin and unpin can only be caused by 
unbalanced DisableCollection/EnableCollection in the wire protocol, and 
I guess we don't really have much control over this and should be defensive.

Simon, can you test if this patch helps:

http://cr.openjdk.java.net/~rkennke/fixlibjdwp.patch

It basically protects from the underflow that Stefan found.

It would be good to have a test case for this. Is there a way to 
construct tests that exercise JDWP commands?

Thanks,
Roman


From chris.plummer at oracle.com  Wed Jun 23 19:35:05 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 23 Jun 2021 12:35:05 -0700
Subject: libjdwp crash while debugging application ran on OpenJDK 16
In-Reply-To: <8b9bdb34-3a4b-b7f6-7d3d-cff6757b323d@redhat.com>
References: <CACcnpz3boY=fc8MwzVG==wT7w++kg6xhe3xLSRSZdt8MuH00ug@mail.gmail.com>
 <6d07afc1-ce8c-f0a5-7b8b-bf1b8357ed4b@oracle.com>
 <8b9bdb34-3a4b-b7f6-7d3d-cff6757b323d@redhat.com>
Message-ID: <9d7e505d-e905-8af6-078a-3a9dfc45b2ad@oracle.com>

On 6/23/21 12:21 PM, Roman Kennke wrote:
> Hi Simon,
>
>>> my colleagues recently ran into a crash in libjdwp, when measuring
>>> performance with OpenJDK 17 (early access build). The same crash was
>>> observed with OpenJDK 16.0.1, but not with OpenJDK 15.
>>>
>>> We are hoping to get a fix for the crash, before the official 
>>> OpenJDK 17
>>> release. We've opened a RHEL bugzilla ticket for this (
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1972529), but we expect 
>>> this
>>> won't be enough to resolve the crash before the release.
>>>
>
>> I wonder if this could be caused by calling commonRef_unpin on a ref 
>> that is not "pinned"? Specifically, look at the updated weakenNode:
>>
>> static jweak
>> weakenNode(JNIEnv *env, RefNode *node)
>> {
>> ???? if (node->strongCount == 1) {
>> ...
>> ???????? return weakRef;
>> ???? } else {
>> ???????? node->strongCount--;
>> ???????? return node->ref;
>> ???? }
>> }
>>
>> if strongCount is 0, this will underflow and then delete node will 
>> take the wrong path:
>>
>> if (node->strongCount != 0) {
>> ?? JNI_FUNC_PTR(env,DeleteGlobalRef)(env, node->ref);
>> } else {
>> ?? JNI_FUNC_PTR(env,DeleteWeakGlobalRef)(env, node->ref);
>> }
>>
>> The previous version of weakenNode looked like this:
>>
>> static jweak
>> weakenNode(JNIEnv *env, RefNode *node)
>> {
>> ???? if (node->isStrong) {
>> ...
>> ???????? return weakRef;
>> ???? } else {
>> ???????? return node->ref;
>> ???? }
>> }
>>
>> so a unbalanced unpin call would previously not fail in the same way.
>
> Thank, Stefan, this seems like a plausible cause for the problem. It 
> seems to me that unbalanced pin and unpin can only be caused by 
> unbalanced DisableCollection/EnableCollection in the wire protocol, 
> and I guess we don't really have much control over this and should be 
> defensive.
>
> Simon, can you test if this patch helps:
>
> http://cr.openjdk.java.net/~rkennke/fixlibjdwp.patch
>
> It basically protects from the underflow that Stefan found.
>
> It would be good to have a test case for this. Is there a way to 
> construct tests that exercise JDWP commands?
>
> Thanks,
> Roman
>
https://bugs.openjdk.java.net/browse/JDK-8269232 has been filed. There 
is more discussion there, including some caveats about the proposed fix. 
I also suggest first adding an assert just to make sure you are indeed 
triggering it. Eclipse should also look into why it likely has 
unbalanced enable/disableCollection calls.

Chris


From sspitsyn at openjdk.java.net  Wed Jun 23 20:34:27 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 23 Jun 2021 20:34:27 GMT
Subject: RFR: 8269186: [REDO] Remove
 CodeCache::mark_for_evol_deoptimization() method
In-Reply-To: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>
References: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>
Message-ID: <EE42v1EC0iSkDWyYR8C2zoGsHjNJgP_G98ZCEHk-S1I=.eadcd72b-68a4-4f51-a760-a47286fc8b01@github.com>

On Wed, 23 Jun 2021 17:27:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is somewhat trivial change to remove CodeCache::mark_for_evol_deoptimization() and its calling method, and nothing else this time.
> Ran vmTestbase/nsk/jvmti tests.

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4575

From coleenp at openjdk.java.net  Wed Jun 23 21:14:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 21:14:30 GMT
Subject: Integrated: 8269186: [REDO] Remove
 CodeCache::mark_for_evol_deoptimization() method
In-Reply-To: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>
References: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>
Message-ID: <yFKgEnRV_6AgNgww3BwYUV4S_FikzEQ58WWvTFBC5aA=.0b0da87e-cc47-467c-816a-a4b71b611473@github.com>

On Wed, 23 Jun 2021 17:27:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is somewhat trivial change to remove CodeCache::mark_for_evol_deoptimization() and its calling method, and nothing else this time.
> Ran vmTestbase/nsk/jvmti tests.

This pull request has now been integrated.

Changeset: f3759164
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f3759164179b2471d34df1225085deaf6c0f8fed
Stats:     24 lines in 4 files changed: 0 ins; 23 del; 1 mod

8269186: [REDO] Remove CodeCache::mark_for_evol_deoptimization() method

Reviewed-by: hseigel, lfoltan, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4575

From coleenp at openjdk.java.net  Wed Jun 23 21:14:29 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Jun 2021 21:14:29 GMT
Subject: RFR: 8269186: [REDO] Remove
 CodeCache::mark_for_evol_deoptimization() method
In-Reply-To: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>
References: <Gu__tyUbstjZgvKKsy8FhzI47Bxx9LiEtbw_rBq45PU=.0a4a530b-3e5e-4659-8161-13be924948b4@github.com>
Message-ID: <1o-JC2SM16KpuS4N4Qj6y0heMEU3JwQZ7ENNPMbeKRk=.a2df25dc-c945-46cf-8e0a-d94589ac1f9e@github.com>

On Wed, 23 Jun 2021 17:27:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is somewhat trivial change to remove CodeCache::mark_for_evol_deoptimization() and its calling method, and nothing else this time.
> Ran vmTestbase/nsk/jvmti tests.

Thanks Harold, Lois and Serguei for reviewing this trivial change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4575

From amenkov at openjdk.java.net  Wed Jun 23 23:38:28 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 23 Jun 2021 23:38:28 GMT
Subject: RFR: 8268433: serviceability/dcmd/framework/VMVersionTest.java
 fails with Unable to send object throw not established PipeIO Listener Thread
 connection
In-Reply-To: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
References: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
Message-ID: <rQVO6rrFtbI3vwjtiv8aGIWQoJeggFy28e0GDbpOqP4=.f415231c-31a4-486a-9e33-e8d7b3804138@github.com>

On Fri, 18 Jun 2021 20:20:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Main logic of the tests is:
> 
> TestProcessLauncher t = ...;
> try {
>     t.launch();
>     .. perform testing ...
> } finally {
>    t.quit();
> }
> 
> We have some problem with the tests, but the exception from TestProcessLauncher.quit() masks it.
> The failures are very intermittent, so need to fix this excption to get more information about real error.

Ping. Need 2nd reviewer

-------------

PR: https://git.openjdk.java.net/jdk/pull/4532

From amenkov at openjdk.java.net  Wed Jun 23 23:39:27 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 23 Jun 2021 23:39:27 GMT
Subject: RFR: 8236212: CompiledMethodLoad and CompiledMethodUnload events
 can be posted in START phase
In-Reply-To: <vwjM2u7Fg5ieFljLYRusBLiTKkpNSAJBVE3vqEg6Qhs=.9fa0cd3d-21c2-4fc6-aa3d-c9c82a53973b@github.com>
References: <vwjM2u7Fg5ieFljLYRusBLiTKkpNSAJBVE3vqEg6Qhs=.9fa0cd3d-21c2-4fc6-aa3d-c9c82a53973b@github.com>
Message-ID: <V2JoNG5NOCt1xXCVRR_PbLQwlrbMJMo3mvVwrkGN5RE=.f0c221d9-42a5-41c3-b463-5a998d06fb28@github.com>

On Fri, 18 Jun 2021 22:57:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Accordingly the spec CompiledMethodLoad/CompiledMethodUnload events may be sent in the start and live phases.
> VM implementation send them only in the live phase, but tests should expect them in the start phase too

Ping. Need 2nd reviewer for the fix

-------------

PR: https://git.openjdk.java.net/jdk/pull/4535

From cjplummer at openjdk.java.net  Wed Jun 23 23:50:27 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 23 Jun 2021 23:50:27 GMT
Subject: RFR: 8268433: serviceability/dcmd/framework/VMVersionTest.java
 fails with Unable to send object throw not established PipeIO Listener Thread
 connection
In-Reply-To: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
References: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
Message-ID: <hRcMJ0V3BtEaEZrbxKFb-GWmeHMPko_AVNWqUxWeSAA=.bd521f7d-2ab3-4ede-b39f-6da3f32eace0@github.com>

On Fri, 18 Jun 2021 20:20:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Main logic of the tests is:
> 
> TestProcessLauncher t = ...;
> try {
>     t.launch();
>     .. perform testing ...
> } finally {
>    t.quit();
> }
> 
> We have some problem with the tests, but the exception from TestProcessLauncher.quit() masks it.
> The failures are very intermittent, so need to fix this excption to get more information about real error.

Doesn't this just result in seeing a WARNING message instead of the failure described in JDK-8268433? Or do you still expect the test to fail, but to give other useful information.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4532

From amenkov at openjdk.java.net  Wed Jun 23 23:58:27 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 23 Jun 2021 23:58:27 GMT
Subject: RFR: 8268433: serviceability/dcmd/framework/VMVersionTest.java
 fails with Unable to send object throw not established PipeIO Listener Thread
 connection
In-Reply-To: <hRcMJ0V3BtEaEZrbxKFb-GWmeHMPko_AVNWqUxWeSAA=.bd521f7d-2ab3-4ede-b39f-6da3f32eace0@github.com>
References: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
 <hRcMJ0V3BtEaEZrbxKFb-GWmeHMPko_AVNWqUxWeSAA=.bd521f7d-2ab3-4ede-b39f-6da3f32eace0@github.com>
Message-ID: <5J2T-hre5T59rnjBUxO3ByBlhtn5RYhMZ8YcyVzAEdM=.081e021f-ae4e-4e01-8ffa-b35cc9cc8630@github.com>

On Wed, 23 Jun 2021 23:47:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> 
> 
> Doesn't this just result in seeing a WARNING message instead of the failure described in JDK-8268433? Or do you still expect the test to fail, but to give other useful information.

Yes, I expect that the tests continue to fail, but with this fix we should see real error.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4532

From cjplummer at openjdk.java.net  Thu Jun 24 00:05:28 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 24 Jun 2021 00:05:28 GMT
Subject: RFR: 8268433: serviceability/dcmd/framework/VMVersionTest.java
 fails with Unable to send object throw not established PipeIO Listener Thread
 connection
In-Reply-To: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
References: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
Message-ID: <CHTC383HouvOnjhRODKof7er5hWLc2Ld3JvtBEquOek=.315bd497-4c05-4250-a79d-14eaef2d70ff@github.com>

On Fri, 18 Jun 2021 20:20:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Main logic of the tests is:
> 
> TestProcessLauncher t = ...;
> try {
>     t.launch();
>     .. perform testing ...
> } finally {
>    t.quit();
> }
> 
> We have some problem with the tests, but the exception from TestProcessLauncher.quit() masks it.
> The failures are very intermittent, so need to fix this excption to get more information about real error.

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4532

From cjplummer at openjdk.java.net  Thu Jun 24 00:12:31 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 24 Jun 2021 00:12:31 GMT
Subject: RFR: 8236212: CompiledMethodLoad and CompiledMethodUnload events
 can be posted in START phase
In-Reply-To: <vwjM2u7Fg5ieFljLYRusBLiTKkpNSAJBVE3vqEg6Qhs=.9fa0cd3d-21c2-4fc6-aa3d-c9c82a53973b@github.com>
References: <vwjM2u7Fg5ieFljLYRusBLiTKkpNSAJBVE3vqEg6Qhs=.9fa0cd3d-21c2-4fc6-aa3d-c9c82a53973b@github.com>
Message-ID: <hSRKwVhF2dWx2jIH4doRlZdrO__-BA2OWqw6sYl2Pa8=.e9486ebd-7604-4043-be5f-99dc24a1bfe6@github.com>

On Fri, 18 Jun 2021 22:57:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Accordingly the spec CompiledMethodLoad/CompiledMethodUnload events may be sent in the start and live phases.
> VM implementation send them only in the live phase, but tests should expect them in the start phase too

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4535

From amenkov at openjdk.java.net  Thu Jun 24 00:31:35 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 24 Jun 2021 00:31:35 GMT
Subject: Integrated: 8268433: serviceability/dcmd/framework/VMVersionTest.java
 fails with Unable to send object throw not established PipeIO Listener Thread
 connection
In-Reply-To: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
References: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
Message-ID: <VEmQq3h1VPh2YUYjdTzmN7gwu-FYmtKPXMazjr4Q0Rg=.c7c56bc5-2268-4095-b839-5763589fb28a@github.com>

On Fri, 18 Jun 2021 20:20:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Main logic of the tests is:
> 
> TestProcessLauncher t = ...;
> try {
>     t.launch();
>     .. perform testing ...
> } finally {
>    t.quit();
> }
> 
> We have some problem with the tests, but the exception from TestProcessLauncher.quit() masks it.
> The failures are very intermittent, so need to fix this excption to get more information about real error.

This pull request has now been integrated.

Changeset: 280f2d57
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/280f2d57d1f78b3d15dd98e726267a100eb0b5db
Stats:     9 lines in 2 files changed: 4 ins; 4 del; 1 mod

8268433: serviceability/dcmd/framework/VMVersionTest.java fails with Unable to send object throw not established PipeIO Listener Thread connection

Reviewed-by: sspitsyn, cjplummer

-------------

PR: https://git.openjdk.java.net/jdk/pull/4532

From amenkov at openjdk.java.net  Thu Jun 24 00:35:33 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 24 Jun 2021 00:35:33 GMT
Subject: Integrated: 8236212: CompiledMethodLoad and CompiledMethodUnload
 events can be posted in START phase
In-Reply-To: <vwjM2u7Fg5ieFljLYRusBLiTKkpNSAJBVE3vqEg6Qhs=.9fa0cd3d-21c2-4fc6-aa3d-c9c82a53973b@github.com>
References: <vwjM2u7Fg5ieFljLYRusBLiTKkpNSAJBVE3vqEg6Qhs=.9fa0cd3d-21c2-4fc6-aa3d-c9c82a53973b@github.com>
Message-ID: <EhPm9YlNaj6sRWMseHr48EeMDTsH5ze71XydFQ0-8wA=.d3f48101-9822-413f-b111-0d4ac186c3e7@github.com>

On Fri, 18 Jun 2021 22:57:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Accordingly the spec CompiledMethodLoad/CompiledMethodUnload events may be sent in the start and live phases.
> VM implementation send them only in the live phase, but tests should expect them in the start phase too

This pull request has now been integrated.

Changeset: 51d91597
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51d915979cec4f4d7f20df8e5d3394025d7a3dc7
Stats:     8 lines in 2 files changed: 0 ins; 0 del; 8 mod

8236212: CompiledMethodLoad and CompiledMethodUnload events can be posted in START phase

Reviewed-by: sspitsyn, cjplummer

-------------

PR: https://git.openjdk.java.net/jdk/pull/4535

From ysuenaga at openjdk.java.net  Thu Jun 24 04:00:38 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 24 Jun 2021 04:00:38 GMT
Subject: [jdk17] RFR: 8269265: ProblemList
 serviceability/sa/TestJmapCoreMetaspace.java with ZGC
Message-ID: <YfXvud_VfgdQKaJDKc1_5kY2TzzpqPZtBPoLLWjPs9U=.5d8532d0-c43c-41e4-bc61-4af3e09096d1@github.com>

In order to reduce the noise in the JDK17 CI, I'm ProblemListing
serviceability/sa/TestJmapCoreMetaspace.java with ZGC.

It has been already added for macosx-x64 and for linux-x64, but we saw same problem on Windows. So we need to add it for all platforms.

-------------

Commit messages:
 - 8269265: ProblemList serviceability/sa/TestJmapCoreMetaspace.java with ZGC

Changes: https://git.openjdk.java.net/jdk17/pull/131/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=131&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269265
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/131.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/131/head:pull/131

PR: https://git.openjdk.java.net/jdk17/pull/131

From cjplummer at openjdk.java.net  Thu Jun 24 04:15:33 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 24 Jun 2021 04:15:33 GMT
Subject: [jdk17] RFR: 8269265: ProblemList
 serviceability/sa/TestJmapCoreMetaspace.java with ZGC
In-Reply-To: <YfXvud_VfgdQKaJDKc1_5kY2TzzpqPZtBPoLLWjPs9U=.5d8532d0-c43c-41e4-bc61-4af3e09096d1@github.com>
References: <YfXvud_VfgdQKaJDKc1_5kY2TzzpqPZtBPoLLWjPs9U=.5d8532d0-c43c-41e4-bc61-4af3e09096d1@github.com>
Message-ID: <nyQYHDLZD_jIlW9CAcNdFOLNreCwmrHaQzPuiArXob0=.defb0542-fdf4-4709-b22d-cc21c6b7da6e@github.com>

On Thu, 24 Jun 2021 03:03:47 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In order to reduce the noise in the JDK17 CI, I'm ProblemListing
> serviceability/sa/TestJmapCoreMetaspace.java with ZGC.
> 
> It has been already added for macosx-x64 and for linux-x64, but we saw same problem on Windows. So we need to add it for all platforms.

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/131

From ysuenaga at openjdk.java.net  Thu Jun 24 05:22:31 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 24 Jun 2021 05:22:31 GMT
Subject: [jdk17] Integrated: 8269265: ProblemList
 serviceability/sa/TestJmapCoreMetaspace.java with ZGC
In-Reply-To: <YfXvud_VfgdQKaJDKc1_5kY2TzzpqPZtBPoLLWjPs9U=.5d8532d0-c43c-41e4-bc61-4af3e09096d1@github.com>
References: <YfXvud_VfgdQKaJDKc1_5kY2TzzpqPZtBPoLLWjPs9U=.5d8532d0-c43c-41e4-bc61-4af3e09096d1@github.com>
Message-ID: <jbXXmU_ftN26v5oNtf-FcljpC8RGklCer9zHWQW4oIY=.fb964d42-ca2b-4bda-bae5-f7984281aa8c@github.com>

On Thu, 24 Jun 2021 03:03:47 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In order to reduce the noise in the JDK17 CI, I'm ProblemListing
> serviceability/sa/TestJmapCoreMetaspace.java with ZGC.
> 
> It has been already added for macosx-x64 and for linux-x64, but we saw same problem on Windows. So we need to add it for all platforms.

This pull request has now been integrated.

Changeset: d3d3b221
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/d3d3b221d3ae8de21c42749f48343fe2d49cdeee
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269265: ProblemList serviceability/sa/TestJmapCoreMetaspace.java with ZGC

Reviewed-by: cjplummer

-------------

PR: https://git.openjdk.java.net/jdk17/pull/131

From cjplummer at openjdk.java.net  Thu Jun 24 05:25:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 24 Jun 2021 05:25:38 GMT
Subject: RFR: 8269268: JDWP: Properly fix thread lookup assert in findThread()
Message-ID: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>

Re-enable the assert that was disabled (with some overhead) by [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation is in the CR and also in comments included with the changes.

I tested by running `vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java` and `vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java` 100's of times, and did not see any failures. I also verified the original issue was still reproducible by temporarily not setting `gdata->handlingVMDeath = JNI_TRUE`, which did trigger the assert as expected.

-------------

Commit messages:
 - Fix minor comment typo.
 - Better fix for dealing with tls related assert

Changes: https://git.openjdk.java.net/jdk/pull/4580/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4580&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269268
  Stats: 39 lines in 3 files changed: 32 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4580.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4580/head:pull/4580

PR: https://git.openjdk.java.net/jdk/pull/4580

From dholmes at openjdk.java.net  Thu Jun 24 06:41:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Jun 2021 06:41:31 GMT
Subject: RFR: 8269268: JDWP: Properly fix thread lookup assert in
 findThread()
In-Reply-To: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
References: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
Message-ID: <kzK4QUXBtkp1WqI7DcGElDdZf9SjQmUO9AT793rqatY=.c1f2c26e-f667-40aa-86f8-38d56e31d288@github.com>

On Thu, 24 Jun 2021 05:17:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Re-enable the assert that was disabled (with some overhead) by [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation is in the CR and also in comments included with the changes.
> 
> I tested by running `vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java` and `vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java` 100's of times, and did not see any failures. I also verified the original issue was still reproducible by temporarily not setting `gdata->handlingVMDeath = JNI_TRUE`, which did trigger the assert as expected.

src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 1243:

> 1241: 
> 1242:     /* Setting this flag is needed for a very special case. See the reference in findThread(). */
> 1243:     gdata->handlingVMDeath = JNI_TRUE;

Is this used to communicate across different threads? If so then it needs to be at least volatile, but a more forceful memory-barrier may be needed on some platforms. I can't tell in what context findThread will be called after this has been set to true.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4580

From cjplummer at openjdk.java.net  Thu Jun 24 07:25:36 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 24 Jun 2021 07:25:36 GMT
Subject: RFR: 8269268: JDWP: Properly fix thread lookup assert in
 findThread()
In-Reply-To: <kzK4QUXBtkp1WqI7DcGElDdZf9SjQmUO9AT793rqatY=.c1f2c26e-f667-40aa-86f8-38d56e31d288@github.com>
References: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
 <kzK4QUXBtkp1WqI7DcGElDdZf9SjQmUO9AT793rqatY=.c1f2c26e-f667-40aa-86f8-38d56e31d288@github.com>
Message-ID: <-zTTvSmEiTuww0gQFNvzkJRbMogUJ7ozBGgTJGk5Z3o=.1199d70e-503a-43af-a489-b7f52ff0db6b@github.com>

On Thu, 24 Jun 2021 06:38:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Re-enable the assert that was disabled (with some overhead) by [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation is in the CR and also in comments included with the changes.
>> 
>> I tested by running `vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java` and `vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java` 100's of times, and did not see any failures. I also verified the original issue was still reproducible by temporarily not setting `gdata->handlingVMDeath = JNI_TRUE`, which did trigger the assert as expected.
>
> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 1243:
> 
>> 1241: 
>> 1242:     /* Setting this flag is needed for a very special case. See the reference in findThread(). */
>> 1243:     gdata->handlingVMDeath = JNI_TRUE;
> 
> Is this used to communicate across different threads? If so then it needs to be at least volatile, but a more forceful memory-barrier may be needed on some platforms. I can't tell in what context findThread will be called after this has been set to true.

I had an answer typed up for you, but I realized I need to think some things through a bit more, and it's getting late. I'll look into it some more tomorrow.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4580

From pconcannon at openjdk.java.net  Thu Jun 24 11:29:14 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 24 Jun 2021 11:29:14 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v2]
In-Reply-To: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
Message-ID: <Uo3M_pm59Hk9V-Mcqm50wBo9JmEsddGTP4pzdvUPp2o=.de9a0d93-11f6-4021-9dea-f83c2147d63b@github.com>

> Hi,
> 
> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
> 
> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
> 
> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
> 
> Kind regards,
> Patrick

Patrick Concannon 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 remote-tracking branch 'origin/master' into JDK-8253119
 - 8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4574/files
  - new: https://git.openjdk.java.net/jdk/pull/4574/files/1aa471c0..4f04b850

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4574&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4574&range=00-01

  Stats: 2308 lines in 25 files changed: 640 ins; 1527 del; 141 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4574/head:pull/4574

PR: https://git.openjdk.java.net/jdk/pull/4574

From pconcannon at openjdk.java.net  Thu Jun 24 11:44:23 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 24 Jun 2021 11:44:23 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v3]
In-Reply-To: <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
Message-ID: <K9LMt-nAzKerr2AAqNA6ioJCekOvE7rL_wdo-AvVt6o=.f66d80d0-6db6-4368-b3eb-8477ce210275@github.com>

On Wed, 23 Jun 2021 13:09:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume DatagramSocket L1043-L1049 (declaration/init of USE_PLAINDATAGRAMSOCKET) can be removed too.

USE_PLAINDATAGRAMSOCKET removed as requested. See 49125e7

> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 69:
> 
>> 67:  * This implementation attempts to be compatible with legacy PlainSocketImpl
>> 68:  * (removed in JDK18), including behavior and exceptions that are not specified by
>> 69:  * SocketImpl.
> 
> Maybe we should just drop this sentence and not attempt to replace it.

Comment removed. See 49125e7

> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 647:
> 
>> 645:             // set the address field to the given host address to keep
>> 646:             // compatibility with SocketImpl. When binding to 0.0.0.0
>> 647:             // then the actual local address will be ::0 when IPv6 is enabled.
> 
> I don't think "SocketImpl" works here. Maybe replace "keep compatibility with PlainSocketImpl" with "to maintain long standing behavior".

Wording replaced as suggested. See 49125e7

> src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c line 269:
> 
>> 267: 
>> 268: /*
>> 269:  * Below Adapted from PlainSocketImpl.c (removed in JDK18), win32 version 1.18.
> 
> I think we'll need decide whether to keep this comment or not, I would be tempted to re-write it.

I've removed the comment after discussing this offline. See 49125e7

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From pconcannon at openjdk.java.net  Thu Jun 24 11:44:24 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 24 Jun 2021 11:44:24 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v3]
In-Reply-To: <C0_qehGuP6IUynXRu6HgODw3aY8hBwjY9eZX_WaOdlk=.344a36ee-d48f-4e53-9005-1e6ac2a19386@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
 <LW8h9nm9ZSwyjK4k-KQegZKgMFpTV5r2KSHHttNUjd8=.2611d502-8f18-4db8-99cb-2a41e4d62378@github.com>
 <t8XY5rbqva5dxvDcjncITTcDfeznMzmvquDXPYMiFFw=.0034afdb-e667-4f97-85ea-02d34990d4b5@github.com>
 <KO_g07q53b3ROAqROlRsV1D9u4b0z6f3gOqyc1O3NQI=.271fe570-2d45-4e83-b5b7-97284009b020@github.com>
 <C0_qehGuP6IUynXRu6HgODw3aY8hBwjY9eZX_WaOdlk=.344a36ee-d48f-4e53-9005-1e6ac2a19386@github.com>
Message-ID: <Eeui6ncyEajp4gaMdDYVIm4zrmWiZcpD9-YOJ72JYJI=.ed442ec0-b2c3-4f8c-a40e-abac68a192c8@github.com>

On Wed, 23 Jun 2021 15:09:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman 
>> 
>> `protected DatagramSocket(DatagramSocketImpl  impl)` throws NPE if `impl` is `null`.
>> (this is covered by the blanket statement for NPE)
>> 
>> Do we really need to specify anything else since the global `setDatagramSocketImplFactory` method has been deprecated? I mean - though we still support it at the moment, using a `DatagramSocketImplFactory` is not recommended, and hopefully only old legacy code would be using that.
>
> Creating an issue to update DatagramSocketImplFactory.createDatagramSocketImpl to say that returning null leads to undefined behavior or DatagramSocket constructors throwing an error is fine, I wasn't suggesting we have to fix it here.

I've created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8269288

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From pconcannon at openjdk.java.net  Thu Jun 24 11:44:19 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 24 Jun 2021 11:44:19 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v3]
In-Reply-To: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
Message-ID: <22VE3tae-FDFYAqzPFaDLlnCkjW78jKsAN0bfj9O6tY=.4da60793-592a-4265-97c8-9cd7eb9d8561@github.com>

> Hi,
> 
> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
> 
> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
> 
> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8253119: Removed redundant comments and USE_PLAINDATAGRAMSOCKET from java/net/DatagramSocket

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4574/files
  - new: https://git.openjdk.java.net/jdk/pull/4574/files/4f04b850..49125e7e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4574&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4574&range=01-02

  Stats: 21 lines in 3 files changed: 0 ins; 19 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4574/head:pull/4574

PR: https://git.openjdk.java.net/jdk/pull/4574

From alanb at openjdk.java.net  Thu Jun 24 14:25:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 24 Jun 2021 14:25:29 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v3]
In-Reply-To: <Eeui6ncyEajp4gaMdDYVIm4zrmWiZcpD9-YOJ72JYJI=.ed442ec0-b2c3-4f8c-a40e-abac68a192c8@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
 <LW8h9nm9ZSwyjK4k-KQegZKgMFpTV5r2KSHHttNUjd8=.2611d502-8f18-4db8-99cb-2a41e4d62378@github.com>
 <t8XY5rbqva5dxvDcjncITTcDfeznMzmvquDXPYMiFFw=.0034afdb-e667-4f97-85ea-02d34990d4b5@github.com>
 <KO_g07q53b3ROAqROlRsV1D9u4b0z6f3gOqyc1O3NQI=.271fe570-2d45-4e83-b5b7-97284009b020@github.com>
 <C0_qehGuP6IUynXRu6HgODw3aY8hBwjY9eZX_WaOdlk=.344a36ee-d48f-4e53-9005-1e6ac2a19386@github.com>
 <Eeui6ncyEajp4gaMdDYVIm4zrmWiZcpD9-YOJ72JYJI=.ed442ec0-b2c3-4f8c-a40e-abac68a192c8@github.com>
Message-ID: <VDswy98FvGuXt9KQltdnJvY7FQwjP_WDqGVj7eeHIoo=.47a12890-16a7-4a26-ace9-bca89ee41ee3@github.com>

On Thu, 24 Jun 2021 11:39:02 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> I've created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8269288

Thanks. So are you keeping the Objects.requireNonNull here? If so then it should probably be the 2-arg version so that the message is clear that the custom DatagramSocketFactory returned null, otherwise it will look like a DS bug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From dcubed at openjdk.java.net  Thu Jun 24 15:08:30 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 15:08:30 GMT
Subject: RFR: 8268433: serviceability/dcmd/framework/VMVersionTest.java
 fails with Unable to send object throw not established PipeIO Listener Thread
 connection
In-Reply-To: <5J2T-hre5T59rnjBUxO3ByBlhtn5RYhMZ8YcyVzAEdM=.081e021f-ae4e-4e01-8ffa-b35cc9cc8630@github.com>
References: <SD6Nnd9iPQNlrIqiuVgzmisqu6qfUiw5ainnhDw_W3I=.60bf8851-c4e8-4cd1-b893-b6fbcf18fc20@github.com>
 <hRcMJ0V3BtEaEZrbxKFb-GWmeHMPko_AVNWqUxWeSAA=.bd521f7d-2ab3-4ede-b39f-6da3f32eace0@github.com>
 <5J2T-hre5T59rnjBUxO3ByBlhtn5RYhMZ8YcyVzAEdM=.081e021f-ae4e-4e01-8ffa-b35cc9cc8630@github.com>
Message-ID: <QW-CyuKWHeB9pAeIrLeFMGrz1PIcUGfGWf5LDs1TdVI=.a13acd45-0f67-41b2-b2ce-bd0ac3221003@github.com>

On Wed, 23 Jun 2021 23:55:04 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Doesn't this just result in seeing a WARNING message instead of the failure described in JDK-8268433? Or do you still expect the test to fail, but to give other useful information.
>
>> 
>> 
>> Doesn't this just result in seeing a WARNING message instead of the failure described in JDK-8268433? Or do you still expect the test to fail, but to give other useful information.
> 
> Yes, I expect that the tests continue to fail, but with this fix we should see real error.

@alexmenkov - please see the new bug I just filed:

    JDK-8269302 serviceability/dcmd/framework/InvalidCommandTest.java still fails after JDK-8268433

Hopefully this new sighting has the info you are looking for.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4532

From dfuchs at openjdk.java.net  Thu Jun 24 15:11:27 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 24 Jun 2021 15:11:27 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v3]
In-Reply-To: <VDswy98FvGuXt9KQltdnJvY7FQwjP_WDqGVj7eeHIoo=.47a12890-16a7-4a26-ace9-bca89ee41ee3@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
 <LW8h9nm9ZSwyjK4k-KQegZKgMFpTV5r2KSHHttNUjd8=.2611d502-8f18-4db8-99cb-2a41e4d62378@github.com>
 <t8XY5rbqva5dxvDcjncITTcDfeznMzmvquDXPYMiFFw=.0034afdb-e667-4f97-85ea-02d34990d4b5@github.com>
 <KO_g07q53b3ROAqROlRsV1D9u4b0z6f3gOqyc1O3NQI=.271fe570-2d45-4e83-b5b7-97284009b020@github.com>
 <C0_qehGuP6IUynXRu6HgODw3aY8hBwjY9eZX_WaOdlk=.344a36ee-d48f-4e53-9005-1e6ac2a19386@github.com>
 <Eeui6ncyEajp4gaMdDYVIm4zrmWiZcpD9-YOJ72JYJI=.ed442ec0-b2c3-4f8c-a40e-abac68a192c8@github.com>
 <VDswy98FvGuXt9KQltdnJvY7FQwjP_WDqGVj7eeHIoo=.47a12890-16a7-4a26-ace9-bca89ee41ee3@github.com>
Message-ID: <1hi5OyHtcomCv4zK5SB49OVCZMzHrEuwNpJ9lDFCPKA=.67f6acd3-5103-4aad-a42b-44007d58c59b@github.com>

On Thu, 24 Jun 2021 14:22:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I've created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8269288
>
>> I've created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8269288
> 
> Thanks. So are you keeping the Objects.requireNonNull here? If so then it should probably be the 2-arg version so that the message is clear that the custom DatagramSocketFactory returned null, otherwise it will look like a DS bug.

@AlanBateman Ah - good idea - something like "implementation returned by installed DatagramSocketFactoryImpl is null"?
Maybe we could add the name of the concrete DatagramSocketFactoryImpl class too?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From dfuchs at openjdk.java.net  Thu Jun 24 15:11:27 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 24 Jun 2021 15:11:27 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v3]
In-Reply-To: <22VE3tae-FDFYAqzPFaDLlnCkjW78jKsAN0bfj9O6tY=.4da60793-592a-4265-97c8-9cd7eb9d8561@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <22VE3tae-FDFYAqzPFaDLlnCkjW78jKsAN0bfj9O6tY=.4da60793-592a-4265-97c8-9cd7eb9d8561@github.com>
Message-ID: <Nx9RzhHjSPzta9RmAUjon9yQas_1kFMcTXnftWcvzOQ=.87f2507b-ec0d-4fc6-8317-b9988f6613ce@github.com>

On Thu, 24 Jun 2021 11:44:19 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>> 
>> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
>> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
>> 
>> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253119: Removed redundant comments and USE_PLAINDATAGRAMSOCKET from java/net/DatagramSocket

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From chegar at openjdk.java.net  Thu Jun 24 15:21:32 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 24 Jun 2021 15:21:32 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v3]
In-Reply-To: <22VE3tae-FDFYAqzPFaDLlnCkjW78jKsAN0bfj9O6tY=.4da60793-592a-4265-97c8-9cd7eb9d8561@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <22VE3tae-FDFYAqzPFaDLlnCkjW78jKsAN0bfj9O6tY=.4da60793-592a-4265-97c8-9cd7eb9d8561@github.com>
Message-ID: <JyR_DEuP3Kjm3bXO8o65cZakc_KUDTx6jHHdQvI3vn8=.288964b7-6d5a-44b7-9e88-3545f90a7327@github.com>

On Thu, 24 Jun 2021 11:44:19 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>> 
>> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
>> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
>> 
>> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253119: Removed redundant comments and USE_PLAINDATAGRAMSOCKET from java/net/DatagramSocket

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From cjplummer at openjdk.java.net  Thu Jun 24 16:29:27 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 24 Jun 2021 16:29:27 GMT
Subject: RFR: 8269268: JDWP: Properly fix thread lookup assert in
 findThread()
In-Reply-To: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
References: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
Message-ID: <3YXSYPwD4XEH1tuaH5MGH-9_XiRpuIH9EzbNV-c52Gk=.7de423c1-6f39-46a2-89ce-b41469343c9b@github.com>

On Thu, 24 Jun 2021 05:17:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Re-enable the assert that was disabled (with some overhead) by [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation is in the CR and also in comments included with the changes.
> 
> I tested by running `vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java` and `vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java` 100's of times, and did not see any failures. I also verified the original issue was still reproducible by temporarily not setting `gdata->handlingVMDeath = JNI_TRUE`, which did trigger the assert as expected.

There are two threads to consider here. The one that `VM_DEATH` was received on and the thread that reads JDWP commands from the debugger. For the latter, a `VM.Resume` command has been received. The debugger does this as the test wraps up, allowing all debuggee threads to resume and the debugeee to exit. `VM.resume()` calls `threadControl_resumeAll()`, which calls `commonResumeList()`, which walks the `runningThreads` list to build an array of jthreads that need to be resumed. This array is passed to JVMTI `ResumeThreadList()`. Any time after this point a `VM_DEATH` can be triggered since the debuggee main thread calls `System.exit()` and does not wait for all the threads it creates to exit first (no join is done). The `VM_DEATH` event leads to clearing all the JVMTI callbacks, so the debug agent is no longer notified of `THREAD_END` events as the other threads created by the debuggee exit. This leads to threads still being on `runningThreads`, even though they have exited and had t
 heir TLS cleared by JVMTI. Keep in mind we are still in `commonResumeList()` when all this is happening. After calling JVMTI `ResumeThreadList()`, it then walks that same array of jthreads that were resumed, doing a `findThread()` on each. This is done mainly so it can update the `suspendCount` the `ThreadNodes`. This is when the assert was getting triggered. Some of the debuggee threads had already exited and had their TLS cleared, but were still in `runningThreads` since the `THREAD_END` was never received. The fix is to not assert (and instead look up the thread in `runningThreads`) if we are dealing with a `VM_DEATH` event.

You mentioned `gdata->handlingVMDeath` should be volatile. I will fix that. I also think I will rename it to `gdata->jvmtiCallBacksCleared`. There is no need to ever set it back false, so I will remove that line of code. Once true, we know the vm is exiting anyway, and the callbacks will never be setup again. Also, I'm going to set it true before actually clearing the callbacks rather than after. Doing it early is fine. In fact if it was always true, `findThread()` would still work, but just be slower.

As far as any other synchronizing or memory barriers being needed, I'm a bit unclear on that part. The only thing that matters is that `gdata->jvmtiCallBacksCleared` being set true is visible to other threads before the callbacks get cleared. It seems the call to `SetEventCallbacks()` should ensure this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4580

From cjplummer at openjdk.java.net  Thu Jun 24 16:51:59 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 24 Jun 2021 16:51:59 GMT
Subject: RFR: 8269268: JDWP: Properly fix thread lookup assert in
 findThread() [v2]
In-Reply-To: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
References: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
Message-ID: <9f0X6MVyTIMTlk17Mqf2QDNeRk8mE7IM1yHvCwg-2lw=.7873ff96-cca0-43ea-9d4b-58a866710a78@github.com>

> Re-enable the assert that was disabled (with some overhead) by [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation is in the CR and also in comments included with the changes.
> 
> I tested by running `vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java` and `vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java` 100's of times, and did not see any failures. I also verified the original issue was still reproducible by temporarily not setting `gdata->handlingVMDeath = JNI_TRUE`, which did trigger the assert as expected.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Rename flag and make some minor adjustments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4580/files
  - new: https://git.openjdk.java.net/jdk/pull/4580/files/7d4a57d3..6e0e54a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4580&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4580&range=00-01

  Stats: 17 lines in 3 files changed: 5 ins; 6 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4580.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4580/head:pull/4580

PR: https://git.openjdk.java.net/jdk/pull/4580

From ccheung at openjdk.java.net  Thu Jun 24 18:59:39 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 18:59:39 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
Message-ID: <55lMJ0OoZXGfcUmuOPMVLuPCcVixWcQhCTv8FFfBvgc=.50f74390-a8f7-44ff-998d-7c5f165207cb@github.com>

On Thu, 24 Jun 2021 18:51:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.

One question.

test/hotspot/jtreg/ProblemList.txt line 113:

> 111: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatArrayCorrectnessTest.java 8224150 generic-all
> 112: serviceability/jvmti/ModuleAwareAgents/ThreadStart/MAAThreadStart.java 8225354 windows-all
> 113: serviceability/dcmd/gc/RunFinalizationTest.java 8227120 linux-all,windows-x64

Should linux-all be linux-aarch64?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From dcubed at openjdk.java.net  Thu Jun 24 18:59:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 18:59:39 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
Message-ID: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>

A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.

-------------

Commit messages:
 - 8269314: ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64

Changes: https://git.openjdk.java.net/jdk17/pull/138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=138&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269314
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/138/head:pull/138

PR: https://git.openjdk.java.net/jdk17/pull/138

From ccheung at openjdk.java.net  Thu Jun 24 19:10:27 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 19:10:27 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
Message-ID: <QfqwLwbnyBEirHy7IWwyMl-3OQjJk8qZU2cnn6psS6E=.fc52b24b-6e6e-49ec-9fbb-7a8a5ce4e59b@github.com>

On Thu, 24 Jun 2021 18:51:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.

Marked as reviewed by ccheung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From dcubed at openjdk.java.net  Thu Jun 24 19:10:28 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 19:10:28 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <55lMJ0OoZXGfcUmuOPMVLuPCcVixWcQhCTv8FFfBvgc=.50f74390-a8f7-44ff-998d-7c5f165207cb@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
 <55lMJ0OoZXGfcUmuOPMVLuPCcVixWcQhCTv8FFfBvgc=.50f74390-a8f7-44ff-998d-7c5f165207cb@github.com>
Message-ID: <luUE_zrOtjlnEoZazqaVS9mUh0eH7K3aVkROIQZCjj4=.7b144e1a-504c-4491-852f-1a939d7a6628@github.com>

On Thu, 24 Jun 2021 18:56:23 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.
>
> test/hotspot/jtreg/ProblemList.txt line 113:
> 
>> 111: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatArrayCorrectnessTest.java 8224150 generic-all
>> 112: serviceability/jvmti/ModuleAwareAgents/ThreadStart/MAAThreadStart.java 8225354 windows-all
>> 113: serviceability/dcmd/gc/RunFinalizationTest.java 8227120 linux-all,windows-x64
> 
> Should linux-all be linux-aarch64?

No, the entry was previously linux-x64 so I've changed it to linux-all to
cover linux-x64 and linux-aarch64.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From ccheung at openjdk.java.net  Thu Jun 24 19:10:28 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 24 Jun 2021 19:10:28 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <luUE_zrOtjlnEoZazqaVS9mUh0eH7K3aVkROIQZCjj4=.7b144e1a-504c-4491-852f-1a939d7a6628@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
 <55lMJ0OoZXGfcUmuOPMVLuPCcVixWcQhCTv8FFfBvgc=.50f74390-a8f7-44ff-998d-7c5f165207cb@github.com>
 <luUE_zrOtjlnEoZazqaVS9mUh0eH7K3aVkROIQZCjj4=.7b144e1a-504c-4491-852f-1a939d7a6628@github.com>
Message-ID: <Waq3nYLMlHq7CRCQxrMY6FnHtR2nkuuE-jsO2jKMrbw=.6b738c50-815d-4ad0-a360-1ec34eb0b181@github.com>

On Thu, 24 Jun 2021 19:04:05 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/ProblemList.txt line 113:
>> 
>>> 111: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatArrayCorrectnessTest.java 8224150 generic-all
>>> 112: serviceability/jvmti/ModuleAwareAgents/ThreadStart/MAAThreadStart.java 8225354 windows-all
>>> 113: serviceability/dcmd/gc/RunFinalizationTest.java 8227120 linux-all,windows-x64
>> 
>> Should linux-all be linux-aarch64?
>
> No, the entry was previously linux-x64 so I've changed it to linux-all to
> cover linux-x64 and linux-aarch64.

Looks good and trivial then.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From dcubed at openjdk.java.net  Thu Jun 24 19:21:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 19:21:34 GMT
Subject: [jdk17] RFR: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <QfqwLwbnyBEirHy7IWwyMl-3OQjJk8qZU2cnn6psS6E=.fc52b24b-6e6e-49ec-9fbb-7a8a5ce4e59b@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
 <QfqwLwbnyBEirHy7IWwyMl-3OQjJk8qZU2cnn6psS6E=.fc52b24b-6e6e-49ec-9fbb-7a8a5ce4e59b@github.com>
Message-ID: <mbmMW55hQEr0eMxrSg18oJsKA8dCzv27vitf2dK0Px4=.21da31db-1090-40a8-9753-c690af6432b5@github.com>

On Thu, 24 Jun 2021 19:07:09 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.
>
> Marked as reviewed by ccheung (Reviewer).

@calvinccheung - Thanks for the fast review (and the sanity check).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From dcubed at openjdk.java.net  Thu Jun 24 20:30:11 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 24 Jun 2021 20:30:11 GMT
Subject: [jdk17] Integrated: 8269314: ProblemList
 serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64
In-Reply-To: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
References: <0J5R765C1uxAuOUb0rFBBS9EZB5ejQFWpB9oSPgsWxo=.8659dc4e-55d6-4806-be3d-5455aad5992a@github.com>
Message-ID: <moyr7X1M6UOznTCthPD2DjlJCBpbKh_hD-3hxOsZRmg=.6521d048-7b2b-4f15-a297-bcac3fc2fa4f@github.com>

On Thu, 24 Jun 2021 18:51:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64.

This pull request has now been integrated.

Changeset: 443a79aa
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/443a79aaa191953e948e4732400c58e1311c3673
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269314: ProblemList serviceability/dcmd/gc/RunFinalizationTest.java on Win-X64 and linux-aarch64

Reviewed-by: ccheung

-------------

PR: https://git.openjdk.java.net/jdk17/pull/138

From amenkov at openjdk.java.net  Fri Jun 25 04:33:15 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 25 Jun 2021 04:33:15 GMT
Subject: RFR: 8269302: serviceability/dcmd/framework/InvalidCommandTest.java
 still fails after JDK-8268433
Message-ID: <QWp2zFMVzdT-MSwgosydTYt7WRf9q6kkbDkOf9fOBCM=.f6cf8bc8-c444-4785-b5e5-cc167b881340@github.com>

Please review this trivial fix in the cycle condition.

The cycle should run until connection is established (connection.isConnected() returns true) or error occurred (error != null)
This wrong condition causes test error if ListenerThread.getConnection() reaches "synchronized (this)" section earlier than ListenerThread.run()

-------------

Commit messages:
 - Fixed cycle condition in ListenerThread.getConnection

Changes: https://git.openjdk.java.net/jdk/pull/4593/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4593&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269302
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4593.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4593/head:pull/4593

PR: https://git.openjdk.java.net/jdk/pull/4593

From dholmes at openjdk.java.net  Fri Jun 25 04:58:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 25 Jun 2021 04:58:01 GMT
Subject: RFR: 8269302:
 serviceability/dcmd/framework/InvalidCommandTest.java still fails after
 JDK-8268433
In-Reply-To: <QWp2zFMVzdT-MSwgosydTYt7WRf9q6kkbDkOf9fOBCM=.f6cf8bc8-c444-4785-b5e5-cc167b881340@github.com>
References: <QWp2zFMVzdT-MSwgosydTYt7WRf9q6kkbDkOf9fOBCM=.f6cf8bc8-c444-4785-b5e5-cc167b881340@github.com>
Message-ID: <hJPasn679-MFI6AD6q1QtYqyWscaCXUDRtBOyfdgZcM=.48e5abee-e48b-4832-aae2-e56832287b2a@github.com>

On Fri, 25 Jun 2021 04:25:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Please review this trivial fix in the cycle condition.
> 
> The cycle should run until connection is established (connection.isConnected() returns true) or error occurred (error != null)
> This wrong condition causes test error if ListenerThread.getConnection() reaches "synchronized (this)" section earlier than ListenerThread.run()

Good catch!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4593

From stuefe at openjdk.java.net  Fri Jun 25 05:37:03 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Jun 2021 05:37:03 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
Message-ID: <An16hOY2P8rV5keHrGk6bxMBROBE8hP5MK0hp1wK61w=.c449257b-2bf5-4048-b99f-fa85256c861e@github.com>

On Thu, 17 Jun 2021 08:53:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> If this finds agreement, I will file a CSR.
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Severin; renamed query function

Hi,

I created the CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345

When you have time, please take a look. Thank you.

..Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From stuefe at openjdk.java.net  Fri Jun 25 06:03:07 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Jun 2021 06:03:07 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v2]
In-Reply-To: <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <XiUZZjwJwKq04aHpMV7xgJgpBrcKvP_miEVJpGRnjLE=.306be017-1533-493a-8d57-153b33369164@github.com>
 <rnu-U-1r8zUk-5fUakS9uOjcD1gdgZxSE0WZQmUbkPo=.1cab608b-6a13-4ac8-8475-4d3f697f4916@github.com>
Message-ID: <0U_Ii4mfxbkFrc8kbWtN8uEaaN6SX8WnPWqNhcv-O0g=.518601c8-81ff-4d06-ad13-f26d2c71d3f2@github.com>

On Mon, 21 Jun 2021 08:25:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback Severin; renamed query function
>
> src/hotspot/os/linux/os_linux.cpp line 2142:
> 
>> 2140: bool os::Linux::query_process_memory_info(os::Linux::meminfo_t* info) {
>> 2141:   FILE* f = ::fopen("/proc/self/status", "r");
>> 2142:   const int num_values = 8;
> 
> Refactoring of `os::Linux::print_process_memory_info` looks good. But now that you've already created `os::Linux::meminfo_t` anyway I'd suggest to make `num_values == sizeof(os::Linux::meminfo_t)/sizeof(ssize_t)`.

Okay, makes sense. I was a bit apprehensive since that relies on the internal layout of this structure. But OTOH if that number is wrong, the worst that happens is that we, each time, parse through the whole of /proc/self/status instead of stopping early when all data are found. Which may happen anyway since not all kernels support all of these data.

> src/hotspot/share/services/diagnosticCommand.cpp line 99:
> 
>> 97:   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<HeapInfoDCmd>(full_export, true, false));
>> 98:   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<FinalizerInfoDCmd>(full_export, true, false));
>> 99:   LINUX_ONLY(DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<TrimCLibcHeapDCmd>(full_export, true, false));)
> 
> Not sure if the commands are really sorted and if order is important here. Otherwise you could add the new command a few lines later where there already exists an `#ifdef LINUX` section:
> 
> 
> #ifdef LINUX
>   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<PerfMapDCmd>(full_export, true, false));
>   DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<TrimCLibcHeapDCmd>(full_export, true, false));
> #endif // LINUX

I don't think order matters, and grouping linux specific commands looks better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4510

From stuefe at openjdk.java.net  Fri Jun 25 06:22:37 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Jun 2021 06:22:37 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v3]
In-Reply-To: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
Message-ID: <NDjsBIfcu8h-e21OTEioLI1pMeNgVzQmywL_1sD_JHk=.1daadc62-0a09-45b1-805a-0da9849ffc65@github.com>

> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
> 
> 
> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
> 
> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
> 
> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
> 
> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
> 
> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
> - as a stop gap measure it allows to release pressure from a high footprint scenario.
> 
> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
> 
> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
> 
> If this finds agreement, I will file a CSR.
> 
> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
> 
> =========
> 
> This patch:
> 
> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
> - includes a (rather basic) test
> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
> 
> =========
> 
> Example:
> 
> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
> 
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>                    ^^^^^^^^
> 
> 
> We execute the new trim command via jcmd:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
> 18770:
> Attempting trim...
> Done.
> Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
> Swap before: 0k, after: 0k, (0k)
> 
> 
> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
> 
> 
> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>                    ^^^^^^^
> 
> 
> When the VM is started with -Xlog:os, this is also logged:
> 
> 
> [139,068s][info][os] malloc_trim:
> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
> RSS before: 8685896k, after: 920740k, (-7765156k)
> Swap before: 0k, after: 0k, (0k)

Thomas Stuefe 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:

 - Volker feedback
 - Merge
 - Feedback Severin; renamed query function
 - start

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4510/files
  - new: https://git.openjdk.java.net/jdk/pull/4510/files/a48791e4..29807b26

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4510&range=01-02

  Stats: 28324 lines in 497 files changed: 16225 ins; 10712 del; 1387 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4510.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4510/head:pull/4510

PR: https://git.openjdk.java.net/jdk/pull/4510

From lzang at openjdk.java.net  Fri Jun 25 08:05:11 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 25 Jun 2021 08:05:11 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v27]
In-Reply-To: <MXonlUa56ZacBQh36BTp_dL0HVej4tUYFx_m7WZhOa8=.12001f9b-58ae-49e9-a1f7-b66c006e5de8@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <MXonlUa56ZacBQh36BTp_dL0HVej4tUYFx_m7WZhOa8=.12001f9b-58ae-49e9-a1f7-b66c006e5de8@github.com>
Message-ID: <NnEymx3Sa1D7rsIbSRemj40FD_cFZnstaFIp2X7ZXzs=.ed90a175-0575-4653-ba98-be41068441b1@github.com>

On Mon, 7 Jun 2021 07:58:26 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 36 commits:
> 
>  - Merge branch 'master' into par-dump
>  - Merge branch 'master' into par-dump
>  - 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
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/908aca29...78c2c763

Dear All? Sorry for not updating this PR for quite a while. I will try to add detailed explaination of the implementation here to make it easier to be reviewed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From kevinw at openjdk.java.net  Fri Jun 25 08:50:01 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 25 Jun 2021 08:50:01 GMT
Subject: RFR: 8269302:
 serviceability/dcmd/framework/InvalidCommandTest.java still fails after
 JDK-8268433
In-Reply-To: <QWp2zFMVzdT-MSwgosydTYt7WRf9q6kkbDkOf9fOBCM=.f6cf8bc8-c444-4785-b5e5-cc167b881340@github.com>
References: <QWp2zFMVzdT-MSwgosydTYt7WRf9q6kkbDkOf9fOBCM=.f6cf8bc8-c444-4785-b5e5-cc167b881340@github.com>
Message-ID: <HENGelpeJgu4-P3LEl3fSXqAglRIpHhurQr7rCPp3WE=.3cb97a44-fb2c-4fa9-a544-f7cef76911ff@github.com>

On Fri, 25 Jun 2021 04:25:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Please review this trivial fix in the cycle condition.
> 
> The cycle should run until connection is established (connection.isConnected() returns true) or error occurred (error != null)
> This wrong condition causes test error if ListenerThread.getConnection() reaches "synchronized (this)" section earlier than ListenerThread.run()

Marked as reviewed by kevinw (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4593

From kevinw at openjdk.java.net  Fri Jun 25 09:43:06 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 25 Jun 2021 09:43:06 GMT
Subject: RFR: 8269268: JDWP: Properly fix thread lookup assert in
 findThread() [v2]
In-Reply-To: <9f0X6MVyTIMTlk17Mqf2QDNeRk8mE7IM1yHvCwg-2lw=.7873ff96-cca0-43ea-9d4b-58a866710a78@github.com>
References: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
 <9f0X6MVyTIMTlk17Mqf2QDNeRk8mE7IM1yHvCwg-2lw=.7873ff96-cca0-43ea-9d4b-58a866710a78@github.com>
Message-ID: <hkQp6PY-tCuFkji2DyhERxNODaYr_W9sJBwjTTkQIxs=.59ad46af-30db-4648-95b9-8d57ec83b9e9@github.com>

On Thu, 24 Jun 2021 16:51:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Re-enable the assert that was disabled (with some overhead) by [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation is in the CR and also in comments included with the changes.
>> 
>> I tested by running `vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java` and `vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java` 100's of times, and did not see any failures. I also verified the original issue was still reproducible by temporarily not setting `gdata->handlingVMDeath = JNI_TRUE`, which did trigger the assert as expected.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename flag and make some minor adjustments.

Marked as reviewed by kevinw (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4580

From pconcannon at openjdk.java.net  Fri Jun 25 10:25:52 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 25 Jun 2021 10:25:52 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v4]
In-Reply-To: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
Message-ID: <our_gwY_FfFhWxfXPg7gCOLqwr7MFpFu0g716Rkfg8w=.9b9d2666-75a2-4a99-956f-c3440f225c46@github.com>

> Hi,
> 
> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
> 
> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
> 
> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
> 
> Kind regards,
> Patrick

Patrick Concannon 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:

 - 8253119: Added message to null check in java/net/DatagramSocket
 - Merge remote-tracking branch 'origin/master' into JDK-8253119
 - 8253119: Removed redundant comments and USE_PLAINDATAGRAMSOCKET from java/net/DatagramSocket
 - Merge remote-tracking branch 'origin/master' into JDK-8253119
 - 8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4574/files
  - new: https://git.openjdk.java.net/jdk/pull/4574/files/49125e7e..36bcee31

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4574&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4574&range=02-03

  Stats: 7050 lines in 209 files changed: 1681 ins; 5063 del; 306 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4574/head:pull/4574

PR: https://git.openjdk.java.net/jdk/pull/4574

From pconcannon at openjdk.java.net  Fri Jun 25 10:25:53 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 25 Jun 2021 10:25:53 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v4]
In-Reply-To: <1hi5OyHtcomCv4zK5SB49OVCZMzHrEuwNpJ9lDFCPKA=.67f6acd3-5103-4aad-a42b-44007d58c59b@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <H5a8tBoBGCAaVGJg4sVH52EX_wLDpCvoBUmlesm51zo=.a2d91038-12ae-46b8-b020-96a679c8076b@github.com>
 <LW8h9nm9ZSwyjK4k-KQegZKgMFpTV5r2KSHHttNUjd8=.2611d502-8f18-4db8-99cb-2a41e4d62378@github.com>
 <t8XY5rbqva5dxvDcjncITTcDfeznMzmvquDXPYMiFFw=.0034afdb-e667-4f97-85ea-02d34990d4b5@github.com>
 <KO_g07q53b3ROAqROlRsV1D9u4b0z6f3gOqyc1O3NQI=.271fe570-2d45-4e83-b5b7-97284009b020@github.com>
 <C0_qehGuP6IUynXRu6HgODw3aY8hBwjY9eZX_WaOdlk=.344a36ee-d48f-4e53-9005-1e6ac2a19386@github.com>
 <Eeui6ncyEajp4gaMdDYVIm4zrmWiZcpD9-YOJ72JYJI=.ed442ec0-b2c3-4f8c-a40e-abac68a192c8@github.com>
 <VDswy98FvGuXt9KQltdnJvY7FQwjP_WDqGVj7eeHIoo=.47a12890-16a7-4a26-ace9-bca89ee41ee3@github.com>
 <1hi5OyHtcomCv4zK5SB49OVCZMzHrEuwNpJ9lDFCPKA=.67f6acd3-5103-4aad-a42b-44007d58c59b@github.com>
Message-ID: <qMIZ__Q1PtjPSqH8Y4DMQDVgtXYtd6fWg6CpgkNvOKQ=.f706f95b-0652-443a-b2b5-7ccbbe0de0d8@github.com>

On Thu, 24 Jun 2021 15:06:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> I've created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8269288
>> 
>> Thanks. So are you keeping the Objects.requireNonNull here? If so then it should probably be the 2-arg version so that the message is clear that the custom DatagramSocketFactory returned null, otherwise it will look like a DS bug.
>
> @AlanBateman Ah - good idea - something like "implementation returned by installed DatagramSocketFactoryImpl is null"?
> Maybe we could add the name of the concrete DatagramSocketFactoryImpl class too?

OK. I've added a message to the null check now. See 36bcee3

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From dfuchs at openjdk.java.net  Fri Jun 25 10:36:09 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 25 Jun 2021 10:36:09 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v4]
In-Reply-To: <our_gwY_FfFhWxfXPg7gCOLqwr7MFpFu0g716Rkfg8w=.9b9d2666-75a2-4a99-956f-c3440f225c46@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <our_gwY_FfFhWxfXPg7gCOLqwr7MFpFu0g716Rkfg8w=.9b9d2666-75a2-4a99-956f-c3440f225c46@github.com>
Message-ID: <grVRVASfgQt0l3eP7LKxeMDWkh-z_CJt9Vu05vojI10=.cea778d2-e98b-4892-bdb8-699241581049@github.com>

On Fri, 25 Jun 2021 10:25:52 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>> 
>> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
>> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
>> 
>> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon 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:
> 
>  - 8253119: Added message to null check in java/net/DatagramSocket
>  - Merge remote-tracking branch 'origin/master' into JDK-8253119
>  - 8253119: Removed redundant comments and USE_PLAINDATAGRAMSOCKET from java/net/DatagramSocket
>  - Merge remote-tracking branch 'origin/master' into JDK-8253119
>  - 8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From alanb at openjdk.java.net  Fri Jun 25 10:59:10 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 25 Jun 2021 10:59:10 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v4]
In-Reply-To: <our_gwY_FfFhWxfXPg7gCOLqwr7MFpFu0g716Rkfg8w=.9b9d2666-75a2-4a99-956f-c3440f225c46@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <our_gwY_FfFhWxfXPg7gCOLqwr7MFpFu0g716Rkfg8w=.9b9d2666-75a2-4a99-956f-c3440f225c46@github.com>
Message-ID: <Ss-232sRfRG-9L04SF-a8WkYDK-PRjwGlkWqFaNFLpk=.373f6dcd-a232-41ee-9441-4e5e595072ea@github.com>

On Fri, 25 Jun 2021 10:25:52 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>> 
>> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
>> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
>> 
>> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon 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:
> 
>  - 8253119: Added message to null check in java/net/DatagramSocket
>  - Merge remote-tracking branch 'origin/master' into JDK-8253119
>  - 8253119: Removed redundant comments and USE_PLAINDATAGRAMSOCKET from java/net/DatagramSocket
>  - Merge remote-tracking branch 'origin/master' into JDK-8253119
>  - 8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation

src/java.base/share/classes/java/net/DatagramSocket.java line 1398:

> 1396:                 DatagramSocketImpl impl = factory.createDatagramSocketImpl();
> 1397:                 Objects.requireNonNull(impl,
> 1398:                         "Implementation returned by installed DatagramSocketFactoryImpl is null");

I think you mean "DatagramSocketFactoryImpl" rather than "DatagramSocketImplFactory" here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From dfuchs at openjdk.java.net  Fri Jun 25 11:41:04 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 25 Jun 2021 11:41:04 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v4]
In-Reply-To: <Ss-232sRfRG-9L04SF-a8WkYDK-PRjwGlkWqFaNFLpk=.373f6dcd-a232-41ee-9441-4e5e595072ea@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <our_gwY_FfFhWxfXPg7gCOLqwr7MFpFu0g716Rkfg8w=.9b9d2666-75a2-4a99-956f-c3440f225c46@github.com>
 <Ss-232sRfRG-9L04SF-a8WkYDK-PRjwGlkWqFaNFLpk=.373f6dcd-a232-41ee-9441-4e5e595072ea@github.com>
Message-ID: <u102xOpvmhLvz7DD1XYeabx_omw7_UcCCFgb-K53R9s=.de97616e-23e8-420c-b58c-d97bfb18c64b@github.com>

On Fri, 25 Jun 2021 10:56:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Patrick Concannon 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:
>> 
>>  - 8253119: Added message to null check in java/net/DatagramSocket
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253119
>>  - 8253119: Removed redundant comments and USE_PLAINDATAGRAMSOCKET from java/net/DatagramSocket
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253119
>>  - 8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation
>
> src/java.base/share/classes/java/net/DatagramSocket.java line 1398:
> 
>> 1396:                 DatagramSocketImpl impl = factory.createDatagramSocketImpl();
>> 1397:                 Objects.requireNonNull(impl,
>> 1398:                         "Implementation returned by installed DatagramSocketFactoryImpl is null");
> 
> I think you mean "DatagramSocketImplFactory" instead of "DatagramSocketFactoryImpl" here.

Yes - good catch! I've been bitten by this before too  :-) 
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/net/DatagramSocketImplFactory.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From pconcannon at openjdk.java.net  Fri Jun 25 11:48:52 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 25 Jun 2021 11:48:52 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v5]
In-Reply-To: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
Message-ID: <bhBtoiHkGBpFYcjI2qYPRGzjlEl93PDRWJfU02odpmo=.205eb1b6-3eda-46f6-845c-e6ecae20872a@github.com>

> Hi,
> 
> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
> 
> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
> 
> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8253119: Fixed typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4574/files
  - new: https://git.openjdk.java.net/jdk/pull/4574/files/36bcee31..686b4369

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4574&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4574&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4574/head:pull/4574

PR: https://git.openjdk.java.net/jdk/pull/4574

From pconcannon at openjdk.java.net  Fri Jun 25 11:48:53 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 25 Jun 2021 11:48:53 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v4]
In-Reply-To: <u102xOpvmhLvz7DD1XYeabx_omw7_UcCCFgb-K53R9s=.de97616e-23e8-420c-b58c-d97bfb18c64b@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <our_gwY_FfFhWxfXPg7gCOLqwr7MFpFu0g716Rkfg8w=.9b9d2666-75a2-4a99-956f-c3440f225c46@github.com>
 <Ss-232sRfRG-9L04SF-a8WkYDK-PRjwGlkWqFaNFLpk=.373f6dcd-a232-41ee-9441-4e5e595072ea@github.com>
 <u102xOpvmhLvz7DD1XYeabx_omw7_UcCCFgb-K53R9s=.de97616e-23e8-420c-b58c-d97bfb18c64b@github.com>
Message-ID: <RkIVXF80RPTrXXr8ziQf63Z-NCP4aFidrvMF252BomA=.caf39407-df9b-4918-8775-9d34821c8243@github.com>

On Fri, 25 Jun 2021 11:37:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/DatagramSocket.java line 1398:
>> 
>>> 1396:                 DatagramSocketImpl impl = factory.createDatagramSocketImpl();
>>> 1397:                 Objects.requireNonNull(impl,
>>> 1398:                         "Implementation returned by installed DatagramSocketFactoryImpl is null");
>> 
>> I think you mean "DatagramSocketImplFactory" instead of "DatagramSocketFactoryImpl" here.
>
> Yes - good catch! I've been bitten by this before too  :-) 
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/net/DatagramSocketImplFactory.html

Well spotted. Thanks Alan. Change made in commit 686b436

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From alanb at openjdk.java.net  Fri Jun 25 12:27:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 25 Jun 2021 12:27:07 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v5]
In-Reply-To: <bhBtoiHkGBpFYcjI2qYPRGzjlEl93PDRWJfU02odpmo=.205eb1b6-3eda-46f6-845c-e6ecae20872a@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <bhBtoiHkGBpFYcjI2qYPRGzjlEl93PDRWJfU02odpmo=.205eb1b6-3eda-46f6-845c-e6ecae20872a@github.com>
Message-ID: <VPqAWYst9nyiCGRoL_BuNRGT4ndlfyqQWZtZta0vQuA=.9af386ff-209e-4d13-8dd0-e24a375cd95e@github.com>

On Fri, 25 Jun 2021 11:48:52 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>> 
>> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
>> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
>> 
>> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253119: Fixed typo

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From dfuchs at openjdk.java.net  Fri Jun 25 13:14:03 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 25 Jun 2021 13:14:03 GMT
Subject: RFR: 8253119: Remove the legacy PlainSocketImpl and
 PlainDatagramSocketImpl implementation [v5]
In-Reply-To: <bhBtoiHkGBpFYcjI2qYPRGzjlEl93PDRWJfU02odpmo=.205eb1b6-3eda-46f6-845c-e6ecae20872a@github.com>
References: <ZceXxvb4Mw2_kmjYCpLlkgbQLqXek4zbfLy4rpkYXnA=.a38aec80-8338-4556-8786-12370864be59@github.com>
 <bhBtoiHkGBpFYcjI2qYPRGzjlEl93PDRWJfU02odpmo=.205eb1b6-3eda-46f6-845c-e6ecae20872a@github.com>
Message-ID: <z864rfp21HOlF0wbcZfCMSQ0ZZ0rqFL0Q9XRoBpi1No=.7745453d-4364-4d59-baeb-b24622014a33@github.com>

On Fri, 25 Jun 2021 11:48:52 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes for the removal of the legacy `PlainSocketImpl` and `PlainDatagramSocketImpl` implementations?
>> 
>> In JDK 13, JEP 353 provided a drop in replacement for the legacy `PlainSocketImpl` implementation. Since JDK 13, the `PlainSocketImpl` implementation was no longer used but included a mitigation mechanism to reduce compatibility risks in the form of a JDK-specific property `jdk.net.usePlainSocketImpl` allowing to switch back to the old implementation. 
>> Similarly, in JDK 15, JEP 373 provided a new implementation for `DatagramSocket` and `MulticastSocket`, with a JDK-specific property `jdk.net.usePlainDatagramSocketImpl` also allowing the user to switch back to the old implementation in case of compatibility issue.
>> 
>> As these implementations (and the mechanisms they use to enable them to mitigate compatibility issues) have been deemed no longer necessary, they now represent a maintenance burden. This patch looks at removing them from the JDK.
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253119: Fixed typo

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4574

From dcubed at openjdk.java.net  Fri Jun 25 15:35:03 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 25 Jun 2021 15:35:03 GMT
Subject: RFR: 8269302:
 serviceability/dcmd/framework/InvalidCommandTest.java still fails after
 JDK-8268433
In-Reply-To: <QWp2zFMVzdT-MSwgosydTYt7WRf9q6kkbDkOf9fOBCM=.f6cf8bc8-c444-4785-b5e5-cc167b881340@github.com>
References: <QWp2zFMVzdT-MSwgosydTYt7WRf9q6kkbDkOf9fOBCM=.f6cf8bc8-c444-4785-b5e5-cc167b881340@github.com>
Message-ID: <yiEjcrCrj9VCFkzSSZS7X2-tpUHP_D4ERXH_M_mlEw4=.464e6e95-ab45-46a2-8f58-1a9edda699de@github.com>

On Fri, 25 Jun 2021 04:25:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Please review this trivial fix in the cycle condition.
> 
> The cycle should run until connection is established (connection.isConnected() returns true) or error occurred (error != null)
> This wrong condition causes test error if ListenerThread.getConnection() reaches "synchronized (this)" section earlier than ListenerThread.run()

@alexmenkov - would you mind withdrawing this PR and creating a new PR against JDK17?
We're seeing these test failures in the JDK17 CI also. I've bumped the priority of the bug
from P4 -> P3 since we're seeing Tier3 test failures.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4593

From simonis at openjdk.java.net  Fri Jun 25 15:38:10 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 25 Jun 2021 15:38:10 GMT
Subject: RFR: JDK-8268893: jcmd to trim the glibc heap [v3]
In-Reply-To: <NDjsBIfcu8h-e21OTEioLI1pMeNgVzQmywL_1sD_JHk=.1daadc62-0a09-45b1-805a-0da9849ffc65@github.com>
References: <t1ff1qJYxJO-aIvHT1kMxmEJ7NEGGt3PFnDsX2RJqlI=.92d0a169-9128-4e95-8206-b91dc63d51ab@github.com>
 <NDjsBIfcu8h-e21OTEioLI1pMeNgVzQmywL_1sD_JHk=.1daadc62-0a09-45b1-805a-0da9849ffc65@github.com>
Message-ID: <MMg7ESm1GxsonnlkARTPdMdhHoF1NfvTavWZ-I4bAuc=.0d2544b4-d8e7-48f1-b0fc-5ca1a57330a3@github.com>

On Fri, 25 Jun 2021 06:22:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Proposal to add a Linux+glibc-only jcmd to manually induce malloc_trim(3) in the VM process.
>> 
>> 
>> The glibc is somewhat notorious for retaining released C Heap memory: calling free(3) returns memory to the glibc, and most libc variants will return at least a portion of it back to the Operating System, but the glibc often does not.
>> 
>> This depends on the granularity of the allocations and a number of other factors, but we found that many small allocations in particular may cause the process heap segment (hence RSS) to get bloaty. This can cause the VM to not recover from C-heap usage spikes.
>> 
>> The glibc offers an API, "malloc_trim", which can be used to cause the glibc to return free'd memory back to the Operating System.
>> 
>> This may cost performance, however, and therefore I hesitate to call malloc_trim automatically. That may be an idea for another day.
>> 
>> Instead of an automatic trim I propose to add a jcmd which allows to manually trigger a libc heap trim. Such a command would have two purposes:
>> - when analyzing cases of high memory footprint, it allows to distinguish "real" footprint, e.g. leaks, from a cases where the glibc just holds on to memory
>> - as a stop gap measure it allows to release pressure from a high footprint scenario.
>> 
>> Note that this command also helps with analyzing libc peaks which had nothing to do with the VM - e.g. peaks created by customer code which just happens to share the same process as the VM. Such memory does not even have to show up in NMT.
>> 
>> I propose to introduce this command for Linux only. Other OSes (apart maybe AIX) do not seem to have this problem, but Linux is arguably important enough in itself to justify a Linux specific jcmd.
>> 
>> CSR for this command: https://bugs.openjdk.java.net/browse/JDK-8269345
>> 
>> Note that an alternative to a Linux-only jcmd would be a command which would trim the C-heap on all platforms, with implementations to be filled out later.
>> 
>> =========
>> 
>> This patch:
>> 
>> - introduces a new jcmd, "VM.trim_libc_heap", no arguments, which trims the glibc heap on glibc platforms.
>> - includes a (rather basic) test
>> - the command calls malloc_trim(3), and additionally prints out its effect (changes caused in virt size, rss and swap space)
>> - I refactored some code in os_linux.cpp to factor out scanning /proc/self/status to get kernel memory information.
>> 
>> =========
>> 
>> Example:
>> 
>> A programm causes a temporary peak in C-heap usage (in this case, triggered via Unsafe.allocateMemory), right away frees the memory again, so its not leaky. The peak in RSS was ~8G (even though the user allocation was way smaller - glibc has a lot of overhead). The effects of this peak linger even after returning that memory to the glibc:
>> 
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 8685896K (peak: 8685896K) (anon: 8648680K, file: 37216K, shmem: 0K)
>>                    ^^^^^^^^
>> 
>> 
>> We execute the new trim command via jcmd:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.trim_libc_heap
>> 18770:
>> Attempting trim...
>> Done.
>> Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)  <<<<
>> Swap before: 0k, after: 0k, (0k)
>> 
>> 
>> It prints out reduction in virtual size, rss and swap. The virtual size did not decrease since no mappings had been unmapped by the glibc. However, the process heap was shrunk heavily by the glibc, resulting in a large drop in RSS (8.5G->900M), freeing >7G of memory:
>> 
>> 
>> thomas at starfish:~$ jjjcmd AllocCHeap VM.info | grep Resident
>> Resident Set Size: 920740K (peak: 8686004K) (anon: 883460K, file: 37280K, shmem: 0K)
>>                    ^^^^^^^
>> 
>> 
>> When the VM is started with -Xlog:os, this is also logged:
>> 
>> 
>> [139,068s][info][os] malloc_trim:
>> [139,068s][info][os] Virtual size before: 28849744k, after: 28849724k, (-20k)
>> RSS before: 8685896k, after: 920740k, (-7765156k)
>> Swap before: 0k, after: 0k, (0k)
>
> Thomas Stuefe 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:
> 
>  - Volker feedback
>  - Merge
>  - Feedback Severin; renamed query function
>  - start

Thanks for the cleanups. Looks good to me now.

-------------

Marked as reviewed by simonis (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4510

From amenkov at openjdk.java.net  Fri Jun 25 18:11:04 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 25 Jun 2021 18:11:04 GMT
Subject: Withdrawn: 8269302:
 serviceability/dcmd/framework/InvalidCommandTest.java still fails after
 JDK-8268433
In-Reply-To: <QWp2zFMVzdT-MSwgosydTYt7WRf9q6kkbDkOf9fOBCM=.f6cf8bc8-c444-4785-b5e5-cc167b881340@github.com>
References: <QWp2zFMVzdT-MSwgosydTYt7WRf9q6kkbDkOf9fOBCM=.f6cf8bc8-c444-4785-b5e5-cc167b881340@github.com>
Message-ID: <DkNZBXLsTNF90ub4j2jsE-dk4vByXqjk1IwC8haKRiQ=.48cdbcbd-9763-487c-a3c0-e1e40c870acb@github.com>

On Fri, 25 Jun 2021 04:25:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Please review this trivial fix in the cycle condition.
> 
> The cycle should run until connection is established (connection.isConnected() returns true) or error occurred (error != null)
> This wrong condition causes test error if ListenerThread.getConnection() reaches "synchronized (this)" section earlier than ListenerThread.run()

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4593

From amenkov at openjdk.java.net  Fri Jun 25 18:11:04 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 25 Jun 2021 18:11:04 GMT
Subject: RFR: 8269302:
 serviceability/dcmd/framework/InvalidCommandTest.java still fails after
 JDK-8268433
In-Reply-To: <yiEjcrCrj9VCFkzSSZS7X2-tpUHP_D4ERXH_M_mlEw4=.464e6e95-ab45-46a2-8f58-1a9edda699de@github.com>
References: <QWp2zFMVzdT-MSwgosydTYt7WRf9q6kkbDkOf9fOBCM=.f6cf8bc8-c444-4785-b5e5-cc167b881340@github.com>
 <yiEjcrCrj9VCFkzSSZS7X2-tpUHP_D4ERXH_M_mlEw4=.464e6e95-ab45-46a2-8f58-1a9edda699de@github.com>
Message-ID: <NWQ7sn-1wfMZnvCMP9ponhLdYrXLr2BT82lzJuwj3_c=.c9336afa-fe11-421f-a867-842d8e699c9d@github.com>

On Fri, 25 Jun 2021 15:32:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> 
> 
> @alexmenkov - would you mind withdrawing this PR and creating a new PR against JDK17?
> We're seeing these test failures in the JDK17 CI also. I've bumped the priority of the bug
> from P4 -> P3 since we're seeing Tier3 test failures.

Makes sense.
Will do

-------------

PR: https://git.openjdk.java.net/jdk/pull/4593

From amenkov at openjdk.java.net  Fri Jun 25 18:18:14 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 25 Jun 2021 18:18:14 GMT
Subject: [jdk17] RFR: 8269302:
 serviceability/dcmd/framework/InvalidCommandTest.java still fails after
 JDK-8268433
Message-ID: <j26MJPkMz7QgP12qfJY8AW4C7Gy4VgUGOwXUIkqXsq8=.0848c593-9731-492d-af13-eea67cd1138f@github.com>

Please review this simple test fix for jdk17.

The cycle should run until connection is established (connection.isConnected() returns true) or error occurred (error != null)
This wrong condition causes test error if ListenerThread.getConnection() reaches "synchronized (this)" section earlier than ListenerThread.run()

-------------

Commit messages:
 - Fixed cycle condition in ListenerThread.getConnection

Changes: https://git.openjdk.java.net/jdk17/pull/150/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=150&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269302
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/150.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/150/head:pull/150

PR: https://git.openjdk.java.net/jdk17/pull/150

From joe.darcy at oracle.com  Fri Jun 25 19:57:43 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 25 Jun 2021 12:57:43 -0700
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: <yUvE83550X7kQ8lwiCiXUlBe6dAvezHwWzrzsLZqUY4=.375c18e1-cb63-42cf-8462-12189b237b61@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <ep_6o8H_fydBJ-oPSWLUve7j-1oiExUbotgjUkys1nM=.7b32370d-cba4-4d32-9520-2e9b59f06982@github.com>
 <yUvE83550X7kQ8lwiCiXUlBe6dAvezHwWzrzsLZqUY4=.375c18e1-cb63-42cf-8462-12189b237b61@github.com>
Message-ID: <1af67d23-10a2-915a-8623-a38190fea6b3@oracle.com>

On 6/21/2021 2:02 PM, Paul Sandoz wrote:
> On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang <yyang at openjdk.org> wrote:
>
>>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    more replacement 2
> All the updates to the check* methods look ok (requires some careful looking!).
>
> I cannot recall what others said about the change in exception messages. @jddarcy any advice here?

Generally, the JDK does not have the text of exception message as a 
supported interface meant to be relied on by users. This doesn't stop 
developers from occasionally parsing those messages, but that is usually 
a sign of a missing API which we try to rectify more directly.

HTH,

-Joe


From weijun at openjdk.java.net  Fri Jun 25 20:11:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 25 Jun 2021 20:11:27 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
Message-ID: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>

More refactoring to limit the scope of `@SuppressWarnings` annotations.

Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

-------------

Commit messages:
 - 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

Changes: https://git.openjdk.java.net/jdk17/pull/152/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269409
  Stats: 289 lines in 21 files changed: 161 ins; 64 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

From kevinw at openjdk.java.net  Fri Jun 25 20:18:03 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 25 Jun 2021 20:18:03 GMT
Subject: [jdk17] RFR: 8269302:
 serviceability/dcmd/framework/InvalidCommandTest.java still fails after
 JDK-8268433
In-Reply-To: <j26MJPkMz7QgP12qfJY8AW4C7Gy4VgUGOwXUIkqXsq8=.0848c593-9731-492d-af13-eea67cd1138f@github.com>
References: <j26MJPkMz7QgP12qfJY8AW4C7Gy4VgUGOwXUIkqXsq8=.0848c593-9731-492d-af13-eea67cd1138f@github.com>
Message-ID: <7M0QQeVgDaO7N2galjji0x3lNGK1hcsVWBmRvj9UGpA=.9660714d-b385-41a9-b897-5efbd0ef5186@github.com>

On Fri, 25 Jun 2021 18:11:27 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Please review this simple test fix for jdk17.
> 
> The cycle should run until connection is established (connection.isConnected() returns true) or error occurred (error != null)
> This wrong condition causes test error if ListenerThread.getConnection() reaches "synchronized (this)" section earlier than ListenerThread.run()

Marked as reviewed by kevinw (Committer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/150

From lancea at openjdk.java.net  Fri Jun 25 20:27:59 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 25 Jun 2021 20:27:59 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
In-Reply-To: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
Message-ID: <DrVZVhP6Dj97uPHwPXYPVHsPUQyI3dBxA2zZEW0VpfU=.ac42aef2-2081-459e-8bd9-4bd8229b6b89@github.com>

On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Changes look good Max

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/152

From dcubed at openjdk.java.net  Fri Jun 25 20:29:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 25 Jun 2021 20:29:01 GMT
Subject: [jdk17] RFR: 8269302:
 serviceability/dcmd/framework/InvalidCommandTest.java still fails after
 JDK-8268433
In-Reply-To: <j26MJPkMz7QgP12qfJY8AW4C7Gy4VgUGOwXUIkqXsq8=.0848c593-9731-492d-af13-eea67cd1138f@github.com>
References: <j26MJPkMz7QgP12qfJY8AW4C7Gy4VgUGOwXUIkqXsq8=.0848c593-9731-492d-af13-eea67cd1138f@github.com>
Message-ID: <Surj_OzCyRRgdpLmDLYJDhEb12sCP6-p600dDJKsKhc=.77967278-6e88-4a93-9bbb-4489ea471689@github.com>

On Fri, 25 Jun 2021 18:11:27 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Please review this simple test fix for jdk17.
> 
> The cycle should run until connection is established (connection.isConnected() returns true) or error occurred (error != null)
> This wrong condition causes test error if ListenerThread.getConnection() reaches "synchronized (this)" section earlier than ListenerThread.run()

Thumbs up.

This looks like a trivial fix to me. I don't see any mention of
testing. It looks like the two tests mentioned in the bug both
run in Tier1 on multiple platforms.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/150

From amenkov at openjdk.java.net  Fri Jun 25 22:01:02 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 25 Jun 2021 22:01:02 GMT
Subject: RFR: 8269268: JDWP: Properly fix thread lookup assert in
 findThread() [v2]
In-Reply-To: <9f0X6MVyTIMTlk17Mqf2QDNeRk8mE7IM1yHvCwg-2lw=.7873ff96-cca0-43ea-9d4b-58a866710a78@github.com>
References: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
 <9f0X6MVyTIMTlk17Mqf2QDNeRk8mE7IM1yHvCwg-2lw=.7873ff96-cca0-43ea-9d4b-58a866710a78@github.com>
Message-ID: <wBl7KlCq_9yERSG83sMOaOEyKD8_eEpGu04q13vyx7U=.f4b38159-44f5-463f-8598-299d385a013b@github.com>

On Thu, 24 Jun 2021 16:51:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Re-enable the assert that was disabled (with some overhead) by [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation is in the CR and also in comments included with the changes.
>> 
>> I tested by running `vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java` and `vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java` 100's of times, and did not see any failures. I also verified the original issue was still reproducible by temporarily not setting `gdata->handlingVMDeath = JNI_TRUE`, which did trigger the assert as expected.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename flag and make some minor adjustments.

Marked as reviewed by amenkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4580

From amenkov at openjdk.java.net  Fri Jun 25 22:14:03 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 25 Jun 2021 22:14:03 GMT
Subject: [jdk17] RFR: 8269302:
 serviceability/dcmd/framework/InvalidCommandTest.java still fails after
 JDK-8268433
In-Reply-To: <Surj_OzCyRRgdpLmDLYJDhEb12sCP6-p600dDJKsKhc=.77967278-6e88-4a93-9bbb-4489ea471689@github.com>
References: <j26MJPkMz7QgP12qfJY8AW4C7Gy4VgUGOwXUIkqXsq8=.0848c593-9731-492d-af13-eea67cd1138f@github.com>
 <Surj_OzCyRRgdpLmDLYJDhEb12sCP6-p600dDJKsKhc=.77967278-6e88-4a93-9bbb-4489ea471689@github.com>
Message-ID: <Kaj8U32r7p_ICooEzs72WqS4SI7dmxA6a7wbU0KI2nE=.a0375466-e3ec-40b2-86bc-5b475177a1e6@github.com>

On Fri, 25 Jun 2021 20:26:16 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up.
> 
> This looks like a trivial fix to me. I don't see any mention of
> testing. It looks like the two tests mentioned in the bug both
> run in Tier1 on multiple platforms.

Run 3 tests in test/hotspot/jtreg/serviceability/dcmd/framework 200 times (win and win-debug).
No failures.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/150

From amenkov at openjdk.java.net  Fri Jun 25 22:14:04 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 25 Jun 2021 22:14:04 GMT
Subject: [jdk17] Integrated: 8269302:
 serviceability/dcmd/framework/InvalidCommandTest.java still fails after
 JDK-8268433
In-Reply-To: <j26MJPkMz7QgP12qfJY8AW4C7Gy4VgUGOwXUIkqXsq8=.0848c593-9731-492d-af13-eea67cd1138f@github.com>
References: <j26MJPkMz7QgP12qfJY8AW4C7Gy4VgUGOwXUIkqXsq8=.0848c593-9731-492d-af13-eea67cd1138f@github.com>
Message-ID: <KUj6TqbG9hRMWHgw2pTYtJTkuwS-itUUy2tRatT50ZA=.6b7a2215-decf-431d-b604-b0f4dabcff2a@github.com>

On Fri, 25 Jun 2021 18:11:27 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Please review this simple test fix for jdk17.
> 
> The cycle should run until connection is established (connection.isConnected() returns true) or error occurred (error != null)
> This wrong condition causes test error if ListenerThread.getConnection() reaches "synchronized (this)" section earlier than ListenerThread.run()

This pull request has now been integrated.

Changeset: 1404e4bf
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/1404e4bf44e28cadda3949f9e398e664cb98a5e2
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269302: serviceability/dcmd/framework/InvalidCommandTest.java still fails after JDK-8268433

Reviewed-by: kevinw, dcubed

-------------

PR: https://git.openjdk.java.net/jdk17/pull/150

From naoto at openjdk.java.net  Fri Jun 25 23:11:02 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Jun 2021 23:11:02 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
In-Reply-To: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
Message-ID: <WRnCZSpJU5jLXFkPL7jTjfWlNM-Js9m7Il_iGv3VjnY=.e8820247-04cb-4fd6-93ec-8208fa9995a5@github.com>

On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

LGTM.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Fri Jun 25 23:40:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 25 Jun 2021 23:40:27 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
Message-ID: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/152/files
  - new: https://git.openjdk.java.net/jdk17/pull/152/files/d8b384df..774eb9da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

From lzang at openjdk.java.net  Sat Jun 26 08:40:06 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 26 Jun 2021 08:40:06 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v27]
In-Reply-To: <MXonlUa56ZacBQh36BTp_dL0HVej4tUYFx_m7WZhOa8=.12001f9b-58ae-49e9-a1f7-b66c006e5de8@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <MXonlUa56ZacBQh36BTp_dL0HVej4tUYFx_m7WZhOa8=.12001f9b-58ae-49e9-a1f7-b66c006e5de8@github.com>
Message-ID: <4jjkkdtom6j_MOe7UM7QSm2-fSpolYTEF4GCyVRznzI=.a1506ab3-ef0c-4318-ae43-942bf42275d9@github.com>

On Mon, 7 Jun 2021 07:58:26 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 36 commits:
> 
>  - Merge branch 'master' into par-dump
>  - Merge branch 'master' into par-dump
>  - 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
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/908aca29...78c2c763

Dear All,
I have made an explaination of the design of this PR. Hope it could be helpful for reviewing. Welcome for any kind of suggestions. 
link: https://docs.google.com/document/d/19iEz5sEJltVuCkFfHsbnzg7ye74OOuB5xO5BaRqVoa8/edit?usp=sharing 
Thanks a lot!

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lancea at openjdk.java.net  Sat Jun 26 11:09:00 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 26 Jun 2021 11:09:00 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
Message-ID: <qJI_flUecx57Eopmrm_eDE4csUV4qIvsgMbLlYQWADA=.a53a887b-20fc-4021-a3da-7eeda2ace99b@github.com>

On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>> 
>> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From alanb at openjdk.java.net  Sat Jun 26 16:55:59 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 26 Jun 2021 16:55:59 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
Message-ID: <PtU4myq-Z6FnKMywGutGlrpbgISOm0YV_cYODMPQ8wk=.65a7475f-9103-4d63-b03f-c9bedae36c7e@github.com>

On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>> 
>> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 53:

> 51:     private static final long CURRENT_PID = AccessController.doPrivileged(
> 52:             (PrivilegedAction<ProcessHandle>) ProcessHandle::current).pid();
> 53: 

The original code separated out the declaration of the PrivilegedAction to avoid this cast. If you move the code from the original static initializer into a static method that it called from initializer then it might provide you with a cleaner way to refactor this. There are several other places in this patch that could do with similar cleanup.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Sat Jun 26 23:59:03 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 26 Jun 2021 23:59:03 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <PtU4myq-Z6FnKMywGutGlrpbgISOm0YV_cYODMPQ8wk=.65a7475f-9103-4d63-b03f-c9bedae36c7e@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
 <PtU4myq-Z6FnKMywGutGlrpbgISOm0YV_cYODMPQ8wk=.65a7475f-9103-4d63-b03f-c9bedae36c7e@github.com>
Message-ID: <vDo_mZw0b4pVOB2rblb35o0dbjSkxWcmjCLtLhyua2I=.307c745e-c0b5-4c1c-8299-d48f6292435e@github.com>

On Sat, 26 Jun 2021 16:53:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   one more
>
> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 53:
> 
>> 51:     private static final long CURRENT_PID = AccessController.doPrivileged(
>> 52:             (PrivilegedAction<ProcessHandle>) ProcessHandle::current).pid();
>> 53: 
> 
> The original code separated out the declaration of the PrivilegedAction to avoid this cast. If you move the code from the original static initializer into a static method that it called from initializer then it might provide you with a cleaner way to refactor this. There are several other places in this patch that could do with similar cleanup.

This cast is only to tell the compiler which overloaded method to call, and I don't think there will be a real cast at runtime. It might look a little ugly but extracting it into a variable declaration/definition plus a new `initStatic` method seems not worth doing, IMHO.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From jwilhelm at openjdk.java.net  Sun Jun 27 23:14:43 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sun, 27 Jun 2021 23:14:43 GMT
Subject: RFR: Merge jdk17
Message-ID: <UuAdbq4PdehshmGp7Ove-549fd3P21JVKOW_5DA7Ohg=.6ea4718d-e033-4f76-b1ba-9e8b21c7e7e4@github.com>

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8258746: illegal access to global field _jvmci_old_thread_counters by terminated thread causes crash
 - 8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class
 - 8269351: Proxy::newProxyInstance and MethodHandleProxies::asInterfaceInstance should reject sealed interfaces
 - 8269260: Add AVX512 and other SSE + AVX combinations testing for tests which generate vector instructions
 - 8269302: serviceability/dcmd/framework/InvalidCommandTest.java still fails after JDK-8268433
 - 8269036: tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create failed - Resource busy"
 - 8269074: (fs) Files.copy fails to copy from /proc on some linux kernel versions
 - 8256919: BCEL: Utility.encode forget to close
 - 8269335: Unable to load svml library
 - ... and 20 more: https://git.openjdk.java.net/jdk/compare/8bed3534...2d9b73c0

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4606&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4606&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4606/files
  Stats: 1925 lines in 90 files changed: 1452 ins; 227 del; 246 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4606/head:pull/4606

PR: https://git.openjdk.java.net/jdk/pull/4606

From jwilhelm at openjdk.java.net  Sun Jun 27 23:55:06 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sun, 27 Jun 2021 23:55:06 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <UuAdbq4PdehshmGp7Ove-549fd3P21JVKOW_5DA7Ohg=.6ea4718d-e033-4f76-b1ba-9e8b21c7e7e4@github.com>
References: <UuAdbq4PdehshmGp7Ove-549fd3P21JVKOW_5DA7Ohg=.6ea4718d-e033-4f76-b1ba-9e8b21c7e7e4@github.com>
Message-ID: <sElvu-UQjqYZKL1uWto8zQPtNExY5pQ2wOcU2qmPKXg=.aeb72bef-15d5-4ff7-8f57-7b8ef9fb6ed3@github.com>

On Sun, 27 Jun 2021 23:05:10 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: a29953d8
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a29953d805ac6360bcfe005bcefa60e112788494
Stats:     1925 lines in 90 files changed: 1452 ins; 227 del; 246 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4606

From stuefe at openjdk.java.net  Mon Jun 28 06:20:07 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Jun 2021 06:20:07 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <aZ3XTqmzSbV2FcWyL3pWA5VFihFPjKPUJB_xeCM8tI4=.0cc366f6-0313-4dbf-8a11-49951af0a820@github.com>

On Thu, 10 Jun 2021 02:07:36 GMT, Yi Yang <yyang at openjdk.org> wrote:

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Changes requested by stuefe (Reviewer).

src/hotspot/share/runtime/osThread.cpp line 41:

> 39: // Printing
> 40: void OSThread::print_on(outputStream *st) const {
> 41:   st->print("nid=%d ", thread_id());

thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume its numeric, but I would print it as an unsigned 64bit int just in case.

src/hotspot/share/runtime/osThread.cpp line 49:

> 47:     case CONDVAR_WAIT:            st->print("waiting on condition ");      break;
> 48:     case OBJECT_WAIT:             st->print("in Object.wait() ");          break;
> 49:     case BREAKPOINTED:            st->print("at breakpoint");               break;

These cleanups don't seem to have anything to do with this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Mon Jun 28 07:40:08 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 28 Jun 2021 07:40:08 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one
In-Reply-To: <aZ3XTqmzSbV2FcWyL3pWA5VFihFPjKPUJB_xeCM8tI4=.0cc366f6-0313-4dbf-8a11-49951af0a820@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <aZ3XTqmzSbV2FcWyL3pWA5VFihFPjKPUJB_xeCM8tI4=.0cc366f6-0313-4dbf-8a11-49951af0a820@github.com>
Message-ID: <u7m1w7jpsHf5zRdKwto1t_J3lo8Phqsy5lOiyGeP-zQ=.b4dfb549-739d-4a43-b1d5-0f63a08a3951@github.com>

On Mon, 28 Jun 2021 06:16:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> src/hotspot/share/runtime/osThread.cpp line 41:
> 
>> 39: // Printing
>> 40: void OSThread::print_on(outputStream *st) const {
>> 41:   st->print("nid=%d ", thread_id());
> 
> thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume its numeric, but I would print it as an unsigned 64bit int just in case.

Hi Thomas, we can not use other format specifiers (`%ld`,`%llu`) after my practice, because it can not compile on my mac:

> src/hotspot/share/runtime/osThread.cpp line 49:
> 
>> 47:     case CONDVAR_WAIT:            st->print("waiting on condition ");      break;
>> 48:     case OBJECT_WAIT:             st->print("in Object.wait() ");          break;
>> 49:     case BREAKPOINTED:            st->print("at breakpoint");               break;
> 
> These cleanups don't seem to have anything to do with this change.

Restored.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Mon Jun 28 07:46:29 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 28 Jun 2021 07:46:29 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  restore cleanup code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4449/files
  - new: https://git.openjdk.java.net/jdk/pull/4449/files/eb469267..4baeb175

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4449/head:pull/4449

PR: https://git.openjdk.java.net/jdk/pull/4449

From stuefe at openjdk.java.net  Mon Jun 28 08:49:09 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Jun 2021 08:49:09 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <u7m1w7jpsHf5zRdKwto1t_J3lo8Phqsy5lOiyGeP-zQ=.b4dfb549-739d-4a43-b1d5-0f63a08a3951@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <aZ3XTqmzSbV2FcWyL3pWA5VFihFPjKPUJB_xeCM8tI4=.0cc366f6-0313-4dbf-8a11-49951af0a820@github.com>
 <u7m1w7jpsHf5zRdKwto1t_J3lo8Phqsy5lOiyGeP-zQ=.b4dfb549-739d-4a43-b1d5-0f63a08a3951@github.com>
Message-ID: <okg8a20YH5FvAJ1WAzvclWnkdlgCh_soQtOhKbnDeHM=.fcfe5f77-3726-4248-b272-8a0486ff1a8f@github.com>

On Mon, 28 Jun 2021 07:37:10 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> src/hotspot/share/runtime/osThread.cpp line 41:
>> 
>>> 39: // Printing
>>> 40: void OSThread::print_on(outputStream *st) const {
>>> 41:   st->print("nid=%d ", thread_id());
>> 
>> thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume its numeric, but I would print it as an unsigned 64bit int just in case.
>
> Hi Thomas, we can not use other format specifiers (`%ld`,`%llu`) after my practice, because it can not compile on my mac:

You'd do:

print("nid: " UINT64_FORMAT, (uint64_t) id):;

thread_t is, among other things, pthread_t, which is opaque. Any current code treating that as signed int is incorrect too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From kevinw at openjdk.java.net  Mon Jun 28 09:01:10 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 28 Jun 2021 09:01:10 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
Message-ID: <esArxVpYbdi3v2m9inGcE1V7l2DiklP_UQ4yXLMsYcg=.5ce0a5a6-066b-4b34-984d-ed9302a709de@github.com>

On Mon, 28 Jun 2021 07:46:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore cleanup code

Hi,
If you attach WinDbg on Windows to a JVM, you might be glad of the nid=0x... format as that is its choice of base for the thread ids.
So this depends on your tools.  Maybe frustrated top users outnumber happy WinDbg users for the JVM, and maybe they don't.  Maybe this change delights some users and frustrates others.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From stuefe at openjdk.java.net  Mon Jun 28 09:20:02 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Jun 2021 09:20:02 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <esArxVpYbdi3v2m9inGcE1V7l2DiklP_UQ4yXLMsYcg=.5ce0a5a6-066b-4b34-984d-ed9302a709de@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
 <esArxVpYbdi3v2m9inGcE1V7l2DiklP_UQ4yXLMsYcg=.5ce0a5a6-066b-4b34-984d-ed9302a709de@github.com>
Message-ID: <f_BZsAk3c7Yn7jUh0V9wyru1I8lw2ewWyDGcJKr-1RQ=.42ea8d53-c4cd-4dcc-877c-94b120ad1410@github.com>

On Mon, 28 Jun 2021 08:58:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hi,
> If you attach WinDbg on Windows to a JVM, you might be glad of the nid=0x... format as that is its choice of base for the thread ids.
> So this depends on your tools. Maybe frustrated top users outnumber happy WinDbg users for the JVM, and maybe they don't. Maybe this change delights some users and frustrates others.

Why not do it platform dependent then? This would make sense especially since the type is opaque. Let each platform handling printing. Windows can hex-print its DWORD thread id. Linux can print its kernel LWP. And platforms where the thread id is 64bit, or a structure, can print that.

For now default implementations could live in `os::Windows::print_thread_id(thread_t)` and `os::Posix::print_thread_id(thread_t)`, respectively.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From kevinw at openjdk.java.net  Mon Jun 28 10:10:02 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 28 Jun 2021 10:10:02 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <f_BZsAk3c7Yn7jUh0V9wyru1I8lw2ewWyDGcJKr-1RQ=.42ea8d53-c4cd-4dcc-877c-94b120ad1410@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
 <esArxVpYbdi3v2m9inGcE1V7l2DiklP_UQ4yXLMsYcg=.5ce0a5a6-066b-4b34-984d-ed9302a709de@github.com>
 <f_BZsAk3c7Yn7jUh0V9wyru1I8lw2ewWyDGcJKr-1RQ=.42ea8d53-c4cd-4dcc-877c-94b120ad1410@github.com>
Message-ID: <HfTDsxn4EpZunPUYvQQhF1KXfOxRP-f2tyg_s_cUq_4=.d140212e-ac63-48a5-8adc-8cc16d555348@github.com>

On Mon, 28 Jun 2021 09:16:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Why not do it platform dependent then? ...

Checked Visual Studio, and that goes with decimal for thread IDs. 8-)

It's the tools rather than the platform.  But yes, hex for thread IDs seems to be in the minority.  (I have occasionally found this annoying.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From dfuchs at openjdk.java.net  Mon Jun 28 12:24:05 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 28 Jun 2021 12:24:05 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <vDo_mZw0b4pVOB2rblb35o0dbjSkxWcmjCLtLhyua2I=.307c745e-c0b5-4c1c-8299-d48f6292435e@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
 <PtU4myq-Z6FnKMywGutGlrpbgISOm0YV_cYODMPQ8wk=.65a7475f-9103-4d63-b03f-c9bedae36c7e@github.com>
 <vDo_mZw0b4pVOB2rblb35o0dbjSkxWcmjCLtLhyua2I=.307c745e-c0b5-4c1c-8299-d48f6292435e@github.com>
Message-ID: <q8F5L2UNdnaE2PSJ9UUGYZ7GwhUNBfLwzJ9VzFhH1sc=.e618c4e6-d10f-442b-99f7-f4d2f8543db4@github.com>

On Sat, 26 Jun 2021 23:55:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 53:
>> 
>>> 51:     private static final long CURRENT_PID = AccessController.doPrivileged(
>>> 52:             (PrivilegedAction<ProcessHandle>) ProcessHandle::current).pid();
>>> 53: 
>> 
>> The original code separated out the declaration of the PrivilegedAction to avoid this cast. If you move the code from the original static initializer into a static method that it called from initializer then it might provide you with a cleaner way to refactor this. There are several other places in this patch that could do with similar cleanup.
>
> This cast is only to tell the compiler which overloaded method to call, and I don't think there will be a real cast at runtime. It might look a little ugly but extracting it into a variable declaration/definition plus a new `initStatic` method seems not worth doing, IMHO.

Why not simply declare a local variable in the static initializer below?


    private static final long CURRENT_PID;
    private static final boolean ALLOW_ATTACH_SELF;
    static {
        PrivilegedAction<ProcessHandle> pa = ProcessHandle::current;
        @SuppressWarnings("removal")
        long pid = AccessController.doPrivileged(pa).pid();
        CURRENT_PID = pid;
        String s = VM.getSavedProperty("jdk.attach.allowAttachSelf");
        ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s);
    }

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From david.holmes at oracle.com  Mon Jun 28 12:37:57 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 28 Jun 2021 22:37:57 +1000
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <okg8a20YH5FvAJ1WAzvclWnkdlgCh_soQtOhKbnDeHM=.fcfe5f77-3726-4248-b272-8a0486ff1a8f@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <aZ3XTqmzSbV2FcWyL3pWA5VFihFPjKPUJB_xeCM8tI4=.0cc366f6-0313-4dbf-8a11-49951af0a820@github.com>
 <u7m1w7jpsHf5zRdKwto1t_J3lo8Phqsy5lOiyGeP-zQ=.b4dfb549-739d-4a43-b1d5-0f63a08a3951@github.com>
 <okg8a20YH5FvAJ1WAzvclWnkdlgCh_soQtOhKbnDeHM=.fcfe5f77-3726-4248-b272-8a0486ff1a8f@github.com>
Message-ID: <550a3797-9694-b4f3-1e64-c556210194b0@oracle.com>

On 28/06/2021 6:49 pm, Thomas Stuefe wrote:
> On Mon, 28 Jun 2021 07:37:10 GMT, Yi Yang <yyang at openjdk.org> wrote:
> 
>>> src/hotspot/share/runtime/osThread.cpp line 41:
>>>
>>>> 39: // Printing
>>>> 40: void OSThread::print_on(outputStream *st) const {
>>>> 41:   st->print("nid=%d ", thread_id());
>>>
>>> thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume its numeric, but I would print it as an unsigned 64bit int just in case.
>>
>> Hi Thomas, we can not use other format specifiers (`%ld`,`%llu`) after my practice, because it can not compile on my mac:
> 
> You'd do:
> 
> print("nid: " UINT64_FORMAT, (uint64_t) id):;
> 
> thread_t is, among other things, pthread_t, which is opaque. Any current code treating that as signed int is incorrect too.

If it is opaque then I don't see how signed or unsigned makes any 
difference. You are assuming it can just be treated as a 64-bit value; 
whether you interpret that as a signed or unsigned value just changes 
how you print it. I agree printing only positive values is nicer visually.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4449
> 

From kevinw at openjdk.java.net  Mon Jun 28 13:10:04 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 28 Jun 2021 13:10:04 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one
In-Reply-To: <ID5uxd8brvT6iLVOWOJ0dAAhvUbwPBdQubzaQ1nH82Y=.73c27ac5-b908-423c-85d6-7e213a5d349c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <ID5uxd8brvT6iLVOWOJ0dAAhvUbwPBdQubzaQ1nH82Y=.73c27ac5-b908-423c-85d6-7e213a5d349c@github.com>
Message-ID: <37m5nc6KDsehgna2Z7xEbz_J5iodCHhUQgpcnXxVEIk=.5cea815d-6cfa-42d2-ba81-391aaaffb1d2@github.com>

On Fri, 18 Jun 2021 06:14:49 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Do you think this would facilitate debugging process? And is it acceptable? Any feedback is appreciated!

My first comments were to say that this makes things better for some people, but a little worse for others.
Maybe overall this looks like it makes things better for most people. 8-)

If so (and if we don't discover more tools that prefer hex for thread IDs!), then we want to be consistent, so in addition to the native/built in implementation, we should also update:

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java
..to keep the SA implementation in sync.  It would be odd to have thread dumps looking more different depending on what generated them.

And if changing that, also change:
test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java

I don't see other tests that parse this information.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From stuefe at openjdk.java.net  Mon Jun 28 13:50:14 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Jun 2021 13:50:14 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one
In-Reply-To: <550a3797-9694-b4f3-1e64-c556210194b0@oracle.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <550a3797-9694-b4f3-1e64-c556210194b0@oracle.com>
Message-ID: <ppYWQCM55LtWK2SS6PJTF5de1pOIUWz2iAG6b4fXrNU=.a5c8365b-ee50-48e7-8915-a472a9534f08@github.com>

On Mon, 28 Jun 2021 12:41:35 GMT, David Holmes <david.holmes at oracle.com> wrote:

> > You'd do:
> > print("nid: " UINT64_FORMAT, (uint64_t) id):;
> > thread_t is, among other things, pthread_t, which is opaque. Any current code treating that as signed int is incorrect too.
> 
> If it is opaque then I don't see how signed or unsigned makes any
> difference. You are assuming it can just be treated as a 64-bit value;
> whether you interpret that as a signed or unsigned value just changes
> how you print it. I agree printing only positive values is nicer visually.
> 
> David

My `signed in` comment was referring to the existing use of `%d` in the code base. I'm more concerned with the 32bit range of int than the signedness (though I never saw an OS tool displaying negative numbers for thread ids).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From weijun at openjdk.java.net  Mon Jun 28 14:22:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 14:22:47 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v3]
In-Reply-To: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
Message-ID: <MRiwxXMyWbilE-qPVeaskpn801Z83SVdmV3tPmjEwDU=.d70a5d0e-0d06-4d9e-a510-acbf36c3f3d5@github.com>

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more refinement

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/152/files
  - new: https://git.openjdk.java.net/jdk17/pull/152/files/774eb9da..2e4a8ba7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=01-02

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Mon Jun 28 14:22:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 14:22:49 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
Message-ID: <NN_9zwG2upPLjrFClvSwbEq7Ydbb7GKyIbpoTFL-BAU=.07e2e6b7-f46e-4784-9c5d-d4520ddc5f90@github.com>

On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>> 
>> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

I'm going to move this to jdk18.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Mon Jun 28 14:22:51 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 14:22:51 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <q8F5L2UNdnaE2PSJ9UUGYZ7GwhUNBfLwzJ9VzFhH1sc=.e618c4e6-d10f-442b-99f7-f4d2f8543db4@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
 <PtU4myq-Z6FnKMywGutGlrpbgISOm0YV_cYODMPQ8wk=.65a7475f-9103-4d63-b03f-c9bedae36c7e@github.com>
 <vDo_mZw0b4pVOB2rblb35o0dbjSkxWcmjCLtLhyua2I=.307c745e-c0b5-4c1c-8299-d48f6292435e@github.com>
 <q8F5L2UNdnaE2PSJ9UUGYZ7GwhUNBfLwzJ9VzFhH1sc=.e618c4e6-d10f-442b-99f7-f4d2f8543db4@github.com>
Message-ID: <921aev1Be6BDt-9x6qkx-DqcgpCdUxkxD5nM8WQsNLs=.adbfc2ef-25cf-468a-8b6e-e8aa92aa8e3c@github.com>

On Mon, 28 Jun 2021 12:20:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This cast is only to tell the compiler which overloaded method to call, and I don't think there will be a real cast at runtime. It might look a little ugly but extracting it into a variable declaration/definition plus a new `initStatic` method seems not worth doing, IMHO.
>
> Why not simply declare a local variable in the static initializer below?
> 
> 
>     private static final long CURRENT_PID;
>     private static final boolean ALLOW_ATTACH_SELF;
>     static {
>         PrivilegedAction<ProcessHandle> pa = ProcessHandle::current;
>         @SuppressWarnings("removal")
>         long pid = AccessController.doPrivileged(pa).pid();
>         CURRENT_PID = pid;
>         String s = VM.getSavedProperty("jdk.attach.allowAttachSelf");
>         ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s);
>     }

I've just pushed a commit with a different fix:

    private static final long CURRENT_PID = pid();

    @SuppressWarnings("removal")
    private static long pid() {
        PrivilegedAction<ProcessHandle> pa = () -> ProcessHandle.current();
        return AccessController.doPrivileged(pa).pid();
    }

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Mon Jun 28 18:11:07 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 18:11:07 GMT
Subject: [jdk17] Withdrawn: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
In-Reply-To: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
References: <O3MhsAA_ASI1luoP4EzFzkZBFWEfGU0dA8FAcrN9hY8=.32b659a6-48af-48a1-8cce-1e762ea61e00@github.com>
Message-ID: <ryoERlcT9Uj4t9WmIyou2T2M6hY2jKeWsj75nVT9S0E=.10e4fef3-df99-40f4-973a-b5b3efad2eda@github.com>

On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Mon Jun 28 18:15:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 18:15:30 GMT
Subject: RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum
 covering > 10K
Message-ID: <YIgLalq4YlsNRp9DAls_OxBjzKqxgtE2qwaxHnBDgKQ=.3dadce0a-49a3-49de-98b5-860a8e3d1c79@github.com>

More refactoring to limit the scope of `@SuppressWarnings` annotations.

Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Note: this is copied from https://github.com/openjdk/jdk17/pull/152.

-------------

Commit messages:
 - copy all code change from jdk17

Changes: https://git.openjdk.java.net/jdk/pull/4615/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4615&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269409
  Stats: 293 lines in 21 files changed: 165 ins; 64 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4615/head:pull/4615

PR: https://git.openjdk.java.net/jdk/pull/4615

From lmesnik at openjdk.java.net  Mon Jun 28 18:44:25 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 28 Jun 2021 18:44:25 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL _value
 in JvmtiExport::post_compiled_method_load
Message-ID: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>

The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.

-------------

Commit messages:
 - fix in problemlist.txt
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8245877
 - ident fixed.
 - test unproblemlisted.
 - fix

Changes: https://git.openjdk.java.net/jdk/pull/4602/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4602&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245877
  Stats: 9 lines in 4 files changed: 5 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4602.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4602/head:pull/4602

PR: https://git.openjdk.java.net/jdk/pull/4602

From lancea at openjdk.java.net  Mon Jun 28 18:44:06 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 28 Jun 2021 18:44:06 GMT
Subject: RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum
 covering > 10K
In-Reply-To: <YIgLalq4YlsNRp9DAls_OxBjzKqxgtE2qwaxHnBDgKQ=.3dadce0a-49a3-49de-98b5-860a8e3d1c79@github.com>
References: <YIgLalq4YlsNRp9DAls_OxBjzKqxgtE2qwaxHnBDgKQ=.3dadce0a-49a3-49de-98b5-860a8e3d1c79@github.com>
Message-ID: <BMRdlpcyWLKRqBW60XUmo-O6ZQloNBMBcxEhVvGjSSk=.59cd7fff-e92f-43c8-bacd-307ebb4f8712@github.com>

On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
> 
> Note: this is copied from https://github.com/openjdk/jdk17/pull/152.

The revisions you made as part of the push to JDK 18 look fine Max.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4615

From sspitsyn at openjdk.java.net  Mon Jun 28 19:02:08 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 28 Jun 2021 19:02:08 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load
In-Reply-To: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
Message-ID: <EN65BUSqR3w-wrngtbzWUT_DbKDE4grXdaN9PpXFw5o=.379bd763-9066-4681-a9b4-a741239caaa0@github.com>

On Sat, 26 Jun 2021 17:48:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.

Hi Leonid,
I looks good to me.
Thank you for addressing it!
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4602

From weijun at openjdk.java.net  Mon Jun 28 19:09:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 19:09:15 GMT
Subject: Integrated: 8269409: Post JEP 411 refactoring: core-libs with maximum
 covering > 10K
In-Reply-To: <YIgLalq4YlsNRp9DAls_OxBjzKqxgtE2qwaxHnBDgKQ=.3dadce0a-49a3-49de-98b5-860a8e3d1c79@github.com>
References: <YIgLalq4YlsNRp9DAls_OxBjzKqxgtE2qwaxHnBDgKQ=.3dadce0a-49a3-49de-98b5-860a8e3d1c79@github.com>
Message-ID: <LhWNws-p44a2Pg12nOWMi7JCEs80hk7wRSo40AFJu44=.76a18364-1df3-42b3-94f5-1215dc3b7fe6@github.com>

On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
> 
> Note: this is copied from https://github.com/openjdk/jdk17/pull/152.

This pull request has now been integrated.

Changeset: e9b2c058
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e9b2c058a4ed5de29b991360f78fc1c5263c9268
Stats:     293 lines in 21 files changed: 165 ins; 64 del; 64 mod

8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/4615

From amenkov at openjdk.java.net  Mon Jun 28 19:39:03 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 28 Jun 2021 19:39:03 GMT
Subject: RFR: 8260540: serviceability/jdwp/AllModulesCommandTest.java
 failed with "Debuggee error: 'ERROR: transport error 202: bind failed:
 Address already in use'"
In-Reply-To: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>
References: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>
Message-ID: <SMn_I_lVZKqZPGfUyb0UziKP7fuV9YyDmTzEiMpdh_Q=.54ee8bc0-57d9-4abc-af5e-52495d44d233@github.com>

On Tue, 22 Jun 2021 21:01:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Updated AllModulesCommandTest to use dynamic port launching debuggee.
> Parsing debuggee listening address functionality is required in several tests (and we have other tests which need to be fixed the same way), so moved the code to new class in jdk.test.lib

Ping

-------------

PR: https://git.openjdk.java.net/jdk/pull/4560

From sspitsyn at openjdk.java.net  Mon Jun 28 20:04:04 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 28 Jun 2021 20:04:04 GMT
Subject: RFR: 8269268: JDWP: Properly fix thread lookup assert in
 findThread() [v2]
In-Reply-To: <9f0X6MVyTIMTlk17Mqf2QDNeRk8mE7IM1yHvCwg-2lw=.7873ff96-cca0-43ea-9d4b-58a866710a78@github.com>
References: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
 <9f0X6MVyTIMTlk17Mqf2QDNeRk8mE7IM1yHvCwg-2lw=.7873ff96-cca0-43ea-9d4b-58a866710a78@github.com>
Message-ID: <4GWTnX1Y-h_dwfkt3xqqMx0x_Rbk_3ynP1fwXQdunYE=.a1654961-ba40-4208-be1b-dea382b5991f@github.com>

On Thu, 24 Jun 2021 16:51:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Re-enable the assert that was disabled (with some overhead) by [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation is in the CR and also in comments included with the changes.
>> 
>> I tested by running `vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java` and `vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java` 100's of times, and did not see any failures. I also verified the original issue was still reproducible by temporarily not setting `gdata->handlingVMDeath = JNI_TRUE`, which did trigger the assert as expected.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename flag and make some minor adjustments.

LGTM.
I like the way it is fixed.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4580

From cjplummer at openjdk.java.net  Mon Jun 28 20:47:17 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 28 Jun 2021 20:47:17 GMT
Subject: [jdk17] RFR: 8269232: assert(!is_jweak(handle)) failed: wrong method
 for detroying jweak
Message-ID: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>

Don't let node->strongRef go below 0, or we end up thinking we still have a strongref when it is a weakref. Note the fact that we are doing nesting counts is still a bug (and the main cause of this issue). However, the fix for that is more complex, and for 17 I would prefer to just apply this simpler fix. For addressing the bigger issue, I filed the following:

[JDK-8269542](https://bugs.openjdk.java.net/browse/JDK-8269542): JDWP: EnableCollection support is no longer spec compliant after [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987)

-------------

Commit messages:
 - Don't decrement strongCount if already 0

Changes: https://git.openjdk.java.net/jdk17/pull/165/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=165&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269232
  Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/165.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/165/head:pull/165

PR: https://git.openjdk.java.net/jdk17/pull/165

From rkennke at openjdk.java.net  Mon Jun 28 21:10:00 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 28 Jun 2021 21:10:00 GMT
Subject: [jdk17] RFR: 8269232: assert(!is_jweak(handle)) failed: wrong
 method for detroying jweak
In-Reply-To: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>
References: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>
Message-ID: <Gntafoxa5BhH-jmO39xCi5Ue_bBCscuLhl2c_3UmbbM=.cb3e4bb8-13ec-448e-8f10-953df8bbeffc@github.com>

On Mon, 28 Jun 2021 20:41:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Don't let node->strongRef go below 0, or we end up thinking we still have a strongref when it is a weakref. Note the fact that we are doing nesting counts is still a bug (and the main cause of this issue). However, the fix for that is more complex, and for 17 I would prefer to just apply this simpler fix. For addressing the bigger issue, I filed the following:
> 
> [JDK-8269542](https://bugs.openjdk.java.net/browse/JDK-8269542): JDWP: EnableCollection support is no longer spec compliant after [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987)

Looks good to me! Thanks!

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/165

From sspitsyn at openjdk.java.net  Mon Jun 28 21:40:00 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 28 Jun 2021 21:40:00 GMT
Subject: RFR: 8260540: serviceability/jdwp/AllModulesCommandTest.java
 failed with "Debuggee error: 'ERROR: transport error 202: bind failed:
 Address already in use'"
In-Reply-To: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>
References: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>
Message-ID: <Bc7-_Ya2oNN4jBvCog5-IiZ56WitX7VVBZVAJQbuVcc=.06dd40e2-ef83-4bc1-bf28-dc427e3e99a0@github.com>

On Tue, 22 Jun 2021 21:01:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Updated AllModulesCommandTest to use dynamic port launching debuggee.
> Parsing debuggee listening address functionality is required in several tests (and we have other tests which need to be fixed the same way), so moved the code to new class in jdk.test.lib

It looks good to me. Just one minor question inlined.
Thanks,
Serguei

test/jdk/com/sun/jdi/JdwpAllowTest.java line 83:

> 81:             String s = app.getProcessStdout();
> 82:             JDWP.ListenAddress addr = JDWP.parseListenAddress(s);
> 83:             if (addr != null) {

What is going to happen in the case of addr == null?

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4560

From amenkov at openjdk.java.net  Mon Jun 28 21:43:04 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 28 Jun 2021 21:43:04 GMT
Subject: [jdk17] RFR: 8269232: assert(!is_jweak(handle)) failed: wrong
 method for detroying jweak
In-Reply-To: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>
References: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>
Message-ID: <jF1yvaXE1XMWCVWPSocAdfoHhSRbVJY4HYt7QNDxDLo=.1a202099-eb4a-4302-ae12-740e927f64e9@github.com>

On Mon, 28 Jun 2021 20:41:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Don't let node->strongRef go below 0, or we end up thinking we still have a strongref when it is a weakref. Note the fact that we are doing nesting counts is still a bug (and the main cause of this issue). However, the fix for that is more complex, and for 17 I would prefer to just apply this simpler fix. For addressing the bigger issue, I filed the following:
> 
> [JDK-8269542](https://bugs.openjdk.java.net/browse/JDK-8269542): JDWP: EnableCollection support is no longer spec compliant after [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987)

Marked as reviewed by amenkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/165

From sspitsyn at openjdk.java.net  Mon Jun 28 21:47:09 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 28 Jun 2021 21:47:09 GMT
Subject: RFR: 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove
 the unused field 'is_deadlock' of DeadlockCycle [v7]
In-Reply-To: <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
References: <Xth8DgfEZY01MU9Eg-f4mIgDgtxxRFQW2bfXgfqerqk=.1b8efe3a-decb-4455-9392-815979179850@github.com>
 <aKSAJaC2ZLJgMd3G6hJMfVnf_M0if1mFk6FrupC8uao=.77b23ae1-5ac1-4320-bc46-5763c2fd57a1@github.com>
Message-ID: <AWr51Whh-2a-xPaKBOrS9NVSH203FugabPTL65Inxc0=.7cc4dc46-a83b-42b7-87a3-4edf9594fffe@github.com>

On Fri, 18 Jun 2021 06:51:53 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Hi,
>> 
>> Could I have a review of this change that merges three vm operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and signal_thread_entry.
>> 
>> `jstack` is a very common command, even in the production environment.
>> 
>> In addition to reduce the cost of entering safepoint, I think this patch also could ensure the consistency of the results of VM_PrintThreads and VM_FindDeadlocks.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Despite the fact it is after the integration it looks good to me. :)
Thanks,
Serguei

-------------

PR: https://git.openjdk.java.net/jdk/pull/4504

From sspitsyn at openjdk.java.net  Mon Jun 28 21:52:03 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 28 Jun 2021 21:52:03 GMT
Subject: [jdk17] RFR: 8269232: assert(!is_jweak(handle)) failed: wrong
 method for detroying jweak
In-Reply-To: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>
References: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>
Message-ID: <KqDQTatil83wwG6aw_pPOwqmETJ8jq8jmOlGsWy9mm8=.8dda3a89-b371-4d93-af8b-70880fa2cecd@github.com>

On Mon, 28 Jun 2021 20:41:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Don't let node->strongRef go below 0, or we end up thinking we still have a strongref when it is a weakref. Note the fact that we are doing nesting counts is still a bug (and the main cause of this issue). However, the fix for that is more complex, and for 17 I would prefer to just apply this simpler fix. For addressing the bigger issue, I filed the following:
> 
> [JDK-8269542](https://bugs.openjdk.java.net/browse/JDK-8269542): JDWP: EnableCollection support is no longer spec compliant after [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987)

LGTM

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/165

From amenkov at openjdk.java.net  Tue Jun 29 01:03:06 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 29 Jun 2021 01:03:06 GMT
Subject: RFR: 8260540: serviceability/jdwp/AllModulesCommandTest.java
 failed with "Debuggee error: 'ERROR: transport error 202: bind failed:
 Address already in use'"
In-Reply-To: <Bc7-_Ya2oNN4jBvCog5-IiZ56WitX7VVBZVAJQbuVcc=.06dd40e2-ef83-4bc1-bf28-dc427e3e99a0@github.com>
References: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>
 <Bc7-_Ya2oNN4jBvCog5-IiZ56WitX7VVBZVAJQbuVcc=.06dd40e2-ef83-4bc1-bf28-dc427e3e99a0@github.com>
Message-ID: <bandL4zg9gNsoMfXuO1VT4Utcuwn00YbGXyPiSe6bZk=.0c9dbcb4-5a78-4f31-9d97-9427ce430593@github.com>

On Mon, 28 Jun 2021 21:36:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Updated AllModulesCommandTest to use dynamic port launching debuggee.
>> Parsing debuggee listening address functionality is required in several tests (and we have other tests which need to be fixed the same way), so moved the code to new class in jdk.test.lib
>
> test/jdk/com/sun/jdi/JdwpAllowTest.java line 83:
> 
>> 81:             String s = app.getProcessStdout();
>> 82:             JDWP.ListenAddress addr = JDWP.parseListenAddress(s);
>> 83:             if (addr != null) {
> 
> What is going to happen in the case of addr == null?

addr == null means we didn't get "listening for transport" output yet.
We continue to run the loop waiting for the parse-able output

-------------

PR: https://git.openjdk.java.net/jdk/pull/4560

From dholmes at openjdk.java.net  Tue Jun 29 02:28:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 02:28:00 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load
In-Reply-To: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
Message-ID: <RLvXg8YpiIVU2Cxd1oUXkIkpcA27BHhQyQUMJ8vyZkA=.a62d91be-28f4-43b8-8698-f17182b20062@github.com>

On Sat, 26 Jun 2021 17:48:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.

Hi Leonid,

I'm not clear on the details here - please see comments below.

Thanks,
David

src/hotspot/share/code/nmethod.cpp line 1611:

> 1609:       return;
> 1610:     }
> 1611:     mark_as_seen_on_stack();

Not obvious what this actually does in relation to the dequeuing problem.

src/hotspot/share/prims/jvmtiImpl.cpp line 968:

> 966:   for (QueueNode* node = _queue_head; node != NULL; node = node->next()) {
> 967:     node->event().post_compiled_method_load_event(env);
> 968:   }

Can't you dequeue() immediately after calling post_compiled_method_load_event()?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From yyang at openjdk.java.net  Tue Jun 29 03:30:06 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 29 Jun 2021 03:30:06 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one
In-Reply-To: <37m5nc6KDsehgna2Z7xEbz_J5iodCHhUQgpcnXxVEIk=.5cea815d-6cfa-42d2-ba81-391aaaffb1d2@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <ID5uxd8brvT6iLVOWOJ0dAAhvUbwPBdQubzaQ1nH82Y=.73c27ac5-b908-423c-85d6-7e213a5d349c@github.com>
 <37m5nc6KDsehgna2Z7xEbz_J5iodCHhUQgpcnXxVEIk=.5cea815d-6cfa-42d2-ba81-391aaaffb1d2@github.com>
Message-ID: <OGTLUlw8eHXmoe1RFgEbwcaUR1tkmt1rOgHwAbCnS-o=.e627354a-d402-4a0a-9785-f42bca1d1fec@github.com>

On Mon, 28 Jun 2021 13:07:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> If so (and if we don't discover more tools that prefer hex for thread IDs!), then we want to be consistent, so in addition to the native/built in implementation, we should also update:

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java
..to keep the SA implementation in sync. It would be odd to have thread dumps looking more different depending on what generated them.

> And if changing that, also change:
test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java

Thanks for the comments! I will change the corresponding SA implementation and tests.


> > Hi,
> > If you attach WinDbg on Windows to a JVM, you might be glad of the nid=0x... format as that is its choice of base for the thread ids.
> > So this depends on your tools. Maybe frustrated top users outnumber happy WinDbg users for the JVM, and maybe they don't. Maybe this change delights some users and frustrates others.
> 
> Why not do it platform dependent then? This would make sense especially since the type is opaque. Let each platform handling printing. Windows can hex-print its DWORD thread id. Linux can print its kernel LWP. And platforms where the thread id is 64bit, or a structure, can print that.
> 
> For now default implementations could live in `os::Windows::print_thread_id(thread_t)` and `os::Posix::print_thread_id(thread_t)`, respectively.

Will it be too heavy to add a platform-dependent implementation for this small function? As Kevin said, maybe this change delights some users and frustrates others. But since POSIX is the vast majority of users, it may be a better choice to adapt to them. Just IMHO..

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Tue Jun 29 03:42:32 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 29 Jun 2021 03:42:32 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v3]
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <qX2zO_pB8LifAqNObfxcMygHvDwOYfMwRAa5cI660Sk=.712382e3-57db-4053-9960-5680374d1264@github.com>

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  use UINT64_FORMAT; change SA and test impl

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4449/files
  - new: https://git.openjdk.java.net/jdk/pull/4449/files/4baeb175..0f230755

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=01-02

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4449/head:pull/4449

PR: https://git.openjdk.java.net/jdk/pull/4449

From lmesnik at openjdk.java.net  Tue Jun 29 05:52:38 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 29 Jun 2021 05:52:38 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
Message-ID: <6J6aOiqWbHZapyork2iniBsbRjxhxNhsLfiK01kBPlU=.8d7b894a-d848-43e0-a5b7-21e6b0f476c6@github.com>

> The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  Added comment.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4602/files
  - new: https://git.openjdk.java.net/jdk/pull/4602/files/35d5848c..9ea2cb9c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4602&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4602&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4602.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4602/head:pull/4602

PR: https://git.openjdk.java.net/jdk/pull/4602

From lmesnik at openjdk.java.net  Tue Jun 29 06:16:02 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 29 Jun 2021 06:16:02 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <RLvXg8YpiIVU2Cxd1oUXkIkpcA27BHhQyQUMJ8vyZkA=.a62d91be-28f4-43b8-8698-f17182b20062@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <RLvXg8YpiIVU2Cxd1oUXkIkpcA27BHhQyQUMJ8vyZkA=.a62d91be-28f4-43b8-8698-f17182b20062@github.com>
Message-ID: <GRP0dGaQbDuSal62I4hbLwkkRxZYzviNrkVFX57HCFE=.b9751a49-c034-4793-950a-6bf1ea658247@github.com>

On Tue, 29 Jun 2021 02:24:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added comment.
>
> Hi Leonid,
> 
> I'm not clear on the details here - please see comments below.
> 
> Thanks,
> David

Replied to [@dholmes-ora] comments but don't see any notifications from GitHub yet. Not clear if it is my PR/GitHub/mail issues.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From dholmes at openjdk.java.net  Tue Jun 29 07:45:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 07:45:07 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <6J6aOiqWbHZapyork2iniBsbRjxhxNhsLfiK01kBPlU=.8d7b894a-d848-43e0-a5b7-21e6b0f476c6@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <6J6aOiqWbHZapyork2iniBsbRjxhxNhsLfiK01kBPlU=.8d7b894a-d848-43e0-a5b7-21e6b0f476c6@github.com>
Message-ID: <65S6fJoltY4UvUNCYWeIIouULgtn7OAgBMU12VocwGQ=.ba555918-d9bb-4058-9ade-358fa5a9f2d9@github.com>

On Tue, 29 Jun 2021 05:52:38 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment.

I see the comment update in the PR and email, but no response to my comment about dequeuing within the for-loop.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From lmesnik at openjdk.java.net  Tue Jun 29 07:51:05 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 29 Jun 2021 07:51:05 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <6J6aOiqWbHZapyork2iniBsbRjxhxNhsLfiK01kBPlU=.8d7b894a-d848-43e0-a5b7-21e6b0f476c6@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <6J6aOiqWbHZapyork2iniBsbRjxhxNhsLfiK01kBPlU=.8d7b894a-d848-43e0-a5b7-21e6b0f476c6@github.com>
Message-ID: <xycAMo9cMWjywBDbfYwymgQuy-RGJKBURx8x-WKrwAE=.08580c7f-df2a-41e3-8dfe-a17eb06b3b11@github.com>

On Tue, 29 Jun 2021 05:52:38 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment.

replied to comments

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From lmesnik at openjdk.java.net  Tue Jun 29 07:51:06 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 29 Jun 2021 07:51:06 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <RLvXg8YpiIVU2Cxd1oUXkIkpcA27BHhQyQUMJ8vyZkA=.a62d91be-28f4-43b8-8698-f17182b20062@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <RLvXg8YpiIVU2Cxd1oUXkIkpcA27BHhQyQUMJ8vyZkA=.a62d91be-28f4-43b8-8698-f17182b20062@github.com>
Message-ID: <xh-3NMC4hPMVroUDXNRlvpwJhWew7D55kvMIjX-ecHQ=.f71e0454-712a-4e46-9440-0c3f7caa2e7d@github.com>

On Tue, 29 Jun 2021 02:23:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added comment.
>
> src/hotspot/share/code/nmethod.cpp line 1611:
> 
>> 1609:       return;
>> 1610:     }
>> 1611:     mark_as_seen_on_stack();
> 
> Not obvious what this actually does in relation to the dequeuing problem.

updated comments

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From lmesnik at openjdk.java.net  Tue Jun 29 07:55:07 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 29 Jun 2021 07:55:07 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <RLvXg8YpiIVU2Cxd1oUXkIkpcA27BHhQyQUMJ8vyZkA=.a62d91be-28f4-43b8-8698-f17182b20062@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <RLvXg8YpiIVU2Cxd1oUXkIkpcA27BHhQyQUMJ8vyZkA=.a62d91be-28f4-43b8-8698-f17182b20062@github.com>
Message-ID: <CNB0x_RPMMp_8BseeqyDJZhbqH3GJMyqHXHCnoENXjY=.6e31f896-f05e-48dd-befb-a40c74f0951b@github.com>

On Tue, 29 Jun 2021 02:23:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added comment.
>
> src/hotspot/share/prims/jvmtiImpl.cpp line 968:
> 
>> 966:   for (QueueNode* node = _queue_head; node != NULL; node = node->next()) {
>> 967:     node->event().post_compiled_method_load_event(env);
>> 968:   }
> 
> Can't you dequeue() immediately after calling post_compiled_method_load_event()?

Seems that dequeue in for-loop deletes the node which posted. It is possible to update the loop to have update dequeue in the same iteration however, I don't think it is a good idea to mix iterator/deletion in the same loop. What is the reason for this change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From luhenry at openjdk.java.net  Tue Jun 29 08:25:05 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Tue, 29 Jun 2021 08:25:05 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks
In-Reply-To: <v9lva0LCv61S2vOl-fOiZFzQlYOWDkglILhACCEZ9oM=.ac9e240b-7b7d-4484-a7e1-3c1b6f2a5569@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <v9lva0LCv61S2vOl-fOiZFzQlYOWDkglILhACCEZ9oM=.ac9e240b-7b7d-4484-a7e1-3c1b6f2a5569@github.com>
Message-ID: <gyYcNZmg-wYzdwSCRYceK6dHgk_pbCpuKO2qwJKardc=.c5ab50b0-11ba-441d-90ab-8936295b574a@github.com>

On Wed, 9 Jun 2021 19:04:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
>> 
>> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
>> 
>> # `Prof1`
>> 
>> public class Prof1 {
>> 
>>     public static void main(String[] args) {
>>         StringBuilder sb = new StringBuilder();
>>         for (int i = 0; i < 1000000; i++) {
>>             sb.append("ab");
>>             sb.delete(0, 1);
>>         }
>>         System.out.println(sb.length());
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>>         (t  0.5,s  0.2) Prof1::main
>>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>>         (t  0.0,s  0.0) java.lang.String::getBytes
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> 
>> - With `StubRoutinesBlob::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>>         (t 99.8,s  0.2) Prof1::main
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
>> 
>> 
>> # `Prof2`
>> 
>> import java.util.function.Supplier;
>> 
>> public class Prof2 {
>> 
>>     public static void main(String[] args) {
>>         var rand = new java.util.Random(0);
>>         Supplier[] suppliers = {
>>                 () -> 0,
>>                 () -> 1,
>>                 () -> 2,
>>                 () -> 3,
>>         };
>> 
>>         long sum = 0;
>>         for (int i = 0; i >= 0; i++) {
>>             sum += (int)suppliers[i % suppliers.length].get();
>>         }
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>>         (t 39.2,s 35.2) Prof2::main
>>         (t  1.4,s  1.4) Prof2::lambda$main$3
>>         (t  1.0,s  1.0) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.Thread::exit
>>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>> 
>> 
>> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 74.1,s 70.3) Prof2::main
>>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>>         (t  1.2,s  1.2) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$3
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>
> Hi Ludovic,
> Thank you for working on this fix in the AsyncGetCallTrace.
> What version of JDK release do you intent to target?
> Just wanted to make sure you know the JDK 17 development cycle will be closed tomorrow for P4 bugs and enhancements. The repository will be forked and the RDP 1 phase started.
> I doubt the review of your fix will be completed by this time.
> So, please, keep in mind your PR will go to 18, not 17.
> Thanks,
> Serguei

@sspitsyn how could we take this change forward? Thank you

-------------

PR: https://git.openjdk.java.net/jdk/pull/4436

From kevinw at openjdk.java.net  Tue Jun 29 09:09:04 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 29 Jun 2021 09:09:04 GMT
Subject: RFR: 8260540: serviceability/jdwp/AllModulesCommandTest.java
 failed with "Debuggee error: 'ERROR: transport error 202: bind failed:
 Address already in use'"
In-Reply-To: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>
References: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>
Message-ID: <_sxoCaSVycIWhHvweU9xxsE2A0fkzr5BdQSVOZYBAOY=.f9e5df56-0024-4077-a9c0-8971b11bca47@github.com>

On Tue, 22 Jun 2021 21:01:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Updated AllModulesCommandTest to use dynamic port launching debuggee.
> Parsing debuggee listening address functionality is required in several tests (and we have other tests which need to be fixed the same way), so moved the code to new class in jdk.test.lib

Marked as reviewed by kevinw (Committer).

OK, so we let the debugee JVM find its own port, and start using it, then JDWP.parseListenAddress() decodes the debugee output to find the port in use.  findFreePort used previously was not working well, or was racing with other tests and clashing.  Sounds good.

I'm not sure in Debugee.java why we use an array for: JDWP.ListenAddress[] listenAddress

-------------

PR: https://git.openjdk.java.net/jdk/pull/4560

From sgehwolf at openjdk.java.net  Tue Jun 29 09:11:05 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 29 Jun 2021 09:11:05 GMT
Subject: [jdk17] RFR: 8269232: assert(!is_jweak(handle)) failed: wrong
 method for detroying jweak
In-Reply-To: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>
References: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>
Message-ID: <qA9Cjl7B5m93yYvwENvALhXf59IEmwjbPBgxIIdFvZw=.91e1b947-654e-4570-9860-57d336aa5958@github.com>

On Mon, 28 Jun 2021 20:41:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Don't let node->strongRef go below 0, or we end up thinking we still have a strongref when it is a weakref. Note the fact that we are doing nesting counts is still a bug (and the main cause of this issue). However, the fix for that is more complex, and for 17 I would prefer to just apply this simpler fix. For addressing the bigger issue, I filed the following:
> 
> [JDK-8269542](https://bugs.openjdk.java.net/browse/JDK-8269542): JDWP: EnableCollection support is no longer spec compliant after [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987)

I can no longer reproduce the crash with this patch. Thumbs up!

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/165

From dholmes at openjdk.java.net  Tue Jun 29 10:33:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 10:33:04 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <CNB0x_RPMMp_8BseeqyDJZhbqH3GJMyqHXHCnoENXjY=.6e31f896-f05e-48dd-befb-a40c74f0951b@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <RLvXg8YpiIVU2Cxd1oUXkIkpcA27BHhQyQUMJ8vyZkA=.a62d91be-28f4-43b8-8698-f17182b20062@github.com>
 <CNB0x_RPMMp_8BseeqyDJZhbqH3GJMyqHXHCnoENXjY=.6e31f896-f05e-48dd-befb-a40c74f0951b@github.com>
Message-ID: <x_qbyKl298orrN5KRGok-uhtNkypgjD7F3peecId-eY=.7a3b6b2d-0324-4392-b3ff-06472867de8d@github.com>

On Tue, 29 Jun 2021 07:51:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiImpl.cpp line 968:
>> 
>>> 966:   for (QueueNode* node = _queue_head; node != NULL; node = node->next()) {
>>> 967:     node->event().post_compiled_method_load_event(env);
>>> 968:   }
>> 
>> Can't you dequeue() immediately after calling post_compiled_method_load_event()?
>
> Seems that dequeue in for-loop deletes the node which posted. It is possible to update the loop to have update dequeue in the same iteration however, I don't think it is a good idea to mix iterator/deletion in the same loop. What is the reason for this change?

Just to save iterating the queue twice. And that is what the original loop did - you just have to switch the order of processing and deleting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From kevinw at openjdk.java.net  Tue Jun 29 11:52:09 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 29 Jun 2021 11:52:09 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v3]
In-Reply-To: <qX2zO_pB8LifAqNObfxcMygHvDwOYfMwRAa5cI660Sk=.712382e3-57db-4053-9960-5680374d1264@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <qX2zO_pB8LifAqNObfxcMygHvDwOYfMwRAa5cI660Sk=.712382e3-57db-4053-9960-5680374d1264@github.com>
Message-ID: <7d4eUfnPx_xpdF2AbHyp6Kuzzg7ppyZesyXMusS7lDk=.2c96c78a-d3af-4684-b5c6-b5393c6a1ced@github.com>

On Tue, 29 Jun 2021 03:42:32 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use UINT64_FORMAT; change SA and test impl

Maybe we can't make everybody happy, but what we have now is a good improvement (for many/most).
I tested with the SA change, the test passes, and manually on Windows I ran jstack and jhsdb jstack, jhsdb clhsdb.

> Will it be too heavy to add a platform-dependent implementation for this small function?...
I think so.
I think this looks good now.

I don't think it's a change we should backport, or at least not quickly, out of concern for people/tools who might be parsing this output.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From kevinw at openjdk.java.net  Tue Jun 29 11:58:04 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 29 Jun 2021 11:58:04 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v3]
In-Reply-To: <qX2zO_pB8LifAqNObfxcMygHvDwOYfMwRAa5cI660Sk=.712382e3-57db-4053-9960-5680374d1264@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <qX2zO_pB8LifAqNObfxcMygHvDwOYfMwRAa5cI660Sk=.712382e3-57db-4053-9960-5680374d1264@github.com>
Message-ID: <LuRJLP3nn2T5CpSXkZQ6aBlwz5lZXNbyDtVC-FwRoQQ=.7afef0a9-672e-4564-a45a-7ecdbb364e48@github.com>

On Tue, 29 Jun 2021 03:42:32 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use UINT64_FORMAT; change SA and test impl

Marked as reviewed by kevinw (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From kevinw at openjdk.java.net  Tue Jun 29 11:58:05 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 29 Jun 2021 11:58:05 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
Message-ID: <qRB2g5KYyuj4BkMuCPfNzLjw7qwZ7XuQ7U_vm9OIQRQ=.07f81ef7-af54-4a7a-89b9-24da35976da1@github.com>

On Mon, 28 Jun 2021 07:46:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore cleanup code

src/hotspot/share/runtime/osThread.cpp line 41:

> 39: // Printing
> 40: void OSThread::print_on(outputStream *st) const {
> 41:   st->print("nid=%d ", thread_id());

Just update the (C) year above from 2019 to 2021.
JhsdbThreadInfoTest.java has it already in the latest revision.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From lmesnik at openjdk.java.net  Tue Jun 29 16:38:29 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 29 Jun 2021 16:38:29 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <65S6fJoltY4UvUNCYWeIIouULgtn7OAgBMU12VocwGQ=.ba555918-d9bb-4058-9ade-358fa5a9f2d9@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <6J6aOiqWbHZapyork2iniBsbRjxhxNhsLfiK01kBPlU=.8d7b894a-d848-43e0-a5b7-21e6b0f476c6@github.com>
 <65S6fJoltY4UvUNCYWeIIouULgtn7OAgBMU12VocwGQ=.ba555918-d9bb-4058-9ade-358fa5a9f2d9@github.com>
Message-ID: <OOxV4kp5hMmenLAeMwRFpLNq5BXA6fRr3PNpIPL4z_k=.a5b47a08-2cca-40c8-9959-405f14055f48@github.com>

On Tue, 29 Jun 2021 07:42:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added comment.
>
> I see the comment update in the PR and email, but no response to my comment about dequeuing within the for-loop.

[@dholmes-ora] I've updated the loop in the post. Seems your comments were removed because I remove the first loop.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From lmesnik at openjdk.java.net  Tue Jun 29 16:38:28 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 29 Jun 2021 16:38:28 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v3]
In-Reply-To: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
Message-ID: <Yh3WWZP3nG5xIDMmTPih3fWZy0akSqhfcAtwOp_Va_k=.af6a4948-6e11-48b1-abe4-a5d982dfce76@github.com>

> The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  post updated.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4602/files
  - new: https://git.openjdk.java.net/jdk/pull/4602/files/9ea2cb9c..2e222f03

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4602&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4602&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4602.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4602/head:pull/4602

PR: https://git.openjdk.java.net/jdk/pull/4602

From amenkov at openjdk.java.net  Tue Jun 29 16:49:04 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 29 Jun 2021 16:49:04 GMT
Subject: RFR: 8260540: serviceability/jdwp/AllModulesCommandTest.java
 failed with "Debuggee error: 'ERROR: transport error 202: bind failed:
 Address already in use'"
In-Reply-To: <_sxoCaSVycIWhHvweU9xxsE2A0fkzr5BdQSVOZYBAOY=.f9e5df56-0024-4077-a9c0-8971b11bca47@github.com>
References: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>
 <_sxoCaSVycIWhHvweU9xxsE2A0fkzr5BdQSVOZYBAOY=.f9e5df56-0024-4077-a9c0-8971b11bca47@github.com>
Message-ID: <MoBjMkgSWUI3YY5d8OYipm6vGmhz6rlDAh6bzx1GyUw=.b1c6488c-ed14-4072-a1ed-80848d0be7e1@github.com>

On Tue, 29 Jun 2021 09:05:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I'm not sure in Debugee.java why we use an array for: JDWP.ListenAddress[] listenAddress

We set the value of the local variable in lambda, so the variable must be final or (as in this case) effectively final

-------------

PR: https://git.openjdk.java.net/jdk/pull/4560

From coleenp at openjdk.java.net  Tue Jun 29 18:02:07 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 29 Jun 2021 18:02:07 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v3]
In-Reply-To: <xh-3NMC4hPMVroUDXNRlvpwJhWew7D55kvMIjX-ecHQ=.f71e0454-712a-4e46-9440-0c3f7caa2e7d@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <RLvXg8YpiIVU2Cxd1oUXkIkpcA27BHhQyQUMJ8vyZkA=.a62d91be-28f4-43b8-8698-f17182b20062@github.com>
 <xh-3NMC4hPMVroUDXNRlvpwJhWew7D55kvMIjX-ecHQ=.f71e0454-712a-4e46-9440-0c3f7caa2e7d@github.com>
Message-ID: <J2x_rNLv9iKH8K2doEUp4xKOPuA3BPuqTCrSE08MSSI=.a8e75b97-c28a-4ee8-addf-1f6736c8bf6c@github.com>

On Tue, 29 Jun 2021 07:46:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 1611:
>> 
>>> 1609:       return;
>>> 1610:     }
>>> 1611:     mark_as_seen_on_stack();
>> 
>> Not obvious what this actually does in relation to the dequeuing problem.
>
> updated comments

I'm not 100% this is needed because we don't handshake this thread and we just checked that it can't be converted to zombie, but I don't think this hurts anything and I thought it might be needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From coleenp at openjdk.java.net  Tue Jun 29 18:02:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 29 Jun 2021 18:02:06 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v3]
In-Reply-To: <Yh3WWZP3nG5xIDMmTPih3fWZy0akSqhfcAtwOp_Va_k=.af6a4948-6e11-48b1-abe4-a5d982dfce76@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <Yh3WWZP3nG5xIDMmTPih3fWZy0akSqhfcAtwOp_Va_k=.af6a4948-6e11-48b1-abe4-a5d982dfce76@github.com>
Message-ID: <9Wb7MLLfo_Rud35xgv0mnJC0XdomfmpYJfwyUaWTV5o=.eac10b02-e8d1-4931-abf6-a57c0ef5a35c@github.com>

On Tue, 29 Jun 2021 16:38:28 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   post updated.

Looks good!

src/hotspot/share/prims/jvmtiImpl.cpp line 968:

> 966:   while (_queue_head != NULL) {
> 967:     _queue_head->event().post_compiled_method_load_event(env);
> 968:     dequeue();

Good find!  So we _can_ zombie the nmethod after we take it off the list.  Makes a lot of sense.  Thank you for your perseverance in tracking this down!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4602

From amenkov at openjdk.java.net  Tue Jun 29 18:43:11 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 29 Jun 2021 18:43:11 GMT
Subject: Integrated: 8260540: serviceability/jdwp/AllModulesCommandTest.java
 failed with "Debuggee error: 'ERROR: transport error 202: bind failed:
 Address already in use'"
In-Reply-To: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>
References: <bwq8jIChG-oxGT73FG_vUEpXFZ5qdwHehXLMB2mFJ-c=.df239c66-aca1-4c22-b822-33fe6c5f2911@github.com>
Message-ID: <DY-_G58v05Rit5d679Xi5e54aIhnTvFoOj9D7IqijxY=.90ee4a6a-4f82-478e-9e00-91fcc279cbb9@github.com>

On Tue, 22 Jun 2021 21:01:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Updated AllModulesCommandTest to use dynamic port launching debuggee.
> Parsing debuggee listening address functionality is required in several tests (and we have other tests which need to be fixed the same way), so moved the code to new class in jdk.test.lib

This pull request has now been integrated.

Changeset: 7a23c9cb
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7a23c9cbb7d09c4e6c4e8d9b2f912e41d60fd05e
Stats:     121 lines in 7 files changed: 62 ins; 33 del; 26 mod

8260540: serviceability/jdwp/AllModulesCommandTest.java failed with "Debuggee error: 'ERROR: transport error 202: bind failed: Address already in use'"

Reviewed-by: sspitsyn, kevinw

-------------

PR: https://git.openjdk.java.net/jdk/pull/4560

From cjplummer at openjdk.java.net  Tue Jun 29 18:45:01 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 29 Jun 2021 18:45:01 GMT
Subject: [jdk17] Integrated: 8269232: assert(!is_jweak(handle)) failed: wrong
 method for detroying jweak
In-Reply-To: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>
References: <FYjJ1J7k8YyyReVxLGbr0XY7GaOI3kZPv9ArO0SaTWI=.2aa25d3a-fdf1-4b80-a5e4-85a33b62789c@github.com>
Message-ID: <uKg-R9Y-2e6CbbghwnO9hT-9AI2e0lnwoTVH4lf-bgM=.c8810785-7b77-46c4-a78c-4200a443cd7a@github.com>

On Mon, 28 Jun 2021 20:41:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Don't let node->strongRef go below 0, or we end up thinking we still have a strongref when it is a weakref. Note the fact that we are doing nesting counts is still a bug (and the main cause of this issue). However, the fix for that is more complex, and for 17 I would prefer to just apply this simpler fix. For addressing the bigger issue, I filed the following:
> 
> [JDK-8269542](https://bugs.openjdk.java.net/browse/JDK-8269542): JDWP: EnableCollection support is no longer spec compliant after [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987)

This pull request has now been integrated.

Changeset: 401cb0ad
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/401cb0ad5517f5962061c7155354380a4c342ddf
Stats:     9 lines in 2 files changed: 6 ins; 0 del; 3 mod

8269232: assert(!is_jweak(handle)) failed: wrong method for detroying jweak

Reviewed-by: rkennke, amenkov, sspitsyn, sgehwolf

-------------

PR: https://git.openjdk.java.net/jdk17/pull/165

From cjplummer at openjdk.java.net  Tue Jun 29 18:49:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 29 Jun 2021 18:49:08 GMT
Subject: Integrated: 8269268: JDWP: Properly fix thread lookup assert in
 findThread()
In-Reply-To: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
References: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
Message-ID: <Cc68irsEyX-f6pm_1hSGJOltjIPsf9kO5rp8W8IE5ao=.7b1ff992-fbbe-458f-a206-381b4380f0a9@github.com>

On Thu, 24 Jun 2021 05:17:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Re-enable the assert that was disabled (with some overhead) by [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation is in the CR and also in comments included with the changes.
> 
> I tested by running `vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java` and `vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java` 100's of times, and did not see any failures. I also verified the original issue was still reproducible by temporarily not setting `gdata->handlingVMDeath = JNI_TRUE`, which did trigger the assert as expected.

This pull request has now been integrated.

Changeset: 7ca753bf
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7ca753bf0cb58ff0f82a7e9baee177a6da9f56e7
Stats:     38 lines in 3 files changed: 31 ins; 0 del; 7 mod

8269268: JDWP: Properly fix thread lookup assert in findThread()

Reviewed-by: kevinw, amenkov, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4580

From dholmes at openjdk.java.net  Tue Jun 29 22:33:21 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 22:33:21 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads
Message-ID: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>

Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.

This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.

The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.

A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).

The trickiest changes related to the CompilerThreads, so they need particular scrutiny.

Testing: tiers 1-3

Thanks,
David

-------------

Commit messages:
 - Removed leftover experimental code
 - Remove unnedded include
 - Fixed old comment
 - Set native priority before starting the CompilerThread.
 - 8269466: Factor out the common code for initializing and starting internal VM JavaThreads
 - interim 2 - template method doesn't work
 - Interim

Changes: https://git.openjdk.java.net/jdk/pull/4629/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269466
  Stats: 278 lines in 13 files changed: 63 ins; 140 del; 75 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4629.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4629/head:pull/4629

PR: https://git.openjdk.java.net/jdk/pull/4629

From david.holmes at oracle.com  Tue Jun 29 22:37:21 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Jun 2021 08:37:21 +1000
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads
In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
Message-ID: <0dfe8a38-b2cb-8e4e-1e4e-6c3a556ce13e@oracle.com>

And apologies for the old commits - I forgot to clear them out before 
creating the PR.

David

On 30/06/2021 8:33 am, David Holmes wrote:
> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
> 
> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
> 
> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
> 
> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
> 
> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David
> 
> -------------
> 
> Commit messages:
>   - Removed leftover experimental code
>   - Remove unnedded include
>   - Fixed old comment
>   - Set native priority before starting the CompilerThread.
>   - 8269466: Factor out the common code for initializing and starting internal VM JavaThreads
>   - interim 2 - template method doesn't work
>   - Interim
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4629/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8269466
>    Stats: 278 lines in 13 files changed: 63 ins; 140 del; 75 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4629.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4629/head:pull/4629
> 
> PR: https://git.openjdk.java.net/jdk/pull/4629
> 

From dholmes at openjdk.java.net  Tue Jun 29 23:39:03 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Jun 2021 23:39:03 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v3]
In-Reply-To: <Yh3WWZP3nG5xIDMmTPih3fWZy0akSqhfcAtwOp_Va_k=.af6a4948-6e11-48b1-abe4-a5d982dfce76@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <Yh3WWZP3nG5xIDMmTPih3fWZy0akSqhfcAtwOp_Va_k=.af6a4948-6e11-48b1-abe4-a5d982dfce76@github.com>
Message-ID: <Jo4YRa1RyWt9amHd4mfnYcoQtO73e9-WRF3uARoowXQ=.7cdee6ff-936b-4c4f-a908-3f792fc0745f@github.com>

On Tue, 29 Jun 2021 16:38:28 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   post updated.

Looks good!

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4602

From sspitsyn at openjdk.java.net  Wed Jun 30 00:21:03 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 30 Jun 2021 00:21:03 GMT
Subject: RFR: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load [v3]
In-Reply-To: <Yh3WWZP3nG5xIDMmTPih3fWZy0akSqhfcAtwOp_Va_k=.af6a4948-6e11-48b1-abe4-a5d982dfce76@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
 <Yh3WWZP3nG5xIDMmTPih3fWZy0akSqhfcAtwOp_Va_k=.af6a4948-6e11-48b1-abe4-a5d982dfce76@github.com>
Message-ID: <SAC_yUwod-6FxiSWEcLQSbVKt2D3k7uVkVHgLfAjqWg=.bd16d370-4df5-4d64-89f1-eeaa8011b45b@github.com>

On Tue, 29 Jun 2021 16:38:28 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   post updated.

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From jwilhelm at openjdk.java.net  Wed Jun 30 00:39:07 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 00:39:07 GMT
Subject: RFR: Merge jdk17
Message-ID: <ibzm2NYoMriKxwlB3J9JYC6vLcd3KsAvlcWg3_5kh6c=.8d2f87a0-3042-44fb-9315-2778cd202d34@github.com>

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8269034: AccessControlException for SunPKCS11 daemon threads
 - 8269529: javax/swing/reliability/HangDuringStaticInitialization.java fails in Windows debug build
 - 8269232: assert(!is_jweak(handle)) failed: wrong method for detroying jweak
 - 8268884: C2: Compile::remove_speculative_types must iterate top-down
 - 8249646: Runtime.exec(String, String[], File) documentation contains literal {@link ...}
 - 8268699: Shenandoah: Add test for JDK-8268127
 - 8269517: compiler/loopopts/TestPartialPeelingSinkNodes.java crashes with -XX:+VerifyGraphEdges
 - 8269126: Rename G1AllowPreventiveGC option to G1UsePreventiveGC

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4630/files
  Stats: 127 lines in 11 files changed: 70 ins; 17 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4630.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4630/head:pull/4630

PR: https://git.openjdk.java.net/jdk/pull/4630

From sspitsyn at openjdk.java.net  Wed Jun 30 01:04:00 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 30 Jun 2021 01:04:00 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads
In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
Message-ID: <LnORBf1Jp2uZzPilWV_3F95ycKV5Szgwx7uV-QsL1kw=.4698c756-7f6e-4384-ab1a-90df9fcd3233@github.com>

On Tue, 29 Jun 2021 21:55:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
> 
> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
> 
> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
> 
> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
> 
> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

Hi David,
This looks good to me.
Some copyright comments need update.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4629

From dholmes at openjdk.java.net  Wed Jun 30 01:14:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Jun 2021 01:14:06 GMT
Subject: RFR: 8269268: JDWP: Properly fix thread lookup assert in
 findThread() [v2]
In-Reply-To: <9f0X6MVyTIMTlk17Mqf2QDNeRk8mE7IM1yHvCwg-2lw=.7873ff96-cca0-43ea-9d4b-58a866710a78@github.com>
References: <Dfu7x9NrVRy0M01Hq6-Gx7HGfvD8Wvu9UZtjBvo9IhQ=.36177211-8a2e-4553-9861-8e8725ce3453@github.com>
 <9f0X6MVyTIMTlk17Mqf2QDNeRk8mE7IM1yHvCwg-2lw=.7873ff96-cca0-43ea-9d4b-58a866710a78@github.com>
Message-ID: <H4xleK_xkf_pI9AQOWIQVJdHwmt1ouUVJxbTPcKfLb0=.b9b4f363-a596-4344-954f-b46bd242eab7@github.com>

On Thu, 24 Jun 2021 16:51:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Re-enable the assert that was disabled (with some overhead) by [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation is in the CR and also in comments included with the changes.
>> 
>> I tested by running `vmTestbase/nsk/jdb/suspend/suspend001/suspend001.java` and `vmTestbase/nsk/jdb/wherei/wherei001/wherei001.java` 100's of times, and did not see any failures. I also verified the original issue was still reproducible by temporarily not setting `gdata->handlingVMDeath = JNI_TRUE`, which did trigger the assert as expected.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename flag and make some minor adjustments.

Just to follow up:

> As far as any other synchronizing or memory barriers being needed, I'm a bit unclear on that part. The only thing that matters is that gdata->jvmtiCallBacksCleared being set true is visible to other threads before the callbacks get cleared. It seems the call to SetEventCallbacks() should ensure this.

In practice this should be fine as `SetEventCallbacks` acquires a monitor/mutex; and `findThread` is also called while holding a monitor, so although different monitors, in practice the acquire/release semantics should make this work. Additionally the complexity of the interaction between the two threads involved will introduce other synchronization actions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4580

From jwilhelm at openjdk.java.net  Wed Jun 30 01:25:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 01:25:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <ibzm2NYoMriKxwlB3J9JYC6vLcd3KsAvlcWg3_5kh6c=.8d2f87a0-3042-44fb-9315-2778cd202d34@github.com>
References: <ibzm2NYoMriKxwlB3J9JYC6vLcd3KsAvlcWg3_5kh6c=.8d2f87a0-3042-44fb-9315-2778cd202d34@github.com>
Message-ID: <pM8dWNQGAKaoJTyKNVhtt_9RBXhC2zM70ozT1b9xdOc=.d3381bc7-bb08-4a8e-9002-0a1c78211a27@github.com>

On Wed, 30 Jun 2021 00:31:34 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: ee526a2e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ee526a2ea840aedb97b23538f9d624acbccebc97
Stats:     127 lines in 11 files changed: 70 ins; 17 del; 40 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4630

From jwilhelm at openjdk.java.net  Wed Jun 30 01:25:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 01:25:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <ibzm2NYoMriKxwlB3J9JYC6vLcd3KsAvlcWg3_5kh6c=.8d2f87a0-3042-44fb-9315-2778cd202d34@github.com>
References: <ibzm2NYoMriKxwlB3J9JYC6vLcd3KsAvlcWg3_5kh6c=.8d2f87a0-3042-44fb-9315-2778cd202d34@github.com>
Message-ID: <8_fkYpZLlCG8Nj5dx5WhuZsWDbFnUHu4OWWY735hdr0=.625da0e5-831e-4c10-afbc-aa5364fba16b@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:

 - Merge
 - 8269615: Fix for 8263640 broke Windows build
   
   Reviewed-by: iklam, dcubed
 - 8269268: JDWP: Properly fix thread lookup assert in findThread()
   
   Reviewed-by: kevinw, amenkov, sspitsyn
 - 8260540: serviceability/jdwp/AllModulesCommandTest.java failed with "Debuggee error: 'ERROR: transport error 202: bind failed: Address already in use'"
   
   Reviewed-by: sspitsyn, kevinw
 - 8263640: hs_err improvement: handle class path longer than O_BUFLEN
   
   Reviewed-by: iklam, minqi, dholmes
 - 8269417: Minor clarification on NonblockingQueue utility
   
   Reviewed-by: kbarrett, iwalulya
 - 8269530: runtime/ParallelLoad/ParallelSuperTest.java timeout
   
   Reviewed-by: dholmes, coleenp
 - 8269126: Rename G1AllowPreventiveGC option to G1UsePreventiveGC
   
   Reviewed-by: iwalulya, kbarrett
 - 8261579: AArch64: Support for weaker memory ordering in Atomic
   
   Reviewed-by: adinn, shade
 - 8268821: Split systemDictionaryShared.cpp
   
   Reviewed-by: erikj, ccheung, iklam
 - ... and 103 more: https://git.openjdk.java.net/jdk/compare/0d745ae8...be964f2e

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4630/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4630&range=01
  Stats: 30219 lines in 619 files changed: 17676 ins; 10608 del; 1935 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4630.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4630/head:pull/4630

PR: https://git.openjdk.java.net/jdk/pull/4630

From dholmes at openjdk.java.net  Wed Jun 30 01:31:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Jun 2021 01:31:30 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
Message-ID: <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>

> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
> 
> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
> 
> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
> 
> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
> 
> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fixed copyright years in hpp files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4629/files
  - new: https://git.openjdk.java.net/jdk/pull/4629/files/d4755137..e547e0a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4629&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4629.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4629/head:pull/4629

PR: https://git.openjdk.java.net/jdk/pull/4629

From dholmes at openjdk.java.net  Wed Jun 30 01:34:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Jun 2021 01:34:00 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads
In-Reply-To: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
Message-ID: <ktSJPhE_5UlghFu191ZwCGqrexf_cBnJNhz_bbrye-o=.d83c7a62-7b6e-4329-ae20-c2177f316d5f@github.com>

On Tue, 29 Jun 2021 21:55:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
> 
> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
> 
> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
> 
> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
> 
> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
> 
> Testing: tiers 1-3
> 
> Thanks,
> David

Thanks for the review Serguei!

Copyright notices fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4629

From lmesnik at openjdk.java.net  Wed Jun 30 02:09:07 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 30 Jun 2021 02:09:07 GMT
Subject: Integrated: 8245877: assert(_value != __null) failed: resolving NULL
 _value in JvmtiExport::post_compiled_method_load
In-Reply-To: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
References: <hfMcNILutoyRJuWTCOkkoj5uAQc55DNGbc-meBYb0vg=.8415745d-86c2-4dd1-87b6-00672a7ce602@github.com>
Message-ID: <z0tFHyuDkwBrZYa5l66oSr4HJyn-KkfzcnOkGvehLuY=.b5298c3f-b2b6-4c86-9834-45f012d2c348@github.com>

On Sat, 26 Jun 2021 17:48:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The crash happens because nmethod might become a zombie before it is enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However, it takes ~3K  runs to hit it. I verified the fix by running this test >100K on each platform. Also, I verified that protecting in 'void JvmtiDeferredEventQueue::post(JvmtiEnv* env)' is not enough.

This pull request has now been integrated.

Changeset: b969136b
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b969136b9fcf5f977ebe466f5f9de5c520413e84
Stats:     7 lines in 4 files changed: 3 ins; 1 del; 3 mod

8245877: assert(_value != __null) failed: resolving NULL _value in JvmtiExport::post_compiled_method_load

Reviewed-by: sspitsyn, dholmes, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/4602

From yyang at openjdk.java.net  Wed Jun 30 02:43:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 30 Jun 2021 02:43:30 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v2]
In-Reply-To: <qRB2g5KYyuj4BkMuCPfNzLjw7qwZ7XuQ7U_vm9OIQRQ=.07f81ef7-af54-4a7a-89b9-24da35976da1@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <cN8OK3oKGSVQl-VxX-ZduLCEq7wYAUhYaCbhoEoE_Ms=.b9631246-3fb7-4960-a61e-d43a393bf475@github.com>
 <qRB2g5KYyuj4BkMuCPfNzLjw7qwZ7XuQ7U_vm9OIQRQ=.07f81ef7-af54-4a7a-89b9-24da35976da1@github.com>
Message-ID: <xRYWxfmFRJbltO3vrBwz-LSGc9uTUllk8ioYwRHlvdA=.efa091e9-cc30-40f8-81e3-f7dae1cd28ac@github.com>

On Tue, 29 Jun 2021 11:54:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore cleanup code
>
> src/hotspot/share/runtime/osThread.cpp line 41:
> 
>> 39: // Printing
>> 40: void OSThread::print_on(outputStream *st) const {
>> 41:   st->print("nid=%d ", thread_id());
> 
> Just update the (C) year above from 2019 to 2021.
> JhsdbThreadInfoTest.java has it already in the latest revision.

Updated in both osThread.cpp and test file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Wed Jun 30 02:43:29 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 30 Jun 2021 02:43:29 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v4]
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Yi Yang 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/4449/files
  - new: https://git.openjdk.java.net/jdk/pull/4449/files/0f230755..6d3d0523

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4449/head:pull/4449

PR: https://git.openjdk.java.net/jdk/pull/4449

From stuefe at openjdk.java.net  Wed Jun 30 04:45:08 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 30 Jun 2021 04:45:08 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v4]
In-Reply-To: <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>
Message-ID: <5j7HXm2U9KqM6te-IT7o60Bb3OsLK_temQ4UGi88WWU=.7b8d6548-cf70-49ec-a458-198edf79c35f@github.com>

On Wed, 30 Jun 2021 02:43:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

LGTM

test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java line 64:

> 62: 
> 63:             out.shouldMatch("\".+\" #\\d+ daemon prio=\\d+ tid=0x[0-9a-f]+ nid=[0-9]+ .+ \\[0x[0-9a-f]+]");
> 64:             out.shouldMatch("\"main\" #\\d+ prio=\\d+ tid=0x[0-9a-f]+ nid=[0-9]+ .+ \\[0x[0-9a-f]+]");

small nit, instead of `[0-9]` you could use `\d`, and to match a hex number `\p{XDigit}` could be used. But since you just follow the existing pattern, I leave it up to you whether you want to change this.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Wed Jun 30 06:01:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 30 Jun 2021 06:01:00 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v4]
In-Reply-To: <5j7HXm2U9KqM6te-IT7o60Bb3OsLK_temQ4UGi88WWU=.7b8d6548-cf70-49ec-a458-198edf79c35f@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>
 <5j7HXm2U9KqM6te-IT7o60Bb3OsLK_temQ4UGi88WWU=.7b8d6548-cf70-49ec-a458-198edf79c35f@github.com>
Message-ID: <wOhiDDmQ27AF_TVE1yQ8g8Vg0vvoxAJJX9RbQ9LjRAw=.f805a13b-79b7-4beb-a01c-07fd22ff3a98@github.com>

On Wed, 30 Jun 2021 04:42:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright
>
> test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java line 64:
> 
>> 62: 
>> 63:             out.shouldMatch("\".+\" #\\d+ daemon prio=\\d+ tid=0x[0-9a-f]+ nid=[0-9]+ .+ \\[0x[0-9a-f]+]");
>> 64:             out.shouldMatch("\"main\" #\\d+ prio=\\d+ tid=0x[0-9a-f]+ nid=[0-9]+ .+ \\[0x[0-9a-f]+]");
> 
> small nit, instead of `[0-9]` you could use `\d`, and to match a hex number `\p{XDigit}` could be used. But since you just follow the existing pattern, I leave it up to you whether you want to change this.

Good catch! [`\p{XDigit}`](https://www.tutorialspoint.com/javaregex/javaregex_posix_class_xdigit.htm) seems a standard/better way to match any hexadecimal character than `[0-9a-fA-F]+`

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Wed Jun 30 06:30:07 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 30 Jun 2021 06:30:07 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v4]
In-Reply-To: <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
 <4_6BIdsGYYONAjubvPtHZakuSRRrM3N5RSKK5-HFI-8=.95ceff04-68cc-4ae5-8338-6e61bbf6edcc@github.com>
Message-ID: <0m0q3DCpLM8PFQK11Kur48hGpRPxT5JOa3L2klxlGMg=.c1330a91-4e0d-4fc8-a1ff-1930369fe9ef@github.com>

On Wed, 30 Jun 2021 02:43:29 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
>> 
>> Jstack Before:
>> 
>> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
>> 
>> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
>> 
>> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
>> 
>> Jstack After:
>> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
>> 
>> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
>> 
>> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
>> 
>> Top:
>>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
>> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> 
> On 28/06/2021 6:49 pm, Thomas Stuefe wrote:
> 
> > On Mon, 28 Jun 2021 07:37:10 GMT, Yi Yang <yyang at openjdk.org> wrote:
> > > > src/hotspot/share/runtime/osThread.cpp line 41:
> > > > > 39: // Printing
> > > > > 40: void OSThread::print_on(outputStream *st) const {
> > > > > 41:   st->print("nid=%d ", thread_id());
> > > > 
> > > > 
> > > > thread_id is of an opaque type (eg pthread_t). I think we can reasonably assume its numeric, but I would print it as an unsigned 64bit int just in case.
> > > 
> > > 
> > > Hi Thomas, we can not use other format specifiers (`%ld`,`%llu`) after my practice, because it can not compile on my mac:
> > 
> > 
> > You'd do:
> > print("nid: " UINT64_FORMAT, (uint64_t) id):;
> > thread_t is, among other things, pthread_t, which is opaque. Any current code treating that as signed int is incorrect too.
> 
> If it is opaque then I don't see how signed or unsigned makes any
> difference. You are assuming it can just be treated as a 64-bit value;
> whether you interpret that as a signed or unsigned value just changes
> how you print it. I agree printing only positive values is nicer visually.
> 
> David

@dholmes-ora David, can you plz take a look at latest versions once you have time. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4449

From yyang at openjdk.java.net  Wed Jun 30 06:38:30 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 30 Jun 2021 06:38:30 GMT
Subject: RFR: 8268425: Show decimal nid of OSThread instead of hex format
 one [v5]
In-Reply-To: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
References: <2XpHch1KL91iW9wQ9VdboCFdkyUxdCwCq_-Dad6zo4E=.b01db185-1596-4f0c-b1ee-2d125d50963c@github.com>
Message-ID: <N9wrxWLSAR641XaAwfdNO2OiT76zhTbC7DcjbmJG6zo=.e96e776e-d3a1-4d60-818c-1cb3ef03a57e@github.com>

> From users' perspective, we can find corresponding os thread via top directly, otherwise, we must convert hex format based nid to an integer, and find that thread via `top -pid <pid>`. This slightly facilitates our debugging process, but would obviously break some existing jstack analysis tool.
> 
> Jstack Before:
> 
> "ParGC Thread#7" os_prio=0 cpu=103260.18ms elapsed=5255043.58s tid=0x00007f967000b000 nid=0x12e67 runnable
> 
> "ParGC Thread#8" os_prio=0 cpu=104818.76ms elapsed=5255043.58s tid=0x00007f967000c000 nid=0x12e68 runnable
> 
> "ParGC Thread#9" os_prio=0 cpu=102164.69ms elapsed=5255043.58s tid=0x00007f967000e000 nid=0x12e69 runnable
> 
> Jstack After:
> "G1 Conc#0" os_prio=0 cpu=0.03ms elapsed=1295.27s tid=0x00007f99dc096490 nid=117707 runnable
> 
> "G1 Refine#0" os_prio=0 cpu=0.06ms elapsed=1295.22s tid=0x00007f99dc2cad20 nid=117708 runnable
> 
> "G1 Service" os_prio=0 cpu=87.05ms elapsed=1295.22s tid=0x00007f99dc2cc140 nid=117709 runnable
> 
> Top:
>    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
>  71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
>  50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 java
>  99923 root 10 -10 288520 163228 5088 S 5.9 0.0 6463:53 AliYunDun

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  use \p{XDigit}

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4449/files
  - new: https://git.openjdk.java.net/jdk/pull/4449/files/6d3d0523..7a30c3df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4449&range=03-04

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4449.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4449/head:pull/4449

PR: https://git.openjdk.java.net/jdk/pull/4449

From sspitsyn at openjdk.java.net  Wed Jun 30 09:21:05 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 30 Jun 2021 09:21:05 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v3]
In-Reply-To: <jfohRNi3z8LnjHcxEzmJNhuO7nKKEtBY5bhR-8uycVI=.b410939d-7166-4ea7-a046-c8ca8f2dcc93@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <jfohRNi3z8LnjHcxEzmJNhuO7nKKEtBY5bhR-8uycVI=.b410939d-7166-4ea7-a046-c8ca8f2dcc93@github.com>
Message-ID: <eebr3nRX7hK2JWexDfv8WJD4f6w-YzBPZ-A2ps3RquU=.1b6132d6-0c47-4b07-9e66-e1563b2b0b5c@github.com>

On Fri, 18 Jun 2021 08:56:32 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime stub (like arraycopy), a vtable stub, or the prolog of a compiled method,  it wouldn't be able to detect the sender (caller) frame for multiple reasons. This patch fixes these cases through adding CodeBlob-specific frame parser which are in the best position to know how a frame is setup.
>> 
>> The following examples have been profiled with honest-profiler which uses `AsyncGetCallTrace`.
>> 
>> # `Prof1`
>> 
>> public class Prof1 {
>> 
>>     public static void main(String[] args) {
>>         StringBuilder sb = new StringBuilder();
>>         for (int i = 0; i < 1000000; i++) {
>>             sb.append("ab");
>>             sb.delete(0, 1);
>>         }
>>         System.out.println(sb.length());
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 99.4,s 99.4) AGCT::Unknown Java[ERR=-5]
>>         (t  0.5,s  0.2) Prof1::main
>>         (t  0.2,s  0.2) java.lang.AbstractStringBuilder::append
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::shift
>>         (t  0.0,s  0.0) java.lang.String::getBytes
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>>         (t  0.0,s  0.0) java.lang.StringBuilder::delete
>>         (t  0.2,s  0.0) java.lang.StringBuilder::append
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::delete
>>         (t  0.0,s  0.0) java.lang.AbstractStringBuilder::putStringAt
>> 
>> - With `StubRoutinesBlob::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 98.7,s 98.7) java.lang.AbstractStringBuilder::ensureCapacityInternal
>>         (t  0.9,s  0.9) java.lang.AbstractStringBuilder::delete
>>         (t 99.8,s  0.2) Prof1::main
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) AGCT::Unknown Java[ERR=-5]
>>         (t 98.8,s  0.0) java.lang.AbstractStringBuilder::append
>>         (t 98.8,s  0.0) java.lang.StringBuilder::append
>>         (t  0.9,s  0.0) java.lang.StringBuilder::delete
>> 
>> 
>> # `Prof2`
>> 
>> import java.util.function.Supplier;
>> 
>> public class Prof2 {
>> 
>>     public static void main(String[] args) {
>>         var rand = new java.util.Random(0);
>>         Supplier[] suppliers = {
>>                 () -> 0,
>>                 () -> 1,
>>                 () -> 2,
>>                 () -> 3,
>>         };
>> 
>>         long sum = 0;
>>         for (int i = 0; i >= 0; i++) {
>>             sum += (int)suppliers[i % suppliers.length].get();
>>         }
>>     }
>> }
>> 
>> 
>> - Baseline:
>> 
>> Flat Profile (by method):
>>         (t 60.7,s 60.7) AGCT::Unknown Java[ERR=-5]
>>         (t 39.2,s 35.2) Prof2::main
>>         (t  1.4,s  1.4) Prof2::lambda$main$3
>>         (t  1.0,s  1.0) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>>         (t  0.0,s  0.0) java.lang.Thread::exit
>>         (t  0.9,s  0.0) Prof2$$Lambda$2.0x0000000800c00c28::get
>>         (t  1.0,s  0.0) Prof2$$Lambda$3.0x0000000800c01000::get
>>         (t  1.4,s  0.0) Prof2$$Lambda$4.0x0000000800c01220::get
>>         (t  0.7,s  0.0) Prof2$$Lambda$1.0x0000000800c00a08::get
>> 
>> 
>> - With `VtableBlob::FrameParser` and `nmethod::FrameParser`:
>> 
>> Flat Profile (by method):
>>         (t 74.1,s 70.3) Prof2::main
>>         (t  6.5,s  5.5) Prof2$$Lambda$29.0x0000000800081220::get
>>         (t  6.6,s  5.4) Prof2$$Lambda$28.0x0000000800081000::get
>>         (t  5.7,s  5.0) Prof2$$Lambda$26.0x0000000800080a08::get
>>         (t  5.9,s  5.0) Prof2$$Lambda$27.0x0000000800080c28::get
>>         (t  4.9,s  4.9) AGCT::Unknown Java[ERR=-5]
>>         (t  1.2,s  1.2) Prof2::lambda$main$2
>>         (t  0.9,s  0.9) Prof2::lambda$main$3
>>         (t  0.9,s  0.9) Prof2::lambda$main$1
>>         (t  0.7,s  0.7) Prof2::lambda$main$0
>>         (t  0.1,s  0.1) AGCT::Unknown not Java[ERR=-3]
>
> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Hi Ludovic,
You need two reviews including one (R)eviewer before integration of your fix.
Thanks,
Serguei

-------------

PR: https://git.openjdk.java.net/jdk/pull/4436

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun 30 11:49:51 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 30 Jun 2021 11:49:51 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v2]
In-Reply-To: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
Message-ID: <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

?????? ??????? 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 8268764
 - 8268764: Use Long.hashCode() instead of int-cast where applicable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4491/files
  - new: https://git.openjdk.java.net/jdk/pull/4491/files/27233ae1..12a1d3ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=00-01

  Stats: 44011 lines in 878 files changed: 23038 ins; 17963 del; 3010 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4491.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491

PR: https://git.openjdk.java.net/jdk/pull/4491

From kevinw at openjdk.java.net  Wed Jun 30 13:23:14 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 30 Jun 2021 13:23:14 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v2]
In-Reply-To: <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>
Message-ID: <kQskR6msy1oj6QYFJZruPlVBkbchJQb7R-quaPk0r74=.4075ca4a-5724-4b7d-866e-e8895a9a721d@github.com>

On Wed, 30 Jun 2021 11:49:51 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? 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 8268764
>  - 8268764: Use Long.hashCode() instead of int-cast where applicable

The changes look good to me, we have done the same thing elsewhere.  This changes things in different functional areas, which is maybe unusual, but seems fine for a small change as long as nobody objects.

Some of the files also need a (C) year update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4491

From pchilanomate at openjdk.java.net  Wed Jun 30 15:57:01 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 30 Jun 2021 15:57:01 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
Message-ID: <fGk8kHg2GTT2NnXUy6GMD87cET1gIWm3yXZyYXNicoM=.55d3a904-086a-43fb-901d-32b58679b55d@github.com>

On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
>> 
>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
>> 
>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
>> 
>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
>> 
>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright years in hpp files

Hi David,

Changes look good to me.

Thanks,
Patricio

-------------

Marked as reviewed by pchilanomate (Committer).

PR: https://git.openjdk.java.net/jdk/pull/4629

From dcubed at openjdk.java.net  Wed Jun 30 16:46:05 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 16:46:05 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
Message-ID: <2wxnNNwh--ROik5g1EyJCB9ibDViy96wjb1Y6-eXoFw=.5e58d3cc-2fa3-49f5-a1fc-3529db4f871b@github.com>

On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
>> 
>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
>> 
>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
>> 
>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
>> 
>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright years in hpp files

Looks good to me. I had a hard time with all the whitespace indentation
changes. Previously I would look at the webrev to filter out that whitespace
difference, but I guess webrev via GitHub doesn't do that anymore.

I'm going to download the patch and do one more sanity check
locally so I can convince myself that nothing unexpected changed.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4629

From dcubed at openjdk.java.net  Wed Jun 30 17:08:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 17:08:10 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
Message-ID: <Uo9S3GGZUFzI6oA3Ku8RClqgFrPqS4sqGpJepe1DV8M=.d3cefea1-6e27-428f-9bdc-9bc39e2c445e@github.com>

On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
>> 
>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
>> 
>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
>> 
>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
>> 
>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright years in hpp files

Finished my re-review without the whitespace noise. I have to say
that really reveals how nice this cleanup is! Thanks for doing it.

I only added some nits. Feel free to fix or not.

src/hotspot/share/compiler/compileBroker.cpp line 938:

> 936:     if (UseDynamicNumberOfCompilerThreads && type == compiler_t
> 937:         && comp->num_compiler_threads() > 0) {
> 938:       // the new thread is not known to Thread-SMR yet so we can just delete

nit: s/the/The/  and add a period to the end of the sentence.

src/hotspot/share/prims/jvmtiEnv.cpp line 1335:

> 1333:   // JavaThread due to lack of memory.
> 1334:   if (new_thread == NULL || new_thread->osthread() == NULL) {
> 1335:     // the new thread is not known to Thread-SMR yet so we can just delete

nit: s/the/The/ and add a period to the end of the sentence.

src/hotspot/share/runtime/monitorDeflationThread.cpp line 51:

> 49:                           CHECK);
> 50: 
> 51:   MonitorDeflationThread* thread =  new MonitorDeflationThread(&monitor_deflation_thread_entry);

nit: s/=  new/= new/

(Not your typo, but please fix it while you're in here.)

src/hotspot/share/runtime/notificationThread.cpp line 63:

> 61:                           THREAD);
> 62: 
> 63:    NotificationThread* thread =  new NotificationThread(&notification_thread_entry);

nit: s/= new/= new/

(Not your typo, but please fix it while you're in here.)

src/hotspot/share/runtime/thread.cpp line 3911:

> 3909:   MutexLocker mu(current, Threads_lock);
> 3910: 
> 3911:   // Initialize the fields of the thread_oop first

nit: please add a period to the end of the sentence.

src/hotspot/share/runtime/thread.cpp line 3923:

> 3921:   java_lang_Thread::set_daemon(thread_oop());
> 3922: 
> 3923:   // Now bind the thread_oop to the target JavaThread

nit: please add a period to the end of the sentence.

src/hotspot/share/services/attachListener.cpp line 490:

> 488:   JavaThread::vm_exit_on_thread_allocation_failure(thread);
> 489: 
> 490:   JavaThread::start_internal_daemon(THREAD, thread, thread_oop, NoPriority);

I wonder if the lack of a specific priority for the attach listener is a
contributing factor to some of the timeouts in attach that we observe.
@plummercj and @sspitsyn - You might be interested here...

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4629

From dcubed at openjdk.java.net  Wed Jun 30 17:33:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 17:33:17 GMT
Subject: [jdk17] RFR: 8269691: ProblemList
 sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
Message-ID: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>

A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64.

-------------

Commit messages:
 - 8269691: ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64

Changes: https://git.openjdk.java.net/jdk17/pull/182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=182&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269691
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/182/head:pull/182

PR: https://git.openjdk.java.net/jdk17/pull/182

From darcy at openjdk.java.net  Wed Jun 30 17:43:04 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 30 Jun 2021 17:43:04 GMT
Subject: [jdk17] RFR: 8269691: ProblemList
 sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
In-Reply-To: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
References: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
Message-ID: <Jq6CRUyQ6GRt-yCc8Ku3Tg2nMRWQm3Sn36QeKTGz6g0=.97a29682-a93a-45ba-a3e7-d6f1e7ca4d96@github.com>

On Wed, 30 Jun 2021 17:27:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/182

From dcubed at openjdk.java.net  Wed Jun 30 17:43:05 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 17:43:05 GMT
Subject: [jdk17] Integrated: 8269691: ProblemList
 sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
In-Reply-To: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
References: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
Message-ID: <uD6oYCCY-YW3mB23rYv2_PLpZqgSBFWRYZ4Hj1fSWFQ=.115f24c5-cb57-4b27-934b-ad08498c41a1@github.com>

On Wed, 30 Jun 2021 17:27:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64.

This pull request has now been integrated.

Changeset: 2b17e95e
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/2b17e95e202a3feae7bf7ccb6af93881ad6de0c3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269691: ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64

Reviewed-by: kvn, darcy

-------------

PR: https://git.openjdk.java.net/jdk17/pull/182

From kvn at openjdk.java.net  Wed Jun 30 17:43:04 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 30 Jun 2021 17:43:04 GMT
Subject: [jdk17] RFR: 8269691: ProblemList
 sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
In-Reply-To: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
References: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
Message-ID: <a42G073iSTXEAMCFE8apTuxq9IGiX-ArfMwX4mTlDqo=.18e971ef-811c-4b15-b04b-3bff6fb8ac6f@github.com>

On Wed, 30 Jun 2021 17:27:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64.

trivial

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/182

From dcubed at openjdk.java.net  Wed Jun 30 17:43:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 17:43:04 GMT
Subject: [jdk17] RFR: 8269691: ProblemList
 sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
In-Reply-To: <a42G073iSTXEAMCFE8apTuxq9IGiX-ArfMwX4mTlDqo=.18e971ef-811c-4b15-b04b-3bff6fb8ac6f@github.com>
References: <xYLiVC9GtktDZYwvWz5rfMtUIXuuBLKxV4DKtlRf9Rk=.d75145e1-2cce-4f37-a107-4fb30011f3b0@github.com>
 <a42G073iSTXEAMCFE8apTuxq9IGiX-ArfMwX4mTlDqo=.18e971ef-811c-4b15-b04b-3bff6fb8ac6f@github.com>
Message-ID: <T3eVSW0AcmusfS6ouiM2U9lNL5WQKXGRmzNY1rbE-N8=.d7769546-7894-42c3-90d8-2bc30d0d1354@github.com>

On Wed, 30 Jun 2021 17:35:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64.
>
> trivial

@vnkozlov and @jddarcy - Thanks for the fast reviews!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/182

From dnsimon at openjdk.java.net  Wed Jun 30 18:38:08 2021
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 30 Jun 2021 18:38:08 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <2wxnNNwh--ROik5g1EyJCB9ibDViy96wjb1Y6-eXoFw=.5e58d3cc-2fa3-49f5-a1fc-3529db4f871b@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <2wxnNNwh--ROik5g1EyJCB9ibDViy96wjb1Y6-eXoFw=.5e58d3cc-2fa3-49f5-a1fc-3529db4f871b@github.com>
Message-ID: <0PS3k4WFWkbG30DSNhuCnpk4oeguVW8BQKANsGsO4Gg=.da20cbce-9fa6-4de8-92bb-bf4279d64fd3@github.com>

On Wed, 30 Jun 2021 16:43:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Looks good to me. I had a hard time with all the whitespace indentation

https://github.blog/2018-05-01-ignore-white-space-in-code-review/

-------------

PR: https://git.openjdk.java.net/jdk/pull/4629

From coleenp at openjdk.java.net  Wed Jun 30 18:56:07 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 30 Jun 2021 18:56:07 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>
Message-ID: <K8MDn-C4DC39Od5dXdNnq7w1M6FCSFY2OyomoUD6CpE=.9706b47b-bf21-4c0e-864e-46cfbe3d1818@github.com>

On Wed, 30 Jun 2021 18:44:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed copyright years in hpp files
>
> src/hotspot/share/runtime/thread.cpp line 3935:
> 
>> 3933:   // in that case. However, since this must work and we do not allow
>> 3934:   // exceptions anyway, check and abort if this fails.
>> 3935:   if (thread == nullptr || thread->osthread() == nullptr) {
> 
> thread shouldn't be NULL here if you haven't used a nothrow version of new to allocate the thread.

Since you're no longer holding the JavaThreads_lock here, it seems like you could do this from the JavaThread constructor instead of adding this function. Except for the case for the JFR thread and JVMTI. So maybe you need this.  Maybe fix the comment at the end of JavaThread constructor that says you're holding a lock and are going to throw OOM and those details.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4629

From coleenp at openjdk.java.net  Wed Jun 30 18:56:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 30 Jun 2021 18:56:06 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
Message-ID: <LxYLS_7x1UhlB9CvfyHqmU7mtBf81L9nJ1CUIGMFKt4=.c12ff5c3-561e-44de-8578-79b4096d1800@github.com>

On Wed, 30 Jun 2021 01:31:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please see the JBS issue for more details, but basically we have 8 different kinds of internal VM JavaThreads (grouping the three types of CompilerThread together) that all basically duplicated the logic for initializing (preparing is the term we use for user-defined JavaThreads) and starting the new thread. This common code can be factored out into static helpers in JavaThread.
>> 
>> This change does not look at the way the java.lang.Thread instance is created - that will be handled by a separate RFE.
>> 
>> The semantics of the changes are not identical, but I don't believe there is any observable change in behaviour. The scope of holding the Threads_lock has been reduced, and we now create the JavaThread instances ("new XXXThread(...)") outside of the lock. As far as I can see nothing in the construction process needs to happen under the Threads_lock.
>> 
>> A few of the threads use a static `_instance` field to hold a reference to the create JavaThread. This proved very difficult to handle, as logically the field would need to be updated in the middle of the new factored-out method: after setting all the fields but before releasing the newly started thread. I eventually realized that in all but one case those `_instance` fields are never used and so could be deleted. The one case remaining does not need to be set as I just described, but can be set after the thread has started, as the new thread does not examine it (arguably its existence is unnecessary).
>> 
>> The trickiest changes related to the CompilerThreads, so they need particular scrutiny.
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed copyright years in hpp files

Some small change requests.

src/hotspot/share/jfr/recorder/service/jfrRecorderThread.cpp line 49:

> 47:   assert(proc != NULL, "invariant");
> 48: 
> 49:   JavaThread* new_thread = new JavaThread(proc);

if new_thread allocation fails, the operator new will call vm_exit_out_of_memory and exit. It won't return NULL.

src/hotspot/share/jfr/recorder/service/jfrRecorderThread.cpp line 54:

> 52:   // osthread was created for the JavaThread due to lack of memory.
> 53:   if (new_thread == NULL || new_thread->osthread() == NULL) {
> 54:     delete new_thread;

Since new_thread can't be null, this delete is going to be ok, but it would better not to check for null.

src/hotspot/share/prims/jvmtiEnv.cpp line 1334:

> 1332:   // At this point it may be possible that no osthread was created for the
> 1333:   // JavaThread due to lack of memory.
> 1334:   if (new_thread == NULL || new_thread->osthread() == NULL) {

Same here, unless there's some operator new overloading that doesn't use the nothrow operator new.

src/hotspot/share/runtime/notificationThread.cpp line 61:

> 59:                           vmSymbols::thread_void_signature(),
> 60:                           thread_oop,
> 61:                           THREAD);

This was all the code that I thought was unnecessarily duplicated.

src/hotspot/share/runtime/thread.cpp line 3935:

> 3933:   // in that case. However, since this must work and we do not allow
> 3934:   // exceptions anyway, check and abort if this fails.
> 3935:   if (thread == nullptr || thread->osthread() == nullptr) {

thread shouldn't be NULL here if you haven't used a nothrow version of new to allocate the thread.

-------------

Changes requested by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4629

From dcubed at openjdk.java.net  Wed Jun 30 19:02:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 19:02:04 GMT
Subject: RFR: 8269466: Factor out the common code for initializing and
 starting internal VM JavaThreads [v2]
In-Reply-To: <0PS3k4WFWkbG30DSNhuCnpk4oeguVW8BQKANsGsO4Gg=.da20cbce-9fa6-4de8-92bb-bf4279d64fd3@github.com>
References: <5HBVUf9nukugj_8zWW_wgd-BSlyDzGTF9ciw2c5kiJM=.2a8e40a5-4c91-41e6-9ea1-21d930144c54@github.com>
 <XTLTTOC3acp19dyoKrnXkCyrZ4EZ9O-1HroTxMQ-Iq4=.e9d22939-2917-4a65-89d3-137859c48a0c@github.com>
 <2wxnNNwh--ROik5g1EyJCB9ibDViy96wjb1Y6-eXoFw=.5e58d3cc-2fa3-49f5-a1fc-3529db4f871b@github.com>
 <0PS3k4WFWkbG30DSNhuCnpk4oeguVW8BQKANsGsO4Gg=.da20cbce-9fa6-4de8-92bb-bf4279d64fd3@github.com>
Message-ID: <zESOcaQLSHnN9zuEQ7uURPYQrCMNCvfffnGJb61tKV0=.1aa133d0-2faf-4bf9-a73f-7e0ed4222b7a@github.com>

On Wed, 30 Jun 2021 18:34:50 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> https://github.blog/2018-05-01-ignore-white-space-in-code-review/

My "Files Changed" view doesn't have a "diff settings" button, but I did click
on the Settings widget and found a button where I could ignore "white space".
Pretty cool. Thanks for the tip @dougxc

-------------

PR: https://git.openjdk.java.net/jdk/pull/4629

From dcubed at openjdk.java.net  Wed Jun 30 21:28:17 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 21:28:17 GMT
Subject: [jdk17] RFR: 8269703: ProblemList
 vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
 Windows-X64 with -Xcomp
Message-ID: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>

A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java
on Windows-X64 with -Xcomp.

-------------

Commit messages:
 - 8269703: ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on Windows-X64 with -Xcomp

Changes: https://git.openjdk.java.net/jdk17/pull/186/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=186&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269703
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/186.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/186/head:pull/186

PR: https://git.openjdk.java.net/jdk17/pull/186

From dholmes at openjdk.java.net  Wed Jun 30 22:17:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 30 Jun 2021 22:17:01 GMT
Subject: [jdk17] RFR: 8269703: ProblemList
 vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
 Windows-X64 with -Xcomp
In-Reply-To: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
References: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
Message-ID: <mTHVmR6LFhhxZ8mfbPma06_HMpTnkzAqMsqsGH44IOs=.1751660f-f953-4567-b2b6-5bfdb1c850a8@github.com>

On Wed, 30 Jun 2021 21:21:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java
> on Windows-X64 with -Xcomp.

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/186

From dcubed at openjdk.java.net  Wed Jun 30 22:17:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 22:17:01 GMT
Subject: [jdk17] RFR: 8269703: ProblemList
 vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
 Windows-X64 with -Xcomp
In-Reply-To: <mTHVmR6LFhhxZ8mfbPma06_HMpTnkzAqMsqsGH44IOs=.1751660f-f953-4567-b2b6-5bfdb1c850a8@github.com>
References: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
 <mTHVmR6LFhhxZ8mfbPma06_HMpTnkzAqMsqsGH44IOs=.1751660f-f953-4567-b2b6-5bfdb1c850a8@github.com>
Message-ID: <UzkarwIgPuVDmoYcXO-3Ut9TkNG3Bsq_gLsJsc8b5v8=.3ab2ac45-ffe8-4ed0-bb9c-79cf908cf22d@github.com>

On Wed, 30 Jun 2021 22:11:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java
>> on Windows-X64 with -Xcomp.
>
> Marked as reviewed by dholmes (Reviewer).

@dholmes-ora - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/186

From dcubed at openjdk.java.net  Wed Jun 30 22:17:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 22:17:02 GMT
Subject: [jdk17] RFR: 8269703: ProblemList
 vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
 Windows-X64 with -Xcomp
In-Reply-To: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
References: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
Message-ID: <lNFkeLgD4cJ7iyRrA9VCWN6Ok7Psbb9Za2BCOpptySM=.68fa907f-0f73-400d-a770-7ee10a7432f3@github.com>

On Wed, 30 Jun 2021 21:21:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java
> on Windows-X64 with -Xcomp.

Cool. I typo'ed the "/integrate" and then edited it. The command still worked.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/186

From dcubed at openjdk.java.net  Wed Jun 30 22:17:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 30 Jun 2021 22:17:02 GMT
Subject: [jdk17] Integrated: 8269703: ProblemList
 vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
 Windows-X64 with -Xcomp
In-Reply-To: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
References: <dqYAhrU75CS7u7hKAzkYmFzqgnsvoYHQGfXXqDDhc2U=.d745c5d0-b182-4cde-9be0-3b72b0e375a4@github.com>
Message-ID: <08weo1J3kupDlwxUeXA0Z5PJfE5Cagj0aSqhm-D-oSE=.f0bf126a-8785-4e6b-a37d-a73d67e923d8@github.com>

On Wed, 30 Jun 2021 21:21:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java
> on Windows-X64 with -Xcomp.

This pull request has now been integrated.

Changeset: aba6c55d
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/aba6c55dacf020d547771c5141092e4b931c232e
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8269703: ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on Windows-X64 with -Xcomp

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk17/pull/186