From dholmes at openjdk.java.net  Mon Aug  2 01:32:47 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 2 Aug 2021 01:32:47 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <4BScf_-Ipx7eEH5LNCXAjhCn7j-JoCikldXnPzX1xZ0=.4827e655-7e70-4174-97af-2f6649e616e9@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev 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.

Hi Igor,

This set of changes seems much more manageable to me.

Not sure about the new deprecation warnings for the old WB classes .. might that not itself trigger some failures? If not then I don't see how the deprecation warnings help with transitioning to the new WB class?

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/290

From jiefu at openjdk.java.net  Mon Aug  2 01:48:33 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 2 Aug 2021 01:48:33 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <5SYAFqMrZzYAv1C1HVLm7ehQ22NmC401c5hiRA0KfsY=.bad74f4b-2787-44d8-9639-a809be6133ea@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev 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 12 new commits since the last revision:
> 
>  - fixed ctw build
>  - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class
>  - updated requires.VMProps
>  - updated TEST.ROOT
>  - adjusted hotspot source
>  - added test
>  - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox)
>  - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
>  - removed sun/hotspot/parser/DiagnosticCommand
>  - deprecated sun/hotspot classes
>    disallowed s.h.WhiteBox w/ security manager
>  - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860

Shall we also update the copyright year like test/lib/sun/hotspot/cpuinfo/CPUInfo.java?
Thanks.

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From dholmes at openjdk.java.net  Mon Aug  2 04:35:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 2 Aug 2021 04:35:31 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator
In-Reply-To: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
Message-ID: <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>

On Fri, 30 Jul 2021 20:20:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to support JFR use of new ThreadsList::Iterator.
> 
> This fix was tested with Mach5 Tier[1-3].

Hi Dan,

I'm assuming that the intent of this conversion is that `JavaThreadIteratorWithHandle` is going to be removed - is that right?

The conversion seems okay but definitely not a trivial change IMO. And a query below before I can approve this.

Thanks,
David

src/hotspot/share/jfr/utilities/jfrThreadIterator.hpp line 50:

> 48: class JfrJavaThreadIteratorAdapter {
> 49:  private:
> 50:   ThreadsListHandle _tlist;

Why do we need to store this?

It looks very suspiocious to have a member that is a stackObj, in a class that is not itself a stackObj. ??

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

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

From serb at openjdk.java.net  Mon Aug  2 05:15:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Aug 2021 05:15:31 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <fBPaA1DeCKvimAokqSF89kq1K4HRQI0CZiNC300ICLY=.047fa5e4-664f-4ea6-8ca0-88b9a2ceb5d4@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

Changes in the desktop module looks fine.

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

Marked as reviewed by serb (Reviewer).

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

From lzang at openjdk.java.net  Mon Aug  2 14:33:38 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 2 Aug 2021 14:33:38 GMT
Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use
 try-with-resource [v4]
In-Reply-To: <jBGy4lHzdV1t6X5dUolyHpyPg36I7S_9OrFMDmntvtI=.c87d9738-a7e6-4de6-b75a-a9c709a3bd84@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <oYpfsJXyV1KVHyGzEKi-9u7ibyTSnlKuFSApw_7QwFI=.ac80fa39-e780-459f-894b-8c46e37898ff@github.com>
 <jBGy4lHzdV1t6X5dUolyHpyPg36I7S_9OrFMDmntvtI=.c87d9738-a7e6-4de6-b75a-a9c709a3bd84@github.com>
Message-ID: <6TtyAzEqX8qaEZdhXGv1sX-LnlsO0xWtfGWrO5XUZ2A=.5ad09abe-7bd3-4838-8397-73ecc7dcc59a@github.com>

On Thu, 15 Jul 2021 17:22:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - fix indentation issue
>>  - Merge branch 'master' into try
>>  - revise code to handle the closing of embeded streams
>>  - Merge branch 'master' into try
>>  - 8269909: getStack method in hprof.parser.Reader should use try-with-resource
>
> Hi Lin,
> These local names with extra numbers look strange.
> You introduced these numbers in order to fix naming conflicts.
> You also can avoid these conflicts by refactoring the code.
> Some of these fragments can be refactored to become a separate methods.
> I do not want to push hard on you with this but it is just something to consider to simplify the code and avoid such naming problems.
> Thanks,
> Serguei

Hi @sspitsyn,
     May I ask your help to see whether this pr is ok for you? Thanks!

-Lin

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

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

From lzang at openjdk.java.net  Mon Aug  2 14:35:35 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 2 Aug 2021 14:35:35 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v3]
In-Reply-To: <DyIwynoIm6DSvzRJoyxB8m65aYMyBuHagz5lwTClc9g=.4af54310-c091-4d5f-a648-27c8bf75d1c7@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
 <DyIwynoIm6DSvzRJoyxB8m65aYMyBuHagz5lwTClc9g=.4af54310-c091-4d5f-a648-27c8bf75d1c7@github.com>
Message-ID: <Co8IzGO8NGKBFUSXKUP-KEEhlCkxkWHcYnvdaT5u-es=.9357f9b6-b8f1-4854-bc92-612116a0a942@github.com>

On Mon, 5 Jul 2021 12:04:17 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
>> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix write size issue

Dear All,
May I ask your help to review this PR? it fix the issue JDK-8262386.
I believe this could be a replacement for #2803.  I am planing to close it if this one looks good.

BRs,
Lin

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

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

From kvn at openjdk.java.net  Mon Aug  2 15:59:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 2 Aug 2021 15:59:36 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <Sd7psaMNOzPgXn6MXO4nqbYOar95nebcGeDQ7TUYZCo=.156f24b1-bce1-4ab8-bd21-414aa51d8839@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev 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 agree with these revised changes for JDK 17.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/290

From iignatyev at openjdk.java.net  Mon Aug  2 16:25:19 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 2 Aug 2021 16:25:19 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v3]
In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
Message-ID: <loW4C0OHE9UVTbpoyDspljVodi4xA8xKi2spS1AALyc=.bff9a367-c923-45ef-a9e5-f5fe8df547af@github.com>

> Hi all,
> 
> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
> 
> the majority of the patch is the following substitutions:
>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
> 
> testing: tier1-4
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision:

 - copyright update
 - fixed typo in ClassFileInstaller

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/290/files
  - new: https://git.openjdk.java.net/jdk17/pull/290/files/237e8860..fcaf41f8

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

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From iignatyev at openjdk.java.net  Mon Aug  2 16:25:21 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 2 Aug 2021 16:25:21 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <gLiHwnjyHZocgtJJSFk1q98oV4Ffqz7e5VWhgI1Ld0o=.8555b8c4-05ca-42bf-96d6-a0e70bd04056@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev 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 12 new commits since the last revision:
> 
>  - fixed ctw build
>  - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class
>  - updated requires.VMProps
>  - updated TEST.ROOT
>  - adjusted hotspot source
>  - added test
>  - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox)
>  - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
>  - removed sun/hotspot/parser/DiagnosticCommand
>  - deprecated sun/hotspot classes
>    disallowed s.h.WhiteBox w/ security manager
>  - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860

Hi David,

> This set of changes seems much more manageable to me.

thank you for your review, David.

> Not sure about the new deprecation warnings for the old WB classes .. might that not itself trigger some failures? If not then I don't see how the deprecation warnings help with transitioning to the new WB class?

the deprecation warnings (hopefully) will help people not to forget that they should use the new WB class in new tests. 

Thanks,
-- Igor

Hi Jie,
> Shall we also update the copyright year like test/lib/sun/hotspot/cpuinfo/CPUInfo.java?

we most certainly shall, just pushed the commit that updates the copyright years in the touched files.

Cheers,
-- Igor

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From iignatyev at openjdk.java.net  Mon Aug  2 16:26:33 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 2 Aug 2021 16:26:33 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <Sd7psaMNOzPgXn6MXO4nqbYOar95nebcGeDQ7TUYZCo=.156f24b1-bce1-4ab8-bd21-414aa51d8839@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
 <Sd7psaMNOzPgXn6MXO4nqbYOar95nebcGeDQ7TUYZCo=.156f24b1-bce1-4ab8-bd21-414aa51d8839@github.com>
Message-ID: <h5CHlSF_Cj70P2Y6laxQMT2SpslrjXfEv_jl45W8A_U=.2c44b77c-b57c-4bb1-8f75-db555212e33f@github.com>

On Mon, 2 Aug 2021 15:56:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I agree with these revised changes for JDK 17.

Thanks for your review, Vladimir. 

I'll rerun my testing before integrating (just for good luck).

-- Igor

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From dcubed at openjdk.java.net  Mon Aug  2 19:22:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 2 Aug 2021 19:22:04 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]
In-Reply-To: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
Message-ID: <GuzRQzdiycGH9wavM09u0ShTA3g8fX5scKCxicQpELI=.e7e8d089-5dda-4b8b-beef-000f765db208@github.com>

> A trivial fix to support JFR use of new ThreadsList::Iterator.
> 
> This fix was tested with Mach5 Tier[1-3].

Daniel D. Daugherty 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 branch 'pull/4948' into JDK-8271514
 - Merge branch 'pull/4948' into JDK-8271514
 - 8271514: support JFR use of new ThreadsList::Iterator

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4949/files
  - new: https://git.openjdk.java.net/jdk/pull/4949/files/056badc2..3c64ea23

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

  Stats: 31265 lines in 73 files changed: 29925 ins; 630 del; 710 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4949.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4949/head:pull/4949

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

From iignatyev at openjdk.java.net  Mon Aug  2 20:47:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 2 Aug 2021 20:47:35 GMT
Subject: [jdk17] Integrated: 8067223: [TESTBUG] Rename Whitebox API package
In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
Message-ID: <7NcTTjXdOT2FGyik79Who_BkmchG225aO4-ufpU1eZk=.9b2f1a53-7739-49ce-b2b8-f587d78f55e4@github.com>

On Wed, 28 Jul 2021 17:13:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
> 
> the majority of the patch is the following substitutions:
>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
> 
> testing: tier1-4
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: ada58d13
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/ada58d13f78eb8a240220c45c573335eeb47cf07
Stats:     532 lines in 36 files changed: 449 ins; 0 del; 83 mod

8067223: [TESTBUG] Rename Whitebox API package

Reviewed-by: dholmes, kvn

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From david.holmes at oracle.com  Mon Aug  2 22:00:36 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Aug 2021 08:00:36 +1000
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <gLiHwnjyHZocgtJJSFk1q98oV4Ffqz7e5VWhgI1Ld0o=.8555b8c4-05ca-42bf-96d6-a0e70bd04056@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
 <gLiHwnjyHZocgtJJSFk1q98oV4Ffqz7e5VWhgI1Ld0o=.8555b8c4-05ca-42bf-96d6-a0e70bd04056@github.com>
Message-ID: <b3283810-5f7e-7161-3bca-5f064dda8441@oracle.com>

On 3/08/2021 2:25 am, Igor Ignatyev wrote:
> On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:
> 
>>> Hi all,
>>>
>>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>>>
>>> the majority of the patch is the following substitutions:
>>>   - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>>   - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>>   - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>>   - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>>   - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>>   - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>>>
>>> testing: tier1-4
>>>
>>> Thanks,
>>> -- Igor
>>
>> Igor Ignatyev 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 12 new commits since the last revision:
>>
>>   - fixed ctw build
>>   - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class
>>   - updated requires.VMProps
>>   - updated TEST.ROOT
>>   - adjusted hotspot source
>>   - added test
>>   - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox)
>>   - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
>>   - removed sun/hotspot/parser/DiagnosticCommand
>>   - deprecated sun/hotspot classes
>>     disallowed s.h.WhiteBox w/ security manager
>>   - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860
> 
> Hi David,
> 
>> This set of changes seems much more manageable to me.
> 
> thank you for your review, David.
> 
>> Not sure about the new deprecation warnings for the old WB classes .. might that not itself trigger some failures? If not then I don't see how the deprecation warnings help with transitioning to the new WB class?
> 
> the deprecation warnings (hopefully) will help people not to forget that they should use the new WB class in new tests.

If the test passes it is unlikely people will actually notice these in 
the jtr file - and even if they see them they may just ignore them 
thinking they are similar to all the security manager warnings that we 
ignore.

But as long as it does no harm.

Cheers,
David

> Thanks,
> -- Igor
> 
> Hi Jie,
>> Shall we also update the copyright year like test/lib/sun/hotspot/cpuinfo/CPUInfo.java?
> 
> we most certainly shall, just pushed the commit that updates the copyright years in the touched files.
> 
> Cheers,
> -- Igor
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk17/pull/290
> 

From dholmes at openjdk.java.net  Mon Aug  2 22:40:34 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 2 Aug 2021 22:40:34 GMT
Subject: RFR: 8269934: RunThese24H.java failed with
 EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status
In-Reply-To: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
References: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
Message-ID: <UMYwp89rFecA0-mlFndsq9icIR4buDSi_VZ8mm1pkXc=.1d1260bd-3f87-4bea-8816-9e9c584f062c@github.com>

On Wed, 28 Jul 2021 10:03:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If a thread is attaching via JNI and has not yet created its Thread object it can be caught in a ThreadSnapshot during a thread dump (VM_DumpThreads) of all threads**, and the threadObj() will be NULL, so we can't pass it to get_thread_status().
> 
> ** JMM dumpThreads API
> 
> The initial fix simply checks for a NULL threadObj() and reports thread status NEW in that case.
> 
> Alternatively we could filter the attaching thread out completely in VM_DumpThreads::doit by expanding:
> 
>       if (jt->is_exiting() ||
>           jt->is_hidden_from_external_view())  {
>         // skip terminating threads and hidden threads
>         continue;
>       }
> 
> to also check jt->is_attaching_via_jni().
> 
> Note that higher-level code already filters out ThreadSnapshots with NULL threadObj() anyway so we could go either way.
> 
> Testing: manual hacks - see bug report.
>   - tier 1-3 sanity testing
> 
> Thanks,
> David

Still looking for a serviceability review please - @sspitsyn , @plummercj  ?

Thanks

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

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

From jwilhelm at openjdk.java.net  Mon Aug  2 23:38:00 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 2 Aug 2021 23:38:00 GMT
Subject: RFR: Merge jdk17
Message-ID: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8067223: [TESTBUG] Rename Whitebox API package
 - 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34)

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

Changes: https://git.openjdk.java.net/jdk/pull/4964/files
  Stats: 535 lines in 37 files changed: 449 ins; 1 del; 85 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4964.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4964/head:pull/4964

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

From jwilhelm at openjdk.java.net  Mon Aug  2 23:53:59 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 2 Aug 2021 23:53:59 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com>
References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com>
Message-ID: <x4gxlN2xHvsE06SPR_CBvGX3nJVJSaziK1bUssfkoDM=.d87127af-ccd2-4fe7-b2ef-1d5d8a7a901b@github.com>

> Forwardport JDK 17 -> JDK 18

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

  Revert "8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34)"
  
  This reverts commit f8fb5713074b8960f5530d7aca954f84d57c1f30.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4964/files
  - new: https://git.openjdk.java.net/jdk/pull/4964/files/a95b06a1..e353ddcc

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

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

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

From mikael at openjdk.java.net  Tue Aug  3 00:01:33 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Tue, 3 Aug 2021 00:01:33 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <x4gxlN2xHvsE06SPR_CBvGX3nJVJSaziK1bUssfkoDM=.d87127af-ccd2-4fe7-b2ef-1d5d8a7a901b@github.com>
References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com>
 <x4gxlN2xHvsE06SPR_CBvGX3nJVJSaziK1bUssfkoDM=.d87127af-ccd2-4fe7-b2ef-1d5d8a7a901b@github.com>
Message-ID: <8IbQAIkLr13OmKSOcnZrb5FRd6tN-pdqAAJlHnIbh-8=.cbb12df6-21d6-42c4-b9f4-82db2dadc9b4@github.com>

On Mon, 2 Aug 2021 23:53:59 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Forwardport JDK 17 -> JDK 18
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34)"
>   
>   This reverts commit f8fb5713074b8960f5530d7aca954f84d57c1f30.

Marked as reviewed by mikael (Reviewer).

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

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

From jwilhelm at openjdk.java.net  Tue Aug  3 01:04:35 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 3 Aug 2021 01:04:35 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com>
References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@github.com>
Message-ID: <q50Sls0m6fLJKDMqVBPDlAWgKsOEw56pE3dN29kw1Yc=.20bfa085-2669-4d43-b083-d37c4c516afd@github.com>

On Mon, 2 Aug 2021 23:30:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: c8add223
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c8add223a10030e40ccef42e081fd0d8f00e0593
Stats:     534 lines in 36 files changed: 449 ins; 1 del; 84 mod

Merge

Reviewed-by: mikael

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

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

From sspitsyn at openjdk.java.net  Tue Aug  3 05:51:29 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 3 Aug 2021 05:51:29 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use"
In-Reply-To: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
Message-ID: <8VQ20fh2TVbWEjK0iuu3YDrCfDkCfRyUrpSwykDIv5w=.a83413e0-ee53-41d7-a700-fb2be65f7683@github.com>

On Sat, 17 Jul 2021 00:38:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the tests to use dynamic port launching debuggee and get the listening port from the debugee output

test/hotspot/jtreg/vmTestbase/nsk/share/IORedirector.java line 74:

> 72:         this();
> 73:         this.bin  = in;
> 74:         addProcessor( s -> log.println(prefix + s));

Nit: unneeded space before "s ->".

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

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

From sspitsyn at openjdk.java.net  Tue Aug  3 05:57:32 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 3 Aug 2021 05:57:32 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use"
In-Reply-To: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
Message-ID: <dHbJfWRt2DTJtrzjRaES5BkKwlLJSLKDqXkBzcQfMb8=.707d0f70-e0b2-472b-9ec1-6f995c31a4a1@github.com>

On Sat, 17 Jul 2021 00:38:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the tests to use dynamic port launching debuggee and get the listening port from the debugee output

Hi Alex,

The fix looks good to me. While you are a this code, may I ask you to do a minor cleanup and get rid of several commented out lines that were there before your fix?

Thanks,
Serguei

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

Changes requested by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Tue Aug  3 06:15:39 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 3 Aug 2021 06:15:39 GMT
Subject: RFR: 8269934: RunThese24H.java failed with
 EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status
In-Reply-To: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
References: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
Message-ID: <Cu20ICgjIY87gpVN-ftxxto-FF_u6XsRSAc6zkuzM_Q=.fb48a678-f281-4cd2-a7b5-7ef1cce67f91@github.com>

On Wed, 28 Jul 2021 10:03:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If a thread is attaching via JNI and has not yet created its Thread object it can be caught in a ThreadSnapshot during a thread dump (VM_DumpThreads) of all threads**, and the threadObj() will be NULL, so we can't pass it to get_thread_status().
> 
> ** JMM dumpThreads API
> 
> The initial fix simply checks for a NULL threadObj() and reports thread status NEW in that case.
> 
> Alternatively we could filter the attaching thread out completely in VM_DumpThreads::doit by expanding:
> 
>       if (jt->is_exiting() ||
>           jt->is_hidden_from_external_view())  {
>         // skip terminating threads and hidden threads
>         continue;
>       }
> 
> to also check jt->is_attaching_via_jni().
> 
> Note that higher-level code already filters out ThreadSnapshots with NULL threadObj() anyway so we could go either way.
> 
> Testing: manual hacks - see bug report.
>   - tier 1-3 sanity testing
> 
> Thanks,
> David

Hi David,
The fix looks fine to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Tue Aug  3 06:15:40 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 3 Aug 2021 06:15:40 GMT
Subject: RFR: 8269934: RunThese24H.java failed with
 EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status
In-Reply-To: <2q5ydXJwaul0jEF2X2c0mDL6dSPmksfoJ2l1a7T7_JM=.01c14a0f-e336-41db-a287-6807f85c1801@github.com>
References: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
 <2q5ydXJwaul0jEF2X2c0mDL6dSPmksfoJ2l1a7T7_JM=.01c14a0f-e336-41db-a287-6807f85c1801@github.com>
Message-ID: <QNz8qlVBaDz7JDCteKuPoQc57mpZ7wEX6VtS1VJLQvk=.69490f0a-ad1b-4773-875f-9cfa6d6e5e95@github.com>

On Wed, 28 Jul 2021 15:17:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> If a thread is attaching via JNI and has not yet created its Thread object it can be caught in a ThreadSnapshot during a thread dump (VM_DumpThreads) of all threads**, and the threadObj() will be NULL, so we can't pass it to get_thread_status().
>> 
>> ** JMM dumpThreads API
>> 
>> The initial fix simply checks for a NULL threadObj() and reports thread status NEW in that case.
>> 
>> Alternatively we could filter the attaching thread out completely in VM_DumpThreads::doit by expanding:
>> 
>>       if (jt->is_exiting() ||
>>           jt->is_hidden_from_external_view())  {
>>         // skip terminating threads and hidden threads
>>         continue;
>>       }
>> 
>> to also check jt->is_attaching_via_jni().
>> 
>> Note that higher-level code already filters out ThreadSnapshots with NULL threadObj() anyway so we could go either way.
>> 
>> Testing: manual hacks - see bug report.
>>   - tier 1-3 sanity testing
>> 
>> Thanks,
>> David
>
> src/hotspot/share/services/threadService.cpp line 879:
> 
>> 877:   // If thread is still attaching then threadObj will be NULL.
>> 878:   _thread_status = threadObj == NULL ? JavaThreadStatus::NEW
>> 879:                                      : java_lang_Thread::get_thread_status(threadObj);
> 
> I like the use of `JavaThreadStatus::NEW` here.
> 
> Since L867 creates the _threadObj OopHandle, do you want to change both
> uses of `threadObj` to `_threadObj()`? Is that still how we fetch the oop from
> an OopHandle? Or even use `threadObj()`... Then we don't have to reason
> about whether the `threadObj` oop is still good...

I was thinking about the same. If we always use _threadObj() then there is no need to make sure the threadObj is still valid.

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

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

From dholmes at openjdk.java.net  Tue Aug  3 06:42:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 3 Aug 2021 06:42:30 GMT
Subject: RFR: 8269934: RunThese24H.java failed with
 EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status
In-Reply-To: <Cu20ICgjIY87gpVN-ftxxto-FF_u6XsRSAc6zkuzM_Q=.fb48a678-f281-4cd2-a7b5-7ef1cce67f91@github.com>
References: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
 <Cu20ICgjIY87gpVN-ftxxto-FF_u6XsRSAc6zkuzM_Q=.fb48a678-f281-4cd2-a7b5-7ef1cce67f91@github.com>
Message-ID: <qZhjEYXa163sHNNb590nQBMgSWwSvJYMa-EVRBWeDJ0=.b552f7df-49eb-4622-bb61-26331d8a883d@github.com>

On Tue, 3 Aug 2021 06:12:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> If a thread is attaching via JNI and has not yet created its Thread object it can be caught in a ThreadSnapshot during a thread dump (VM_DumpThreads) of all threads**, and the threadObj() will be NULL, so we can't pass it to get_thread_status().
>> 
>> ** JMM dumpThreads API
>> 
>> The initial fix simply checks for a NULL threadObj() and reports thread status NEW in that case.
>> 
>> Alternatively we could filter the attaching thread out completely in VM_DumpThreads::doit by expanding:
>> 
>>       if (jt->is_exiting() ||
>>           jt->is_hidden_from_external_view())  {
>>         // skip terminating threads and hidden threads
>>         continue;
>>       }
>> 
>> to also check jt->is_attaching_via_jni().
>> 
>> Note that higher-level code already filters out ThreadSnapshots with NULL threadObj() anyway so we could go either way.
>> 
>> Testing: manual hacks - see bug report.
>>   - tier 1-3 sanity testing
>> 
>> Thanks,
>> David
>
> Hi David,
> The fix looks fine to me.
> Thanks,
> Serguei

Thanks for the review @sspitsyn !

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

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

From dholmes at openjdk.java.net  Tue Aug  3 06:42:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 3 Aug 2021 06:42:30 GMT
Subject: RFR: 8269934: RunThese24H.java failed with
 EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status
In-Reply-To: <QNz8qlVBaDz7JDCteKuPoQc57mpZ7wEX6VtS1VJLQvk=.69490f0a-ad1b-4773-875f-9cfa6d6e5e95@github.com>
References: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
 <2q5ydXJwaul0jEF2X2c0mDL6dSPmksfoJ2l1a7T7_JM=.01c14a0f-e336-41db-a287-6807f85c1801@github.com>
 <QNz8qlVBaDz7JDCteKuPoQc57mpZ7wEX6VtS1VJLQvk=.69490f0a-ad1b-4773-875f-9cfa6d6e5e95@github.com>
Message-ID: <5vwpd4pnJ7qW1F1uop_nR7gog1Xa8rNNSgM1CT5ApqE=.7d672921-4257-4d25-90de-e5c1e8837f2c@github.com>

On Tue, 3 Aug 2021 06:11:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/services/threadService.cpp line 879:
>> 
>>> 877:   // If thread is still attaching then threadObj will be NULL.
>>> 878:   _thread_status = threadObj == NULL ? JavaThreadStatus::NEW
>>> 879:                                      : java_lang_Thread::get_thread_status(threadObj);
>> 
>> I like the use of `JavaThreadStatus::NEW` here.
>> 
>> Since L867 creates the _threadObj OopHandle, do you want to change both
>> uses of `threadObj` to `_threadObj()`? Is that still how we fetch the oop from
>> an OopHandle? Or even use `threadObj()`... Then we don't have to reason
>> about whether the `threadObj` oop is still good...
>
> I was thinking about the same. If we always use _threadObj() then there is no need to make sure the threadObj is still valid.

I'm not quite sure what point is being made here. We don't have to do anything to "make sure the threadObj is still valid" as we don't have any code here that could expose a "naked oop". We only need/want to use a handle when we have to ensure the oop is preserved across calls. That is not the case here.

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

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

From ddong at openjdk.java.net  Tue Aug  3 10:28:33 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 3 Aug 2021 10:28:33 GMT
Subject: Withdrawn: 8269470: Add truncation and compression information to
 EventHeapDump
In-Reply-To: <6aIKhIzZuN1t1DZhSzfV9HLQrKnau9zB77VggMdg1sQ=.a8128116-723d-4384-a1b4-36ba3e7fc46c@github.com>
References: <6aIKhIzZuN1t1DZhSzfV9HLQrKnau9zB77VggMdg1sQ=.a8128116-723d-4384-a1b4-36ba3e7fc46c@github.com>
Message-ID: <DGm67TW7ChTnogrbZ2sULbEwlW9-2UKEbNw5leNbp-4=.b121c37f-8bff-43fc-b472-b46314119309@github.com>

On Mon, 28 Jun 2021 07:07:07 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Could I have a review of this change that adds the truncation and compression information to EventHeapDump?
> 
> We occasionally receive feedback from users that the heap size parsed from the heap dump does not match the GC log. We think this may be caused by the truncation of the heap dump.
> 
> It would be nice to add truncation info to the EventHeapDump.
> 
> Also, this patch adds the compression info which is trivial to add.
> 
> Regards,
> Denghui

This pull request has been closed without being integrated.

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

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

From ddong at openjdk.java.net  Tue Aug  3 10:28:33 2021
From: ddong at openjdk.java.net (Denghui Dong)
Date: Tue, 3 Aug 2021 10:28:33 GMT
Subject: RFR: 8269470: Add truncation and compression information to
 EventHeapDump [v2]
In-Reply-To: <arcifDTQoKL6qDJ7mg0ml94-1evr0nAAUmqA9wlcgy8=.0057fdf3-d930-4cef-8161-20ec3ee55235@github.com>
References: <6aIKhIzZuN1t1DZhSzfV9HLQrKnau9zB77VggMdg1sQ=.a8128116-723d-4384-a1b4-36ba3e7fc46c@github.com>
 <arcifDTQoKL6qDJ7mg0ml94-1evr0nAAUmqA9wlcgy8=.0057fdf3-d930-4cef-8161-20ec3ee55235@github.com>
Message-ID: <o1Xdb2XV87lkFt3I5dX5gJNmBumxnxg_eHqml5gK_QU=.03ac471e-cf1e-43ac-bdb5-42b85688cb75@github.com>

On Mon, 28 Jun 2021 07:39:40 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Could I have a review of this change that adds the truncation and compression information to EventHeapDump?
>> 
>> We occasionally receive feedback from users that the heap size parsed from the heap dump does not match the GC log. We think this may be caused by the truncation of the heap dump.
>> 
>> It would be nice to add truncation info to the EventHeapDump.
>> 
>> Also, this patch adds the compression info which is trivial to add.
>> 
>> Regards,
>> Denghui
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrong return type

It seems that this issue has no obvious value, I temporarily closed it.
The test problem(misuse of Object.equals) fixed in this pr  I will  a new issue to fix.

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

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

From sspitsyn at openjdk.java.net  Tue Aug  3 10:56:27 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 3 Aug 2021 10:56:27 GMT
Subject: RFR: 8269934: RunThese24H.java failed with
 EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status
In-Reply-To: <5vwpd4pnJ7qW1F1uop_nR7gog1Xa8rNNSgM1CT5ApqE=.7d672921-4257-4d25-90de-e5c1e8837f2c@github.com>
References: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
 <2q5ydXJwaul0jEF2X2c0mDL6dSPmksfoJ2l1a7T7_JM=.01c14a0f-e336-41db-a287-6807f85c1801@github.com>
 <QNz8qlVBaDz7JDCteKuPoQc57mpZ7wEX6VtS1VJLQvk=.69490f0a-ad1b-4773-875f-9cfa6d6e5e95@github.com>
 <5vwpd4pnJ7qW1F1uop_nR7gog1Xa8rNNSgM1CT5ApqE=.7d672921-4257-4d25-90de-e5c1e8837f2c@github.com>
Message-ID: <aP-4fnPun9b5eS_1R7h4HGQNHZ9Djihec85tv7_DZQw=.c0db9cd3-2991-4a45-9f6d-f75ee4f701d0@github.com>

On Tue, 3 Aug 2021 06:38:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I was thinking about the same. If we always use _threadObj() then there is no need to make sure the threadObj is still valid.
>
> I'm not quite sure what point is being made here. We don't have to do anything to "make sure the threadObj is still valid" as we don't have any code here that could expose a "naked oop". We only need/want to use a handle when we have to ensure the oop is preserved across calls. That is not the case here.

I agree, it is not the case here. Thanks.

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

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

From cjplummer at openjdk.java.net  Tue Aug  3 18:38:29 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 3 Aug 2021 18:38:29 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use"
In-Reply-To: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
Message-ID: <Alfnoev0Tpf-xIqZOUQbyvJfXmVK_iLBvw9XukM3mC0=.fba4bfd7-e51b-41c9-9963-f1721ba11c53@github.com>

On Sat, 17 Jul 2021 00:38:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the tests to use dynamic port launching debuggee and get the listening port from the debugee output

test/hotspot/jtreg/vmTestbase/nsk/jdi/AttachingConnector/attachnosuspend/attachnosuspend001.java line 101:

> 99:         String cmd = java
> 100:                 + " -Xdebug -Xnoagent -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=0"
> 101:                 + " " + DEBUGEE_CLASS;

You've lost logging of the port you end up listening on. Is the dynamically discovered listening port logged somewhere else?

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 330:

> 328:      */
> 329:     public void redirectStdout(Log log, String prefix) {
> 330:         redirectStdout(log, prefix, null);

Is there a reason to still support passing in the prefix even though it is ignored. Seems that could be confusing to someone looking at the caller code.

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

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

From amenkov at openjdk.java.net  Tue Aug  3 19:59:53 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 3 Aug 2021 19:59:53 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use" [v2]
In-Reply-To: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
Message-ID: <58_1ZiJHHJtZZqIgVYYW4_mjAsMk8IZw_tQ-Gi5UYDo=.1eeb2b2f-631f-4442-bc16-24a75d9ded26@github.com>

> The fix updates the tests to use dynamic port launching debuggee and get the listening port from the debugee output

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

  Additional code cleanup as requested by reviewer

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4817/files
  - new: https://git.openjdk.java.net/jdk/pull/4817/files/04114de3..77eb0c1f

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

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

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

From amenkov at openjdk.java.net  Tue Aug  3 19:59:54 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 3 Aug 2021 19:59:54 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use" [v2]
In-Reply-To: <58_1ZiJHHJtZZqIgVYYW4_mjAsMk8IZw_tQ-Gi5UYDo=.1eeb2b2f-631f-4442-bc16-24a75d9ded26@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
 <58_1ZiJHHJtZZqIgVYYW4_mjAsMk8IZw_tQ-Gi5UYDo=.1eeb2b2f-631f-4442-bc16-24a75d9ded26@github.com>
Message-ID: <7aCUzNBqIRStWnrkufltbigRm4pFTvx0eDJOUy5WbPY=.105a66f2-355c-4694-ae21-f2db0ad62aed@github.com>

On Tue, 3 Aug 2021 19:56:47 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates the tests to use dynamic port launching debuggee and get the listening port from the debugee output
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional code cleanup as requested by reviewer

> The fix looks good to me. While you are a this code, may I ask you to do a minor cleanup and get rid of several commented out lines that were there before your fix?

Dropped commented lines in DebugeeProcess.java.
Also updated methods description as they were incorrect.

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

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

From amenkov at openjdk.java.net  Tue Aug  3 19:59:55 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 3 Aug 2021 19:59:55 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use" [v2]
In-Reply-To: <Alfnoev0Tpf-xIqZOUQbyvJfXmVK_iLBvw9XukM3mC0=.fba4bfd7-e51b-41c9-9963-f1721ba11c53@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
 <Alfnoev0Tpf-xIqZOUQbyvJfXmVK_iLBvw9XukM3mC0=.fba4bfd7-e51b-41c9-9963-f1721ba11c53@github.com>
Message-ID: <fIOJmJhTlU0_YmQP3dlKYa57mK6_lW64LHVXfWCyHoI=.2c4e55d0-afa1-4aab-ab3d-c06a09428d62@github.com>

On Tue, 3 Aug 2021 18:35:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional code cleanup as requested by reviewer
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/AttachingConnector/attachnosuspend/attachnosuspend001.java line 101:
> 
>> 99:         String cmd = java
>> 100:                 + " -Xdebug -Xnoagent -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=0"
>> 101:                 + " " + DEBUGEE_CLASS;
> 
> You've lost logging of the port you end up listening on. Is the dynamically discovered listening port logged somewhere else?

DebugeeProcess.redirectOutputAndDetectListeningAddress logs it
(see DebugeeProcess.java, line 428)
Also IORedirector logs debugee output (including "Listening for transport ... at address ..." line)

> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 330:
> 
>> 328:      */
>> 329:     public void redirectStdout(Log log, String prefix) {
>> 330:         redirectStdout(log, prefix, null);
> 
> Is there a reason to still support passing in the prefix even though it is ignored. Seems that could be confusing to someone looking at the caller code.

I dont' quite follow.
The prefix is not ignored, it's passed to IORedirector and is used for logging

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

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

From amenkov at openjdk.java.net  Tue Aug  3 19:59:57 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 3 Aug 2021 19:59:57 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use" [v2]
In-Reply-To: <8VQ20fh2TVbWEjK0iuu3YDrCfDkCfRyUrpSwykDIv5w=.a83413e0-ee53-41d7-a700-fb2be65f7683@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
 <8VQ20fh2TVbWEjK0iuu3YDrCfDkCfRyUrpSwykDIv5w=.a83413e0-ee53-41d7-a700-fb2be65f7683@github.com>
Message-ID: <n0cypZ4_-3aOIaLy4eTUx6fdPrVUzxSS7Xb-l_15Irk=.567d81ab-c961-4bce-a42b-a7c8cd048e29@github.com>

On Tue, 3 Aug 2021 05:48:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional code cleanup as requested by reviewer
>
> test/hotspot/jtreg/vmTestbase/nsk/share/IORedirector.java line 74:
> 
>> 72:         this();
>> 73:         this.bin  = in;
>> 74:         addProcessor( s -> log.println(prefix + s));
> 
> Nit: unneeded space before "s ->".

Fixed

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

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

From cjplummer at openjdk.java.net  Tue Aug  3 21:13:34 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 3 Aug 2021 21:13:34 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use" [v2]
In-Reply-To: <58_1ZiJHHJtZZqIgVYYW4_mjAsMk8IZw_tQ-Gi5UYDo=.1eeb2b2f-631f-4442-bc16-24a75d9ded26@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
 <58_1ZiJHHJtZZqIgVYYW4_mjAsMk8IZw_tQ-Gi5UYDo=.1eeb2b2f-631f-4442-bc16-24a75d9ded26@github.com>
Message-ID: <jwP92BHS-lTE4LC3UA3lTGTLvY_mXYY5iVuE1j0JJUc=.9c8d7b3f-961a-4ffc-a5ae-173cba933ad1@github.com>

On Tue, 3 Aug 2021 19:59:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates the tests to use dynamic port launching debuggee and get the listening port from the debugee output
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional code cleanup as requested by reviewer

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Tue Aug  3 21:13:35 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 3 Aug 2021 21:13:35 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use" [v2]
In-Reply-To: <fIOJmJhTlU0_YmQP3dlKYa57mK6_lW64LHVXfWCyHoI=.2c4e55d0-afa1-4aab-ab3d-c06a09428d62@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
 <Alfnoev0Tpf-xIqZOUQbyvJfXmVK_iLBvw9XukM3mC0=.fba4bfd7-e51b-41c9-9963-f1721ba11c53@github.com>
 <fIOJmJhTlU0_YmQP3dlKYa57mK6_lW64LHVXfWCyHoI=.2c4e55d0-afa1-4aab-ab3d-c06a09428d62@github.com>
Message-ID: <Krzj9Shtl3mZtf7iW3RDyRQ0W5qBmMnVtopI3CB6wrM=.44ac9ef1-3433-4cc5-8655-7a332756ad13@github.com>

On Tue, 3 Aug 2021 19:21:27 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 330:
>> 
>>> 328:      */
>>> 329:     public void redirectStdout(Log log, String prefix) {
>>> 330:         redirectStdout(log, prefix, null);
>> 
>> Is there a reason to still support passing in the prefix even though it is ignored. Seems that could be confusing to someone looking at the caller code.
>
> I dont' quite follow.
> The prefix is not ignored, it's passed to IORedirector and is used for logging

Sorry, I misread it. I thought the 3rd argument passed was the prefix.

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

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

From dholmes at openjdk.java.net  Wed Aug  4 02:12:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 4 Aug 2021 02:12:31 GMT
Subject: Integrated: 8269934: RunThese24H.java failed with
 EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status
In-Reply-To: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
References: <UzuojghwZRtOLyDt-hVFIOVPJaRA_mlN2w7M6T7r5pY=.341e649c-2cad-4059-b63f-2a89699fa97d@github.com>
Message-ID: <bjxtq4FQk8CEk46ESJUDRZFbpkjQJN4Z4WhGr63a28k=.bf7076a9-b107-48d3-93db-81fe1b56fcdd@github.com>

On Wed, 28 Jul 2021 10:03:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If a thread is attaching via JNI and has not yet created its Thread object it can be caught in a ThreadSnapshot during a thread dump (VM_DumpThreads) of all threads**, and the threadObj() will be NULL, so we can't pass it to get_thread_status().
> 
> ** JMM dumpThreads API
> 
> The initial fix simply checks for a NULL threadObj() and reports thread status NEW in that case.
> 
> Alternatively we could filter the attaching thread out completely in VM_DumpThreads::doit by expanding:
> 
>       if (jt->is_exiting() ||
>           jt->is_hidden_from_external_view())  {
>         // skip terminating threads and hidden threads
>         continue;
>       }
> 
> to also check jt->is_attaching_via_jni().
> 
> Note that higher-level code already filters out ThreadSnapshots with NULL threadObj() anyway so we could go either way.
> 
> Testing: manual hacks - see bug report.
>   - tier 1-3 sanity testing
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 7e518f42
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7e518f42c9346abdf0c8059b45d3dfef95ed69bb
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8269934: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status

Reviewed-by: stuefe, dcubed, sspitsyn

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

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

From ysuenaga at openjdk.java.net  Wed Aug  4 14:03:42 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 4 Aug 2021 14:03:42 GMT
Subject: RFR: 8271863: ProblemList serviceability/sa/TestJmapCore.java on
 linux-x64 with ZGC
Message-ID: <kfX76cABwdHBD-oSBcX5pmR8rTYj1EN5Wd8DQq2h-M4=.cc74ab1a-7d67-461e-80c4-09b1956db0be@github.com>

We saw some failures of TestJmapCore.java, and we need more time to fix it. So we should add it to ProblemList-zgc.

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

Commit messages:
 - 8271863: ProblemList serviceability/sa/TestJmapCore.java on linux-x64 with ZGC

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

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

From dcubed at openjdk.java.net  Wed Aug  4 15:28:29 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 4 Aug 2021 15:28:29 GMT
Subject: RFR: 8271863: ProblemList serviceability/sa/TestJmapCore.java on
 linux-x64 with ZGC
In-Reply-To: <kfX76cABwdHBD-oSBcX5pmR8rTYj1EN5Wd8DQq2h-M4=.cc74ab1a-7d67-461e-80c4-09b1956db0be@github.com>
References: <kfX76cABwdHBD-oSBcX5pmR8rTYj1EN5Wd8DQq2h-M4=.cc74ab1a-7d67-461e-80c4-09b1956db0be@github.com>
Message-ID: <eGjYRnRtXj3eUDck2CHDg9Dz1JbyrZTSjhh_Q7E7m5U=.72d8d52a-f72d-4e13-ab39-c39617bab885@github.com>

On Wed, 4 Aug 2021 13:57:25 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We saw some failures of TestJmapCore.java, and we need more time to fix it. So we should add it to ProblemList-zgc.

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

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

From sspitsyn at openjdk.java.net  Wed Aug  4 21:26:30 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 4 Aug 2021 21:26:30 GMT
Subject: RFR: 8213714: AttachingConnector/attach/attach001 failed due to
 "bind failed: Address already in use" [v2]
In-Reply-To: <58_1ZiJHHJtZZqIgVYYW4_mjAsMk8IZw_tQ-Gi5UYDo=.1eeb2b2f-631f-4442-bc16-24a75d9ded26@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
 <58_1ZiJHHJtZZqIgVYYW4_mjAsMk8IZw_tQ-Gi5UYDo=.1eeb2b2f-631f-4442-bc16-24a75d9ded26@github.com>
Message-ID: <2qsWwj7qPSdv62t4z_YfBQCYNVgRlQEzIq7C_A9lBhQ=.1503267c-eca6-4aac-ac1c-4275424d37ba@github.com>

On Tue, 3 Aug 2021 19:59:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates the tests to use dynamic port launching debuggee and get the listening port from the debugee output
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional code cleanup as requested by reviewer

Marked as reviewed by sspitsyn (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Wed Aug  4 23:00:36 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 4 Aug 2021 23:00:36 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]
In-Reply-To: <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
 <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>
Message-ID: <Jf7XTGdCTXqpmHGiWZ271qxFuUePNSfHij7kHMaGAOE=.5aadbd01-4a38-4975-b4c8-dcad0f58e4b2@github.com>

On Mon, 2 Aug 2021 04:31:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty 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 branch 'pull/4948' into JDK-8271514
>>  - Merge branch 'pull/4948' into JDK-8271514
>>  - 8271514: support JFR use of new ThreadsList::Iterator
>
> src/hotspot/share/jfr/utilities/jfrThreadIterator.hpp line 50:
> 
>> 48: class JfrJavaThreadIteratorAdapter {
>> 49:  private:
>> 50:   ThreadsListHandle _tlist;
> 
> Why do we need to store this?
> 
> It looks very suspiocious to have a member that is a stackObj, in a class that is not itself a stackObj. ??

The _tlist is used locally in JfrJavaThreadIteratorAdapter constructor only, so it is possible to get rid of it for the price of complicating the constructor a little bit.

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

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

From sspitsyn at openjdk.java.net  Wed Aug  4 23:00:34 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 4 Aug 2021 23:00:34 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]
In-Reply-To: <GuzRQzdiycGH9wavM09u0ShTA3g8fX5scKCxicQpELI=.e7e8d089-5dda-4b8b-beef-000f765db208@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
 <GuzRQzdiycGH9wavM09u0ShTA3g8fX5scKCxicQpELI=.e7e8d089-5dda-4b8b-beef-000f765db208@github.com>
Message-ID: <zW48J-fTzfjsEGiuBV9jgBT5zV3baboax3xEcVuUMkY=.c85d4916-3cb0-45f0-b293-7b24934c880b@github.com>

On Mon, 2 Aug 2021 19:22:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to support JFR use of new ThreadsList::Iterator.
>> 
>> This fix was tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty 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 branch 'pull/4948' into JDK-8271514
>  - Merge branch 'pull/4948' into JDK-8271514
>  - 8271514: support JFR use of new ThreadsList::Iterator

Hi Dan,
It looks good to me modulo the question from David.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From ysuenaga at openjdk.java.net  Wed Aug  4 23:46:32 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 4 Aug 2021 23:46:32 GMT
Subject: Integrated: 8271863: ProblemList serviceability/sa/TestJmapCore.java
 on linux-x64 with ZGC
In-Reply-To: <kfX76cABwdHBD-oSBcX5pmR8rTYj1EN5Wd8DQq2h-M4=.cc74ab1a-7d67-461e-80c4-09b1956db0be@github.com>
References: <kfX76cABwdHBD-oSBcX5pmR8rTYj1EN5Wd8DQq2h-M4=.cc74ab1a-7d67-461e-80c4-09b1956db0be@github.com>
Message-ID: <jNp1N7t9EVpfzeSjeZfcD_tzuVw4aX-fHhrfCK0atSo=.7822348f-d850-435f-9a9d-a18f571b3224@github.com>

On Wed, 4 Aug 2021 13:57:25 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We saw some failures of TestJmapCore.java, and we need more time to fix it. So we should add it to ProblemList-zgc.

This pull request has now been integrated.

Changeset: a007cb1a
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a007cb1a1dd6a716555031c271cb11f4980813e7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8271863: ProblemList serviceability/sa/TestJmapCore.java on linux-x64 with ZGC

Reviewed-by: dcubed

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

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

From kbarrett at openjdk.java.net  Thu Aug  5 04:03:30 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 5 Aug 2021 04:03:30 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]
In-Reply-To: <Jf7XTGdCTXqpmHGiWZ271qxFuUePNSfHij7kHMaGAOE=.5aadbd01-4a38-4975-b4c8-dcad0f58e4b2@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
 <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>
 <Jf7XTGdCTXqpmHGiWZ271qxFuUePNSfHij7kHMaGAOE=.5aadbd01-4a38-4975-b4c8-dcad0f58e4b2@github.com>
Message-ID: <HK22i5IFIGBCirZhL7VylAhCcV0tfmrlyacN_dL6umo=.c0d1e16f-e28c-4228-b253-92a6b4385069@github.com>

On Wed, 4 Aug 2021 22:56:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/jfr/utilities/jfrThreadIterator.hpp line 50:
>> 
>>> 48: class JfrJavaThreadIteratorAdapter {
>>> 49:  private:
>>> 50:   ThreadsListHandle _tlist;
>> 
>> Why do we need to store this?
>> 
>> It looks very suspiocious to have a member that is a stackObj, in a class that is not itself a stackObj. ??
>
> The _tlist is used locally in JfrJavaThreadIteratorAdapter constructor only, so it is possible to get rid of it for the price of complicating the constructor a little bit.

The `_tlist` is a handle that ensures the captured ThreadsList remains live while the iterator (or a copy) exists.  Dropping it would leave `_it` and `_end` potentially dangling.

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

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

From kbarrett at openjdk.java.net  Thu Aug  5 04:08:29 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 5 Aug 2021 04:08:29 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]
In-Reply-To: <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
 <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>
Message-ID: <Ite8E61bQzEso_PTg8Ymr0pBdAHkSfnyoIG54NzqGeM=.6fe25723-b64c-4c94-8c6a-d71d8ee0f896@github.com>

On Mon, 2 Aug 2021 04:32:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm assuming that the intent of this conversion is that `JavaThreadIteratorWithHandle` is going to be removed - is that right?

That was my intent.  But this is a somewhat complicated use, so dealing with it separately.  And I agree this is not a trivial change.

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

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

From jakob at jcornell.net  Thu Aug  5 04:11:27 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Wed, 4 Aug 2021 23:11:27 -0500
Subject: Proposed changes to empty command handling in JDB
Message-ID: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>

Hi folks,

I've been looking to improve the usability of JDB a bit by imitating GDB's handling of empty commands.  If the most recent command is one that it makes sense to invoke repeatedly, GDB does so.  Also, when the `list' command is repeated (by either typing it out or issuing an empty command after a `list'), GDB shows the next chunk of source lines, resetting to the line being executed when the user moves up or down the stack or advances execution.

Here are the changes I propose, based on suggestions from Chris Plummer:

A new command line option (`-gdb' or `-repeat'?) is introduced which enables GDB-like behavior.  When this mode is selected, entering an empty command at the prompt reruns the previous command if it was one of the following forms: `up', `down', `step', `step up', `stepi', `next', `cont', `pop', `reenter', `!!', and `<n> <command>' (where any of the preceding commands is being repeated).

Currently JDB appears to use the current source line as the center of its listings even when invoked repeatedly.  I haven't included an auto-advance enhancement to that command here because it goes somewhat beyond the narrow scope of implementing command repetition, but I'm happy to implement that alongside these changes or in a separate change set if the community sees fit.  I find this auto-advance useful when using GDB and PDB.

Any feedback is appreciated, but in particular I'm hoping to get some input on these points:

- If the repetition is limited to commands that are likely to be repeated, is it necessary to have this feature off by default?
- Would folks like to see auto-advance `list' behavior along with these changes?

JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8271356

Best,
Jakob

From dholmes at openjdk.java.net  Thu Aug  5 05:47:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 5 Aug 2021 05:47:28 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]
In-Reply-To: <HK22i5IFIGBCirZhL7VylAhCcV0tfmrlyacN_dL6umo=.c0d1e16f-e28c-4228-b253-92a6b4385069@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
 <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>
 <Jf7XTGdCTXqpmHGiWZ271qxFuUePNSfHij7kHMaGAOE=.5aadbd01-4a38-4975-b4c8-dcad0f58e4b2@github.com>
 <HK22i5IFIGBCirZhL7VylAhCcV0tfmrlyacN_dL6umo=.c0d1e16f-e28c-4228-b253-92a6b4385069@github.com>
Message-ID: <lfYUORaqnSvMeEdQGDYi-sN_k6oyJiLgadjyumiqjpg=.6529453b-f06c-45b5-b6c9-518ba0ecb6f2@github.com>

On Thu, 5 Aug 2021 04:00:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> The _tlist is used locally in JfrJavaThreadIteratorAdapter constructor only, so it is possible to get rid of it for the price of complicating the constructor a little bit.
>
> The `_tlist` is a handle that ensures the captured ThreadsList remains live while the iterator (or a copy) exists.  Dropping it would leave `_it` and `_end` potentially dangling.

Okay I had assumed there was a ThreadsList/Handle in the enclosing scope that was being used to initialize this and keep things live, but that is not the case.
I still think it makes no sense to have a StackObj subtype as a member though. Maybe ThreadsListHandle should no longer be a StackObj ?

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

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

From Alan.Bateman at oracle.com  Thu Aug  5 07:10:35 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 5 Aug 2021 08:10:35 +0100
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
Message-ID: <b4d6d1cc-2b42-9ec0-bc7b-2b4f683754d0@oracle.com>

On 05/08/2021 05:11, Jakob Cornell wrote:
> Hi folks,
>
> I've been looking to improve the usability of JDB a bit by imitating 
> GDB's handling of empty commands.? If the most recent command is one 
> that it makes sense to invoke repeatedly, GDB does so.? Also, when the 
> `list' command is repeated (by either typing it out or issuing an 
> empty command after a `list'), GDB shows the next chunk of source 
> lines, resetting to the line being executed when the user moves up or 
> down the stack or advances execution.
>
> Here are the changes I propose, based on suggestions from Chris Plummer:
>
> A new command line option (`-gdb' or `-repeat'?) is introduced which 
> enables GDB-like behavior.? When this mode is selected, entering an 
> empty command at the prompt reruns the previous command if it was one 
> of the following forms: `up', `down', `step', `step up', `stepi', 
> `next', `cont', `pop', `reenter', `!!', and `<n> <command>' (where any 
> of the preceding commands is being repeated).
>
> Currently JDB appears to use the current source line as the center of 
> its listings even when invoked repeatedly.? I haven't included an 
> auto-advance enhancement to that command here because it goes somewhat 
> beyond the narrow scope of implementing command repetition, but I'm 
> happy to implement that alongside these changes or in a separate 
> change set if the community sees fit.? I find this auto-advance useful 
> when using GDB and PDB.
>
> Any feedback is appreciated, but in particular I'm hoping to get some 
> input on these points:
>
> - If the repetition is limited to commands that are likely to be 
> repeated, is it necessary to have this feature off by default?
> - Would folks like to see auto-advance `list' behavior along with 
> these changes?
>
> JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8271356

The gdb behavior is context dependent and not clear to me that it's 
worth trying to add it to jdb. If it is added then I think Chris is 
right that is might have to be disabled by default as it could otherwise 
break existing scripts/tests with empty lines. One place for 
configuration ~/.jdbrc and it might be that it can only be enabled for 
interactive sessions.

If usability is an issue then maybe it would be better to look at 
jshell? (the REPL that has been included since JDK 9). It makes us of 
jline so you get better input navigation, history navigation, and tab 
completion.? I suspect there is an interesting project there.

-Alan

From kbarrett at openjdk.java.net  Thu Aug  5 07:58:28 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 5 Aug 2021 07:58:28 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]
In-Reply-To: <lfYUORaqnSvMeEdQGDYi-sN_k6oyJiLgadjyumiqjpg=.6529453b-f06c-45b5-b6c9-518ba0ecb6f2@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
 <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>
 <Jf7XTGdCTXqpmHGiWZ271qxFuUePNSfHij7kHMaGAOE=.5aadbd01-4a38-4975-b4c8-dcad0f58e4b2@github.com>
 <HK22i5IFIGBCirZhL7VylAhCcV0tfmrlyacN_dL6umo=.c0d1e16f-e28c-4228-b253-92a6b4385069@github.com>
 <lfYUORaqnSvMeEdQGDYi-sN_k6oyJiLgadjyumiqjpg=.6529453b-f06c-45b5-b6c9-518ba0ecb6f2@github.com>
Message-ID: <hafKRbdg9V2IxXSMy5__J-Pw2FR7AO9DSVMYpA5vJB8=.58013d68-5f60-4db8-b8f2-1d8aa89d78b2@github.com>

On Thu, 5 Aug 2021 05:44:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `_tlist` is a handle that ensures the captured ThreadsList remains live while the iterator (or a copy) exists.  Dropping it would leave `_it` and `_end` potentially dangling.
>
> Okay I had assumed there was a ThreadsList/Handle in the enclosing scope that was being used to initialize this and keep things live, but that is not the case.
> I still think it makes no sense to have a StackObj subtype as a member though. Maybe ThreadsListHandle should no longer be a StackObj ?

This isn't a change wrto StackObj usage. This adapter class used to have a member that was a JavaThreadIteratorWithHandle (the WithHandle class for the same reason the new code has a ThreadsListHandle, to keep the associated ThreadsList alive), which also derives from StackObj.

Personally, I want to agree with you. I would (and do) use StackObj far more sparingly than it appears in our code base. But I've had this same argument with other folks. The de facto situation, so far as I understand it, is that deriving from StackObj documents normal usage. It has no operational behavior or additional semantics, other than attempting to prevent heap allocation (and it doesn't really succeed there, since a derived class could override that behavior, though I don't currently know of any that do so).  That seems to be what some people want from it and think is useful, and I've stopped trying to convince them otherwise.

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

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

From mgronlun at openjdk.java.net  Thu Aug  5 09:27:28 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 5 Aug 2021 09:27:28 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]
In-Reply-To: <hafKRbdg9V2IxXSMy5__J-Pw2FR7AO9DSVMYpA5vJB8=.58013d68-5f60-4db8-b8f2-1d8aa89d78b2@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
 <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>
 <Jf7XTGdCTXqpmHGiWZ271qxFuUePNSfHij7kHMaGAOE=.5aadbd01-4a38-4975-b4c8-dcad0f58e4b2@github.com>
 <HK22i5IFIGBCirZhL7VylAhCcV0tfmrlyacN_dL6umo=.c0d1e16f-e28c-4228-b253-92a6b4385069@github.com>
 <lfYUORaqnSvMeEdQGDYi-sN_k6oyJiLgadjyumiqjpg=.6529453b-f06c-45b5-b6c9-518ba0ecb6f2@github.com>
 <hafKRbdg9V2IxXSMy5__J-Pw2FR7AO9DSVMYpA5vJB8=.58013d68-5f60-4db8-b8f2-1d8aa89d78b2@github.com>
Message-ID: <HmKZMqg3dXZ1Ku3hAsyUE2XleQH2SMUCGs1SOdMzjd0=.1877430a-5634-4f33-8f17-6a4e78b672eb@github.com>

On Thu, 5 Aug 2021 07:55:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Okay I had assumed there was a ThreadsList/Handle in the enclosing scope that was being used to initialize this and keep things live, but that is not the case.
>> I still think it makes no sense to have a StackObj subtype as a member though. Maybe ThreadsListHandle should no longer be a StackObj ?
>
> This isn't a change wrto StackObj usage. This adapter class used to have a member that was a JavaThreadIteratorWithHandle (the WithHandle class for the same reason the new code has a ThreadsListHandle, to keep the associated ThreadsList alive), which also derives from StackObj.
> 
> Personally, I want to agree with you. I would (and do) use StackObj far more sparingly than it appears in our code base. But I've had this same argument with other folks. The de facto situation, so far as I understand it, is that deriving from StackObj documents normal usage. It has no operational behavior or additional semantics, other than attempting to prevent heap allocation (and it doesn't really succeed there, since a derived class could override that behavior, though I don't currently know of any that do so).  That seems to be what some people want from it and think is useful, and I've stopped trying to convince them otherwise.

The adapter is only used as a stack-allocated object, so it can be decorated with StackObj to better communicate this intent.

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

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

From dholmes at openjdk.java.net  Thu Aug  5 09:36:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 5 Aug 2021 09:36:33 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]
In-Reply-To: <HmKZMqg3dXZ1Ku3hAsyUE2XleQH2SMUCGs1SOdMzjd0=.1877430a-5634-4f33-8f17-6a4e78b672eb@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
 <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>
 <Jf7XTGdCTXqpmHGiWZ271qxFuUePNSfHij7kHMaGAOE=.5aadbd01-4a38-4975-b4c8-dcad0f58e4b2@github.com>
 <HK22i5IFIGBCirZhL7VylAhCcV0tfmrlyacN_dL6umo=.c0d1e16f-e28c-4228-b253-92a6b4385069@github.com>
 <lfYUORaqnSvMeEdQGDYi-sN_k6oyJiLgadjyumiqjpg=.6529453b-f06c-45b5-b6c9-518ba0ecb6f2@github.com>
 <hafKRbdg9V2IxXSMy5__J-Pw2FR7AO9DSVMYpA5vJB8=.58013d68-5f60-4db8-b8f2-1d8aa89d78b2@github.com>
 <HmKZMqg3dXZ1Ku3hAsyUE2XleQH2SMUCGs1SOdMzjd0=.1877430a-5634-4f33-8f17-6a4e78b672eb@github.com>
Message-ID: <TmkBQppTdF1Tyh_RinVYffqhQ6pc74aFDlDlbeT_GCg=.86029d51-2a34-4a5a-b52a-75c2d619ab98@github.com>

On Thu, 5 Aug 2021 09:24:13 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This isn't a change wrto StackObj usage. This adapter class used to have a member that was a JavaThreadIteratorWithHandle (the WithHandle class for the same reason the new code has a ThreadsListHandle, to keep the associated ThreadsList alive), which also derives from StackObj.
>> 
>> Personally, I want to agree with you. I would (and do) use StackObj far more sparingly than it appears in our code base. But I've had this same argument with other folks. The de facto situation, so far as I understand it, is that deriving from StackObj documents normal usage. It has no operational behavior or additional semantics, other than attempting to prevent heap allocation (and it doesn't really succeed there, since a derived class could override that behavior, though I don't currently know of any that do so).  That seems to be what some people want from it and think is useful, and I've stopped trying to convince them otherwise.
>
> The adapter is only used as a stack-allocated object, so it can be decorated with StackObj to better communicate this intent.

Ah I didn't realise JTIWH was also stackObj.

The thing with StackObj to me is that it indicates a local object that does something interesting on construction and then also on destruction (eg. like MutexLocker). So having one as a member where the destruction is not related to a stack scope seems odd to me. But a stackObj member in a stackObj class seems more reasonable.

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

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

From jakob at jcornell.net  Thu Aug  5 17:42:13 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Thu, 5 Aug 2021 12:42:13 -0500
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <b4d6d1cc-2b42-9ec0-bc7b-2b4f683754d0@oracle.com>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <b4d6d1cc-2b42-9ec0-bc7b-2b4f683754d0@oracle.com>
Message-ID: <e10b0f8e-9631-1178-0a67-ec903c6a32b0@jcornell.net>

Hi Alan, thanks for the input.

> The gdb behavior is context dependent and not clear to me that it's worth trying to add it to jdb.

Could you provide some more detail about the context upon which GDB's behavior depends?  And are you saying that my proposed changes aren't worth adding, or that it's not worth replicating the exact behavior of GDB?  In my opinion a straightforward approximation of GDB's behavior will be more convenient for users than the current behavior.

> If it is added then I think Chris is right that is might have to be disabled by default as it could otherwise break existing scripts/tests with empty lines. One place for configuration ~/.jdbrc and it might be that it can only be enabled for interactive sessions.

Okay, so it sounds like rather than using a command line option you're suggesting we create new JDB commands (e.g. `repeat' and `norepeat') to enable/disable the feature, plus a check (`System.console() != null' perhaps?) that honors `repeat' only in an interactive session.  This sounds fine to me, although I suspect it becomes a lot more difficult to test this feature when it doesn't work in non-interactive sessions.

> If usability is an issue then maybe it would be better to look at jshell  (the REPL that has been included since JDK 9). It makes us of jline so you get better input navigation, history navigation, and tab completion.  I suspect there is an interesting project there.

Thanks for this tip; line editing is also on my wishlist for JDB, so I would be interested in a jline integration.  However, based on the JBS discussion Chris seems to have sort of the opposite view; that a jline integration likely isn't worth the effort whereas command repetition may be.  I would be interested in both, since I think automatic repetition provides utility beyond line editing, and I would be willing to work on both, but I want to make sure I end up with a change that someone is willing to sponsor and review.

Jakob

From chris.plummer at oracle.com  Thu Aug  5 18:24:18 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 5 Aug 2021 11:24:18 -0700
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <b4d6d1cc-2b42-9ec0-bc7b-2b4f683754d0@oracle.com>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <b4d6d1cc-2b42-9ec0-bc7b-2b4f683754d0@oracle.com>
Message-ID: <5390d861-a112-10c0-8e80-887e877080bd@oracle.com>

On 8/5/21 12:10 AM, Alan Bateman wrote:
> On 05/08/2021 05:11, Jakob Cornell wrote:
>> Hi folks,
>>
>> I've been looking to improve the usability of JDB a bit by imitating 
>> GDB's handling of empty commands.? If the most recent command is one 
>> that it makes sense to invoke repeatedly, GDB does so.? Also, when 
>> the `list' command is repeated (by either typing it out or issuing an 
>> empty command after a `list'), GDB shows the next chunk of source 
>> lines, resetting to the line being executed when the user moves up or 
>> down the stack or advances execution.
>>
>> Here are the changes I propose, based on suggestions from Chris Plummer:
>>
>> A new command line option (`-gdb' or `-repeat'?) is introduced which 
>> enables GDB-like behavior.? When this mode is selected, entering an 
>> empty command at the prompt reruns the previous command if it was one 
>> of the following forms: `up', `down', `step', `step up', `stepi', 
>> `next', `cont', `pop', `reenter', `!!', and `<n> <command>' (where 
>> any of the preceding commands is being repeated).
>>
>> Currently JDB appears to use the current source line as the center of 
>> its listings even when invoked repeatedly.? I haven't included an 
>> auto-advance enhancement to that command here because it goes 
>> somewhat beyond the narrow scope of implementing command repetition, 
>> but I'm happy to implement that alongside these changes or in a 
>> separate change set if the community sees fit.? I find this 
>> auto-advance useful when using GDB and PDB.
>>
>> Any feedback is appreciated, but in particular I'm hoping to get some 
>> input on these points:
>>
>> - If the repetition is limited to commands that are likely to be 
>> repeated, is it necessary to have this feature off by default?
>> - Would folks like to see auto-advance `list' behavior along with 
>> these changes?
>>
>> JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8271356
>
> The gdb behavior is context dependent and not clear to me that it's 
> worth trying to add it to jdb. If it is added then I think Chris is 
> right that is might have to be disabled by default as it could 
> otherwise break existing scripts/tests with empty lines. One place for 
> configuration ~/.jdbrc and it might be that it can only be enabled for 
> interactive sessions.
>
> If usability is an issue then maybe it would be better to look at 
> jshell? (the REPL that has been included since JDK 9). It makes us of 
> jline so you get better input navigation, history navigation, and tab 
> completion.? I suspect there is an interesting project there.
>
> -Alan
Yes, it would be an "interesting project", but I'm not so sure we want 
to put that level of effort into jdb. It's just not that widely used, 
and is mainly there to demonstrate JDI use and to help test JDI, and on 
occasion for very basic java debugging when the user doesn't care to 
config an IDE to do such.

Chris


From chris.plummer at oracle.com  Thu Aug  5 18:28:29 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 5 Aug 2021 11:28:29 -0700
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <e10b0f8e-9631-1178-0a67-ec903c6a32b0@jcornell.net>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <b4d6d1cc-2b42-9ec0-bc7b-2b4f683754d0@oracle.com>
 <e10b0f8e-9631-1178-0a67-ec903c6a32b0@jcornell.net>
Message-ID: <8fd70151-8fa7-d514-fcc4-48b666b94522@oracle.com>

On 8/5/21 10:42 AM, Jakob Cornell wrote:
> Hi Alan, thanks for the input.
>
>> The gdb behavior is context dependent and not clear to me that it's 
>> worth trying to add it to jdb.
>
> Could you provide some more detail about the context upon which GDB's 
> behavior depends?? And are you saying that my proposed changes aren't 
> worth adding, or that it's not worth replicating the exact behavior of 
> GDB?? In my opinion a straightforward approximation of GDB's behavior 
> will be more convenient for users than the current behavior.
I believe only "list" and "x" have content dependent behavior. I'm not 
sure of the list of commands that are purposefully not repeated, such as 
"run".
>
>> If it is added then I think Chris is right that is might have to be 
>> disabled by default as it could otherwise break existing 
>> scripts/tests with empty lines. One place for configuration ~/.jdbrc 
>> and it might be that it can only be enabled for interactive sessions.
>
> Okay, so it sounds like rather than using a command line option you're 
> suggesting we create new JDB commands (e.g. `repeat' and `norepeat') 
> to enable/disable the feature, plus a check (`System.console() != 
> null' perhaps?) that honors `repeat' only in an interactive session.? 
> This sounds fine to me, although I suspect it becomes a lot more 
> difficult to test this feature when it doesn't work in non-interactive 
> sessions.
>
>> If usability is an issue then maybe it would be better to look at 
>> jshell? (the REPL that has been included since JDK 9). It makes us of 
>> jline so you get better input navigation, history navigation, and tab 
>> completion.? I suspect there is an interesting project there.
>
> Thanks for this tip; line editing is also on my wishlist for JDB, so I 
> would be interested in a jline integration.? However, based on the JBS 
> discussion Chris seems to have sort of the opposite view; that a jline 
> integration likely isn't worth the effort whereas command repetition 
> may be.? I would be interested in both, since I think automatic 
> repetition provides utility beyond line editing, and I would be 
> willing to work on both, but I want to make sure I end up with a 
> change that someone is willing to sponsor and review.
Yes, your last comment is part of what I was getting at when I said this 
is probably not worth the effort. It will take a fair amount of review 
effort, and as I pointed out in my previous email, in general jdb is not 
high priority and we shouldn't be directing much of our time to it.

thanks,

Chris
>
> Jakob



From jjg at openjdk.java.net  Thu Aug  5 19:26:50 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 5 Aug 2021 19:26:50 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
Message-ID: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>

Please review a semi-automatic update of the nroff man pages from the upstream files.

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

Commit messages:
 - JDK-8270872: Final nroff manpage update for JDK 17

Changes: https://git.openjdk.java.net/jdk17/pull/303/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=303&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270872
  Stats: 289 lines in 27 files changed: 117 ins; 31 del; 141 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/303/head:pull/303

PR: https://git.openjdk.java.net/jdk17/pull/303

From darcy at openjdk.java.net  Thu Aug  5 19:44:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 5 Aug 2021 19:44:37 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <aWsXaUX5hmJ55kEcFzOXW7NqpE9NgjKXkZrDuNOHFJo=.2e213a1d-9d49-41ac-92d7-166ef9c08c67@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From naoto at openjdk.java.net  Thu Aug  5 20:01:37 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Aug 2021 20:01:37 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

src/jdk.hotspot.agent/share/man/jhsdb.1 line 1:

> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.

This seems not correct?

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From mr at openjdk.java.net  Thu Aug  5 20:13:39 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 5 Aug 2021 20:13:39 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <jv6rEFb4aLBK1e6FBH186cyOqbPFVYLvomqdfzafljA=.95892c77-ab88-422f-91fc-343dfe6f99c6@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by mr (Lead).

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From iris at openjdk.java.net  Thu Aug  5 20:40:40 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 5 Aug 2021 20:40:40 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <liAhrSHq9y4NbW5DufoiKCG95FcISducefm4wUe8ocE=.57c889b5-b016-4678-9980-e62769b62f8d@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From jjg at openjdk.java.net  Thu Aug  5 21:39:38 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 5 Aug 2021 21:39:38 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
 <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
Message-ID: <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>

On Thu, 5 Aug 2021 19:57:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review a semi-automatic update of the nroff man pages from the upstream files.
>
> src/jdk.hotspot.agent/share/man/jhsdb.1 line 1:
> 
>> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
> 
> This seems not correct?

According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file.

I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1.

This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem.

I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command.

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From naoto at openjdk.java.net  Thu Aug  5 21:44:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Aug 2021 21:44:35 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <aq2UDjtBswQl63RvqgMXPgYZu5Eo9b34GJqGM0YzOpE=.185c7174-d0dd-4b52-9815-f7909a45187a@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From naoto at openjdk.java.net  Thu Aug  5 21:44:36 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Aug 2021 21:44:36 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
 <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
 <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>
Message-ID: <zxzpN1zq_GPnLlqPZjkb7VWpnT9XlftAF6CiUVNUuQI=.7d6b28b8-1e27-4783-86f7-d3a6f71bb39d@github.com>

On Thu, 5 Aug 2021 21:36:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/man/jhsdb.1 line 1:
>> 
>>> 1: .\" Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
>> 
>> This seems not correct?
>
> According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file.
> 
> I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1.
> 
> This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem.
> 
> I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command.

Thanks for the explanation, Jon. Fine by me.

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From mr at openjdk.java.net  Thu Aug  5 21:44:36 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 5 Aug 2021 21:44:36 GMT
Subject: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <zxzpN1zq_GPnLlqPZjkb7VWpnT9XlftAF6CiUVNUuQI=.7d6b28b8-1e27-4783-86f7-d3a6f71bb39d@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
 <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com>
 <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com>
 <zxzpN1zq_GPnLlqPZjkb7VWpnT9XlftAF6CiUVNUuQI=.7d6b28b8-1e27-4783-86f7-d3a6f71bb39d@github.com>
Message-ID: <k4aobJsxKwpdOZQqr1GFaBhAGbMh16e4EUxpDAql-Us=.5d7d0799-8d1c-42a0-91a2-44b0912ed475@github.com>

On Thu, 5 Aug 2021 21:40:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> According to the comments in the makefile (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the original Markdown file, so if the year is wrong there, it will be wrong in the generated nroff file.
>> 
>> I think it would be incorrect to edit the dates locally in these files, because they'll just be overwritten when we generate the files again. Ideally, the dates should be fixed (if necessary) in the Markdown files, but that seems out of scope for this P1.
>> 
>> This is "just" an issue with copyright dates in source files ... and yes, while I know copyright dates are important, this problem is arguably part of an ongoing more general problem.
>> 
>> I note that the generated files *do* correctly identify themselves with `2021` in the visible output generated to the console by the `man` command.
>
> Thanks for the explanation, Jon. Fine by me.

I agree that fixing this date is not necessary at this time.

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From jjg at openjdk.java.net  Thu Aug  5 22:15:29 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 5 Aug 2021 22:15:29 GMT
Subject: [jdk17] Integrated: JDK-8270872: Final nroff manpage update for JDK 17
In-Reply-To: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
References: <o52TRFEciQIkCH68afOXPv-DPva8a-LLokU6K0aPPVI=.ca6ced5d-9a0c-4700-bf86-0f29750adca6@github.com>
Message-ID: <k3Bqh5GeG3FgEBh_9rbFrDjJrTd6VSoO2S-KYSPIY_s=.50ab8e33-39b0-4ca9-9931-61cb55ec5c0d@github.com>

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a semi-automatic update of the nroff man pages from the upstream files.

This pull request has now been integrated.

Changeset: dfacda48
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/dfacda488bfbe2e11e8d607a6d08527710286982
Stats:     289 lines in 27 files changed: 117 ins; 31 del; 141 mod

8270872: Final nroff manpage update for JDK 17

Reviewed-by: darcy, mr, iris, naoto

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

PR: https://git.openjdk.java.net/jdk17/pull/303

From jwilhelm at openjdk.java.net  Thu Aug  5 23:57:59 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 5 Aug 2021 23:57:59 GMT
Subject: RFR: Merge jdk17
Message-ID: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8270872: Final nroff manpage update for JDK 17
 - 8271588: JFR Recorder Thread crashed with SIGSEGV in write_klass
 - 8271863: ProblemList serviceability/sa/TestJmapCore.java on linux-x64 with ZGC

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

Changes: https://git.openjdk.java.net/jdk/pull/5026/files
  Stats: 307 lines in 32 files changed: 129 ins; 33 del; 145 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5026/head:pull/5026

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

From jwilhelm at openjdk.java.net  Fri Aug  6 01:27:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 6 Aug 2021 01:27:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
References: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
Message-ID: <1oUovSIU_RoljyN5VHPljZLMI5NpHqK3ys9BDhsuLI8=.15d53c62-802e-4982-9415-527c302b8ab4@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 440 commits:

 - Merge
 - 8271293: Monitor class should use ThreadBlockInVMPreprocess
   
   Reviewed-by: dholmes, dcubed
 - 8270116: Expand ButtonGroupLayoutTraversalTest.java to run in all LaFs, including Aqua on macOS
   
   Reviewed-by: psadhukhan, aivanov
 - 8271905: mark hotspot runtime/Metaspace tests which ignore external VM flags
   
   Reviewed-by: stuefe
 - 8271308: (fc) FileChannel.transferTo() transfers no more than Integer.MAX_VALUE bytes in one call
   
   Reviewed-by: alanb, vtewari
 - 8271953: fix mis-merge in JDK-8271878
   
   Reviewed-by: jwilhelm, ctornqvi
 - 8267840: Improve URLStreamHandler.parseURL()
   
   Reviewed-by: dfuchs, redestad
 - 8271840: Add simple Integer.toString microbenchmarks
   
   Reviewed-by: shade
 - 8271121: ZGC: stack overflow (segv) when -Xlog:gc+start=debug
   
   Reviewed-by: ayang, eosterlund
 - 8270903: sun.net.httpserver.HttpConnection: Improve toString
   
   Reviewed-by: chegar, vtewari
 - ... and 430 more: https://git.openjdk.java.net/jdk/compare/dfacda48...7e069880

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

Changes: https://git.openjdk.java.net/jdk/pull/5026/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5026&range=01
  Stats: 97370 lines in 1522 files changed: 61891 ins; 27834 del; 7645 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5026/head:pull/5026

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

From jwilhelm at openjdk.java.net  Fri Aug  6 01:27:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 6 Aug 2021 01:27:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
References: <ZWfLNTnRXylfPAqm6WcKdGasNkjf5rRSe56fGDYxYsw=.b7033ab6-6b03-4303-afcc-71fd6b9ec8b2@github.com>
Message-ID: <lfK3BfjviJuRKG0C--gFo3MRja2_KrGtQjN4gEp4OsU=.9c421dfd-08de-40d5-8fb5-f88dcad215bb@github.com>

On Thu, 5 Aug 2021 23:49:48 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 14692d5e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/14692d5ed0652b867fcf28baafa498a9441683ac
Stats:     307 lines in 32 files changed: 129 ins; 33 del; 145 mod

Merge

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

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

From Alan.Bateman at oracle.com  Fri Aug  6 08:43:58 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 6 Aug 2021 09:43:58 +0100
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <5390d861-a112-10c0-8e80-887e877080bd@oracle.com>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <b4d6d1cc-2b42-9ec0-bc7b-2b4f683754d0@oracle.com>
 <5390d861-a112-10c0-8e80-887e877080bd@oracle.com>
Message-ID: <7521049a-d476-a1e4-0ff0-4ea06eda844c@oracle.com>

On 05/08/2021 19:24, Chris Plummer wrote:
> Yes, it would be an "interesting project", but I'm not so sure we want 
> to put that level of effort into jdb. It's just not that widely used, 
> and is mainly there to demonstrate JDI use and to help test JDI, and 
> on occasion for very basic java debugging when the user doesn't care 
> to config an IDE to do such.

Yes, I assume most developers will just debug in the IDE. For the JDK 
then its usage is mostly for tests. It was originally intended as an 
example debugger but since it has been included in the JDK for a long 
time then it may be used for rudimentary debugging when there isn't 
anything else.

In any case, my main point is that if Jakob wants to put time into 
improving its usability then prototyping something that adds basic line 
editing and history support is potentially useful. I assume that would 
replace the TTY read/dispatch loop. If that were prototyped then it 
might give some sense on the effort to review, maintain, and be sure 
that the tests continue to run. I'm a bit dubious about changing jdb to 
have blank lines repeat like gdb. Hard to know if users of jdb expect 
that behavior and also it feels like basic history navigation would be 
better.

-Alan

From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net  Fri Aug  6 14:24:32 2021
From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot])
Date: Fri, 6 Aug 2021 14:24:32 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2]
In-Reply-To: <GuzRQzdiycGH9wavM09u0ShTA3g8fX5scKCxicQpELI=.e7e8d089-5dda-4b8b-beef-000f765db208@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
 <GuzRQzdiycGH9wavM09u0ShTA3g8fX5scKCxicQpELI=.e7e8d089-5dda-4b8b-beef-000f765db208@github.com>
Message-ID: <U-dI8N5rRvdRmDVXZiY3Qd0AlHr7aCwCvH80C5BB68I=.f5f84026-070c-4756-8c1e-61f531124cd5@github.com>

On Mon, 2 Aug 2021 19:22:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to support JFR use of new ThreadsList::Iterator.
>> 
>> This fix was tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty 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 branch 'pull/4948' into JDK-8271514
>  - Merge branch 'pull/4948' into JDK-8271514
>  - 8271514: support JFR use of new ThreadsList::Iterator

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 JDK-8271513
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/4949

From larry.cable at oracle.com  Fri Aug  6 15:12:35 2021
From: larry.cable at oracle.com (Laurence Cable)
Date: Fri, 6 Aug 2021 08:12:35 -0700
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <7521049a-d476-a1e4-0ff0-4ea06eda844c@oracle.com>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <b4d6d1cc-2b42-9ec0-bc7b-2b4f683754d0@oracle.com>
 <5390d861-a112-10c0-8e80-887e877080bd@oracle.com>
 <7521049a-d476-a1e4-0ff0-4ea06eda844c@oracle.com>
Message-ID: <0798bc02-7cba-81af-ea7a-2d7295cebe47@oracle.com>



On 8/6/21 1:43 AM, Alan Bateman wrote:
> On 05/08/2021 19:24, Chris Plummer wrote:
>> Yes, it would be an "interesting project", but I'm not so sure we 
>> want to put that level of effort into jdb. It's just not that widely 
>> used, and is mainly there to demonstrate JDI use and to help test 
>> JDI, and on occasion for very basic java debugging when the user 
>> doesn't care to config an IDE to do such.
>
> Yes, I assume most developers will just debug in the IDE. For the JDK 
> then its usage is mostly for tests. It was originally intended as an 
> example debugger but since it has been included in the JDK for a long 
> time then it may be used for rudimentary debugging when there isn't 
> anything else.
>
> In any case, my main point is that if Jakob wants to put time into 
> improving its usability then prototyping something that adds basic 
> line editing and history support is potentially useful. I assume that 
> would replace the TTY read/dispatch loop. If that were prototyped then 
> it might give some sense on the effort to review, maintain, and be 
> sure that the tests continue to run. _/*I'm a bit dubious about 
> changing jdb to have blank lines repeat like gdb. Hard to know if 
> users of jdb expect that behavior and also it feels like basic history 
> navigation would be better. */_
>
> -Alan

this is my concern also...

- Larry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210806/1114b39a/attachment.htm>

From coleenp at openjdk.java.net  Fri Aug  6 15:22:35 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 6 Aug 2021 15:22:35 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v3]
In-Reply-To: <TmkBQppTdF1Tyh_RinVYffqhQ6pc74aFDlDlbeT_GCg=.86029d51-2a34-4a5a-b52a-75c2d619ab98@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
 <hLKXyCxyIu94L_QusC1oS_sb_UuXwbHLh2PHZOI_KYo=.7206b393-53be-4c1f-8bd9-68e7eb86fb3f@github.com>
 <Jf7XTGdCTXqpmHGiWZ271qxFuUePNSfHij7kHMaGAOE=.5aadbd01-4a38-4975-b4c8-dcad0f58e4b2@github.com>
 <HK22i5IFIGBCirZhL7VylAhCcV0tfmrlyacN_dL6umo=.c0d1e16f-e28c-4228-b253-92a6b4385069@github.com>
 <lfYUORaqnSvMeEdQGDYi-sN_k6oyJiLgadjyumiqjpg=.6529453b-f06c-45b5-b6c9-518ba0ecb6f2@github.com>
 <hafKRbdg9V2IxXSMy5__J-Pw2FR7AO9DSVMYpA5vJB8=.58013d68-5f60-4db8-b8f2-1d8aa89d78b2@github.com>
 <HmKZMqg3dXZ1Ku3hAsyUE2XleQH2SMUCGs1SOdMzjd0=.1877430a-5634-4f33-8f17-6a4e78b672eb@github.com>
 <TmkBQppTdF1Tyh_RinVYffqhQ6pc74aFDlDlbeT_GCg=.86029d51-2a34-4a5a-b52a-75c2d619ab98@github.com>
Message-ID: <QF5hEMyNvkDfJZvsIVgwr4TkYInq4UEs207bQp05wHo=.cd2c54d1-97c1-4222-9381-55dc31315dbc@github.com>

On Thu, 5 Aug 2021 09:33:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The JfrThreadIterator is only used as a stack-allocated object, so it and the adapters can be decorated with StackObj to better communicate this intent. The AP (Allocation Policy) policy in JfrThreadIterator can be removed and the JfrThreadIterator can be decorated with StackObj (unconditionally). Depends on how much you want to spend on this (I would guess minimal). But in actual usages, the iterators and adapters are de-facto StackObj already.
>
> Ah I didn't realise JTIWH was also stackObj.
> 
> The thing with StackObj to me is that it indicates a local object that does something interesting on construction and then also on destruction (eg. like MutexLocker). So having one as a member where the destruction is not related to a stack scope seems odd to me. But a stackObj member in a stackObj class seems more reasonable.

StackObj to me communicates intent. I don't have to look for "new SomeClass" to see how it is allocated and deallocated, since the new and delete operator are private and won't compile.  Same is true for AllStatic.  I'm one that hasn't been convinced otherwise.  I'm not totally intransigent though as i approved the removal of ValueObj. So there's that.

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

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

From jakob at jcornell.net  Fri Aug  6 16:04:23 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Fri, 6 Aug 2021 11:04:23 -0500
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <0798bc02-7cba-81af-ea7a-2d7295cebe47@oracle.com>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <b4d6d1cc-2b42-9ec0-bc7b-2b4f683754d0@oracle.com>
 <5390d861-a112-10c0-8e80-887e877080bd@oracle.com>
 <7521049a-d476-a1e4-0ff0-4ea06eda844c@oracle.com>
 <0798bc02-7cba-81af-ea7a-2d7295cebe47@oracle.com>
Message-ID: <da45b719-5df2-a43e-bd02-f02db0e1ef94@jcornell.net>

> I'm a bit dubious about changing jdb to have blank lines repeat like gdb. Hard to know if users of jdb expect that behavior and also it feels like basic history navigation would be better.

Well that would be addressed by our plan to leave the functionality off by default; I believe enable/disable commands are the currently preferred way, so that I can then specify something like `repeat' in my jdbrc file to enable it.

In my view line editing/history would make JDB much better, but the difference between one keystroke (Enter) per repetition with auto-repeat and two (Up, Enter) with history navigation would be noticeable when quickly stepping through a few lines of code.  Also I'd note that PDB and perhaps other debuggers already replicate GDB's auto-repeat behavior, so at least for developers with language experience beyond Java I would expect this to be a welcome change.

From dcubed at openjdk.java.net  Fri Aug  6 16:52:43 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 6 Aug 2021 16:52:43 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v3]
In-Reply-To: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
Message-ID: <RN2oiVEmCk0A0YAew8dEi0v5WCppjhHee8Sv1WAnhyc=.d62656fe-1ad8-489b-92b2-7b798ce74ffd@github.com>

> A trivial fix to support JFR use of new ThreadsList::Iterator.
> 
> This fix was tested with Mach5 Tier[1-3].

Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8271514
 - Merge branch 'pull/4948' into JDK-8271514
 - Merge branch 'master' into JDK-8271513
 - Merge branch 'pull/4948' into JDK-8271514
 - Merge branch 'pull/4671' into JDK-8271513
 - kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)'
 - 8271514: support JFR use of new ThreadsList::Iterator
 - 8271513: support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator
 - 8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features.
 - Merge branch 'master' into JDK-8193559
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/fa36e334...8873ddd5

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

Changes: https://git.openjdk.java.net/jdk/pull/4949/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4949&range=02
  Stats: 39 lines in 2 files changed: 20 ins; 11 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4949.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4949/head:pull/4949

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Aug  9 07:19:35 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 9 Aug 2021 07:19:35 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <FRn0jQHYWMJL5GTfhu4TWGlg8OaBHVpEoIQ_pCka3rs=.151177ce-ac88-4932-b8c9-c6e59a148b5c@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
 <FRn0jQHYWMJL5GTfhu4TWGlg8OaBHVpEoIQ_pCka3rs=.151177ce-ac88-4932-b8c9-c6e59a148b5c@github.com>
Message-ID: <Xqihf0FQRXJ1pSX1pwiDvQtkch4rk3NzsqueqX3oHeE=.1ef95f7e-1fa9-4a62-adba-fc71af5b256d@github.com>

On Mon, 26 Jul 2021 19:55:09 GMT, Brett Okken <github.com+2996845+bokken at openjdk.org> wrote:

>> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
>> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java line 92:
> 
>> 90:       }
>> 91: 
>> 92:       InstanceKlass[] searchResult = tmp.toArray(new InstanceKlass[0]);
> 
> Is it too far outside the scope of these changes to make `tmp` an `ArrayList` rather than a `Vector`?

I'll create separate PRs to migrate Vector usages to ArrayList.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Aug  9 07:22:32 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 9 Aug 2021 07:22:32 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <amB5jIt1-LyF6A8_OxgTfO6tDKhujRwvnM1QYqPbzkU=.17cd1c88-0ff5-42f6-ad9b-53d5cbdd74e5@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
 <amB5jIt1-LyF6A8_OxgTfO6tDKhujRwvnM1QYqPbzkU=.17cd1c88-0ff5-42f6-ad9b-53d5cbdd74e5@github.com>
Message-ID: <HqD_Urp5kW5PrEuwhyKtoXVvwNjXIJw-yJcLQBx4Ki4=.3c256fe3-ce0d-4fb9-83c1-1b0f355e764e@github.com>

On Mon, 26 Jul 2021 19:15:55 GMT, Brett Okken <github.com+2996845+bokken at openjdk.org> wrote:

>> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
>> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.
>
> src/java.base/share/classes/java/security/Security.java line 656:
> 
>> 654:             return null;
>> 655: 
>> 656:         return candidates.toArray(new Provider[0]);
> 
> Is this called often enough to warrant creating a constant of `new Provider[0]` (benefits of this covered in the _Wisdom of the Ancients_ blog linked)?

May be yes, may be not. I like `0`-sized array approach more.
1. It looks clearer and easier to read
2. It should be faster than original code anyway

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

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

From serb at openjdk.java.net  Tue Aug 10 05:20:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Aug 2021 05:20:42 GMT
Subject: RFR: 8272120: Avoid looking for standard encodings in "java." modules
Message-ID: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>

This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once.

In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");

This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
absolutePath.getBytes(StandardCharsets.UTF_8);

The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.

tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

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

Commit messages:
 - Initial fix of JDK-8272120

Changes: https://git.openjdk.java.net/jdk/pull/5063/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5063&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272120
  Stats: 127 lines in 15 files changed: 24 ins; 53 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5063.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5063/head:pull/5063

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

From alanb at openjdk.java.net  Tue Aug 10 09:21:28 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 Aug 2021 09:21:28 GMT
Subject: RFR: 8272120: Avoid looking for standard encodings in "java."
 modules
In-Reply-To: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
References: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
Message-ID: <iaZwq7CkU8Sx0dM5aHN70uJhB87ALtUNod1yl20qyE8=.a0f4b7e6-1718-406c-a57c-a02dd23cd242@github.com>

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

It would be useful to get up to date performance data on using Charset vs. charset name. At least historically, the charset name versions were faster (see [JDK-6764325](https://bugs.openjdk.java.net/browse/JDK-6764325)).

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Aug 10 13:31:33 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 10 Aug 2021 13:31:33 GMT
Subject: Integrated: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <JJGZR4laP8KnqFOpSXhP3OgWsKPHImScciAp3144GYE=.3f71f3f5-ada9-42d6-b82f-206fcc3354bb@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

This pull request has now been integrated.

Changeset: 35b399ac
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/35b399aca810db63371ff65046f047ef0b955161
Stats:     70 lines in 8 files changed: 0 ins; 54 del; 16 mod

8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying

Reviewed-by: mullan, serb

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

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

From serb at openjdk.java.net  Tue Aug 10 18:09:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 10 Aug 2021 18:09:26 GMT
Subject: RFR: 8272120: Avoid looking for standard encodings in "java."
 modules
In-Reply-To: <iaZwq7CkU8Sx0dM5aHN70uJhB87ALtUNod1yl20qyE8=.a0f4b7e6-1718-406c-a57c-a02dd23cd242@github.com>
References: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
 <iaZwq7CkU8Sx0dM5aHN70uJhB87ALtUNod1yl20qyE8=.a0f4b7e6-1718-406c-a57c-a02dd23cd242@github.com>
Message-ID: <9hTy8U6wk2uDoxCYlENexy2olb-8vaF49ZukcQj_bSA=.b9c53124-ea69-4cee-8698-3781b2b4acc5@github.com>

On Tue, 10 Aug 2021 09:18:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It would be useful to get up to date performance data on using Charset vs. charset name. At least historically, the charset name versions were faster (see [JDK-6764325](https://bugs.openjdk.java.net/browse/JDK-6764325)).

The code in question was changed a few times since then, the last change was done by the https://github.com/openjdk/jdk/pull/2102. So currently the code for string.getBytes String/Charset uses the same code paths, except that the string version has an additional call to lookup the charset.
The string version:
https://github.com/openjdk/jdk/blob/66d1faa7847b645f20ab2e966adf0a523e3ffeb2/src/java.base/share/classes/java/lang/String.java#L1753
The charset version:
https://github.com/openjdk/jdk/blob/66d1faa7847b645f20ab2e966adf0a523e3ffeb2/src/java.base/share/classes/java/lang/String.java#L1777

I checked the performance and the charset is always faster, depending on the string size, up to x20.

@cl4es please confirm my observation since you did it already for https://github.com/openjdk/jdk/pull/2102

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

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

From redestad at openjdk.java.net  Tue Aug 10 18:44:26 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 10 Aug 2021 18:44:26 GMT
Subject: RFR: 8272120: Avoid looking for standard encodings in "java."
 modules
In-Reply-To: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
References: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
Message-ID: <yDUEF2bX4Ysmpo5kH_cu5lSgBQlXr0TIA9qySLKdNUY=.68bcc4dd-6359-4ea5-8fc1-96072c1ab975@github.com>

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Yes, while I don't know exactly which changes resolved JDK-6764325, it's clear from the microbenchmarks added for #2102 that it's no longer an issue - at least not in the mainline.

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

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

From amenkov at openjdk.java.net  Tue Aug 10 19:16:32 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 10 Aug 2021 19:16:32 GMT
Subject: Integrated: 8213714: AttachingConnector/attach/attach001 failed due
 to "bind failed: Address already in use"
In-Reply-To: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
References: <XC3jPAqcwPStNmclkfA7ObuPIGAbF09ikdinOiexUpE=.44f022c9-fe41-4345-8a60-45479fd79e01@github.com>
Message-ID: <J_l2qIHnZLL30wIvuLYcWMt7O9CvdN5kJZO50VZU_7I=.044fa288-997b-4c79-91a5-9ef40b8b436b@github.com>

On Sat, 17 Jul 2021 00:38:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates the tests to use dynamic port launching debuggee and get the listening port from the debugee output

This pull request has now been integrated.

Changeset: b62e7420
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b62e7420450dad5a807a5afa0f65f6632b344e29
Stats:     146 lines in 4 files changed: 63 ins; 53 del; 30 mod

8213714: AttachingConnector/attach/attach001 failed due to "bind failed: Address already in use"

Reviewed-by: sspitsyn, cjplummer

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

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

From dfuchs at openjdk.java.net  Wed Aug 11 09:15:24 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 Aug 2021 09:15:24 GMT
Subject: RFR: 8272120: Avoid looking for standard encodings in "java."
 modules
In-Reply-To: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
References: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
Message-ID: <FibpkA8k62h5ScNVcNS8qxbBGN88KJ-eL6BNU29qYjg=.4ff80097-a983-4e75-a80f-8a246f83e3ae@github.com>

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

>From my pure developer's perspective the proposed changes look good. If the performance concerns are removed I'd say it looks good to me.

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

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

From rschmelter at openjdk.java.net  Wed Aug 11 13:11:33 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Wed, 11 Aug 2021 13:11:33 GMT
Subject: RFR: JDK-8272318: Improve performance of HeapDumpAllTest
Message-ID: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>

This change triggers a GC by System.gc() in the test case, so the created heap dump is significantly smaller and the test runs much faster.

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

Commit messages:
 - Improve performance of HeapDumpAllTest

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

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

From naoto at openjdk.java.net  Wed Aug 11 17:08:23 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 Aug 2021 17:08:23 GMT
Subject: RFR: 8272120: Avoid looking for standard encodings in "java."
 modules
In-Reply-To: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
References: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
Message-ID: <rXBNXoSAErS6KdW8Kmed72dVPojZNPOtVgPELIlPvH0=.a64674dc-2e12-404f-934e-486cacc61bf3@github.com>

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

+1

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

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

From alanb at openjdk.java.net  Wed Aug 11 18:59:22 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 Aug 2021 18:59:22 GMT
Subject: RFR: 8272120: Avoid looking for standard encodings in "java."
 modules
In-Reply-To: <yDUEF2bX4Ysmpo5kH_cu5lSgBQlXr0TIA9qySLKdNUY=.68bcc4dd-6359-4ea5-8fc1-96072c1ab975@github.com>
References: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
 <yDUEF2bX4Ysmpo5kH_cu5lSgBQlXr0TIA9qySLKdNUY=.68bcc4dd-6359-4ea5-8fc1-96072c1ab975@github.com>
Message-ID: <IYmlj5OTz6XK0dGBqmsqvU4K7mT1AH_B4am9325jF6A=.c4501c2a-1486-4ea3-9927-5aed28a6ce6b@github.com>

On Tue, 10 Aug 2021 18:41:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Yes, while I don't know exactly which changes resolved JDK-6764325, it's clear from the microbenchmarks added for #2102 that it's no longer an issue - at least not in the mainline.

Thanks for checking and for closing that issue.

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

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

From alanb at openjdk.java.net  Wed Aug 11 18:59:22 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 Aug 2021 18:59:22 GMT
Subject: RFR: 8272120: Avoid looking for standard encodings in "java."
 modules
In-Reply-To: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
References: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
Message-ID: <qd25FkCswF5DmUqz6lUaafw2rSJLT_SrVpbwJmeF3S8=.8a9bf468-9fe3-438f-a9fe-171aa08d8240@github.com>

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Marked as reviewed by alanb (Reviewer).

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

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

From dfuchs at openjdk.java.net  Wed Aug 11 19:04:24 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 11 Aug 2021 19:04:24 GMT
Subject: RFR: 8272120: Avoid looking for standard encodings in "java."
 modules
In-Reply-To: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
References: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
Message-ID: <XnSxRnUhzu3bVzmpwIZqMRbDn0mVdAHl7KxVBwPa4Go=.74b06372-0753-4b23-8920-1c0f86fde9a9@github.com>

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Marked as reviewed by dfuchs (Reviewer).

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

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

From naoto at openjdk.java.net  Wed Aug 11 19:10:26 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 Aug 2021 19:10:26 GMT
Subject: RFR: 8272120: Avoid looking for standard encodings in "java."
 modules
In-Reply-To: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
References: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
Message-ID: <ItBrtiG4VzdSJQvvY_DeW8gCzBGh1EX6I-sFyqvpxPg=.f4062c6c-1ac0-4f5c-a496-03059a0214f4@github.com>

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Marked as reviewed by naoto (Reviewer).

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

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

From cjplummer at openjdk.java.net  Wed Aug 11 19:22:24 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 11 Aug 2021 19:22:24 GMT
Subject: RFR: JDK-8272318: Improve performance of HeapDumpAllTest
In-Reply-To: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
References: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
Message-ID: <xmAQpV4UhaQxBwA_kPbDLO3rbqfgqTe_qgdOv0zdS70=.c100558b-de3c-4f15-971f-ddc93d8d3a6a@github.com>

On Wed, 11 Aug 2021 13:05:06 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> This change triggers a GC by System.gc() in the test case, so the created heap dump is significantly smaller and the test runs much faster.

Is there a reason you don't want this change to also apply to HeapDumpTest?

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

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

From serb at openjdk.java.net  Thu Aug 12 01:51:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 01:51:23 GMT
Subject: RFR: JDK-8272318: Improve performance of HeapDumpAllTest
In-Reply-To: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
References: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
Message-ID: <i06tmcEF93W8yRTFhb476tor2h6O4O2LS1NYXdZzBro=.33165bdf-8f60-48a9-b5b0-f77cc2221e58@github.com>

On Wed, 11 Aug 2021 13:05:06 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> This change triggers a GC by System.gc() in the test case, so the created heap dump is significantly smaller and the test runs much faster.

I also tried to improve this test, it almost always fails because of OOM when tried to parse the heap dump, the solution which works on my system is to mark the test as othervm. Can we do this in this change, or I can create a separate CR.

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

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

From serb at openjdk.java.net  Thu Aug 12 05:49:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 12 Aug 2021 05:49:28 GMT
Subject: Integrated: 8272120: Avoid looking for standard encodings in "java."
 modules
In-Reply-To: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
References: <hg4-IMgpOdDNPoJDtl-mOYbpRx9moJ_YnWVzuM0MdCU=.68a1683a-f896-491b-acef-d4002c25e5dd@github.com>
Message-ID: <agg3n6G3MH6Oa9VOYwVrWvhzX9MU6qy2CoGkZlxSjnI=.fb969f07-75d2-46f6-8486-a706d6f86cca@github.com>

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

This pull request has now been integrated.

Changeset: ec2fc384
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec2fc384e50668b667335f973ffeb5a19bbcfb9b
Stats:     127 lines in 15 files changed: 24 ins; 53 del; 50 mod

8272120: Avoid looking for standard encodings in "java." modules

Reviewed-by: alanb, dfuchs, naoto

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

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

From rschmelter at openjdk.java.net  Thu Aug 12 06:13:23 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Thu, 12 Aug 2021 06:13:23 GMT
Subject: RFR: JDK-8272318: Improve performance of HeapDumpAllTest
In-Reply-To: <xmAQpV4UhaQxBwA_kPbDLO3rbqfgqTe_qgdOv0zdS70=.c100558b-de3c-4f15-971f-ddc93d8d3a6a@github.com>
References: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
 <xmAQpV4UhaQxBwA_kPbDLO3rbqfgqTe_qgdOv0zdS70=.c100558b-de3c-4f15-971f-ddc93d8d3a6a@github.com>
Message-ID: <Xs7t5WX_bMayXE1P8DNg_kFrYvNvGP42U7KWkApp0Ss=.868ff165-9519-47e8-8257-612493146bb9@github.com>

On Wed, 11 Aug 2021 19:19:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Is there a reason you don't want this change to also apply to HeapDumpTest?

Since the GC.heap_dump already does a GC it is not really needed. Of course doing the gc in HeapDumpTest is a smaller change, so I'm open for that.

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

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

From lzang at openjdk.java.net  Thu Aug 12 07:52:25 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 12 Aug 2021 07:52:25 GMT
Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use
 try-with-resource [v4]
In-Reply-To: <B5yhNUrAI9UbfoaiCcd0plO6RLP_wrROyl-QtZydY3o=.d57e1426-cd9e-4db6-b931-ed825ff411c8@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <oYpfsJXyV1KVHyGzEKi-9u7ibyTSnlKuFSApw_7QwFI=.ac80fa39-e780-459f-894b-8c46e37898ff@github.com>
 <B5yhNUrAI9UbfoaiCcd0plO6RLP_wrROyl-QtZydY3o=.d57e1426-cd9e-4db6-b931-ed825ff411c8@github.com>
Message-ID: <3PwAHJTghJ05xA9EOo4_GKQ0QEC03OtbGzyvN5NMI0E=.664a0bb4-aca5-4ee0-9cdb-ad8aca0c3fc6@github.com>

On Wed, 14 Jul 2021 05:05:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - fix indentation issue
>>  - Merge branch 'master' into try
>>  - revise code to handle the closing of embeded streams
>>  - Merge branch 'master' into try
>>  - 8269909: getStack method in hprof.parser.Reader should use try-with-resource
>
> The indentation of the first two try-with-resources blocks is still wrong.

Hi @dholmes-ora  and @plummercj,
I think this PR has been there for quite a while, I have no idea for what I can do to make progress, so may I ask your help to sponsor it? or should we wait for Serguei's approve?  Any suggestions? 
Thanks!
- Lin

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

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

From lzang at openjdk.java.net  Thu Aug 12 09:44:29 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 12 Aug 2021 09:44:29 GMT
Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use
 try-with-resource [v5]
In-Reply-To: <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com>
Message-ID: <yig1A-r-ylsqkwM9RC_ueskVKKnBRVPPe8VDqW3syLw=.1a24cbdb-f5f6-43f4-89c6-2e9d324c08cd@github.com>

On Fri, 16 Jul 2021 11:53:15 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8269909: getStack method in hprof.parser.Reader should use try-with-resource
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename variables

Just got a quick update from Serguei, Let's wait for his approve. Thanks all for your help!
-Lin

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

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

From sspitsyn at openjdk.java.net  Thu Aug 12 23:19:28 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 12 Aug 2021 23:19:28 GMT
Subject: RFR: 8269909: getStack method in hprof.parser.Reader should use
 try-with-resource [v5]
In-Reply-To: <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
 <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com>
Message-ID: <KKTQuITUKxiNdvLMIUtLML-EjlAIc8eEbB2M_hLIy6M=.106a0b54-05b8-4894-b0b8-7c4e39ea090f@github.com>

On Fri, 16 Jul 2021 11:53:15 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8269909: getStack method in hprof.parser.Reader should use try-with-resource
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename variables

Hi Lin,
Sorry for latency. I was on vacation and thought you have already integrated this fix.
The update looks okay to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From lzang at openjdk.java.net  Thu Aug 12 23:19:29 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 12 Aug 2021 23:19:29 GMT
Subject: Integrated: 8269909: getStack method in hprof.parser.Reader should
 use try-with-resource
In-Reply-To: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
References: <Rj-woDf_XO3AA6O_6W-quKVmJNfj4xhIUW50r6g2bfM=.64c886fa-74b2-475a-8d33-7268a35d03fc@github.com>
Message-ID: <IUQBNXdYe1O9iUjkBA_mn93I82IWgpO637G8RSVPSKU=.f6eca76b-90c0-4e52-93d5-286e19755ffe@github.com>

On Thu, 8 Jul 2021 08:16:51 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 8269909: getStack method in hprof.parser.Reader should use try-with-resource

This pull request has now been integrated.

Changeset: 09ab86b4
Author:    Lin Zang <lzang at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/09ab86b40cb11d526c70e0a1847451e06c54a58c
Stats:     18 lines in 1 file changed: 2 ins; 0 del; 16 mod

8269909: getStack method in hprof.parser.Reader should use try-with-resource

Reviewed-by: dholmes, cjplummer, sspitsyn

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

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

From lzang at openjdk.java.net  Fri Aug 13 03:15:21 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 13 Aug 2021 03:15:21 GMT
Subject: RFR: JDK-8272318: Improve performance of HeapDumpAllTest
In-Reply-To: <Xs7t5WX_bMayXE1P8DNg_kFrYvNvGP42U7KWkApp0Ss=.868ff165-9519-47e8-8257-612493146bb9@github.com>
References: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
 <xmAQpV4UhaQxBwA_kPbDLO3rbqfgqTe_qgdOv0zdS70=.c100558b-de3c-4f15-971f-ddc93d8d3a6a@github.com>
 <Xs7t5WX_bMayXE1P8DNg_kFrYvNvGP42U7KWkApp0Ss=.868ff165-9519-47e8-8257-612493146bb9@github.com>
Message-ID: <qny8Aav1WGZov9sQtzQgIbzamwI_T-h5Vty2D88xgS0=.ee689a09-882d-4be3-9b04-a733682748b4@github.com>

On Thu, 12 Aug 2021 06:10:45 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> > Is there a reason you don't want this change to also apply to HeapDumpTest?
> 
> Since the GC.heap_dump already does a GC it is not really needed. Of course doing the gc in HeapDumpTest is a smaller change, so I'm open for that.

I prefer having System.gc() for "-all=true" only, IMO if put it into the HeapDumpTest, there can be 2 gc triggered, one from System.gc() and one from heapdump, which may be not necessary.  

One more question, is there necessary to have a test for using argument "-all=false" explicitly? Although it is used by default, maybe we need to test whether jcmd could accept the arguments normally.

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

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

From lzang at openjdk.java.net  Fri Aug 13 10:42:43 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 13 Aug 2021 10:42:43 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v30]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <CI-H7K2lhfROxivX8iafzwYPfCMpnluQ44oVAkl3XAE=.05a0ef4e-7d88-46b6-8acb-05f1f1ea0e6d@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 39 commits:

 - Merge branch 'master' into par-dump
 - fix build issue
 - Merge branch 'master' into par-dump
 - 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
 - ... and 29 more: https://git.openjdk.java.net/jdk/compare/d06d0b9e...5268e5d9

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

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=29
  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 Aug 13 10:46:02 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 13 Aug 2021 10:46:02 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v4]
In-Reply-To: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
Message-ID: <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com>

> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.

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 four additional commits since the last revision:

 - Merge branch 'master' into hprof
 - fix write size issue
 - Merge branch 'master' into hprof
 - 8269685: Optimize HeapHprofBinWriter implementation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4666/files
  - new: https://git.openjdk.java.net/jdk/pull/4666/files/59691b54..cb1cbeb0

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

  Stats: 91418 lines in 1578 files changed: 64311 ins; 19652 del; 7455 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4666.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4666/head:pull/4666

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

From dcubed at openjdk.java.net  Fri Aug 13 21:49:50 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 13 Aug 2021 21:49:50 GMT
Subject: RFR: 8249004: Reduce ThreadListHandle overhead in relation to
 direct handshakes [v3]
In-Reply-To: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com>
References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com>
Message-ID: <8UPe_BoT0l35YQqOY6e8GvT2swi6U7tTKTVpwt3NboM=.c4db8eac-946d-428d-8f9a-3dc6e84887ca@github.com>

> A trivial fix to reduce ThreadListHandle overhead in relation to handshakes.
> 
> This refactoring was tested with Mach5 Tier[1-3].

Daniel D. Daugherty 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 branch 'master' into JDK-8249004
 - Merge branch 'master' into JDK-8249004
 - Merge branch 'master' into JDK-8249004
 - 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4677/files
  - new: https://git.openjdk.java.net/jdk/pull/4677/files/bc82cfa6..507bcbc1

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

  Stats: 51887 lines in 716 files changed: 46118 ins; 3195 del; 2574 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4677.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4677/head:pull/4677

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

From hseigel at openjdk.java.net  Mon Aug 16 17:33:36 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 16 Aug 2021 17:33:36 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes NullPointerException
 when path contains colon
Message-ID: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>

Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".

The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.

Thanks, Harold

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

Commit messages:
 - 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon

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

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

From mseledtsov at openjdk.java.net  Mon Aug 16 23:40:44 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 16 Aug 2021 23:40:44 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage()
In-Reply-To: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
Message-ID: <UStqqHBtpUriKdou0OYnJnIPd0puWyqCUonD5DTs8pY=.2752bf5c-c2ee-448f-b672-99e51ab0a700@github.com>

On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Please review this change that updates the buildJdkDockerImage() test library API.
> 
> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
> As I analyzed the usage of buildJdkDockerImage() I realized that:
>   - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>       its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
>   - 3rd argument "buildDirName" is also always the same: "jdk-docker"
> 
> Hence I thought it would be a good idea to simplify this API and make it up-to-date.
> 
> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
> buildJdkDockerImage() --> buildJdkContainerImage()

@hseigel Could you please review when you have a chance ?

Testing:
  - ran jdk/containers and hotspot/containers tests on
     - OL 7.9 with Docker
     - OL 8.3 with Podman
     - OL 8.3 aarch64 with Podman
All PASS

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

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

From mseledtsov at openjdk.java.net  Mon Aug 16 23:40:44 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 16 Aug 2021 23:40:44 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage()
Message-ID: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>

Please review this change that updates the buildJdkDockerImage() test library API.

This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
As I analyzed the usage of buildJdkDockerImage() I realized that:
  - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
      its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
  - 3rd argument "buildDirName" is also always the same: "jdk-docker"

Hence I thought it would be a good idea to simplify this API and make it up-to-date.

Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
buildJdkDockerImage() --> buildJdkContainerImage()

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

Commit messages:
 - Updated buildJdkDockerImage, changed signature and renamed to buildJdkContainerImage
 - Proposed docker build API updates

Changes: https://git.openjdk.java.net/jdk/pull/5134/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5134&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272398
  Stats: 68 lines in 17 files changed: 20 ins; 15 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5134/head:pull/5134

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

From iignatyev at openjdk.java.net  Mon Aug 16 23:51:33 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 16 Aug 2021 23:51:33 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage()
In-Reply-To: <jnrub-odrT4PdXJ90nAdfKuZNIwK1xWMhiwiPrIZHGI=.76f4d360-13e1-4705-8cf8-460712032bce@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <jnrub-odrT4PdXJ90nAdfKuZNIwK1xWMhiwiPrIZHGI=.76f4d360-13e1-4705-8cf8-460712032bce@github.com>
Message-ID: <pHyfQWjFBkJ4GndKWANhdMmWMjIvsLixQe-ooDybmfc=.4bb5517f-60d4-46d0-821b-a19e8bafc2df@github.com>

On Mon, 16 Aug 2021 23:47:04 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Please review this change that updates the buildJdkDockerImage() test library API.
>> 
>> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
>> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
>> As I analyzed the usage of buildJdkDockerImage() I realized that:
>>   - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>>       its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
>>   - 3rd argument "buildDirName" is also always the same: "jdk-docker"
>> 
>> Hence I thought it would be a good idea to simplify this API and make it up-to-date.
>> 
>> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
>> buildJdkDockerImage() --> buildJdkContainerImage()
>
> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 145:
> 
>> 143: 
>> 144:         // Create an image build/staging directory
>> 145:         Path buildDir = Paths.get(".", "image-build");
> 
> to make it more robust and possible to have more than one container within a test, I'd use `imagName` + "image-build" as build dir name.

you also don't need to have `.` as a first argument, `Paths.get("x")` returns you a path to "x" in current directory.

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

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

From iignatyev at openjdk.java.net  Mon Aug 16 23:51:32 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 16 Aug 2021 23:51:32 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage()
In-Reply-To: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
Message-ID: <jnrub-odrT4PdXJ90nAdfKuZNIwK1xWMhiwiPrIZHGI=.76f4d360-13e1-4705-8cf8-460712032bce@github.com>

On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Please review this change that updates the buildJdkDockerImage() test library API.
> 
> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
> As I analyzed the usage of buildJdkDockerImage() I realized that:
>   - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>       its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
>   - 3rd argument "buildDirName" is also always the same: "jdk-docker"
> 
> Hence I thought it would be a good idea to simplify this API and make it up-to-date.
> 
> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
> buildJdkDockerImage() --> buildJdkContainerImage()

Changes requested by iignatyev (Reviewer).

test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 145:

> 143: 
> 144:         // Create an image build/staging directory
> 145:         Path buildDir = Paths.get(".", "image-build");

to make it more robust and possible to have more than one container within a test, I'd use `imagName` + "image-build" as build dir name.

test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 179:

> 177:      * @throws Exception
> 178:      */
> 179:     public static void buildImage(String imageName, Path buildDir) throws Exception {

it seems there are no users of this method, do we need to keep it public?

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

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

From mseledtsov at openjdk.java.net  Tue Aug 17 00:51:23 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 17 Aug 2021 00:51:23 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when path contains colon
In-Reply-To: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
Message-ID: <4K0vR12G3TYzHYgOjxrlL23DqsDzRdKZlvtQXPOKhc0=.16e92016-8bd3-49ae-abb6-d21a358c8122@github.com>

On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
> 
> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
> 
> Thanks, Harold

Changes look good to me.

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

Marked as reviewed by mseledtsov (Committer).

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

From mseledtsov at openjdk.java.net  Tue Aug 17 01:49:23 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 17 Aug 2021 01:49:23 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage()
In-Reply-To: <jnrub-odrT4PdXJ90nAdfKuZNIwK1xWMhiwiPrIZHGI=.76f4d360-13e1-4705-8cf8-460712032bce@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <jnrub-odrT4PdXJ90nAdfKuZNIwK1xWMhiwiPrIZHGI=.76f4d360-13e1-4705-8cf8-460712032bce@github.com>
Message-ID: <LOccRDfJbpa2gbpdDW-qmb_kHSmxvLiERRZDayfDTx4=.e5323e1c-4bed-42d7-ab4a-e43d12d4f757@github.com>

On Mon, 16 Aug 2021 23:48:46 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Please review this change that updates the buildJdkDockerImage() test library API.
>> 
>> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
>> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
>> As I analyzed the usage of buildJdkDockerImage() I realized that:
>>   - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>>       its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
>>   - 3rd argument "buildDirName" is also always the same: "jdk-docker"
>> 
>> Hence I thought it would be a good idea to simplify this API and make it up-to-date.
>> 
>> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
>> buildJdkDockerImage() --> buildJdkContainerImage()
>
> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 179:
> 
>> 177:      * @throws Exception
>> 178:      */
>> 179:     public static void buildImage(String imageName, Path buildDir) throws Exception {
> 
> it seems there are no users of this method, do we need to keep it public?

Sounds good. Will do.

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

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

From hirt at openjdk.java.net  Tue Aug 17 08:37:25 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Tue, 17 Aug 2021 08:37:25 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v3]
In-Reply-To: <eebr3nRX7hK2JWexDfv8WJD4f6w-YzBPZ-A2ps3RquU=.1b6132d6-0c47-4b07-9e66-e1563b2b0b5c@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <jfohRNi3z8LnjHcxEzmJNhuO7nKKEtBY5bhR-8uycVI=.b410939d-7166-4ea7-a046-c8ca8f2dcc93@github.com>
 <eebr3nRX7hK2JWexDfv8WJD4f6w-YzBPZ-A2ps3RquU=.1b6132d6-0c47-4b07-9e66-e1563b2b0b5c@github.com>
Message-ID: <O5qloDOgFuIb1VcZdbACL83pQhZZ124SBMVBx0brZGM=.58cd0ee3-84cb-4c49-adaf-7544dd9c8d47@github.com>

On Wed, 30 Jun 2021 09:17:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

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

Hi @sspitsyn! Will you be the one reviewing this?

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

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

From sgehwolf at openjdk.java.net  Tue Aug 17 13:12:24 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 17 Aug 2021 13:12:24 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when path contains colon
In-Reply-To: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
Message-ID: <2UtKcMi4-HV7wJ-jXgw1eicdGRCKmHdt5MLrEzU2woI=.a01f2eff-0d80-499a-97bc-91bf26ca7b67@github.com>

On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
> 
> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
> 
> Thanks, Harold

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 199:

> 197:                 action = (tokens -> setCgroupV2Path(infos, tokens));
> 198:             }
> 199:             selfCgroupLines.map(line -> line.split(":", 3))

Could you please add a comment explaining that the limit value of 3 comes from the fact that `/proc/self/cgroup` contains three colon-separated tokens per line. The last value, cgroup path, might contain `:`.

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 200:

> 198:             }
> 199:             selfCgroupLines.map(line -> line.split(":", 3))
> 200:                      .filter(tokens -> (tokens.length >= 3))

This filter no longer makes sense as tokens.length == 3 in every case after this patch. Please remove. From the javadoc from `String.split(String, limit)`:

If the limit is positive then the pattern will be applied
at most limit-1 times, the array's length will be
no greater than limit, and the array's last entry will contain
all input beyond the last matched delimiter.

test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 175:

> 173:     private String mntInfoCgroupsV1DoubleCpuset = mntInfoHybrid + mntInfoCgroupv1MoreCpusetLine;
> 174:     private String mntInfoCgroupsV1DoubleCpuset2 = mntInfoCgroupv1MoreCpusetLine + mntInfoHybrid;
> 175:     private String cgroupv1SelfCgroupContent = "11:memory:/user.slice/user-1000.slice/user at 1000.s:ervice\n" +

Could you please add a comment explaining that `/proc/self/cgroup` is supposed to contain **three** colon-separated fields, `hierarchy-ID:controller-list:cgroup-path`. Thus, this cgroup-path intentionally contains a colon so as to ensure the correct path is being extracted by the logic in CgroupSubsystemFactory.

Better yet, add a new test with `mountinfo` and `/proc/self/cgroup` contents observed in the wild and assert that `memoryInfo.getCgroupPath()` equals `memoryInfo.getMountRoot()`

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

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

From mseledtsov at openjdk.java.net  Tue Aug 17 14:58:48 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 17 Aug 2021 14:58:48 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v2]
In-Reply-To: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
Message-ID: <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>

> Please review this change that updates the buildJdkDockerImage() test library API.
> 
> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
> As I analyzed the usage of buildJdkDockerImage() I realized that:
>   - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>       its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
>   - 3rd argument "buildDirName" is also always the same: "jdk-docker"
> 
> Hence I thought it would be a good idea to simplify this API and make it up-to-date.
> 
> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
> buildJdkDockerImage() --> buildJdkContainerImage()

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

  Addressing review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5134/files
  - new: https://git.openjdk.java.net/jdk/pull/5134/files/51a75339..d211c220

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

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

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

From sgehwolf at openjdk.java.net  Tue Aug 17 15:04:28 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 17 Aug 2021 15:04:28 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when path contains colon
In-Reply-To: <2UtKcMi4-HV7wJ-jXgw1eicdGRCKmHdt5MLrEzU2woI=.a01f2eff-0d80-499a-97bc-91bf26ca7b67@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
 <2UtKcMi4-HV7wJ-jXgw1eicdGRCKmHdt5MLrEzU2woI=.a01f2eff-0d80-499a-97bc-91bf26ca7b67@github.com>
Message-ID: <w-IE4KoFre7gDgzCGEfQmzo4TbBRNCqvFL2OCZLaXg0=.ce726960-c97f-4fec-8dea-667e8b6d22e9@github.com>

On Tue, 17 Aug 2021 09:07:17 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
>> 
>> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
>> 
>> Thanks, Harold
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 200:
> 
>> 198:             }
>> 199:             selfCgroupLines.map(line -> line.split(":", 3))
>> 200:                      .filter(tokens -> (tokens.length >= 3))
> 
> This filter no longer makes sense as tokens.length == 3 in every case after this patch. Please remove. From the javadoc from `String.split(String, limit)`:
> 
> If the limit is positive then the pattern will be applied
> at most limit-1 times, the array's length will be
> no greater than limit, and the array's last entry will contain
> all input beyond the last matched delimiter.

On second thought, we might want to keep `tokens.length == 3`, but I don't know if it'll ever be < 3 in reality. It certainly would no longer be > 3.

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

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

From iignatyev at openjdk.java.net  Tue Aug 17 15:06:25 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 17 Aug 2021 15:06:25 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v2]
In-Reply-To: <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>
Message-ID: <tTL-Jc27gD1qm3Jm9Bu1NPRjH_BoAjEIG2eFPheqgPA=.301b2c1e-8fb9-491f-a30b-ff00d41a042b@github.com>

On Tue, 17 Aug 2021 14:58:48 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Please review this change that updates the buildJdkDockerImage() test library API.
>> 
>> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
>> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
>> As I analyzed the usage of buildJdkDockerImage() I realized that:
>>   - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>>       its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
>>   - 3rd argument "buildDirName" is also always the same: "jdk-docker"
>> 
>> Hence I thought it would be a good idea to simplify this API and make it up-to-date.
>> 
>> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
>> buildJdkDockerImage() --> buildJdkContainerImage()
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review feedback

Looks good and trivial to me.

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

Marked as reviewed by iignatyev (Reviewer).

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

From hseigel at openjdk.java.net  Tue Aug 17 17:39:49 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 17 Aug 2021 17:39:49 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when path contains colon
In-Reply-To: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
Message-ID: <gMs9VMd76p2RhhIgdWKzE7G3AhjyW3htJkuRbm-5Xn4=.59d7a46c-0c07-425c-a21e-c07f73d91493@github.com>

On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
> 
> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
> 
> Thanks, Harold

Thanks Misha and Severin for looking at this change!

Please review this updated commit that tries to address Severin's comments.  A new test case was added to TestCgroupSubsystemFactory.java for the multiple ':'s case and comments were added to CgroupSubsystemFactory.java.

The ".filter(tokens -> (tokens.length >= 3))" code was removed but can be restored if need be.

Thanks, Harold

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

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

From hseigel at openjdk.java.net  Tue Aug 17 17:39:49 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 17 Aug 2021 17:39:49 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when path contains colon [v2]
In-Reply-To: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
Message-ID: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com>

> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
> 
> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
> 
> Thanks, Harold

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

  add test case, comments, and other small changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5127/files
  - new: https://git.openjdk.java.net/jdk/pull/5127/files/918df2b4..5fa37e97

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

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

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

From sgehwolf at openjdk.java.net  Tue Aug 17 17:51:25 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 17 Aug 2021 17:51:25 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when path contains colon [v2]
In-Reply-To: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
 <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com>
Message-ID: <JfhKNr_0HtbT2yN3ovBv-TqAnh8wKIQun8KCp4pIn7Y=.f1f94ec7-5196-4508-8eb8-5518b85e01bd@github.com>

On Tue, 17 Aug 2021 17:39:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
>> 
>> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test case, comments, and other small changes

test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 375:

> 373:         CgroupInfo memoryInfo = res.getInfos().get("memory");
> 374:         assertEquals(memoryInfo.getCgroupPath(), "/system.slice/containerd.service/kubepods-burstable-podf65e797d_d5f9_4604_9773_94f4bb9946a0.slice:cri-containerd:86ac6260f9f8a9c1276748250f330ae9c2fcefe5ae809364ad1e45f3edf7e08a");
> 375:         assertEquals(memoryInfo.getMountRoot(), memoryInfo.getMountRoot());

What I meant here is to also change the mountinfo entry for `memory` and then use

assertEquals(memoryInfo.getMountRoot(), memoryInfo.getCgroupPath());

as that's really what was happening in the wild. mount root - containing colons - would correctly parse, but the cgroup path - containing colons - would not and the assertion would fail (without the change in CgroupSubsystemFactory). Thanks!

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

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

From hseigel at openjdk.java.net  Tue Aug 17 20:35:23 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 17 Aug 2021 20:35:23 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v2]
In-Reply-To: <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>
Message-ID: <L6DLEN-Wi6AM69qAXtWawEwgjsQsb-hE0XLwaxq10yw=.f397b447-be29-48fd-8c38-b859999fda4c@github.com>

On Tue, 17 Aug 2021 14:58:48 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Please review this change that updates the buildJdkDockerImage() test library API.
>> 
>> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
>> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
>> As I analyzed the usage of buildJdkDockerImage() I realized that:
>>   - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>>       its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
>>   - 3rd argument "buildDirName" is also always the same: "jdk-docker"
>> 
>> Hence I thought it would be a good idea to simplify this API and make it up-to-date.
>> 
>> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
>> buildJdkDockerImage() --> buildJdkContainerImage()
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review feedback

Other than that one obsolete comment the changes look good.
Thanks, Harold

test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 175:

> 173:     /**
> 174:      * Build a container image based on given Dockerfile and image build directory.
> 175:      *

This comment looks wrong because there is no longer a given Dockerfile.

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

Marked as reviewed by hseigel (Reviewer).

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

From mseledtsov at openjdk.java.net  Tue Aug 17 22:06:22 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 17 Aug 2021 22:06:22 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v2]
In-Reply-To: <L6DLEN-Wi6AM69qAXtWawEwgjsQsb-hE0XLwaxq10yw=.f397b447-be29-48fd-8c38-b859999fda4c@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <NPi2G0bRVmGneWyQAy8r2kp4zJDWsVw0Y69humawy9M=.1d234686-5053-4727-8b31-48c7796bb635@github.com>
 <L6DLEN-Wi6AM69qAXtWawEwgjsQsb-hE0XLwaxq10yw=.f397b447-be29-48fd-8c38-b859999fda4c@github.com>
Message-ID: <WUpJx86v6gR5GPPGGaM3lVfu-b5HgyN27pTozir0IEM=.090086ea-d037-47a9-b8d1-f51da1b5d150@github.com>

On Tue, 17 Aug 2021 20:30:04 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review feedback
>
> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 175:
> 
>> 173:     /**
>> 174:      * Build a container image based on given Dockerfile and image build directory.
>> 175:      *
> 
> This comment looks wrong because there is no longer a given Dockerfile.

Thanks. I will remove this comment.

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

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

From mseledtsov at openjdk.java.net  Tue Aug 17 22:13:54 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 17 Aug 2021 22:13:54 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v3]
In-Reply-To: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
Message-ID: <egat4OkVTZK7SpgD2-oEYhghFqpdke-nwRJbGP95I00=.87444341-45de-453a-ab8a-713a591a2603@github.com>

> Please review this change that updates the buildJdkDockerImage() test library API.
> 
> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
> As I analyzed the usage of buildJdkDockerImage() I realized that:
>   - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>       its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
>   - 3rd argument "buildDirName" is also always the same: "jdk-docker"
> 
> Hence I thought it would be a good idea to simplify this API and make it up-to-date.
> 
> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
> buildJdkDockerImage() --> buildJdkContainerImage()

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

  Fixed a comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5134/files
  - new: https://git.openjdk.java.net/jdk/pull/5134/files/d211c220..5dc08781

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

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

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

From mseledtsov at openjdk.java.net  Tue Aug 17 23:26:28 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 17 Aug 2021 23:26:28 GMT
Subject: Integrated: 8272398: Update DockerTestUtils.buildJdkDockerImage()
In-Reply-To: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
Message-ID: <36l3IOw3PFT9woDJaDBUSztd7XkzYJWeCEX2lZvTwI4=.dff81de4-b593-4519-afc9-4a8fab496ec2@github.com>

On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Please review this change that updates the buildJdkDockerImage() test library API.
> 
> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
> As I analyzed the usage of buildJdkDockerImage() I realized that:
>   - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>       its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
>   - 3rd argument "buildDirName" is also always the same: "jdk-docker"
> 
> Hence I thought it would be a good idea to simplify this API and make it up-to-date.
> 
> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
> buildJdkDockerImage() --> buildJdkContainerImage()

This pull request has now been integrated.

Changeset: ec63957f
Author:    Mikhailo Seledtsov <mseledtsov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec63957f9d103e86d3b8e235e79cabb8992cb3ca
Stats:     68 lines in 17 files changed: 20 ins; 13 del; 35 mod

8272398: Update DockerTestUtils.buildJdkDockerImage()

Reviewed-by: iignatyev, hseigel

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

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

From mseledtsov at openjdk.java.net  Tue Aug 17 23:26:27 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 17 Aug 2021 23:26:27 GMT
Subject: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v3]
In-Reply-To: <egat4OkVTZK7SpgD2-oEYhghFqpdke-nwRJbGP95I00=.87444341-45de-453a-ab8a-713a591a2603@github.com>
References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com>
 <egat4OkVTZK7SpgD2-oEYhghFqpdke-nwRJbGP95I00=.87444341-45de-453a-ab8a-713a591a2603@github.com>
Message-ID: <6nxeZAJ9wzVs6WB41Jcfx-4d3iQ24BJ78aPLA6Mmdpc=.e1298d97-a3cd-44b0-a482-3f51c90b3532@github.com>

On Tue, 17 Aug 2021 22:13:54 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Please review this change that updates the buildJdkDockerImage() test library API.
>> 
>> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l support for containers is not tested".
>> The initial intent was to extend the buildJdkDockerImage() API of DockerTestUtils to accept custom Dockerfile content.
>> As I analyzed the usage of buildJdkDockerImage() I realized that:
>>   - 2nd argument "dockerfile" is always the same: "Dockerfile-BasicTest"
>>       its use has been obsolete for some time, in favor of Dockerfile generated by DockerTestUtils
>>   - 3rd argument "buildDirName" is also always the same: "jdk-docker"
>> 
>> Hence I thought it would be a good idea to simplify this API and make it up-to-date.
>> 
>> Also, since the method signature is being updated, I thought it would be a good idea to also change the name to use more generic container terminology:
>> buildJdkDockerImage() --> buildJdkContainerImage()
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a comment

Igor, Harold, thank you for review.

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

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

From sspitsyn at openjdk.java.net  Wed Aug 18 06:54:34 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 18 Aug 2021 06:54:34 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
Message-ID: <MsTynAoBTqtmuCJKHJPQrQ-hyr6mvHzfRkujqMNgjHs=.4bb5ffeb-4958-4018-8e22-ee4733698258@github.com>

On Mon, 19 Jul 2021 09:25:59 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Remove FrameParser and the required allocation
>    
>    The need for the allocation would be it non async-safe. However,
>    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix-8178287
>  - Fix comments
>  - 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.

Hi Markus! I have a lack of expertize in this area and can't be the primary reviewer.
The problem is we have no test coverage to verify fixes.

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

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

From lucy at openjdk.java.net  Wed Aug 18 11:03:31 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 18 Aug 2021 11:03:31 GMT
Subject: RFR: JDK-8272318: Improve performance of HeapDumpAllTest
In-Reply-To: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
References: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
Message-ID: <eHQizUWyQhaI2IGuAXnW9xXcbEzS-c_ZLM9GDiZ2Npc=.ac1ed587-3d02-4042-a285-4cd301abc788@github.com>

On Wed, 11 Aug 2021 13:05:06 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> This change triggers a GC by System.gc() in the test case, so the created heap dump is significantly smaller and the test runs much faster.

Changes look good to me.
Thanks for optimizing!

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

Marked as reviewed by lucy (Reviewer).

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

From hseigel at openjdk.java.net  Wed Aug 18 12:25:46 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 18 Aug 2021 12:25:46 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when path contains colon [v2]
In-Reply-To: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
 <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com>
Message-ID: <8DLm9R5g9w6NFIpQO6L2DkinqvbCYJedTtc7guuhRGw=.1814fadd-53e7-4442-b136-56599fa86cc9@github.com>

On Tue, 17 Aug 2021 17:39:49 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
>> 
>> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test case, comments, and other small changes

Please review this update that modifies the new test case to have a mountinfo entry that contains multiple ":" characters.
Thanks, Harold

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

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

From hseigel at openjdk.java.net  Wed Aug 18 12:25:45 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 18 Aug 2021 12:25:45 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when path contains colon [v3]
In-Reply-To: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
Message-ID: <UrQv8Ol-48u7OD-vGcjfmcBkcfcn1X9pR-v049FFftU=.75cf9931-c190-413b-b657-e1ffcb79a61a@github.com>

> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
> 
> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
> 
> Thanks, Harold

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

  add mountinfo containing colongs to test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5127/files
  - new: https://git.openjdk.java.net/jdk/pull/5127/files/5fa37e97..fcc8c908

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

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

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

From sgehwolf at openjdk.java.net  Wed Aug 18 12:49:26 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 Aug 2021 12:49:26 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when cgroup path contains colon [v2]
In-Reply-To: <JfhKNr_0HtbT2yN3ovBv-TqAnh8wKIQun8KCp4pIn7Y=.f1f94ec7-5196-4508-8eb8-5518b85e01bd@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
 <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com>
 <JfhKNr_0HtbT2yN3ovBv-TqAnh8wKIQun8KCp4pIn7Y=.f1f94ec7-5196-4508-8eb8-5518b85e01bd@github.com>
Message-ID: <SypY25Ge6zQd8vZR_QHJfu2tdsHumkzALMYASd91loE=.4dbdafc7-1b65-4043-aaa0-ba1a8b2c7a10@github.com>

On Tue, 17 Aug 2021 17:46:29 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test case, comments, and other small changes
>
> test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 375:
> 
>> 373:         CgroupInfo memoryInfo = res.getInfos().get("memory");
>> 374:         assertEquals(memoryInfo.getCgroupPath(), "/system.slice/containerd.service/kubepods-burstable-podf65e797d_d5f9_4604_9773_94f4bb9946a0.slice:cri-containerd:86ac6260f9f8a9c1276748250f330ae9c2fcefe5ae809364ad1e45f3edf7e08a");
>> 375:         assertEquals(memoryInfo.getMountRoot(), memoryInfo.getMountRoot());
> 
> What I meant here is to also change the mountinfo entry for `memory` and then use
> 
> assertEquals(memoryInfo.getMountRoot(), memoryInfo.getCgroupPath());
> 
> as that's really what was happening in the wild. mount root - containing colons - would correctly parse, but the cgroup path - containing colons - would not and the assertion would fail (without the change in CgroupSubsystemFactory). Thanks!

@hseigel it still has `assertEquals(memoryInfo.getMountRoot(), memoryInfo.getMountRoot());` - tautology - should be: `assertEquals(memoryInfo.getMountRoot(), memoryInfo.getCgroupPath());`

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

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

From sgehwolf at openjdk.java.net  Wed Aug 18 12:49:25 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 Aug 2021 12:49:25 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when cgroup path contains colon [v3]
In-Reply-To: <UrQv8Ol-48u7OD-vGcjfmcBkcfcn1X9pR-v049FFftU=.75cf9931-c190-413b-b657-e1ffcb79a61a@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
 <UrQv8Ol-48u7OD-vGcjfmcBkcfcn1X9pR-v049FFftU=.75cf9931-c190-413b-b657-e1ffcb79a61a@github.com>
Message-ID: <Z8jTxoJdkQJ69Sti6R1CQVyk8Qjq6jWJl1m7E-6pHTE=.cf986249-a41f-4af8-96bc-2c5a2094b605@github.com>

On Wed, 18 Aug 2021 12:25:45 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
>> 
>> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add mountinfo containing colongs to test

Changes requested by sgehwolf (Reviewer).

test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 207:

> 205:     // `hierarchy-ID:controller-list:cgroup-path`. This cgroup-path intentionally
> 206:     // contains a colon to ensure that the correct path is being extracted by the
> 207:     // login in CgroupSubsystemFactory.

s/login/logic

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

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

From hseigel at openjdk.java.net  Wed Aug 18 13:04:46 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 18 Aug 2021 13:04:46 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when cgroup path contains colon [v4]
In-Reply-To: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
Message-ID: <oXdziUG4nGy7DfFGFq8bQzdYimrK9GG_jNPCh8Ww4Y0=.582a026f-065b-4393-951c-eb6c214c3a05@github.com>

> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
> 
> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
> 
> Thanks, Harold

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

  Fix test typo and error

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5127/files
  - new: https://git.openjdk.java.net/jdk/pull/5127/files/fcc8c908..f339fe14

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

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

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

From hseigel at openjdk.java.net  Wed Aug 18 13:04:47 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 18 Aug 2021 13:04:47 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when cgroup path contains colon [v3]
In-Reply-To: <UrQv8Ol-48u7OD-vGcjfmcBkcfcn1X9pR-v049FFftU=.75cf9931-c190-413b-b657-e1ffcb79a61a@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
 <UrQv8Ol-48u7OD-vGcjfmcBkcfcn1X9pR-v049FFftU=.75cf9931-c190-413b-b657-e1ffcb79a61a@github.com>
Message-ID: <ygFEafAyccHgR69B46U0Xz7LjUbPIn6Rgz3wqkGP7lI=.ba9dd56a-07fe-430e-9836-68e7e8c971a8@github.com>

On Wed, 18 Aug 2021 12:25:45 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
>> 
>> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add mountinfo containing colongs to test

Thanks for finding those issues.  Please review the latest iteration of this fix.
Thanks, Harold

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

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

From turbanoff at gmail.com  Wed Aug 18 11:52:03 2021
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Wed, 18 Aug 2021 14:52:03 +0300
Subject: Buggy exception handling in
 ServerNotifForwarder#removeNotificationListener
Message-ID: <CAF+DQ5c6E3UXYCZjVDwxpfpiAZi6+VZWK20W6e3vTzG9VQs9PQ@mail.gmail.com>

Hello.

During investigation of IDEA inspections I found suspicious code in a method
com.sun.jmx.remote.internal.ServerNotifForwarder#removeNotificationListener
https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java#L167

Exception re = null;
for (int i = 0 ; i < listenerIDs.length ; i++) {
    try {
        removeNotificationListener(name, listenerIDs[i]);
    } catch (Exception e) {
        // Give back the first exception
        //
        if (re != null) {
            re = e;
        }
    }
}
if (re != null) {
    throw re;
}

Variable 're' set initially to 'null', but then in a catch block it
checked to be '!= null'.
As you can see this condition can never be true. And exceptions from
inner calls are not propagated as expected.
It seems that it should check if (re == null) inside the catch block.


Andrey Turbanov

From sgehwolf at openjdk.java.net  Wed Aug 18 14:13:28 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 Aug 2021 14:13:28 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when cgroup path contains colon [v4]
In-Reply-To: <oXdziUG4nGy7DfFGFq8bQzdYimrK9GG_jNPCh8Ww4Y0=.582a026f-065b-4393-951c-eb6c214c3a05@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
 <oXdziUG4nGy7DfFGFq8bQzdYimrK9GG_jNPCh8Ww4Y0=.582a026f-065b-4393-951c-eb6c214c3a05@github.com>
Message-ID: <Fd15w5E4vhHbx35EbhA70yA9-B7MGgO2O9ezFDk08VE=.e74a45e6-2fa5-4c3c-a6b1-ee7a25ab1715@github.com>

On Wed, 18 Aug 2021 13:04:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
>> 
>> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test typo and error

Looks good. Thank you!

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

Marked as reviewed by sgehwolf (Reviewer).

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

From hseigel at openjdk.java.net  Wed Aug 18 14:28:27 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 18 Aug 2021 14:28:27 GMT
Subject: RFR: 8272124: Cgroup v1 initialization causes
 NullPointerException when cgroup path contains colon [v4]
In-Reply-To: <oXdziUG4nGy7DfFGFq8bQzdYimrK9GG_jNPCh8Ww4Y0=.582a026f-065b-4393-951c-eb6c214c3a05@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
 <oXdziUG4nGy7DfFGFq8bQzdYimrK9GG_jNPCh8Ww4Y0=.582a026f-065b-4393-951c-eb6c214c3a05@github.com>
Message-ID: <xmKuBFEpRcU9zraSJEmdSorV_XhJo1UhN_e43JL_B5I=.29e2b9ba-9c60-44af-8098-13684816d665@github.com>

On Wed, 18 Aug 2021 13:04:46 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
>> 
>> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test typo and error

Thanks Severin and Misha for your reviews and improvements for this fix!

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

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

From hseigel at openjdk.java.net  Wed Aug 18 14:28:28 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 18 Aug 2021 14:28:28 GMT
Subject: Integrated: 8272124: Cgroup v1 initialization causes
 NullPointerException when cgroup path contains colon
In-Reply-To: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
References: <fcoCLJYp3tZwWRv4Fh-dLpO6MCD_pYHM5iUzy_A6Hxg=.0e0a9933-d618-4aab-8b7b-f526473c064a@github.com>
Message-ID: <HAgjoaX4XDitQQU3nphajgy0eGlvpwy5syjeOUBsBJ4=.7201c3d6-89aa-4663-9020-48e5192deceb@github.com>

On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8272124.  The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s.  For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path of "/user.sli:ce" instead of "/user.sli".
> 
> The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 and Linux aarch64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 4d6593ce
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4d6593ce0243457e7431a5990957a8f880e0a3fb
Stats:     57 lines in 2 files changed: 54 ins; 0 del; 3 mod

8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon

Reviewed-by: mseledtsov, sgehwolf

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

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

From sspitsyn at openjdk.java.net  Wed Aug 18 17:54:30 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 18 Aug 2021 17:54:30 GMT
Subject: RFR: JDK-8272318: Improve performance of HeapDumpAllTest
In-Reply-To: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
References: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
Message-ID: <3plknACpu3AerBPF8SOEh7V_RH8obcHn7I4xclck2sY=.8d3d2872-cef6-439e-afd5-bbe2b308f775@github.com>

On Wed, 11 Aug 2021 13:05:06 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> This change triggers a GC by System.gc() in the test case, so the created heap dump is significantly smaller and the test runs much faster.

Ralf,
The fix looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From rschmelter at openjdk.java.net  Wed Aug 18 18:33:27 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Wed, 18 Aug 2021 18:33:27 GMT
Subject: Integrated: JDK-8272318: Improve performance of HeapDumpAllTest
In-Reply-To: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
References: <YjjNONCLpTIpomgPCVexx2XcYyaFBehIjmERZ6uYWXU=.f734f094-e456-44ba-affe-1134550f2d52@github.com>
Message-ID: <W8WxfBWrYbzGFtGI2g76ByN3jPWAIpM4eIaCUPsXiXM=.1439ffe3-2ab6-48ba-8109-5a94d1bfa434@github.com>

On Wed, 11 Aug 2021 13:05:06 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> This change triggers a GC by System.gc() in the test case, so the created heap dump is significantly smaller and the test runs much faster.

This pull request has now been integrated.

Changeset: 73da66ff
Author:    Ralf Schmelter <rschmelter at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/73da66ffb707abf6dc38368a12e337d52597de25
Stats:     12 lines in 1 file changed: 12 ins; 0 del; 0 mod

8272318: Improve performance of HeapDumpAllTest

Reviewed-by: lucy, sspitsyn

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

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

From hirt at openjdk.java.net  Wed Aug 18 19:19:33 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Wed, 18 Aug 2021 19:19:33 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
Message-ID: <DGifHTg7nIn5v9jLtDHTWvj1SxNfv3DxVz5Y4FaRCxY=.7f279e15-526c-469b-8872-4504fde721bd@github.com>

On Mon, 19 Jul 2021 09:25:59 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Remove FrameParser and the required allocation
>    
>    The need for the allocation would be it non async-safe. However,
>    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix-8178287
>  - Fix comments
>  - 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.

Ok. Do you know who should be the primary reviewer? Rickard B?ckman? Nils Eliasson?

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

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

From kevin.walls at oracle.com  Thu Aug 19 09:58:09 2021
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 19 Aug 2021 09:58:09 +0000
Subject: Buggy exception handling in
 ServerNotifForwarder#removeNotificationListener
In-Reply-To: <CAF+DQ5c6E3UXYCZjVDwxpfpiAZi6+VZWK20W6e3vTzG9VQs9PQ@mail.gmail.com>
References: <CAF+DQ5c6E3UXYCZjVDwxpfpiAZi6+VZWK20W6e3vTzG9VQs9PQ@mail.gmail.com>
Message-ID: <MN2PR10MB32782E50A40C6C6F3DA6925097C09@MN2PR10MB3278.namprd10.prod.outlook.com>

Hi -

Yes, looks like we intend to keep the first Exception thrown, and throw that after the loop, but not to stop the loop attempting all removeNotificationListener() calls.  So it would make sense to assign the caught Exception to re, only if re IS null. 

So currently this method never throws an Exception.  Let me know if you've tested the change or plan to log a bug.  We should proceed with care in case this change causes any surprises, as it  has been like this forever.

Thanks
Kevin


-----Original Message-----
From: serviceability-dev <serviceability-dev-retn at openjdk.java.net> On Behalf Of Andrey Turbanov
Sent: 18 August 2021 12:52
To: serviceability-dev at openjdk.java.net
Subject: Buggy exception handling in ServerNotifForwarder#removeNotificationListener

Hello.

During investigation of IDEA inspections I found suspicious code in a method com.sun.jmx.remote.internal.ServerNotifForwarder#removeNotificationListener
https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java#L167

Exception re = null;
for (int i = 0 ; i < listenerIDs.length ; i++) {
    try {
        removeNotificationListener(name, listenerIDs[i]);
    } catch (Exception e) {
        // Give back the first exception
        //
        if (re != null) {
            re = e;
        }
    }
}
if (re != null) {
    throw re;
}

Variable 're' set initially to 'null', but then in a catch block it checked to be '!= null'.
As you can see this condition can never be true. And exceptions from inner calls are not propagated as expected.
It seems that it should check if (re == null) inside the catch block.


Andrey Turbanov

From github.com+10835776+stsypanov at openjdk.java.net  Thu Aug 19 11:18:26 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: Thu, 19 Aug 2021 11:18:26 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v4]
In-Reply-To: <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>
Message-ID: <2Y5ulI-nScJrXU-odPSJt0mDFuXaE9cbqwnc0U-tqqI=.c714ad19-2cc1-421d-bf57-12767cd60d25@github.com>

On Thu, 1 Jul 2021 12:19:53 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 incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Let's wait, bridgekeeper.

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

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

From kevin.walls at oracle.com  Fri Aug 20 14:47:32 2021
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 20 Aug 2021 14:47:32 +0000
Subject: Buggy exception handling in
 ServerNotifForwarder#removeNotificationListener
In-Reply-To: <MN2PR10MB32782E50A40C6C6F3DA6925097C09@MN2PR10MB3278.namprd10.prod.outlook.com>
References: <CAF+DQ5c6E3UXYCZjVDwxpfpiAZi6+VZWK20W6e3vTzG9VQs9PQ@mail.gmail.com>
 <MN2PR10MB32782E50A40C6C6F3DA6925097C09@MN2PR10MB3278.namprd10.prod.outlook.com>
Message-ID: <MN2PR10MB3278BBEDD4A5FE3943D23D2F97C19@MN2PR10MB3278.namprd10.prod.outlook.com>

I logged this: https://bugs.openjdk.java.net/browse/JDK-8272780


-----Original Message-----
From: Kevin Walls 
Sent: 19 August 2021 10:58
To: Andrey Turbanov <turbanoff at gmail.com>; serviceability-dev at openjdk.java.net
Subject: RE: Buggy exception handling in ServerNotifForwarder#removeNotificationListener

Hi -

Yes, looks like we intend to keep the first Exception thrown, and throw that after the loop, but not to stop the loop attempting all removeNotificationListener() calls.  So it would make sense to assign the caught Exception to re, only if re IS null. 

So currently this method never throws an Exception.  Let me know if you've tested the change or plan to log a bug.  We should proceed with care in case this change causes any surprises, as it  has been like this forever.

Thanks
Kevin


-----Original Message-----
From: serviceability-dev <serviceability-dev-retn at openjdk.java.net> On Behalf Of Andrey Turbanov
Sent: 18 August 2021 12:52
To: serviceability-dev at openjdk.java.net
Subject: Buggy exception handling in ServerNotifForwarder#removeNotificationListener

Hello.

During investigation of IDEA inspections I found suspicious code in a method com.sun.jmx.remote.internal.ServerNotifForwarder#removeNotificationListener
https://github.com/openjdk/jdk/blob/master/src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java#L167

Exception re = null;
for (int i = 0 ; i < listenerIDs.length ; i++) {
    try {
        removeNotificationListener(name, listenerIDs[i]);
    } catch (Exception e) {
        // Give back the first exception
        //
        if (re != null) {
            re = e;
        }
    }
}
if (re != null) {
    throw re;
}

Variable 're' set initially to 'null', but then in a catch block it checked to be '!= null'.
As you can see this condition can never be true. And exceptions from inner calls are not propagated as expected.
It seems that it should check if (re == null) inside the catch block.


Andrey Turbanov

From ludovic at datadoghq.com  Fri Aug 20 06:49:30 2021
From: ludovic at datadoghq.com (Ludovic Henry)
Date: Fri, 20 Aug 2021 08:49:30 +0200
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <DGifHTg7nIn5v9jLtDHTWvj1SxNfv3DxVz5Y4FaRCxY=.7f279e15-526c-469b-8872-4504fde721bd@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <DGifHTg7nIn5v9jLtDHTWvj1SxNfv3DxVz5Y4FaRCxY=.7f279e15-526c-469b-8872-4504fde721bd@github.com>
Message-ID: <CAFR8T3tSR-yA901Tskwt-OrZaeuupBfdUQ+r2y4gmsde1Sj=3w@mail.gmail.com>

Hello,

As it's been quite a while already, I wanted to nudge this RFR forward. Who
would be best qualified to review this PR?

Thank you!
Ludovic

On Wed, Aug 18, 2021 at 9:21 PM Marcus Hirt <hirt at openjdk.java.net> wrote:

> On Mon, 19 Jul 2021 09:25:59 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 with a new target base due to
> a merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains eight additional
> commits since the last revision:
> >
> >  - Remove FrameParser and the required allocation
> >
> >    The need for the allocation would be it non async-safe. However,
> >    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
> >  - Merge branch 'master' of https://github.com/openjdk/jdk into
> fix-8178287
> >  - Fix comments
> >  - 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.
>
> Ok. Do you know who should be the primary reviewer? Rickard B?ckman? Nils
> Eliasson?
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4436
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210820/58e602c0/attachment-0001.htm>

From ludovic at datadoghq.com  Fri Aug 20 12:59:43 2021
From: ludovic at datadoghq.com (Ludovic Henry)
Date: Fri, 20 Aug 2021 14:59:43 +0200
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <CAFR8T3tSR-yA901Tskwt-OrZaeuupBfdUQ+r2y4gmsde1Sj=3w@mail.gmail.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <DGifHTg7nIn5v9jLtDHTWvj1SxNfv3DxVz5Y4FaRCxY=.7f279e15-526c-469b-8872-4504fde721bd@github.com>
 <CAFR8T3tSR-yA901Tskwt-OrZaeuupBfdUQ+r2y4gmsde1Sj=3w@mail.gmail.com>
Message-ID: <CAFR8T3t9EWN9sELWEymptaR5-NooGeFVRpO9oQdjYg3V__rJ2Q@mail.gmail.com>

[Sending again now with the email address properly registered to the
mailing lists]

Hello,

As it's been quite a while already, I wanted to nudge this RFR forward. Who
would be best qualified to review this PR?

Thank you!
Ludovic

On Fri, Aug 20, 2021 at 8:49 AM Ludovic Henry <ludovic at datadoghq.com> wrote:

> Hello,
>
> As it's been quite a while already, I wanted to nudge this RFR forward.
> Who would be best qualified to review this PR?
>
> Thank you!
> Ludovic
>
> On Wed, Aug 18, 2021 at 9:21 PM Marcus Hirt <hirt at openjdk.java.net> wrote:
>
>> On Mon, 19 Jul 2021 09:25:59 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 with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains eight
>> additional commits since the last revision:
>> >
>> >  - Remove FrameParser and the required allocation
>> >
>> >    The need for the allocation would be it non async-safe. However,
>> >    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
>> >  - Merge branch 'master' of https://github.com/openjdk/jdk into
>> fix-8178287
>> >  - Fix comments
>> >  - 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.
>>
>> Ok. Do you know who should be the primary reviewer? Rickard B?ckman? Nils
>> Eliasson?
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4436
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210820/0f42f19a/attachment-0001.htm>

From coleenp at openjdk.java.net  Fri Aug 20 16:48:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 20 Aug 2021 16:48:41 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be safepoint_check_never
Message-ID: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>

I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
Tested with tier1-3.  Tier 4-6 testing in progress.

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

Commit messages:
 - 8272788: Nonleaf ranked locks should not be safepoint_check_neve

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

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

From jakob at jcornell.net  Sat Aug 21 21:46:04 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Sat, 21 Aug 2021 16:46:04 -0500
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
Message-ID: <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>

Well I let this thread go quiet for a few weeks, but I did want to follow up on the new input we got in August.  It sounds like multiple people are concerned about the cost of reviewing a change to JDB that implements GDB's empty command handling, but a patch that adds Jline line editing and history would be worth considering.

I think I'll start looking into that change, and if I'm able to prepare a patch we can have some people take a look.  If it's too much to merge then I suppose I could keep it in a fork and benefit from the work myself at least.  In the meantime, perhaps JBS 8271356 should be closed, since the community isn't interested in the change.  If so, somebody with access will need to do that.

Jakob

From serb at openjdk.java.net  Sun Aug 22 06:28:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 22 Aug 2021 06:28:18 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
Message-ID: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>

This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
See https://github.com/openjdk/jdk/pull/5063 and https://github.com/openjdk/jdk/pull/4951

In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");

This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
absolutePath.getBytes(StandardCharsets.UTF_8);

The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.

This change includes:
 * demo/utils
 * jdk.xx packages
 * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests. Also checked for "aliases" usage.

Some performance discussion: https://github.com/openjdk/jdk/pull/5063

Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the "java.naming"(the change there is not straightforward, will do it later).

Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

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

Commit messages:
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - Rollback TextRenderTests, should be compatible with jdk1.4
 - Cleanup the UnsupportedEncodingException
 - aliases for ISO_8859_1
 - Update imageio
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/5210/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5210&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272805
  Stats: 333 lines in 48 files changed: 91 ins; 123 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From weijun at openjdk.java.net  Sun Aug 22 13:22:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sun, 22 Aug 2021 13:22:38 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <0eO4SD_N9lrP5k5bhEejUKXeMauRC8zuc_slUJSrc5c=.c886ae36-5039-450f-9293-5f9910ce432d@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

The security related change looks fine to me.

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

Marked as reviewed by weijun (Reviewer).

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

From alanb at openjdk.java.net  Sun Aug 22 15:12:26 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Aug 2021 15:12:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342:

> 340: 
> 341:         try {
> 342:             for (String line : Files.readAllLines(statusPath, UTF_8)) {

The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Aug 22 18:34:26 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 22 Aug 2021 18:34:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.
![???????????](https://user-images.githubusercontent.com/741251/130366051-ef093bf1-d7d9-4ad1-91e7-5df5af8678af.png)

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

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

From serb at openjdk.java.net  Sun Aug 22 23:02:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 22 Aug 2021 23:02:06 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

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

 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - Rollback TextRenderTests, should be compatible with jdk1.4
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/37357100...e7127644

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/2d9c80b8..e7127644

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

  Stats: 3598 lines in 210 files changed: 2055 ins; 1115 del; 428 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From naoto at openjdk.java.net  Mon Aug 23 00:26:31 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 Aug 2021 00:26:31 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <YDjqMHQFk2IHLNrmd3MahBp6vvL4D3x4ncTa3PvvQWY=.39eace25-57d6-4981-a1ad-31901c061b25@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c262b06f...e7127644

Looks good.

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

Marked as reviewed by naoto (Reviewer).

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

From lzang at openjdk.java.net  Mon Aug 23 07:30:37 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 23 Aug 2021 07:30:37 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v4]
In-Reply-To: <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
 <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com>
Message-ID: <V0Th_ipCMMBKNReSw9B4438X-1q9pkyXOmKIf9P483U=.55b54340-5794-4ecf-a0b1-6b8055f957f9@github.com>

On Fri, 13 Aug 2021 10:46:02 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
>> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into hprof
>  - fix write size issue
>  - Merge branch 'master' into hprof
>  - 8269685: Optimize HeapHprofBinWriter implementation

Added the tests I have conducted:
    Passed test tier1 (tier2 and tier3 not executed)
    Tested to dump netbeans with heap size at ~500MB, ~700MB and 1GB, and tested w/o -gz option from 1-9. all passed.
    A workload that generate different object to fill heap, I have tested with heap usage from 1GB to 4GB with different gz options. All passed.

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

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

From dfuchs at openjdk.java.net  Mon Aug 23 09:36:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 23 Aug 2021 09:36:40 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <iwz79djzNlUzGYlpBbrLcycsmNcDy3bZF7qc4vozQAI=.e4aa79aa-f9cd-413a-bb5a-dc95023dc410@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/db47f6e1...e7127644

Changes to http server look good to me.

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

Marked as reviewed by dfuchs (Reviewer).

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

From jbachorik at openjdk.java.net  Mon Aug 23 10:31:36 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Mon, 23 Aug 2021 10:31:36 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
Message-ID: <BWanYitzfyqkvmVIKndceXJDtbA5lBDxKA94gsMt9hY=.4d5d7dc0-e763-499b-9a3c-8ac75f4415e4@github.com>

On Mon, 19 Jul 2021 09:25:59 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Remove FrameParser and the required allocation
>    
>    The need for the allocation would be it non async-safe. However,
>    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix-8178287
>  - Fix comments
>  - 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.

@dcubed-ojdk , @dholmes-ora would you be willing/able to take a look at this change, pretty please?

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

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

From dholmes at openjdk.java.net  Mon Aug 23 10:56:24 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 23 Aug 2021 10:56:24 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never
In-Reply-To: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
Message-ID: <b_IR_9FEkLjUSpmh7f0_pdZnRPGdLUa8p52EsZhcW2w=.d5abd930-dc03-485a-927e-a62161ee3eb2@github.com>

On Fri, 20 Aug 2021 16:41:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
> Tested with tier1-3.  Tier 4-6 testing in progress.

Hi Coleen,

Sorry I'm struggling to interpret exactly what these changes mean.  You're redefining the ranking for some locks so that you can then declare that nonleaf locks should not be safepoint-check-never. But in changing those rankings you are also potentially reducing the set of lock nestings that are permitted - so for example a lock that was Barrier and is now leaf+1 can no longer be locked before locking a leaf+2, 3...9. That might be valid but it is not at all obvious how to verify that - testing alone will only cover the common code paths, not necessarily those rarely taken e.g for debugging, logging, exceptional conditions, event processing, non-default flag values ...

It is not at all clear to me that the ranking strategy and the safepoint-checking strategy align in the way you are implying.

Could you elaborate on how you expect this to end up looking please.

Thanks,
David

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

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

From dholmes at openjdk.java.net  Mon Aug 23 11:00:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 23 Aug 2021 11:00:36 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <BWanYitzfyqkvmVIKndceXJDtbA5lBDxKA94gsMt9hY=.4d5d7dc0-e763-499b-9a3c-8ac75f4415e4@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <BWanYitzfyqkvmVIKndceXJDtbA5lBDxKA94gsMt9hY=.4d5d7dc0-e763-499b-9a3c-8ac75f4415e4@github.com>
Message-ID: <APS6H9AlsHSVKx62JWEAfdZjjbSJ58Wor7GHYPyhe74=.0c65e5fe-848e-42e9-b61b-890f81a5e1c2@github.com>

On Mon, 23 Aug 2021 10:28:36 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Remove FrameParser and the required allocation
>>    
>>    The need for the allocation would be it non async-safe. However,
>>    AsyncGetCallTrace is async-safe and thus can't allow for allocations.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix-8178287
>>  - Fix comments
>>  - 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.
>
> @dcubed-ojdk , @dholmes-ora would you be willing/able to take a look at this change, pretty please?

Sorry @jbachorik  but frames and code-blobs are not an area I know.

David

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

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

From coleenp at openjdk.java.net  Mon Aug 23 12:26:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 12:26:30 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never
In-Reply-To: <b_IR_9FEkLjUSpmh7f0_pdZnRPGdLUa8p52EsZhcW2w=.d5abd930-dc03-485a-927e-a62161ee3eb2@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
 <b_IR_9FEkLjUSpmh7f0_pdZnRPGdLUa8p52EsZhcW2w=.d5abd930-dc03-485a-927e-a62161ee3eb2@github.com>
Message-ID: <K4TB4kb3ruROU-Ntev5JKMP3FKfhfj_5NJgiMMeNHyM=.2c58fce6-4f1a-473c-aba8-d5bb348d09a7@github.com>

On Mon, 23 Aug 2021 10:53:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
>> Tested with tier1-3.  Tier 4-6 testing in progress.
>
> Hi Coleen,
> 
> Sorry I'm struggling to interpret exactly what these changes mean.  You're redefining the ranking for some locks so that you can then declare that nonleaf locks should not be safepoint-check-never. But in changing those rankings you are also potentially reducing the set of lock nestings that are permitted - so for example a lock that was Barrier and is now leaf+1 can no longer be locked before locking a leaf+2, 3...9. That might be valid but it is not at all obvious how to verify that - testing alone will only cover the common code paths, not necessarily those rarely taken e.g for debugging, logging, exceptional conditions, event processing, non-default flag values ...
> 
> It is not at all clear to me that the ranking strategy and the safepoint-checking strategy align in the way you are implying.
> 
> Could you elaborate on how you expect this to end up looking please.
> 
> Thanks,
> David

@dholmes-ora I put some comments in the main bug (this is a subtask) about what I'm trying to do.  Please comment there and make suggestions that you believe in. If you'd like to discuss, we can do that also.  These subtasks are cleanups that break up the larger problem into smaller pieces. I could share a patch of the whole cleanup with you but I don't think you want that in a pull request!

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

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

From coleenp at openjdk.java.net  Mon Aug 23 12:36:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 12:36:30 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never
In-Reply-To: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
Message-ID: <_yvAqBNWPO9gt0XX0lFRm4PDetoZDQ0YhrUFvzOPnx4=.6f1c8917-2169-4494-93f4-a87af5a2e31e@github.com>

On Fri, 20 Aug 2021 16:41:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
> Tested with tier1-3.  Tier 4-6 testing in progress.

src/hotspot/share/prims/jvmtiTagMap.cpp line 75:

> 73: JvmtiTagMap::JvmtiTagMap(JvmtiEnv* env) :
> 74:   _env(env),
> 75:   _lock(Mutex::leaf, "JvmtiTagMap_lock", Mutex::_allow_vm_block_flag,

David, note this lock.  Since it allows the VM to block, then making it non-leaf is meaningless, since allowing the VM to block means that once you take this lock, you may NOT take another lock that blocks for safepoint.

src/hotspot/share/runtime/mutexLocker.cpp line 289:

> 287:   def(JfieldIdCreation_lock        , PaddedMutex  , nonleaf+1,   true,  _safepoint_check_always); // jfieldID, Used in VM_Operation
> 288: 
> 289:   def(CompiledIC_lock              , PaddedMutex  , leaf+2,      false, _safepoint_check_never);      // locks VtableStubs_lock, InlineCacheBuffer_lock

In my testing, the CompiledIC_lock only takes other locks that never safepoint check, so this should be at the top of the hierarchy of locks that do that.  OR it can safepoint_check_always.  That might make sense, but I'd rather not change the safepoint checking properties with this change.

src/hotspot/share/runtime/mutexLocker.cpp line 318:

> 316:   def(JfrMsg_lock                  , PaddedMonitor, leaf,        true,  _safepoint_check_always);
> 317:   def(JfrBuffer_lock               , PaddedMutex  , leaf,        true,  _safepoint_check_never);
> 318:   def(JfrStream_lock               , PaddedMutex  , leaf+1,      false, _safepoint_check_never);

This lock is actually unused.

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

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

From coleenp at openjdk.java.net  Mon Aug 23 13:03:10 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 13:03:10 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never [v2]
In-Reply-To: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
Message-ID: <c9XP_Cq6DAIS35iekHb0Sm6VRJDUKcjamXNeoiHvQsw=.68afb9c7-c4a8-44cc-af2c-1ca118b3b56a@github.com>

> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
> Tested with tier1-3.  Tier 4-6 testing in progress.

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

  Remove JfrSream_lock and rerun JFR tests.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5203/files
  - new: https://git.openjdk.java.net/jdk/pull/5203/files/fb80fe6c..7aba7c3c

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

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

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

From chris.plummer at oracle.com  Mon Aug 23 17:36:56 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Mon, 23 Aug 2021 10:36:56 -0700
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
Message-ID: <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>

My thoughts were actually that integrating jline would result in too 
much disruption to the source, and also require a fair amount of 
documentation update, but I don't know enough about what would be 
involved with integrating jline to say for sure. It seems that just 
adding empty command support to the few commands where it would be 
useful would be much simpler, but you do also need to add a flag to 
enable it (I think you would need this for jline integration also).

Chris

On 8/21/21 2:46 PM, Jakob Cornell wrote:
> Well I let this thread go quiet for a few weeks, but I did want to 
> follow up on the new input we got in August.? It sounds like multiple 
> people are concerned about the cost of reviewing a change to JDB that 
> implements GDB's empty command handling, but a patch that adds Jline 
> line editing and history would be worth considering.
>
> I think I'll start looking into that change, and if I'm able to 
> prepare a patch we can have some people take a look.? If it's too much 
> to merge then I suppose I could keep it in a fork and benefit from the 
> work myself at least.? In the meantime, perhaps JBS 8271356 should be 
> closed, since the community isn't interested in the change.? If so, 
> somebody with access will need to do that.
>
> Jakob



From jakob at jcornell.net  Mon Aug 23 18:41:28 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Mon, 23 Aug 2021 13:41:28 -0500
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
 <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
Message-ID: <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>

Hi Chris,

Yeah, I think I agree with you, but I seem to recall a few people having the opposite opinion, so I've been a bit confused about how to proceed.  However, given that we'll be keeping the empty command handling off by default I don't think it's possible for the change to disrupt anything.  Unless anybody brings up any more concerns are we ready to start a CSR request for the change?

Also, with regard to the feature flag, somebody mentioned implementing that as a new command pair (e.g. `repeat'/`norepeat') so that the default behavior can be controlled in a jdbrc file (and manually during a session), but there was never much discussion of this aspect.  So I'm not sure whether we're looking at a pair of new commands or a command line flag or both, although both sounds most convenient to me.  Can you advise on that?  Once it's settled I can work on extending my existing patch.

Jakob

From chris.plummer at oracle.com  Mon Aug 23 19:29:01 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Mon, 23 Aug 2021 12:29:01 -0700
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
 <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
 <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>
Message-ID: <ee3fdde7-a5e6-e116-7a37-c4f7721f1db0@oracle.com>

It looks like we don't have anything similar in place already. I was 
looking for an echo or verbose command to compare to, hoping it would 
take an on/off parameter, but they don't exist. The following pairs are 
the best examples I see:

stop/clear
enablegc/disablegc
watch/unwatch
trace/untrace
monitor/unmonitor

We also have "dbgtrace [flag]".

repeat/unrepeat doesn't quite work. repeat/nopeat is probably fine, but 
maybe also "repeat on/off". You can also consider a command line option. 
The only similar type option I currently see is "-dbgtrace [flags]".? So 
you could use "-repeat". Doing both a command and a command line option 
is not necessarily required. Either one gets the job done, and you can 
argue that if set on the command line, there would be no reason for the 
user to turn it off once in jdb. On the other hand, if you forgot to set 
it on the command line, you need to abort your session and relaunch to 
get it enabled, so if only doing one, probably a command would be better.

Chris

On 8/23/21 11:41 AM, Jakob Cornell wrote:
> Hi Chris,
>
> Yeah, I think I agree with you, but I seem to recall a few people 
> having the opposite opinion, so I've been a bit confused about how to 
> proceed.? However, given that we'll be keeping the empty command 
> handling off by default I don't think it's possible for the change to 
> disrupt anything.? Unless anybody brings up any more concerns are we 
> ready to start a CSR request for the change?
>
> Also, with regard to the feature flag, somebody mentioned implementing 
> that as a new command pair (e.g. `repeat'/`norepeat') so that the 
> default behavior can be controlled in a jdbrc file (and manually 
> during a session), but there was never much discussion of this 
> aspect.? So I'm not sure whether we're looking at a pair of new 
> commands or a command line flag or both, although both sounds most 
> convenient to me.? Can you advise on that?? Once it's settled I can 
> work on extending my existing patch.
>
> Jakob



From serb at openjdk.java.net  Mon Aug 23 19:34:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 19:34:38 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <OvTvFnSa61RYUr_VO3fRcnjTkxDwYX0VdqwiiGnveBs=.78ea3741-9e90-447b-909c-be7fedf40f8f@github.com>
Message-ID: <aKpPQPgoXRthV1BM7HdtVLagya1bBbQnwQNj68kW_q8=.12c01c5d-b0d5-42a7-b7ce-6a03b5d05b59@github.com>

On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/465eb90c...e7127644
>
> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 342:
> 
>> 340: 
>> 341:         try {
>> 342:             for (String line : Files.readAllLines(statusPath, UTF_8)) {
> 
> The 1-arg readAllLines is specified to use UTF-8 so you can drop the second parameter here if you want.

Thank you for the suggestion, I have fixed this and a few other places as well.

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

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

From serb at openjdk.java.net  Mon Aug 23 19:34:34 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 23 Aug 2021 19:34:34 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets
In-Reply-To: <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <Ng1z8PAjPNJ8IC8xxYp_Px4NlXJ8DWqs6e12eGb5wP0=.09ad1ed7-2788-48cb-a067-76955b5e912c@github.com>
Message-ID: <KyQxSd0IYEEoEC0acPE16G5CIvwqPTVGVZOP1M9Me8o=.f1d93383-8174-4731-8e16-ef72b415b34a@github.com>

On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I think it's worth to update _static_ initializer in `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.

Updated as suggested.

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

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

From coleenp at openjdk.java.net  Mon Aug 23 20:09:31 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 20:09:31 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never [v2]
In-Reply-To: <_yvAqBNWPO9gt0XX0lFRm4PDetoZDQ0YhrUFvzOPnx4=.6f1c8917-2169-4494-93f4-a87af5a2e31e@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
 <_yvAqBNWPO9gt0XX0lFRm4PDetoZDQ0YhrUFvzOPnx4=.6f1c8917-2169-4494-93f4-a87af5a2e31e@github.com>
Message-ID: <kcXG6zNE3-kYGxJAi3Tg-_8cwbfDGDEUlASZj9tSgtM=.b04d1f1e-8664-4cde-8c81-ac5087fd3b2e@github.com>

On Mon, 23 Aug 2021 12:27:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove JfrSream_lock and rerun JFR tests.
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 75:
> 
>> 73: JvmtiTagMap::JvmtiTagMap(JvmtiEnv* env) :
>> 74:   _env(env),
>> 75:   _lock(Mutex::leaf, "JvmtiTagMap_lock", Mutex::_allow_vm_block_flag,
> 
> David, note this lock.  Since it allows the VM to block, then making it non-leaf is meaningless, since allowing the VM to block means that once you take this lock, you may NOT take another lock that blocks for safepoint.

Let me add more detail here.  This code only takes out the oopstorage ranked lock while this lock is held. I don't know why I made it nonleaf+1. Our testing covers this code really well with the jvmti and jdi tests, which are run in the tiered testing.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Aug 23 20:54:36 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 23 Aug 2021 20:54:36 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <N67-urPlw_TC9qhch8RkndEzRrP3vUMmVDk-e_nEt-g=.b05fa6c6-04b4-449b-8f93-b00ce5f3e81e@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/aaa7beaf...e7127644

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

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

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

From jakob at jcornell.net  Mon Aug 23 21:01:07 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Mon, 23 Aug 2021 16:01:07 -0500
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <ee3fdde7-a5e6-e116-7a37-c4f7721f1db0@oracle.com>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
 <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
 <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>
 <ee3fdde7-a5e6-e116-7a37-c4f7721f1db0@oracle.com>
Message-ID: <e8ea512c-08fb-b455-1961-f1c31ebd93f5@jcornell.net>

Yeah, `repeat on/off' seems a bit better to me too.  With the command (and the option to use it in a jdbrc) I don't think a command-line option would provide much use, so I'll propose implementing the command alone.

Does this wrap up the pre-CSR discussion?  If so, would you like to see a PR before starting the CSR process or can those two happen concurrently?

Jakob

From chris.plummer at oracle.com  Mon Aug 23 21:53:08 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Mon, 23 Aug 2021 14:53:08 -0700
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <e8ea512c-08fb-b455-1961-f1c31ebd93f5@jcornell.net>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
 <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
 <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>
 <ee3fdde7-a5e6-e116-7a37-c4f7721f1db0@oracle.com>
 <e8ea512c-08fb-b455-1961-f1c31ebd93f5@jcornell.net>
Message-ID: <a4cea881-eacd-512a-c3f2-366f0557b8d8@oracle.com>

On 8/23/21 2:01 PM, Jakob Cornell wrote:
> Yeah, `repeat on/off' seems a bit better to me too.? With the command 
> (and the option to use it in a jdbrc) I don't think a command-line 
> option would provide much use, so I'll propose implementing the 
> command alone.
>
> Does this wrap up the pre-CSR discussion?? If so, would you like to 
> see a PR before starting the CSR process or can those two happen 
> concurrently?
>
> Jakob
There's no requirement to have the CSR in place before the PR goes out. 
There are advantages to either order. If you wrap up CSR details first, 
then you can work towards an implementation that you know won't run into 
later CSR roadblocks, but then the PR implementation might run into 
objections that require interface changes to resolve (and therefore CSR 
changes). On the other hand, getting the PR out first can lead to 
discussions that will then shape the CSR (and possibly adjustments to 
the PR also).

Chris


From jakob at jcornell.net  Mon Aug 23 22:46:05 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Mon, 23 Aug 2021 17:46:05 -0500
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <a4cea881-eacd-512a-c3f2-366f0557b8d8@oracle.com>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
 <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
 <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>
 <ee3fdde7-a5e6-e116-7a37-c4f7721f1db0@oracle.com>
 <e8ea512c-08fb-b455-1961-f1c31ebd93f5@jcornell.net>
 <a4cea881-eacd-512a-c3f2-366f0557b8d8@oracle.com>
Message-ID: <e13e274e-dcd7-b54f-d634-70401ba5d857@jcornell.net>

Okay thanks, that's useful advice.  I don't think I'll mind reworking my changes after the fact, so why don't I post an update here once the PR is done and we'll open a CSR request then.

Jakob

From sspitsyn at openjdk.java.net  Mon Aug 23 23:29:34 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 23 Aug 2021 23:29:34 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v4]
In-Reply-To: <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
 <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com>
Message-ID: <Ic37zSxgXZhFJIXpmO4BdGOtxXI2ZRrHd9qedz69VI4=.5ea478a4-941a-4bf0-bee6-b78cadc85283@github.com>

On Fri, 13 Aug 2021 10:46:02 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
>> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into hprof
>  - fix write size issue
>  - Merge branch 'master' into hprof
>  - 8269685: Optimize HeapHprofBinWriter implementation

Hi Lin,

You did not answer my question about empty methods in the AbstractHeapGraphWriter.java.
It seems the following methods have to be abstract instead of being empty:

+    protected int calculateGlobalJNIHandlesDumpRecordSize() {
+        return 0;
+    }
+
+    protected int calculateJavaThreadsDumpRecordSize() {
+        return 0;
+    }
+
+    protected int calculateOopDumpRecordSize(Oop oop) throws IOException {
+        return 0;
+    }
. . . 
    // object field writers
protected void writeReferenceField(Oop oop, OopField field)
     throws IOException {
}
protected void writeByteField(Oop oop, ByteField field)
    throws IOException {
}
protected void writeCharField(Oop oop, CharField field)
    throws IOException {
}
protected void writeBooleanField(Oop oop, BooleanField field)
    throws IOException {
}
protected void writeShortField(Oop oop, ShortField field)
    throws IOException {
}
protected void writeIntField(Oop oop, IntField field)
    throws IOException {
}
protected void writeLongField(Oop oop, LongField field)
    throws IOException {
}
protected void writeFloatField(Oop oop, FloatField field)
    throws IOException {
}
protected void writeDoubleField(Oop oop, DoubleField field)
    throws IOException {
}
protected void writeObjectFooter(Oop oop) throws IOException {
}
protected void writeHeapFooter() throws IOException {
}
protected void writeHeapRecordPrologue() throws IOException {
} 
+    protected void writeHeapRecordPrologue(int size) throws IOException {
+    }
+
protected void writeHeapRecordEpilogue() throws IOException {
}

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

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

From hirt at openjdk.java.net  Mon Aug 23 23:40:27 2021
From: hirt at openjdk.java.net (Marcus Hirt)
Date: Mon, 23 Aug 2021 23:40:27 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <APS6H9AlsHSVKx62JWEAfdZjjbSJ58Wor7GHYPyhe74=.0c65e5fe-848e-42e9-b61b-890f81a5e1c2@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <BWanYitzfyqkvmVIKndceXJDtbA5lBDxKA94gsMt9hY=.4d5d7dc0-e763-499b-9a3c-8ac75f4415e4@github.com>
 <APS6H9AlsHSVKx62JWEAfdZjjbSJ58Wor7GHYPyhe74=.0c65e5fe-848e-42e9-b61b-890f81a5e1c2@github.com>
Message-ID: <bAYTfa-yS2001C0o8PEv6Mc67LU9eTgAe-6GMReuJEY=.92fce6f1-086f-4ce6-97d9-b8aed3321b37@github.com>

On Mon, 23 Aug 2021 10:57:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @dcubed-ojdk , @dholmes-ora would you be willing/able to take a look at this change, pretty please?
>
> Sorry @jbachorik  but frames and code-blobs are not an area I know.
> 
> David

@dholmes-ora, do you know anyone who could be the primary reviewer for this?

@neliasso? @rickard?

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

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

From lzang at openjdk.java.net  Mon Aug 23 23:55:27 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 23 Aug 2021 23:55:27 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v4]
In-Reply-To: <Ic37zSxgXZhFJIXpmO4BdGOtxXI2ZRrHd9qedz69VI4=.5ea478a4-941a-4bf0-bee6-b78cadc85283@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
 <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com>
 <Ic37zSxgXZhFJIXpmO4BdGOtxXI2ZRrHd9qedz69VI4=.5ea478a4-941a-4bf0-bee6-b78cadc85283@github.com>
Message-ID: <nyd3VFInrEAJQDInV6ATWgcndIRMAC0SUFxq401NooU=.ea59c65b-a065-4bfe-837e-94b6a5e55f21@github.com>

On Mon, 23 Aug 2021 23:26:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into hprof
>>  - fix write size issue
>>  - Merge branch 'master' into hprof
>>  - 8269685: Optimize HeapHprofBinWriter implementation
>
> Hi Lin,
> 
> You did not answer my question about empty methods in the AbstractHeapGraphWriter.java.
> It seems the following methods have to be abstract instead of being empty:
> 
> +    protected int calculateGlobalJNIHandlesDumpRecordSize() {
> +        return 0;
> +    }
> +
> +    protected int calculateJavaThreadsDumpRecordSize() {
> +        return 0;
> +    }
> +
> +    protected int calculateOopDumpRecordSize(Oop oop) throws IOException {
> +        return 0;
> +    }
> . . . 
>     // object field writers
> protected void writeReferenceField(Oop oop, OopField field)
>      throws IOException {
> }
> protected void writeByteField(Oop oop, ByteField field)
>     throws IOException {
> }
> protected void writeCharField(Oop oop, CharField field)
>     throws IOException {
> }
> protected void writeBooleanField(Oop oop, BooleanField field)
>     throws IOException {
> }
> protected void writeShortField(Oop oop, ShortField field)
>     throws IOException {
> }
> protected void writeIntField(Oop oop, IntField field)
>     throws IOException {
> }
> protected void writeLongField(Oop oop, LongField field)
>     throws IOException {
> }
> protected void writeFloatField(Oop oop, FloatField field)
>     throws IOException {
> }
> protected void writeDoubleField(Oop oop, DoubleField field)
>     throws IOException {
> }
> protected void writeObjectFooter(Oop oop) throws IOException {
> }
> protected void writeHeapFooter() throws IOException {
> }
> protected void writeHeapRecordPrologue() throws IOException {
> } 
> +    protected void writeHeapRecordPrologue(int size) throws IOException {
> +    }
> +
> protected void writeHeapRecordEpilogue() throws IOException {
> }

Hi Serguei (@sspitsyn),

   So sorry that I missed your comments, it is strange that your review didn't show on github in this PR.
   I make these methods empty in AbstractHeapGraphWriter rather than abstract so that there is no need to add these empty code in HeapGXLWriter, which is a subclass of AbstractHeapGraphWriter.  I think this may help make the code change clean. 
   What do you think?

BRs,
Lin

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

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

From apangin at openjdk.java.net  Tue Aug 24 00:28:31 2021
From: apangin at openjdk.java.net (Andrei Pangin)
Date: Tue, 24 Aug 2021 00:28:31 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v3]
In-Reply-To: <U5QTRyN0fSEVSnt6Dlwtjk8QYbQAXRYFFUN6fJTEvXk=.7bea3615-4fd5-4e3a-bbb4-5c9b4bfe76c2@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <jfohRNi3z8LnjHcxEzmJNhuO7nKKEtBY5bhR-8uycVI=.b410939d-7166-4ea7-a046-c8ca8f2dcc93@github.com>
 <zEfeAKmEcH3klTLjoOc4ww7yMMlaQmasB0LGXYFREDM=.911f044b-665a-4ca1-a604-66e1270ef191@github.com>
 <U5QTRyN0fSEVSnt6Dlwtjk8QYbQAXRYFFUN6fJTEvXk=.7bea3615-4fd5-4e3a-bbb4-5c9b4bfe76c2@github.com>
Message-ID: <2b10zJmYvua1kRntBFLHbMlbetwJEYuviNJ4GN9z9Ko=.d117de14-6e85-4aa3-84c7-e7d88490f9cf@github.com>

On Mon, 19 Jul 2021 07:07:04 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hi Ludovic,
>> 
>> Thank you for working on this long-standing bug.
>> I like the idea of the proposed solution, but unfortunately it cannot be applied as is. Since the stack walking code runs inside a signal handler, it is very limited in things it can do. In particular, it must not allocate, acquire locks, etc. In your implementation, FrameParser does allocate though.
>> 
>> The issue is not just theoretical: when I ran JDK with this patch with async-profiler, I immediately got the following deadlock:
>> 
>> 
>> (gdb) bt
>> #0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
>> #1  0x00007fa2363ca025 in __GI___pthread_mutex_lock (mutex=0x7fa235da5440 <tc_mutex>)
>>     at ../nptl/pthread_mutex_lock.c:80
>> #2  0x00007fa235696cb6 in ThreadCritical::ThreadCritical() () from /usr/java/jdk-18/lib/server/libjvm.so
>> #3  0x00007fa234b6fe53 in Chunk::next_chop() () from /usr/java/jdk-18/lib/server/libjvm.so
>> #4  0x00007fa234e88523 in frame::safe_for_sender(JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
>> #5  0x00007fa234e838f2 in vframeStreamForte::forte_next() () from /usr/java/jdk-18/lib/server/libjvm.so
>> #6  0x00007fa2349fbb9b in forte_fill_call_trace_given_top(JavaThread*, ASGCT_CallTrace*, int, frame) [clone .isra.20]
>>     () from /usr/java/jdk-18/lib/server/libjvm.so
>> #7  0x00007fa234e8426e in AsyncGetCallTrace () from /usr/java/jdk-18/lib/server/libjvm.so
>> #8  0x00007fa228519312 in Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int) ()
>>    from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
>> #9  0x00007fa228519c72 in Profiler::recordSample(void*, unsigned long long, int, Event*) ()
>>    from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
>> #10 0x00007fa2285164f8 in WallClock::signalHandler(int, siginfo_t*, void*) ()
>>    from /mnt/c/Users/Andrei/java/async-profiler/build/libasyncProfiler.so
>> #11 <signal handler called>
>> #12 __pthread_mutex_unlock_usercnt (decr=1, mutex=0x7fa235da5440 <tc_mutex>) at pthread_mutex_unlock.c:41
>> #13 __GI___pthread_mutex_unlock (mutex=0x7fa235da5440 <tc_mutex>) at pthread_mutex_unlock.c:356
>> #14 0x00007fa235696d3b in ThreadCritical::~ThreadCritical() () from /usr/java/jdk-18/lib/server/libjvm.so
>> #15 0x00007fa234b6fe71 in Chunk::next_chop() () from /usr/java/jdk-18/lib/server/libjvm.so
>> #16 0x00007fa234d1ca62 in ClassFileParser::parse_method(ClassFileStream const*, bool, ConstantPool const*, AccessFlags*, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
>> #17 0x00007fa234d1e338 in ClassFileParser::parse_methods(ClassFileStream const*, bool, AccessFlags*, bool*, bool*, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
>> #18 0x00007fa234d22459 in ClassFileParser::parse_stream(ClassFileStream const*, JavaThread*) ()
>>    from /usr/java/jdk-18/lib/server/libjvm.so
>> #19 0x00007fa234d2291c in ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*) () from /usr/java/jdk-18/lib/server/libjvm.so
>> #20 0x00007fa2351febb6 in KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*) ()
>>    from /usr/java/jdk-18/lib/server/libjvm.so
>> #21 0x00007fa235645b40 in SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*) ()
>>    from /usr/java/jdk-18/lib/server/libjvm.so
>> #22 0x00007fa2350bad0a in jvm_define_class_common(char const*, _jobject*, signed char const*, int, _jobject*, char const*, JavaThread*) [clone .constprop.299] ()
>>    from /usr/java/jdk-18/lib/server/libjvm.so
>> #23 0x00007fa2350bae6d in JVM_DefineClassWithSource () from /usr/java/jdk-18/lib/server/libjvm.so
>> #24 0x00007fa236a0ee12 in Java_java_lang_ClassLoader_defineClass1 () from /usr/java/jdk-18/lib/libjava.so
>
> @apangin Thanks for pointing that out! I'm updating it right now and should be pushing an update very soon. I'll also add examples on how it impacts JFR.

Hi @luhenry,
I had a chance to test your patch on realistic applications, and here are my observations:
1. JVM does not crash or hang, which is already a good sign.
2. The amount of `unknown_Java` samples indeed decreased, roughly by a factor of 2.
3. Now the bad news: with this patch, AsyncGetCallTrace starts returning many orphaned (truncated) stack traces that consist of just one or a few top frames.

For example, here are the results of profiling spring-petclinic application startup.
I summarized the amount of AsyncGetCallTrace failures by type in the following table.
Click on the links in the left column to open the entire flame graphs.

? | Success | Failures | unknown_Java | not_walkable_Java | unknown_not_Java | not_walkable_not_Java | Truncated
-- | -- | -- | -- | -- | -- | -- | --
[Baseline](https://cr.openjdk.java.net/~apangin/8178287/flamegraph/baseline.html) | 86.17% | 13.83% | 7.55% | 1.54% | 2.28% | 2.45% | 0.01%
[AGCT patch](https://cr.openjdk.java.net/~apangin/8178287/flamegraph/agct-patch.html) | 89.75% | 10.25% | 3.77% | 1.02% | 2.26% | - | 3.20%
[Async-profiler](https://cr.openjdk.java.net/~apangin/8178287/flamegraph/async-profiler.html) | 98.12% | 1.88% | 1.45% | 0.29% | 0.09% | - | 0.05%
[Async-profiler with?patch](https://cr.openjdk.java.net/~apangin/8178287/flamegraph/async-profiler-patch.html) | 94.95% | 5.05% | 1.21% | 0.05% | 0.10% | - | 3.69%

My biggest concern is the large number (>3%) of truncated stack traces. The probem is, such stack traces are indistinguishable (by the tools) from normal stack traces, and therefore the tools will display misleading information to a user, without even knowing that something went wrong. In this sense I'd prefer to return an error code rather than an invalid stack trace.

The above table illustrates the problem in practice. With the proposed patch, async-profiler actually performs worse than without it, because async-profiler can recover from most AGCT failures on its own, but not when AGCT returns an invalid stack trace instead of an error code.

In view of the aforementioned, I'll ask not to commit this patch before the problem of truncated stack traces is fixed. Thank you.

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

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

From sspitsyn at openjdk.java.net  Tue Aug 24 05:28:30 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 Aug 2021 05:28:30 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v4]
In-Reply-To: <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
 <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com>
Message-ID: <6Zju7N-AB0X4oj3aeBrAPl59d0oW4v-dMeDMnL1v7mc=.cb3aed84-040b-48a7-b950-67e6d61d0e23@github.com>

On Fri, 13 Aug 2021 10:46:02 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
>> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into hprof
>  - fix write size issue
>  - Merge branch 'master' into hprof
>  - 8269685: Optimize HeapHprofBinWriter implementation

Lin, in order to see my inlined comment you need to look at "Files changed".
I still miss something. If these methods have to be empty then what is the purpose to have them?
Also, a couple of new empty methods are not used, so the question is why do you add them:
  calculateGlobalJNIHandlesDumpRecordSize, calculateJavaThreadsDumpRecordSize

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

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

From sspitsyn at openjdk.java.net  Tue Aug 24 05:39:29 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 Aug 2021 05:39:29 GMT
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <DGifHTg7nIn5v9jLtDHTWvj1SxNfv3DxVz5Y4FaRCxY=.7f279e15-526c-469b-8872-4504fde721bd@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <DGifHTg7nIn5v9jLtDHTWvj1SxNfv3DxVz5Y4FaRCxY=.7f279e15-526c-469b-8872-4504fde721bd@github.com>
Message-ID: <ZInvKtjBA0wKEQm2RO1rkIXHwl70SiHRsPKzt6Lyjm4=.28e867f1-9864-456e-93d0-bf575ff67fd5@github.com>

On Wed, 18 Aug 2021 19:16:39 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Ok. Do you know who should be the primary reviewer? Rickard B?ckman? Nils Eliasson?

Markus,
There is no primary reviewer for this area as it is officially unsupported.
Also, the problem is that we have no test coverage in this area.
It is not easy to take a responsibility without it.

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

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

From lzang at openjdk.java.net  Tue Aug 24 06:39:36 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 24 Aug 2021 06:39:36 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v4]
In-Reply-To: <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
 <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com>
Message-ID: <dhMjy_o5k2J7ey8TOqEtOP6L43c3Ys0bTJo5Qer0-oY=.cd2cf4d3-3f3d-4a3d-96e3-e8337ff1362c@github.com>

On Fri, 13 Aug 2021 10:46:02 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
>> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into hprof
>  - fix write size issue
>  - Merge branch 'master' into hprof
>  - 8269685: Optimize HeapHprofBinWriter implementation

Dear Serguei,

> Lin, in order to see my inlined comment you need to look at "Files changed".

I can not find your comments here either, would you like to help check whether you sumbited the inlined commit after review?

> I still miss something. If these methods have to be empty then what is the purpose to have them?

The main reason is that both `HeapHprofBinWriter` and `HeapGXLWriter` are extended from `AbstractHeapGraphWriter`, and they both invoke method `write()` in `AbstractHeapGraphWriter` for heap iteration which invoke `doObj()`.  And in method `doObj()`, it calls `writeHeapRecordPrologue(calculateOopDumpRecordSize())` which should do nothing for `HeapGXLWriter` and do some work for `HeapHprofBinWriter`.  So I made empty method `writeHeapRecordPrologue(int)` and `calculateOopDumpRecordSize()` in base class and have them implemented in `HeapHprofBinWriter` only. 

> Also, a couple of new empty methods are not used, so the question is why do you add them:
> calculateGlobalJNIHandlesDumpRecordSize, calculateJavaThreadsDumpRecordSize

Thanks for point them out, I will remove these not used methods.

BRs,
Lin

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

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

From lzang at openjdk.java.net  Tue Aug 24 07:12:51 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 24 Aug 2021 07:12:51 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v5]
In-Reply-To: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
Message-ID: <OSyoU1Lf4CB4wBfxzlHKNjUr5UzYl9XvZql-w1PP4cs=.dc2ff164-17f4-4b5c-b8a4-42f06c8adf02@github.com>

> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.

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

  code clean up and remove useless methods

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4666/files
  - new: https://git.openjdk.java.net/jdk/pull/4666/files/cb1cbeb0..7b2a964c

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

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

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

From david.holmes at oracle.com  Tue Aug 24 07:43:36 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Aug 2021 17:43:36 +1000
Subject: RFR: 8178287: AsyncGetCallTrace fails to traverse valid Java
 stacks [v4]
In-Reply-To: <bAYTfa-yS2001C0o8PEv6Mc67LU9eTgAe-6GMReuJEY=.92fce6f1-086f-4ce6-97d9-b8aed3321b37@github.com>
References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com>
 <sct-931HkBBPm1W_sP4hDiMMbFeet5YDIkPkWTNgypw=.2de7fa38-dbac-49ea-a7e7-ebd791c79591@github.com>
 <BWanYitzfyqkvmVIKndceXJDtbA5lBDxKA94gsMt9hY=.4d5d7dc0-e763-499b-9a3c-8ac75f4415e4@github.com>
 <APS6H9AlsHSVKx62JWEAfdZjjbSJ58Wor7GHYPyhe74=.0c65e5fe-848e-42e9-b61b-890f81a5e1c2@github.com>
 <bAYTfa-yS2001C0o8PEv6Mc67LU9eTgAe-6GMReuJEY=.92fce6f1-086f-4ce6-97d9-b8aed3321b37@github.com>
Message-ID: <64a8287e-f8e9-aed7-b870-f08d16af74af@oracle.com>

On 24/08/2021 9:40 am, Marcus Hirt wrote:
> On Mon, 23 Aug 2021 10:57:54 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> @dcubed-ojdk , @dholmes-ora would you be willing/able to take a look at this change, pretty please?
>>
>> Sorry @jbachorik  but frames and code-blobs are not an area I know.
>>
>> David
> 
> @dholmes-ora, do you know anyone who could be the primary reviewer for this?

I don't know sorry.

David

> @neliasso? @rickard?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4436
> 

From sspitsyn at openjdk.java.net  Tue Aug 24 10:19:29 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 Aug 2021 10:19:29 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v3]
In-Reply-To: <DyIwynoIm6DSvzRJoyxB8m65aYMyBuHagz5lwTClc9g=.4af54310-c091-4d5f-a648-27c8bf75d1c7@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
 <DyIwynoIm6DSvzRJoyxB8m65aYMyBuHagz5lwTClc9g=.4af54310-c091-4d5f-a648-27c8bf75d1c7@github.com>
Message-ID: <Z8-YtaX9Pd1ye12BgjMJ6QlFlzUnykZoQ6nx9C_fd0Y=.1e7d70d1-5c8b-4277-aa32-33f456d31749@github.com>

On Mon, 5 Jul 2021 12:04:17 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
>> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix write size issue

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java line 141:

> 139:         return 0;
> 140:     }
> 141: 

Hi Lin,
I don't like these empty methods in this abstract class.
Should they be just abstract instead?
Thanks,
Serguei

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

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

From sspitsyn at openjdk.java.net  Tue Aug 24 10:22:28 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 24 Aug 2021 10:22:28 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v5]
In-Reply-To: <OSyoU1Lf4CB4wBfxzlHKNjUr5UzYl9XvZql-w1PP4cs=.dc2ff164-17f4-4b5c-b8a4-42f06c8adf02@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
 <OSyoU1Lf4CB4wBfxzlHKNjUr5UzYl9XvZql-w1PP4cs=.dc2ff164-17f4-4b5c-b8a4-42f06c8adf02@github.com>
Message-ID: <careoNb09cgmG6C9gwIZf57RkUH1S5oKIY0OEh-4yPU=.14ac8dc9-d3a3-48c1-889b-6eac59257407@github.com>

On Tue, 24 Aug 2021 07:12:51 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
>> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code clean up and remove useless methods

Lin, you are right. It occurred I did not submit my comment (while I was sure that I did it).

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

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

From lzang at openjdk.java.net  Tue Aug 24 12:33:48 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 24 Aug 2021 12:33:48 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v6]
In-Reply-To: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
Message-ID: <H9J0mHJstBTcH_yKO_RccYiyYHR9rFz4IiPG9DgFeuU=.6c50d851-715e-4a51-914c-792d16d5abb5@github.com>

> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.

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

  make calculateGlobalJNIHandlesDumpRecordSize abstract

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4666/files
  - new: https://git.openjdk.java.net/jdk/pull/4666/files/7b2a964c..32e6b4cb

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

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

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

From lzang at openjdk.java.net  Tue Aug 24 12:36:29 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 24 Aug 2021 12:36:29 GMT
Subject: RFR: 8269685: Optimize HeapHprofBinWriter implementation [v5]
In-Reply-To: <OSyoU1Lf4CB4wBfxzlHKNjUr5UzYl9XvZql-w1PP4cs=.dc2ff164-17f4-4b5c-b8a4-42f06c8adf02@github.com>
References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com>
 <OSyoU1Lf4CB4wBfxzlHKNjUr5UzYl9XvZql-w1PP4cs=.dc2ff164-17f4-4b5c-b8a4-42f06c8adf02@github.com>
Message-ID: <7iymJyHzXaIWVxKEMfm_u5ECYvgqEQ_NvjLQuVKXRVQ=.e02b1544-3e6a-40dd-b624-edf729cb01f5@github.com>

On Tue, 24 Aug 2021 07:12:51 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> This PR rewrite the implementation of the HeapHprofBinWriter, which could simplify the logic of current implementation.
>> please see detail description at https://bugs.openjdk.java.net/browse/JDK-8269685.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code clean up and remove useless methods

Hi Serguei, 
    I update the PR to make the `calculateGlobalJNIHandlesDumpRecordSize()` method abstract. 
    For other empty ones that already there in original implementation, I will leave them as they are. do you think it is OK? 

BRs,
Lin

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

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

From azvegint at openjdk.java.net  Tue Aug 24 13:09:37 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 24 Aug 2021 13:09:37 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <cI5w9AqyTY2y-cy5LJA9fbGFkB2s_-hhoVOCP6w0CaE=.d56a95c4-0a92-45e2-944b-0d0e3dce165e@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8c6e27c3...e7127644

Marked as reviewed by azvegint (Reviewer).

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

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

From sspitsyn at openjdk.java.net  Wed Aug 25 09:20:41 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 25 Aug 2021 09:20:41 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: <tpdjLh31_-34iguCkW4lmb9f4WCVIvONmk1VTo-8S6s=.8d371e0e-644a-4984-8d4c-b5d09581b141@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/1b5ecf20...a87793c3

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1580:

> 1578:         private boolean allowSegmented;
> 1579:         // Write data directly to underlying stream. Don't use internal buffer.
> 1580:         private boolean unbufferedMode;

I would suggest replace `unbufferedMode` with `bufferedMode` field. It will simplify logic a little bit.
Then you will need to rename the method `fillSegmentSizeAndEnableUnbufferedMode` to be `fillSegmentSizeAndDisableBufferedMode`. 
There are several places where `!unbufferedMode` will be replaced with `bufferedMode` .

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

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

From sspitsyn at openjdk.java.net  Wed Aug 25 09:26:40 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 25 Aug 2021 09:26:40 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: <PfWtJk8iDx5FDoWEM7aPxmFNqmulTaK6ntCMht5QE4M=.34ca673d-78dd-4aca-80ad-4c84fa0c5bf4@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/9ac5b235...a87793c3

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 592:

> 590:         // only process when segmented heap dump is not used, since SegmentedOutputStream
> 591:         // could create segment automatically.
> 592:         long currentRecordLength = (dumpEnd - currentSegmentStart - 4L);

As you moved this initialization inside the `if (!useSegmentedHeapDump)` condition then the `currentRecordLength` will be now equal to 0 for segmented heap dump as well.
Could you, please, confirm it was your intention?

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

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

From sspitsyn at openjdk.java.net  Wed Aug 25 09:34:43 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 25 Aug 2021 09:34:43 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: <nOcA-1yJwMhFUI5wSaIti0gBkvu8QwpDQdQmLVqOe-Q=.aa37dd31-5a93-466f-bf47-0b614d58e5bb@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/ae8d154f...a87793c3

Changes requested by sspitsyn (Reviewer).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1367:

> 1365:         @Override
> 1366:         public synchronized void write(int b) throws IOException {
> 1367:            if (segmentMode && !unbufferedMode) {

It is not clear why the condition` !unbufferedMode` is additionally checked here and several places below. The `SegmentedOutputStream` constructor always sets `false` to the`unbufferedMode` field at L1344. Is it possible that `segmentMode` can be also unbuffered?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1496:

> 1494:             }
> 1495:             // buffer must be empty now.
> 1496:             assert (segmentMode && (segmentWritten == 0) && (unbufferedMode == false)) : "Wrong Status";

This assert repeats checks in asserts at lines L1489 and L1490.
It is not clear why this duplication is needed.

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

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

From eosterlund at openjdk.java.net  Wed Aug 25 15:40:26 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 25 Aug 2021 15:40:26 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never [v2]
In-Reply-To: <c9XP_Cq6DAIS35iekHb0Sm6VRJDUKcjamXNeoiHvQsw=.68afb9c7-c4a8-44cc-af2c-1ca118b3b56a@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
 <c9XP_Cq6DAIS35iekHb0Sm6VRJDUKcjamXNeoiHvQsw=.68afb9c7-c4a8-44cc-af2c-1ca118b3b56a@github.com>
Message-ID: <f-L5vU12HtvMGr9v9wrw5iEsU95pFW0sj0DBcwc3HNs=.252802d8-34b4-4ad2-9c68-ed12cd98a0e9@github.com>

On Mon, 23 Aug 2021 13:03:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
>> Tested with tier1-3.  Tier 4-6 testing in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove JfrSream_lock and rerun JFR tests.

So you are enforcing the relationship between safepoint checking and rank. In a way we already had that for special locks. I like it.

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

Marked as reviewed by eosterlund (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Aug 25 17:25:37 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 25 Aug 2021 17:25:37 GMT
Subject: RFR: 8272992: Replace usages of Collections.sort with List.sort call
 in jdk.* modules
Message-ID: <9xbhI0rwD3XbAHZFfQAkJHYivbC5F4N085RuSVWx8HU=.8a470c93-5fee-4981-97e4-afb6cb1147b9@github.com>

Collections.sort is just a wrapper, so it is better to use an instance method directly.

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

Commit messages:
 - [PATCH] Replace usages of Collections.sort with List.sort call in jdk.* modules

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

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

From coleenp at openjdk.java.net  Wed Aug 25 18:55:27 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 25 Aug 2021 18:55:27 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never [v2]
In-Reply-To: <c9XP_Cq6DAIS35iekHb0Sm6VRJDUKcjamXNeoiHvQsw=.68afb9c7-c4a8-44cc-af2c-1ca118b3b56a@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
 <c9XP_Cq6DAIS35iekHb0Sm6VRJDUKcjamXNeoiHvQsw=.68afb9c7-c4a8-44cc-af2c-1ca118b3b56a@github.com>
Message-ID: <sZxwnAQaWtDOjyuI2VyRII324IdXcH4yJ4JRuXLKGME=.6f769ba6-7546-4ddb-ada2-0f59bf3f6344@github.com>

On Mon, 23 Aug 2021 13:03:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
>> Tested with tier1-3.  Tier 4-6 testing in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove JfrSream_lock and rerun JFR tests.

Yes, eventually I'd like there to be a more strict relationship between rank and safepoint checking, so that's why I moved these locks down in the ranking system.  Thank you Erik!

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

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

From lzang at openjdk.java.net  Thu Aug 26 04:17:34 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 26 Aug 2021 04:17:34 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v14]
In-Reply-To: <PfWtJk8iDx5FDoWEM7aPxmFNqmulTaK6ntCMht5QE4M=.34ca673d-78dd-4aca-80ad-4c84fa0c5bf4@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <pew__FWJ2yL8cHc4dBGF8RBNk8AQbIHpnjOi7z4Ishk=.750d707c-3109-4ab9-be73-8889066b2a05@github.com>
 <PfWtJk8iDx5FDoWEM7aPxmFNqmulTaK6ntCMht5QE4M=.34ca673d-78dd-4aca-80ad-4c84fa0c5bf4@github.com>
Message-ID: <Et3fRKcVnFL2BjacsHLKGhnuBCtr-c6FzPgPP-CNSqE=.bb0ecf31-1133-4f10-b671-5ee7ec9cff49@github.com>

On Wed, 25 Aug 2021 09:23:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 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/8fe9638f...a87793c3
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 592:
> 
>> 590:         // only process when segmented heap dump is not used, since SegmentedOutputStream
>> 591:         // could create segment automatically.
>> 592:         long currentRecordLength = (dumpEnd - currentSegmentStart - 4L);
> 
> As you moved this initialization inside the `if (!useSegmentedHeapDump)` condition then the `currentRecordLength` will be now equal to 0 for segmented heap dump as well.
> Could you, please, confirm it was your intention?

Yes, it is intended. 
The logic here is that when **not** using segmented dump, it needs to get the current data written size from the underlying file position, and then cut the array to satisfy that the U4 `size` slot does not overflow, as comments stats. 
But when it is in segmented dump, the previously written data has already written in the previous segment, it only need to consider that the current array size + the segment header size could satisfy the `size` slot.  so the `currentRecordLength` is zero.

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

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

From lzang at openjdk.java.net  Thu Aug 26 04:32:35 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 26 Aug 2021 04:32:35 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v14]
In-Reply-To: <nOcA-1yJwMhFUI5wSaIti0gBkvu8QwpDQdQmLVqOe-Q=.aa37dd31-5a93-466f-bf47-0b614d58e5bb@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <pew__FWJ2yL8cHc4dBGF8RBNk8AQbIHpnjOi7z4Ishk=.750d707c-3109-4ab9-be73-8889066b2a05@github.com>
 <nOcA-1yJwMhFUI5wSaIti0gBkvu8QwpDQdQmLVqOe-Q=.aa37dd31-5a93-466f-bf47-0b614d58e5bb@github.com>
Message-ID: <xv17DFwt5u6jS1IqfGrMvZW-Aw8jWhVPCeRSrpKEOzI=.7f810af9-c422-4510-953e-cb4209141141@github.com>

On Wed, 25 Aug 2021 09:27:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 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/b7eb86a6...a87793c3
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1367:
> 
>> 1365:         @Override
>> 1366:         public synchronized void write(int b) throws IOException {
>> 1367:            if (segmentMode && !unbufferedMode) {
> 
> It is not clear why the condition` !unbufferedMode` is additionally checked here and several places below. The `SegmentedOutputStream` constructor always sets `false` to the`unbufferedMode` field at L1344. Is it possible that `segmentMode` can be also unbuffered?

The `unbufferedMode` is set to true at L1498, and it is use when writing array data. The purpose is to write the data directly to the file instead of buffering them first, it can avoid memory copy and also avoid timeout when dumping large array (because the buffer must contains the whole segment before it is written to file, to avoid data pollution for compressed dump, and if the buffer is not enough, a memory copy is conducted)

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1496:
> 
>> 1494:             }
>> 1495:             // buffer must be empty now.
>> 1496:             assert (segmentMode && (segmentWritten == 0) && (unbufferedMode == false)) : "Wrong Status";
> 
> This assert repeats checks in asserts at lines L1489 and L1490.
> It is not clear why this duplication is needed.

You are right, it is unnecessary, I will fix it .

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1580:
> 
>> 1578:         private boolean allowSegmented;
>> 1579:         // Write data directly to underlying stream. Don't use internal buffer.
>> 1580:         private boolean unbufferedMode;
> 
> I would suggest replace `unbufferedMode` with `bufferedMode` field. It will simplify logic a little bit.
> Then you will need to rename the method `fillSegmentSizeAndEnableUnbufferedMode` to be `fillSegmentSizeAndDisableBufferedMode`. 
> There are several places where `!unbufferedMode` will be replaced with `bufferedMode` .

Good idea, I will made the change. Thanks.

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

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

From sspitsyn at openjdk.java.net  Thu Aug 26 07:22:31 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 26 Aug 2021 07:22:31 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v14]
In-Reply-To: <Et3fRKcVnFL2BjacsHLKGhnuBCtr-c6FzPgPP-CNSqE=.bb0ecf31-1133-4f10-b671-5ee7ec9cff49@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <pew__FWJ2yL8cHc4dBGF8RBNk8AQbIHpnjOi7z4Ishk=.750d707c-3109-4ab9-be73-8889066b2a05@github.com>
 <PfWtJk8iDx5FDoWEM7aPxmFNqmulTaK6ntCMht5QE4M=.34ca673d-78dd-4aca-80ad-4c84fa0c5bf4@github.com>
 <Et3fRKcVnFL2BjacsHLKGhnuBCtr-c6FzPgPP-CNSqE=.bb0ecf31-1133-4f10-b671-5ee7ec9cff49@github.com>
Message-ID: <tYhvhVHPFbF1x_mBH_BrONuoj9s-rQ-DIzRF5GJW3-c=.a6fe2e2f-0637-48c0-ae55-ab158a2ebddc@github.com>

On Thu, 26 Aug 2021 04:14:07 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 592:
>> 
>>> 590:         // only process when segmented heap dump is not used, since SegmentedOutputStream
>>> 591:         // could create segment automatically.
>>> 592:         long currentRecordLength = (dumpEnd - currentSegmentStart - 4L);
>> 
>> As you moved this initialization inside the `if (!useSegmentedHeapDump)` condition then the `currentRecordLength` will be now equal to 0 for segmented heap dump as well.
>> Could you, please, confirm it was your intention?
>
> Yes, it is intended. 
> The logic here is that when **not** using segmented dump, it needs to get the current data written size from the underlying file position, and then cut the array to satisfy that the U4 `size` slot does not overflow, as comments stats. 
> But when it is in segmented dump, the previously written data has already been flushed in the previous segment, it only needs to consider that the current array size + the segment header size could satisfy the `size` slot.  so the `currentRecordLength` is zero.

Okay, thanks.

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

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

From lzang at openjdk.java.net  Thu Aug 26 07:58:37 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 26 Aug 2021 07:58:37 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v15]
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: <VxwZ3-PAcufMOjVCrASG76hmc_2UNLXgP7gL61gzaOI=.6ea35975-e2ee-432b-904f-43d5a11fa6eb@github.com>

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

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

  rename unbufferedMode and code refine

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

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

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

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

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

From lzang at openjdk.java.net  Thu Aug 26 07:58:49 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 26 Aug 2021 07:58:49 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: <olzOf59Udm96rsz8diiXYBXRv2tUzakJpVcnJcSnGC8=.5f01d23a-afa2-408b-819b-8fa3da33c71e@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/f5df44c5...a87793c3

Dear Serguei,
    Thanks a lot for your review and comments! I have updated the PR with your suggestions, and done some basic tests on my side. (tier1, and a test for dump heap with clhsdb).

Thanks!
Lin

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

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

From sspitsyn at openjdk.java.net  Thu Aug 26 07:58:50 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 26 Aug 2021 07:58:50 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v14]
In-Reply-To: <xv17DFwt5u6jS1IqfGrMvZW-Aw8jWhVPCeRSrpKEOzI=.7f810af9-c422-4510-953e-cb4209141141@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <pew__FWJ2yL8cHc4dBGF8RBNk8AQbIHpnjOi7z4Ishk=.750d707c-3109-4ab9-be73-8889066b2a05@github.com>
 <nOcA-1yJwMhFUI5wSaIti0gBkvu8QwpDQdQmLVqOe-Q=.aa37dd31-5a93-466f-bf47-0b614d58e5bb@github.com>
 <xv17DFwt5u6jS1IqfGrMvZW-Aw8jWhVPCeRSrpKEOzI=.7f810af9-c422-4510-953e-cb4209141141@github.com>
Message-ID: <kRYgbOLXz2dJCWbh6s63XaHuZBu0Y721d6lM6yrvR0g=.714e9010-47c7-46e9-b87f-21df6953b5ff@github.com>

On Thu, 26 Aug 2021 04:27:36 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1367:
>> 
>>> 1365:         @Override
>>> 1366:         public synchronized void write(int b) throws IOException {
>>> 1367:            if (segmentMode && !unbufferedMode) {
>> 
>> It is not clear why the condition` !unbufferedMode` is additionally checked here and several places below. The `SegmentedOutputStream` constructor always sets `false` to the`unbufferedMode` field at L1344. Is it possible that `segmentMode` can be also unbuffered?
>
> The `unbufferedMode` is set to true at L1498, and it is use when writing array data. The purpose is to write the data directly to the file instead of buffering them first, it can avoid memory copy and also avoid timeout when dumping large array (because the buffer must contains the whole segment before it is written to file, to avoid data pollution for compressed dump, and if the buffer is not enough, a memory copy is conducted)

Okay, thanks.

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1580:
>> 
>>> 1578:         private boolean allowSegmented;
>>> 1579:         // Write data directly to underlying stream. Don't use internal buffer.
>>> 1580:         private boolean unbufferedMode;
>> 
>> I would suggest replace `unbufferedMode` with `bufferedMode` field. It will simplify logic a little bit.
>> Then you will need to rename the method `fillSegmentSizeAndEnableUnbufferedMode` to be `fillSegmentSizeAndDisableBufferedMode`. 
>> There are several places where `!unbufferedMode` will be replaced with `bufferedMode` .
>
> Good idea, I will made the change. Thanks.

Lin, I'm okay with your fix in general and will approve it after check of your change for the above suggestion.

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

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

From sspitsyn at openjdk.java.net  Thu Aug 26 08:10:29 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 26 Aug 2021 08:10:29 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v15]
In-Reply-To: <VxwZ3-PAcufMOjVCrASG76hmc_2UNLXgP7gL61gzaOI=.6ea35975-e2ee-432b-904f-43d5a11fa6eb@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <VxwZ3-PAcufMOjVCrASG76hmc_2UNLXgP7gL61gzaOI=.6ea35975-e2ee-432b-904f-43d5a11fa6eb@github.com>
Message-ID: <BDTuw9B5gU4oaEHnjrtyX2Cd0bmPB1zR4UOswLINgmE=.34208f54-6e4a-4fef-a380-ea4073a277d5@github.com>

On Thu, 26 Aug 2021 07:58:37 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename unbufferedMode and code refine

Lin,
The fix looks good to me.
Thank you for your patience!
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From lzang at openjdk.java.net  Thu Aug 26 08:57:17 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 26 Aug 2021 08:57:17 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v16]
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: <S_4zANA8MLnZYktpbhg1C9umaOseAueaUqVbRbjatvQ=.6992ffb3-80b7-4b0e-8082-fca629b72dad@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 20 additional commits since the last revision:

 - Merge branch 'master' into sadump-fix
 - rename unbufferedMode and code refine
 - 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
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/3d027bff...9b614aff

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2803/files
  - new: https://git.openjdk.java.net/jdk/pull/2803/files/621b27dc..9b614aff

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

  Stats: 191855 lines in 3156 files changed: 130698 ins; 45098 del; 16059 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803

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

From lzang at openjdk.java.net  Thu Aug 26 08:57:19 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 26 Aug 2021 08:57:19 GMT
Subject: RFR: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v5]
In-Reply-To: <rFBFEymgIrkLQdW4dLSSRthpE6vu629ScEsMmO8YM3w=.a8182d50-bb9e-4a2a-9cec-c965f80cca80@github.com>
References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com>
 <Zvf7GN59hJdc7SgVRao3cEbcpU99CbGceULIfJnDJOE=.4bd79c51-6b9b-4ff9-9ada-dc43fd6ca6e8@github.com>
 <e6bMvI_trIEXu7SAiM98-OpZug3Mwli00owZzLXxJNo=.fa0b5857-28b8-428d-9477-61044e32ad49@github.com>
 <oaMRL-GuwQKYlGByJvPhHH63A4LTvQLsL2W6BOIS6cc=.5ee0e7f9-bdc3-4e51-9fcf-999d607730c1@github.com>
 <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com>
 <cedPjc6Gumib0S_yqDLAm8up9lPEGguw5w5LJblpKHM=.cad805fe-ab47-4eb4-8c78-e2a17109a2ce@github.com>
 <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com>
 <2J1CEmVaXJuvU3fseIBYDcJCihqoeAf07bt0hgvJWWE=.259496ed-1883-4035-a4e5-e6c45f511707@github.com>
 <rFBFEymgIrkLQdW4dLSSRthpE6vu629ScEsMmO8YM3w=.a8182d50-bb9e-4a2a-9cec-c965f80cca80@github.com>
Message-ID: <ijgtuFejtd812e8A56QnNdVZ4MqBl7BcNrSrKE32q7k=.9f4d4d61-14b2-4826-bfc9-c91a45ef13df@github.com>

On Wed, 17 Mar 2021 06:40:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo in comments
>
> One more question.
> 
> 1367         public synchronized void write(int b) throws IOException {
> 1368            if (segmentMode && !writeThrough) {
> 1369                if (segmentWritten == 0) {
> 1370                    // At the begining of the segment.
> 1371                    writeSegmentHeader();
> 1372                } else if (segmentWritten == segmentBuffer.length) {
> 1373                    // Internal buffer is full, extend a larger one.
> 1374                    int newSize = segmentBuffer.length + SEGMENT_BUFFER_INC_SIZE;
> 1375                    byte newBuf[] = new byte[newSize];
> 1376                    System.arraycopy(segmentBuffer, 0, newBuf, 0, segmentWritten);
> 1377                    segmentBuffer = newBuf;
> 1378                }
> 1379                segmentBuffer[segmentWritten++] = (byte)b;
> 1380                return;
> 1381            }
> 1382            super.write(b);
> 1383         }
> 
> Does the check for "!writeThrough" at L1368 means there is no need to write the segment header (as at L1371)?

Hi Serguei (@sspitsyn ),
Really thanks for your help!

Hi Chris (@plummercj ), 
Would you like to review the latest change again? There are not too much changes since your approval, but I think it is better if you could help take a look.

@plummercj @sspitsyn , I will tag this PR with /integrate, and may need your help to sponsor it when it is ready. Thanks!

BRs,
Lin

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

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

From serb at openjdk.java.net  Thu Aug 26 17:42:33 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 17:42:33 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/be695a9b...e7127644

Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

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

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

From github.com+5709644+fdesu at openjdk.java.net  Thu Aug 26 18:33:27 2021
From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko)
Date: Thu, 26 Aug 2021 18:33:27 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
 <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
Message-ID: <vjfSSXTwCTncHGyKQOw5M3cV_bCdmb89ZEFgZ8ggTkQ=.b617da20-0a0c-4b55-8011-184d1932e2aa@github.com>

On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/810191b6...e7127644
>
> Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

@mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. Here they are:
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyURIDV.java
- src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java
- src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java

would it make sense to go through them as well?

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

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

From serb at openjdk.java.net  Thu Aug 26 18:38:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 26 Aug 2021 18:38:26 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
 <Hnmto7j73nysCgUxJ3iQ3kyAELMm0XPaTT2SP0UOJAY=.d612ef3a-836c-4742-b934-dcd6f22bbe47@github.com>
Message-ID: <a97uQJLcPbeqHP6UVqNXMtqDq4bf4GytTvBLl4C5HPk=.3a50dcbe-d199-4df4-9af7-a94f7755bfe3@github.com>

On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Update the usage of Files.readAllLines()
>>  - Update datatransfer
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Fix related imports
>>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>>  - Cleanup UnsupportedEncodingException
>>  - Update PacketStream.java
>>  - Rollback TextTests, should be compatible with jdk1.4
>>  - Rollback TextRenderTests, should be compatible with jdk1.4
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/e5c71cd0...e7127644
>
> Can somebody take a look too the changes in the "jdk.attach", "jdk.hotspot.agent" and IdealGraphVisualizer?

> @mrserb Not sure if it applies but there are couple of classes in `java.xml` that use charset names instead of standard charsets. 
> would it make sense to go through them as well?

Most of the cases in the XML module are related to the Xerces library, I have skipped it to make the future merges from upstream of that library simpler.

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

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

From amenkov at openjdk.java.net  Thu Aug 26 22:46:24 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 26 Aug 2021 22:46:24 GMT
Subject: RFR: 8269770: nsk tests should start IOPipe channel before launch
 debuggee - Debugee.prepareDebugee [v2]
In-Reply-To: <NN8U4ddBK-4rcoVri_yEo8o13MAOajtLl4smgln4PJ0=.347bd198-8e2e-4b8b-99bf-ef808f5c894f@github.com>
References: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>
 <NN8U4ddBK-4rcoVri_yEo8o13MAOajtLl4smgln4PJ0=.347bd198-8e2e-4b8b-99bf-ef808f5c894f@github.com>
Message-ID: <8NVDrw74Vd0opZm6RUbpEA6fVvZ8OKbFLSor8y_bzpI=.b4962781-157a-4818-81cd-2196b433d1b5@github.com>

On Fri, 2 Jul 2021 19:30:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes several hundreds tests which launch debugee by using uses Debugee.prepareDebugee() method or use 
>> debugee = Binder.bindToDebugee(...);
>> IOPipe pipe = debugee.createIOPipe();
>> logic.
>> Debugee.prepareDebugee() and Binder.bindToDebugee() launch debuggee by using CommandLineLaunch JDI connector with suspend=="true" argument, so they return debuggee suspended before the main class is loaded.
>> The fix starts IOPipe listening before debuggee VM is resumed.
>> 
>> Simplified isPackagePrivate/accipp001.java test to use Debugee.prepareDebugee() - it does exactly the same as Debugee.prepareDebugee() does (the only difference is using deprecated IOPipe ctor instead of Debugee.createIOPipe())
>> 
>> Tested all affected tests:
>> test/hotspot/jtreg/vmTestbase/nsk/jdi
>> test/hotspot/jtreg/vmTestbase/nsk/jdwp
>> test/hotspot/jtreg/serviceability/dcmd
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed comment

Ping. Still looking for 2nd reviewer

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

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

From lzang at openjdk.java.net  Fri Aug 27 09:05:32 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 27 Aug 2021 09:05:32 GMT
Subject: Integrated: 8262386:
 resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out
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: <XzJn__KbkDppFDeVUggHbAnrY0TNcRJwiH1KtRjFX7A=.3cc227a4-cfc5-4d72-b816-96d475ac20da@github.com>

On Wed, 3 Mar 2021 07:01:46 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

This pull request has now been integrated.

Changeset: 46684a4e
Author:    Lin Zang <lzang at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/46684a4efa165d97c0ef8f56248ee82003acdb7b
Stats:     84 lines in 2 files changed: 57 ins; 5 del; 22 mod

8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out

Reviewed-by: cjplummer, sspitsyn

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

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

From simeon.danailov.andreev at gmail.com  Fri Aug 27 10:53:36 2021
From: simeon.danailov.andreev at gmail.com (S A)
Date: Fri, 27 Aug 2021 13:53:36 +0300
Subject: StringBuilder OOMs earlier with JRE 11 compared to JRE 8
Message-ID: <CACcnpz3RmwBmM=ycEKAPrmLhXq_fXNMoisnXnQSZMEfdwkPZtg@mail.gmail.com>

Hi all,

while working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=575641, I
noticed that StringBuilder throws an OOM "half as early" in OpenJDK 11 (and
17 early access), when compared to OpenJDK 8.

In particular, I ran the following snippet to see where the limit of
appending to a StringBuilder is:

StringBuilder sb = new StringBuilder();
long n = 8L * 1024L * 1024L;
for (long i = 0; i < n; ++i) {
int m = 1024;
for (int j = 0; j < m; ++j) {
int length = sb.length();
try {
sb.append((char) j);
} catch (Error e) {
System.out.println("Error occurred at length=" + length + " [i=" + i + ",
j=" + j + "]");
throw e;
}

}
}

JRE 8:

Error occurred at length=2147483645 [i=2097151, j=1021]
Exception in thread "main" java.lang.OutOfMemoryError: Requested array size
exceeds VM limit
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649)
at java.lang.StringBuilder.append(StringBuilder.java:202)
at
test.stringbuilder.TestStringbuilderOOM.main(TestStringbuilderOOM.java:13)

JRE 11:

Error occurred at length=1073741822 [i=1048575, j=1022]
Exception in thread "main" java.lang.OutOfMemoryError: Requested array size
exceeds VM limit
at java.base/java.util.Arrays.copyOf(Arrays.java:3745)
at
java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:172)
at
java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:748)
at java.base/java.lang.StringBuilder.append(StringBuilder.java:241)
at
TestJava11/test.stringbuilder.TestStringbuilderOOM.main(TestStringbuilderOOM.java:13)

While StringBuilder is not a good choice for holding GBs of text, I wonder
that no effort is made to clamp the capacity to its limit when (I assume)
it is being doubled upon array expansion.

Is this something that should be looked into or it can be safely ignored
(from JDK users POV)?

Best regards,
Simeon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210827/faefb0de/attachment.htm>

From david.holmes at oracle.com  Fri Aug 27 13:25:25 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Aug 2021 23:25:25 +1000
Subject: StringBuilder OOMs earlier with JRE 11 compared to JRE 8
In-Reply-To: <CACcnpz3RmwBmM=ycEKAPrmLhXq_fXNMoisnXnQSZMEfdwkPZtg@mail.gmail.com>
References: <CACcnpz3RmwBmM=ycEKAPrmLhXq_fXNMoisnXnQSZMEfdwkPZtg@mail.gmail.com>
Message-ID: <99e1fc68-a602-0a31-a98a-03548fa63665@oracle.com>

Hi Simeon,

Redirecting this to core-libs-dev as it is not a serviceability issue. 
(bcc serviceabillity-dev)

Thanks,
David

On 27/08/2021 8:53 pm, S A wrote:
> Hi all,
> 
> while working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=575641 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=575641>, I noticed that 
> StringBuilder throws an OOM "half as early" in OpenJDK 11 (and 17 early 
> access), when compared to OpenJDK 8.
> 
> In particular, I ran the following snippet to see where the limit of 
> appending to a StringBuilder is:
> 
> StringBuilder sb = new StringBuilder();
> long n = 8L * 1024L * 1024L;
> for (long i = 0; i < n; ++i) {
> int m = 1024;
> for (int j = 0; j < m; ++j) {
> int length = sb.length();
> try {
> sb.append((char) j);
> } catch (Error e) {
> System.out.println("Error occurred at length=" + length + " [i=" + i + 
> ", j=" + j + "]");
> throw e;
> }
> 
> }
> }
> 
> JRE 8:
> 
> Error occurred at length=2147483645 [i=2097151, j=1021]
> Exception in thread "main" java.lang.OutOfMemoryError: Requested array 
> size exceeds VM limit
> at java.util.Arrays.copyOf(Arrays.java:3332)
> at 
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649)
> at java.lang.StringBuilder.append(StringBuilder.java:202)
> at 
> test.stringbuilder.TestStringbuilderOOM.main(TestStringbuilderOOM.java:13)
> 
> JRE 11:
> 
> Error occurred at length=1073741822 [i=1048575, j=1022]
> Exception in thread "main" java.lang.OutOfMemoryError: Requested array 
> size exceeds VM limit
> at java.base/java.util.Arrays.copyOf(Arrays.java:3745)
> at 
> java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:172)
> at 
> java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:748)
> at java.base/java.lang.StringBuilder.append(StringBuilder.java:241)
> at 
> TestJava11/test.stringbuilder.TestStringbuilderOOM.main(TestStringbuilderOOM.java:13)
> 
> While StringBuilder is not a good choice for holding GBs of text, I 
> wonder that no effort is made to clamp the capacity to its limit when (I 
> assume) it is being doubled upon array expansion.
> 
> Is this something that should be looked into or it can be safely ignored 
> (from JDK users POV)?
> 
> Best regards,
> Simeon

From mgronlun at openjdk.java.net  Fri Aug 27 15:23:36 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 27 Aug 2021 15:23:36 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v9]
In-Reply-To: <AHdJq1iFYOssjn0f8Q8N8e1YDSQ0qizjFShbDh5uWCQ=.1a7fbda3-22e1-420d-9221-ea4ccea55d58@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <AHdJq1iFYOssjn0f8Q8N8e1YDSQ0qizjFShbDh5uWCQ=.1a7fbda3-22e1-420d-9221-ea4ccea55d58@github.com>
Message-ID: <bx4XmANLTPXj6E3GAJszjZvid3OfeeLK5pdBXeFiA9A=.041bcf22-4b31-4ec1-aa36-fd861f07b39b@github.com>

On Tue, 24 Aug 2021 12:58:29 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
>> 
>> We also like to assist users in replacing and mitigating uses in non-JDK code.
>> 
>> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Model as finalizerService

Sorry for the wide distribution, but this became necessary as the PR touches many component areas, if only some with minor parts. Below is a high-level description of this suggested PR.

// Design
Per class statistics about finalizers is implemented by services/finalizerServices. The concept of a "service" is modelled after other management components, such as ClassLoadingService and RuntimeService.

Allocation of an object with a class overriding finalize() with a non-empty finalize() method, is hooked by the runtime using bytecode "_return_register_finalizer", which lets it enter InstanceKlass::register_finalizer().
A hook is added to InstanceKlass::register_finalizer() to notify FinalizerService which increments the number of "objects_on_heap" for the corresponding InstanceKlass.

The dedicated finalizer thread is responsible for running the finalizer methods for referent objects whose java.lang.ref.Finalizers have been enqueued for finalization by the GC.
It will get a native method to report the completion state of a finalizer back to the VM. FinalizerService will then increase the total number of finalizers run and decrease the number of outstanding objects on the heap for the corresponding InstanceKlass.

Class Unloading support is in place by adding a hook into SystemDictionary::do_unloading(). The existing JFR class unloading support is extended to also report a FinalizerStatistic event for the class unloading before its corresponding FinalizerEntry is purged.

-Xlog:finalize is added for Unified Logging support.

// JFR event output jdk.FinalizerStatistics:
Event:jdk.FinalizerStatistics {
  startTime = 14:22:06.683
  finalizableClass = jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize (classLoader = app)
  codeSource = "file:///D:/utilities/jtreg/runtime_artifacts/work/classes/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.d/"
  objects = 0
  totalFinalizersRun = 2
}


Event:jdk.FinalizerStatistics {
  startTime = 14:22:07.244
  finalizableClass = jdk.jfr.internal.RepositoryChunk (classLoader = bootstrap)
  codeSource = N/A
  objects = 3
  totalFinalizersRun = 0
}


// Xlog:finalizer output:
[4.517s][info][finalizer] Registered object (0x0000000073fbf594) of class jdk.jfr.internal.RepositoryChunk as finalizable
[4.737s][info][finalizer] Registered object (0x000000007ee4f130) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize as finalizable
[5.002s][info][finalizer] Finalizer was run for object (0x000000007ee4f130) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize
[5.004s][info][finalizer] Registered object (0x0000000056bf003b) of class jdk.jfr.internal.RepositoryChunk as finalizable
[5.127s][info][finalizer] Registered object (0x0000000014d51169) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize as finalizable
[5.325s][info][finalizer] Finalizer was run for object (0x0000000014d51169) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize
[5.691s][info][finalizer] Registered object (0x000000002baaa366) of class jdk.jfr.internal.RepositoryChunk as finalizable
[5.696s][info][finalizer] Registered object (0x0000000075b10e10) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize as finalizable
[5.891s][info][finalizer] Finalizer was run for object (0x0000000075b10e10) of class jdk.jfr.event.runtime.TestFinalizerStatisticsEvent$TestClassOverridingFinalize
[6.121s][info][finalizer] Registered object (0x000000003c036ecb) of class jdk.jfr.internal.ChunksChannel as finalizable
[6.342s][info][finalizer] Finalizer was run for object (0x000000003c036ecb) of class jdk.jfr.internal.ChunksChannel

// Misc
JfrSymbolTable - an existing JFR internal component repackaged and published to let other JFR native components re-use the symbol ids (more specifically for the CodeSource in this case).

ClassLoadingService - some parts needed to have better conditional compilation and runtime support for running the JVM when excluding JVM feature 'management'.

jmm.h - is a private interface between the JVM and the JDK, so a CSR should not be necessary for the update and version change.

// Performance
The construction of objects with non-empty finalizers is already relatively slow, in that the VM intercepts the allocation using bytecode _return_register_finalizer, where it has to enter the VM. There, another call is made back into Java to construct a java.lang.ref.Finalizer instance. Therefore, the overhead of placing the hook in InstanceKlass::register_finalizer() is considered minimal from a performance perspective (it performs a lookup in a concurrenthashtable and a CAS).

The reporting back to the VM on finalization complete is performed only by the dedicated FinalizerThread. It introduces some additional work, but FinalizerThread is not considered performance-sensitive because of the indeterministic nature of when finalizers are run (if at all).

// Extensibility
The data saved in FinalizerService can also easily be exposed via JMX (java.lang.Management), but it is not part of this change.

The FinalizerEntry struct can also be extended, for example, with performance data.

An attempt was made to see if it was possible to attribute CPU time as well. However, the relatively short-lived character of a typical finalize() method combined with existing thread CPU timing APIs, which proved too coarse-grained (at least on some platforms?), did not give valuable data.
Another possibility could be to attribute some wall-clock time info, but it is currently unclear how useful that is. Also, the selection of what time source to use is another complexity to consider.

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

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

From mgronlun at openjdk.java.net  Fri Aug 27 15:23:35 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 27 Aug 2021 15:23:35 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v10]
In-Reply-To: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
Message-ID: <kDbmRbj6sWLGGhNprH_U8-9vsmbzsOkxU7_ekGtec6g=.3c825a07-fc0e-43ed-8cf7-76b62c096ee7@github.com>

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision:

 - localize
 - cleanup
 - FinalizerStatistics

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/e6b786f1..fd86899f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=08-09

  Stats: 457 lines in 17 files changed: 190 ins; 222 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731

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

From kevinw at openjdk.java.net  Fri Aug 27 17:26:27 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 27 Aug 2021 17:26:27 GMT
Subject: RFR: 8269770: nsk tests should start IOPipe channel before launch
 debuggee - Debugee.prepareDebugee [v2]
In-Reply-To: <NN8U4ddBK-4rcoVri_yEo8o13MAOajtLl4smgln4PJ0=.347bd198-8e2e-4b8b-99bf-ef808f5c894f@github.com>
References: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>
 <NN8U4ddBK-4rcoVri_yEo8o13MAOajtLl4smgln4PJ0=.347bd198-8e2e-4b8b-99bf-ef808f5c894f@github.com>
Message-ID: <C1aZZOWJ1cFqyfCxaWSrDR4e9wHPuHf7BK0Uo6MmCLo=.ea14326a-a88e-4c59-88f9-6209ef01b0ff@github.com>

On Fri, 2 Jul 2021 19:30:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes several hundreds tests which launch debugee by using uses Debugee.prepareDebugee() method or use 
>> debugee = Binder.bindToDebugee(...);
>> IOPipe pipe = debugee.createIOPipe();
>> logic.
>> Debugee.prepareDebugee() and Binder.bindToDebugee() launch debuggee by using CommandLineLaunch JDI connector with suspend=="true" argument, so they return debuggee suspended before the main class is loaded.
>> The fix starts IOPipe listening before debuggee VM is resumed.
>> 
>> Simplified isPackagePrivate/accipp001.java test to use Debugee.prepareDebugee() - it does exactly the same as Debugee.prepareDebugee() does (the only difference is using deprecated IOPipe ctor instead of Debugee.createIOPipe())
>> 
>> Tested all affected tests:
>> test/hotspot/jtreg/vmTestbase/nsk/jdi
>> test/hotspot/jtreg/vmTestbase/nsk/jdwp
>> test/hotspot/jtreg/serviceability/dcmd
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed comment

Marked as reviewed by kevinw (Committer).

OK...  New to me but I think I follow enough to sanity check this.

I found that e.g. vmTestbase/nsk/share/jdi/Debugee.java defines prepareDebuggee() which calls debugee.createIOPipe(), which is changed here.
Previously, DebugeeProcess.java uses an IOPipe constructor which is marked deprecated.
Now calls IOPipe.startDebuggerPipe(Binder binder), which calls startListening().
In accipp001.java the prepareDebugee() call in runThis() handles everything it used to do itself.

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

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

From erikj at openjdk.java.net  Fri Aug 27 17:51:31 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 27 Aug 2021 17:51:31 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v2]
In-Reply-To: <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
 <owyqzdQ73pp0FcvmvfMBbjnJv4MBrG56wNLyR62BWDg=.133c71d6-1f14-44ee-8862-a4a80e3945a0@github.com>
Message-ID: <LEmAelLl1suWas8ISeUc4p87XtgSBWwBTRPz5YSPguo=.6a717c6e-1d62-405e-9f65-2b2949f33c30@github.com>

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/6af90a19...e7127644

Build tool change looks good.

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

Marked as reviewed by erikj (Reviewer).

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

From github.com+5642931+jakobcornell at openjdk.java.net  Sat Aug 28 05:44:39 2021
From: github.com+5642931+jakobcornell at openjdk.java.net (Jakob Cornell)
Date: Sat, 28 Aug 2021 05:44:39 GMT
Subject: RFR: 8271356: JDB: GDB-style command repetition and `list`
 auto-advance
Message-ID: <YnegCYQIVL_ZEpfdAJee-ORVUQ7jv3ve_c3pw0CH0AI=.e9ffe178-21c3-40dd-8bb1-af3c96a1a4bb@github.com>

This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress.

Notes on the patch:

- The `list` command previously marked a line in each listing with `=>`.  In a bare `list` this is the next line up for execution.  Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked.  With the patch applied, `list` will only ever mark the next line up for execution.  This is consistent with the behavior of GDB and PDB (at least).
- `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line.  This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range.
- I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales.  However, I updated the help text in both to include the new commands, with the descriptions left empty for now.

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

Commit messages:
 - 8271356: JDB: implement GDB-style command repetition and `list' auto-advance

Changes: https://git.openjdk.java.net/jdk/pull/5289/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5289&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271356
  Stats: 336 lines in 5 files changed: 107 ins; 20 del; 209 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5289/head:pull/5289

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

From github.com+5642931+jakobcornell at openjdk.java.net  Sat Aug 28 05:55:49 2021
From: github.com+5642931+jakobcornell at openjdk.java.net (Jakob Cornell)
Date: Sat, 28 Aug 2021 05:55:49 GMT
Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the
 previous command
Message-ID: <R_DWFxWElopo6mXUChsYmRFAdgBH28rxvOMROdpvAvg=.cd7ebe2a-2d4b-4d72-9376-b02e2d0c9c66@github.com>

This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress.

Notes on the patch:

- The `list` command previously marked a line in each listing with `=>`.  In a bare `list` this is the next line up for execution.  Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked.  With the patch applied, `list` will only ever mark the next line up for execution.  This is consistent with the behavior of GDB and PDB (at least).
- `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line.  This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range.
- I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales.  However, I updated the help text in both to include the new commands, with the descriptions left empty for now.

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

Commit messages:
 - 8271356: JDB: implement GDB-style command repetition and `list' auto-advance

Changes: https://git.openjdk.java.net/jdk/pull/5290/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5290&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271356
  Stats: 336 lines in 5 files changed: 107 ins; 20 del; 209 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5290/head:pull/5290

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

From github.com+5642931+jakobcornell at openjdk.java.net  Sat Aug 28 06:05:56 2021
From: github.com+5642931+jakobcornell at openjdk.java.net (Jakob Cornell)
Date: Sat, 28 Aug 2021 06:05:56 GMT
Subject: Withdrawn: 8271356: JDB: GDB-style command repetition and `list`
 auto-advance
In-Reply-To: <YnegCYQIVL_ZEpfdAJee-ORVUQ7jv3ve_c3pw0CH0AI=.e9ffe178-21c3-40dd-8bb1-af3c96a1a4bb@github.com>
References: <YnegCYQIVL_ZEpfdAJee-ORVUQ7jv3ve_c3pw0CH0AI=.e9ffe178-21c3-40dd-8bb1-af3c96a1a4bb@github.com>
Message-ID: <p8UyzVEUqMQhsTOWRB3Sl5NxNyfR3evemriMZsCfEBg=.60e7a12b-ec50-4908-a83c-e4c32d06c4b6@github.com>

On Sat, 28 Aug 2021 05:37:23 GMT, Jakob Cornell <github.com+5642931+jakobcornell at openjdk.org> wrote:

> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress.
> 
> Notes on the patch:
> 
> - The `list` command previously marked a line in each listing with `=>`.  In a bare `list` this is the next line up for execution.  Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked.  With the patch applied, `list` will only ever mark the next line up for execution.  This is consistent with the behavior of GDB and PDB (at least).
> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line.  This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range.
> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales.  However, I updated the help text in both to include the new commands, with the descriptions left empty for now.

This pull request has been closed without being integrated.

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

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

From github.com+5642931+jakobcornell at openjdk.java.net  Sat Aug 28 06:05:54 2021
From: github.com+5642931+jakobcornell at openjdk.java.net (Jakob Cornell)
Date: Sat, 28 Aug 2021 06:05:54 GMT
Subject: RFR: 8271356: JDB: GDB-style command repetition and `list`
 auto-advance [v2]
In-Reply-To: <YnegCYQIVL_ZEpfdAJee-ORVUQ7jv3ve_c3pw0CH0AI=.e9ffe178-21c3-40dd-8bb1-af3c96a1a4bb@github.com>
References: <YnegCYQIVL_ZEpfdAJee-ORVUQ7jv3ve_c3pw0CH0AI=.e9ffe178-21c3-40dd-8bb1-af3c96a1a4bb@github.com>
Message-ID: <T7iSKnC9oAcNiECyP706N4fLSbRd1PQs4ELDR8l2McM=.f7fd2e1d-8b3d-43ec-9226-7a07f5b88e1e@github.com>

> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress.
> 
> Notes on the patch:
> 
> - The `list` command previously marked a line in each listing with `=>`.  In a bare `list` this is the next line up for execution.  Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked.  With the patch applied, `list` will only ever mark the next line up for execution.  This is consistent with the behavior of GDB and PDB (at least).
> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line.  This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range.
> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales.  However, I updated the help text in both to include the new commands, with the descriptions left empty for now.

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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5289/files
  - new: https://git.openjdk.java.net/jdk/pull/5289/files/eb45155e..90cd2fa1

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

  Stats: 393 lines in 5 files changed: 77 ins; 164 del; 152 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5289/head:pull/5289

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

From jakob at jcornell.net  Sat Aug 28 15:12:16 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Sat, 28 Aug 2021 10:12:16 -0500
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <e13e274e-dcd7-b54f-d634-70401ba5d857@jcornell.net>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
 <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
 <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>
 <ee3fdde7-a5e6-e116-7a37-c4f7721f1db0@oracle.com>
 <e8ea512c-08fb-b455-1961-f1c31ebd93f5@jcornell.net>
 <a4cea881-eacd-512a-c3f2-366f0557b8d8@oracle.com>
 <e13e274e-dcd7-b54f-d634-70401ba5d857@jcornell.net>
Message-ID: <85438af8-94b2-8e43-11a5-745b9c5937ba@jcornell.net>

I've finished a patch for this and created PR #5290.  #5289 is also linked in the JBS issue but can be ignored (closed due to wrong source repo branch).  Chris, would you be able to briefly review the PR/patch as necessary to see whether we're ready to start the CSR process, and if so get that going?  I'm assuming as with other JBS operations I don't have access to do that.

Thanks,
Jakob

From Alan.Bateman at oracle.com  Sat Aug 28 16:36:14 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 28 Aug 2021 17:36:14 +0100
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <85438af8-94b2-8e43-11a5-745b9c5937ba@jcornell.net>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
 <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
 <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>
 <ee3fdde7-a5e6-e116-7a37-c4f7721f1db0@oracle.com>
 <e8ea512c-08fb-b455-1961-f1c31ebd93f5@jcornell.net>
 <a4cea881-eacd-512a-c3f2-366f0557b8d8@oracle.com>
 <e13e274e-dcd7-b54f-d634-70401ba5d857@jcornell.net>
 <85438af8-94b2-8e43-11a5-745b9c5937ba@jcornell.net>
Message-ID: <46b65268-31c9-56cd-0642-c72d6f75cf60@oracle.com>

On 28/08/2021 16:12, Jakob Cornell wrote:
> I've finished a patch for this and created PR #5290.? #5289 is also 
> linked in the JBS issue but can be ignored (closed due to wrong source 
> repo branch).? Chris, would you be able to briefly review the PR/patch 
> as necessary to see whether we're ready to start the CSR process, and 
> if so get that going?? I'm assuming as with other JBS operations I 
> don't have access to do that.

This seems to just repeating the previous command. Are you also doing a 
prototyping of switching the command loop to use jline to improve the 
usability of jdb or is your interest just the repeat?

-Alan

From jakob at jcornell.net  Sat Aug 28 17:59:51 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Sat, 28 Aug 2021 12:59:51 -0500
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <46b65268-31c9-56cd-0642-c72d6f75cf60@oracle.com>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
 <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
 <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>
 <ee3fdde7-a5e6-e116-7a37-c4f7721f1db0@oracle.com>
 <e8ea512c-08fb-b455-1961-f1c31ebd93f5@jcornell.net>
 <a4cea881-eacd-512a-c3f2-366f0557b8d8@oracle.com>
 <e13e274e-dcd7-b54f-d634-70401ba5d857@jcornell.net>
 <85438af8-94b2-8e43-11a5-745b9c5937ba@jcornell.net>
 <46b65268-31c9-56cd-0642-c72d6f75cf60@oracle.com>
Message-ID: <571ba08c-1ba4-ed1f-50f9-3c486e3c8103@jcornell.net>

Hi Alan,

Yes, this is just the empty command handling.  I am personally interested in Jline integration, but Chris is skeptical about the review prospects for that, and since he's been helping me through the process I've limited the present work.  Maybe now that the patch for empty command handling is done (for now) I'll look into prototyping Jline integration.  I believe that would need a separate JBS ticket, and a separate PR once ready, and we probably want to kick off a new thread here since the present subject lines don't mention Jline.

Jakob

From Alan.Bateman at oracle.com  Sun Aug 29 08:31:40 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 29 Aug 2021 09:31:40 +0100
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <571ba08c-1ba4-ed1f-50f9-3c486e3c8103@jcornell.net>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
 <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
 <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>
 <ee3fdde7-a5e6-e116-7a37-c4f7721f1db0@oracle.com>
 <e8ea512c-08fb-b455-1961-f1c31ebd93f5@jcornell.net>
 <a4cea881-eacd-512a-c3f2-366f0557b8d8@oracle.com>
 <e13e274e-dcd7-b54f-d634-70401ba5d857@jcornell.net>
 <85438af8-94b2-8e43-11a5-745b9c5937ba@jcornell.net>
 <46b65268-31c9-56cd-0642-c72d6f75cf60@oracle.com>
 <571ba08c-1ba4-ed1f-50f9-3c486e3c8103@jcornell.net>
Message-ID: <3993dfce-c2c2-c83c-6320-d8d5b729d5d5@oracle.com>

On 28/08/2021 18:59, Jakob Cornell wrote:
> Hi Alan,
>
> Yes, this is just the empty command handling.? I am personally 
> interested in Jline integration, but Chris is skeptical about the 
> review prospects for that, and since he's been helping me through the 
> process I've limited the present work.? Maybe now that the patch for 
> empty command handling is done (for now) I'll look into prototyping 
> Jline integration.? I believe that would need a separate JBS ticket, 
> and a separate PR once ready, and we probably want to kick off a new 
> thread here since the present subject lines don't mention Jline.

Okay, I just checking as improving the line editing experience would go 
a long way to improve the overall usability and bring it closer to the 
jshell experience. At the same time, most developers will use IDEs and 
other tools for debugging and probably only rarely use jdb. Aside from 
the JDK tests, the number of direct users of jdb may be small, perhaps 
only as a simple tool for debugging/diagnostics when accessing remote 
systems. So not opposed to just focusing on have a way for empty lines 
repeat the command, I'm just pointing out that there are larger 
usability issues.

As requires JBS issues, PR, and CSRs, then I view the currently 
discussion as mostly in exploratory phase right now. The extent of the 
changes with the prototypes will help building consensus on a direction.

-Alan.

From jakob at jcornell.net  Sun Aug 29 13:55:25 2021
From: jakob at jcornell.net (Jakob Cornell)
Date: Sun, 29 Aug 2021 08:55:25 -0500
Subject: Proposed changes to empty command handling in JDB
In-Reply-To: <3993dfce-c2c2-c83c-6320-d8d5b729d5d5@oracle.com>
References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net>
 <1767b645-00ee-299e-2592-5f196d369559@jcornell.net>
 <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com>
 <ac4c8546-7a01-8864-d7ae-fc5d2b05551c@jcornell.net>
 <ee3fdde7-a5e6-e116-7a37-c4f7721f1db0@oracle.com>
 <e8ea512c-08fb-b455-1961-f1c31ebd93f5@jcornell.net>
 <a4cea881-eacd-512a-c3f2-366f0557b8d8@oracle.com>
 <e13e274e-dcd7-b54f-d634-70401ba5d857@jcornell.net>
 <85438af8-94b2-8e43-11a5-745b9c5937ba@jcornell.net>
 <46b65268-31c9-56cd-0642-c72d6f75cf60@oracle.com>
 <571ba08c-1ba4-ed1f-50f9-3c486e3c8103@jcornell.net>
 <3993dfce-c2c2-c83c-6320-d8d5b729d5d5@oracle.com>
Message-ID: <5752ba75-8062-8437-1a6e-199468c44522@jcornell.net>

Hi Alan,

Yep, that's along the lines of what I was thinking.  Thanks for clarification, and I'm glad we have potential interest in Jshell integration.  I hope to have a prototype ready for that in the coming weeks.

Jakob

From cjplummer at openjdk.java.net  Mon Aug 30 21:11:30 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 30 Aug 2021 21:11:30 GMT
Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of
 the previous command
In-Reply-To: <R_DWFxWElopo6mXUChsYmRFAdgBH28rxvOMROdpvAvg=.cd7ebe2a-2d4b-4d72-9376-b02e2d0c9c66@github.com>
References: <R_DWFxWElopo6mXUChsYmRFAdgBH28rxvOMROdpvAvg=.cd7ebe2a-2d4b-4d72-9376-b02e2d0c9c66@github.com>
Message-ID: <Oz-kRGmIFfbFZ4SiaqntuYZX6op4VF3Xp6O345jBmC4=.e6cb3082-3ecd-465f-ac77-f38b69a106b8@github.com>

On Sat, 28 Aug 2021 05:48:47 GMT, Jakob Cornell <github.com+5642931+jakobcornell at openjdk.org> wrote:

> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress.
> 
> Notes on the patch:
> 
> - The `list` command previously marked a line in each listing with `=>`.  In a bare `list` this is the next line up for execution.  Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked.  With the patch applied, `list` will only ever mark the next line up for execution.  This is consistent with the behavior of GDB and PDB (at least).
> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line.  This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range.
> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales.  However, I updated the help text in both to include the new commands, with the descriptions left empty for now.

I'm not sure how to advise about the Chinese or Japanese localization. I don't know what the process is for getting the text updated and properly tested. Hopefully someone else has that knowledge and will comment.

What testing have you done? There are jdb tests in `test/hotspot/jtreg/vmTestbase/nsk/jdb`. You'll also need to write some tests for the new functionality.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 441:

> 439:      */
> 440:     String executeCommand(StringTokenizer t) {
> 441:         String name = t.nextToken().toLowerCase();

Because of this rename of "cmd" to "name", the diff below is very hard to read. It basically just shows that you removed a large section of code and replaced it with another large section of code, which isn't really the case. I think the indentation change with the introduce of `if (valid)` might also be partly to blame. it would be much easier to review if you could clean up the diff.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 457:

> 455:             while (Character.isDigit(name.charAt(0)) && t.hasMoreTokens()) {
> 456:                 try {
> 457:                     reps *= Integer.parseInt(name);  // nested repeats are possible

I don't fully understand the relevance of the changes here to the goal of adding the empty line repeat support. Is this new functionality (nested repeats)?

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 483:

> 481:                     } else {
> 482:                         Commands evaluator = new Commands();
> 483:                         var args = new StringTokenizer(argsLine);

I think the introduction of `args` here and referenced below instead of `t` is also contributing to the issue with the diff. Can you explain why `t` can just continue to be used below?

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

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

From serb at openjdk.java.net  Mon Aug 30 23:46:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 30 Aug 2021 23:46:15 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v3]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <TqRtp_210_WAMsWmEo00_0RH7ZdcoPgWKC0f5bt0YMQ=.a0f183a7-969d-4601-940e-d8a9558bddee@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

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

 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - Rollback TextTests, should be compatible with jdk1.4
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/22865adf...79829ec8

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/e7127644..79829ec8

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

  Stats: 9423 lines in 339 files changed: 5247 ins; 1917 del; 2259 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From github.com+5642931+jakobcornell at openjdk.java.net  Mon Aug 30 23:50:03 2021
From: github.com+5642931+jakobcornell at openjdk.java.net (Jakob Cornell)
Date: Mon, 30 Aug 2021 23:50:03 GMT
Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of
 the previous command [v2]
In-Reply-To: <R_DWFxWElopo6mXUChsYmRFAdgBH28rxvOMROdpvAvg=.cd7ebe2a-2d4b-4d72-9376-b02e2d0c9c66@github.com>
References: <R_DWFxWElopo6mXUChsYmRFAdgBH28rxvOMROdpvAvg=.cd7ebe2a-2d4b-4d72-9376-b02e2d0c9c66@github.com>
Message-ID: <-0s4VHNKtrrYLTcTT4PszoUFxcX9LeEnqIdetqc_oz4=.535a00b6-7a17-44c9-ba6b-ac28fa566706@github.com>

> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress.
> 
> Notes on the patch:
> 
> - The `list` command previously marked a line in each listing with `=>`.  In a bare `list` this is the next line up for execution.  Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked.  With the patch applied, `list` will only ever mark the next line up for execution.  This is consistent with the behavior of GDB and PDB (at least).
> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line.  This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range.
> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales.  However, I updated the help text in both to include the new commands, with the descriptions left empty for now.

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

 - 8271356: correct indentation (see previous commit)
 - 8271356: JDB: implement GDB-style command repetition and `list' auto-advance
   
   This commit includes intentionally incorrect indentation in `executeCommand' in order to provide two straightforward
   diffs instead of one confusing one.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5290/files
  - new: https://git.openjdk.java.net/jdk/pull/5290/files/eb45155e..6328744f

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

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

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

From github.com+5642931+jakobcornell at openjdk.java.net  Tue Aug 31 00:36:51 2021
From: github.com+5642931+jakobcornell at openjdk.java.net (Jakob Cornell)
Date: Tue, 31 Aug 2021 00:36:51 GMT
Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of
 the previous command [v3]
In-Reply-To: <R_DWFxWElopo6mXUChsYmRFAdgBH28rxvOMROdpvAvg=.cd7ebe2a-2d4b-4d72-9376-b02e2d0c9c66@github.com>
References: <R_DWFxWElopo6mXUChsYmRFAdgBH28rxvOMROdpvAvg=.cd7ebe2a-2d4b-4d72-9376-b02e2d0c9c66@github.com>
Message-ID: <5Wo7vItsEvIXn4NnwI_dmQtuECudOw_VOcy5EVyYfxg=.efc62db8-2878-4a38-b646-60d5e0b6a3ac@github.com>

> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress.
> 
> Notes on the patch:
> 
> - The `list` command previously marked a line in each listing with `=>`.  In a bare `list` this is the next line up for execution.  Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked.  With the patch applied, `list` will only ever mark the next line up for execution.  This is consistent with the behavior of GDB and PDB (at least).
> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line.  This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range.
> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales.  However, I updated the help text in both to include the new commands, with the descriptions left empty for now.

Jakob Cornell 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:

  8271356: JDB: implement GDB-style command repetition and `list' auto-advance

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5290/files
  - new: https://git.openjdk.java.net/jdk/pull/5290/files/6328744f..a44b8b4b

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

  Stats: 206 lines in 1 file changed: 15 ins; 18 del; 173 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5290/head:pull/5290

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

From github.com+5642931+jakobcornell at openjdk.java.net  Tue Aug 31 00:52:35 2021
From: github.com+5642931+jakobcornell at openjdk.java.net (Jakob Cornell)
Date: Tue, 31 Aug 2021 00:52:35 GMT
Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of
 the previous command [v3]
In-Reply-To: <5Wo7vItsEvIXn4NnwI_dmQtuECudOw_VOcy5EVyYfxg=.efc62db8-2878-4a38-b646-60d5e0b6a3ac@github.com>
References: <R_DWFxWElopo6mXUChsYmRFAdgBH28rxvOMROdpvAvg=.cd7ebe2a-2d4b-4d72-9376-b02e2d0c9c66@github.com>
 <5Wo7vItsEvIXn4NnwI_dmQtuECudOw_VOcy5EVyYfxg=.efc62db8-2878-4a38-b646-60d5e0b6a3ac@github.com>
Message-ID: <uDHKy_bgrGLPjpyXuumWz60gG7fB08V9BNBni63Ocow=.bf0b13ad-51e4-468f-84f5-2ff79dc285c0@github.com>

On Tue, 31 Aug 2021 00:36:51 GMT, Jakob Cornell <github.com+5642931+jakobcornell at openjdk.org> wrote:

>> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress.
>> 
>> Notes on the patch:
>> 
>> - The `list` command previously marked a line in each listing with `=>`.  In a bare `list` this is the next line up for execution.  Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked.  With the patch applied, `list` will only ever mark the next line up for execution.  This is consistent with the behavior of GDB and PDB (at least).
>> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line.  This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range.
>> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales.  However, I updated the help text in both to include the new commands, with the descriptions left empty for now.
>
> Jakob Cornell 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 think the main reason the diff was so unhelpful is that part of my original change was converting the `<n> <command>` handling from recursive to iterative.  I think the code as a whole is more intuitive when this is done iteratively, and along with the iterative approach came a fix (for synchronous commands) for a minor bug in which the prompt is printed along with each iteration of an `<n> <command>` command.

However, reverting to the recursive approach and restoring some original variable names has made the diff much easier to understand.  I do have the iterative version saved on a local branch in case it becomes useful.

I've run the tests you indicated (`make run-test-vmTestbase_nsk_jdb`) and those are all passing.  I'll take a look into writing some new tests for the changes.

I think the main reason the diff was so unhelpful is that part of my original change was converting the `<n> <command>` handling from recursive to iterative.  I think the code as a whole is more intuitive when this is done iteratively, and along with the iterative approach came a fix (for synchronous commands) for a minor bug in which the prompt is printed along with each iteration of an `<n> <command>` command.

However, reverting to the recursive approach and restoring some original variable names has made the diff much easier to understand.  I do have the iterative version saved on a local branch in case it becomes useful.

I've run the tests you indicated (`make run-test-vmTestbase_nsk_jdb`) and those are all passing.  I'll take a look into writing some new tests for the changes.

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

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

From cjplummer at openjdk.java.net  Tue Aug 31 19:04:30 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 31 Aug 2021 19:04:30 GMT
Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of
 the previous command [v3]
In-Reply-To: <5Wo7vItsEvIXn4NnwI_dmQtuECudOw_VOcy5EVyYfxg=.efc62db8-2878-4a38-b646-60d5e0b6a3ac@github.com>
References: <R_DWFxWElopo6mXUChsYmRFAdgBH28rxvOMROdpvAvg=.cd7ebe2a-2d4b-4d72-9376-b02e2d0c9c66@github.com>
 <5Wo7vItsEvIXn4NnwI_dmQtuECudOw_VOcy5EVyYfxg=.efc62db8-2878-4a38-b646-60d5e0b6a3ac@github.com>
Message-ID: <UuUO9pBtHqOxDGhk70f_Ks32ePcksEqf2Z7CMAwe1ng=.40793bd5-3d7c-4614-b983-6270ab93bb01@github.com>

On Tue, 31 Aug 2021 00:36:51 GMT, Jakob Cornell <github.com+5642931+jakobcornell at openjdk.org> wrote:

>> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress.
>> 
>> Notes on the patch:
>> 
>> - The `list` command previously marked a line in each listing with `=>`.  In a bare `list` this is the next line up for execution.  Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked.  With the patch applied, `list` will only ever mark the next line up for execution.  This is consistent with the behavior of GDB and PDB (at least).
>> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line.  This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range.
>> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales.  However, I updated the help text in both to include the new commands, with the descriptions left empty for now.
>
> Jakob Cornell 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 think overall it looks good. Still need tests and still need to resolve the localization issues.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 458:

> 456:                     int repeat = Integer.parseInt(cmd);
> 457:                     String subcom = t.nextToken("");
> 458:                     for (int r = 0; r < repeat; r += 1) {

Not sure why you made this change. The previous version seems more readable.

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

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

From naoto at openjdk.java.net  Tue Aug 31 20:16:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 31 Aug 2021 20:16:05 GMT
Subject: Integrated: 8273197: ProblemList 2 jtools tests due to JDK-8273187
In-Reply-To: <rjuJdKOLzaG6mLNsDDY63hUbFo5c6D4njr93pamuTfY=.80dd3885-41b9-4439-82e5-6f384a3909e2@github.com>
References: <rjuJdKOLzaG6mLNsDDY63hUbFo5c6D4njr93pamuTfY=.80dd3885-41b9-4439-82e5-6f384a3909e2@github.com>
Message-ID: <huc6gbQBfDqKJpNIFxF98JedRTfK0jb7P2exKllXXA8=.b9e4d71d-8c75-4c3a-8a08-f30a655b222f@github.com>

On Tue, 31 Aug 2021 19:44:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to reduce the noise in the JDK18 CI:
> JDK-8273197 ProblemList 2 jtools tests due to JDK-8273187
> JDK-8273198 ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188
> 
> These failures happen in Tier5 so I'm ProblemListing them now to give @naotoj time to
> work on the issues introduced by JDK-8260265 UTF-8 by Default.

Marked as reviewed by naoto (Reviewer).

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

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

From dcubed at openjdk.java.net  Tue Aug 31 20:16:05 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 31 Aug 2021 20:16:05 GMT
Subject: Integrated: 8273197: ProblemList 2 jtools tests due to JDK-8273187
Message-ID: <rjuJdKOLzaG6mLNsDDY63hUbFo5c6D4njr93pamuTfY=.80dd3885-41b9-4439-82e5-6f384a3909e2@github.com>

Trivial fixes to reduce the noise in the JDK18 CI:
JDK-8273197 ProblemList 2 jtools tests due to JDK-8273187
JDK-8273198 ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188

These failures happen in Tier5 so I'm ProblemListing them now to give @naotoj time to
work on the issues introduced by JDK-8260265 UTF-8 by Default.

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

Commit messages:
 - 8273198: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188
 - 8273197: ProblemList 2 jtools tests due to JDK-8273187

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

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

From dcubed at openjdk.java.net  Tue Aug 31 20:16:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 31 Aug 2021 20:16:06 GMT
Subject: Integrated: 8273197: ProblemList 2 jtools tests due to JDK-8273187
In-Reply-To: <rjuJdKOLzaG6mLNsDDY63hUbFo5c6D4njr93pamuTfY=.80dd3885-41b9-4439-82e5-6f384a3909e2@github.com>
References: <rjuJdKOLzaG6mLNsDDY63hUbFo5c6D4njr93pamuTfY=.80dd3885-41b9-4439-82e5-6f384a3909e2@github.com>
Message-ID: <uLTA3AhdGfNy_y4yv35eHX87BbEj2gIvcBGrtuJQsh8=.a00e0a95-62e6-4b42-a6cb-3deaaf2ebe8c@github.com>

On Tue, 31 Aug 2021 19:44:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to reduce the noise in the JDK18 CI:
> JDK-8273197 ProblemList 2 jtools tests due to JDK-8273187
> JDK-8273198 ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188
> 
> These failures happen in Tier5 so I'm ProblemListing them now to give @naotoj time to
> work on the issues introduced by JDK-8260265 UTF-8 by Default.

This pull request has now been integrated.

Changeset: 9c392d00
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9c392d008a5a34cdc2ed6339a63f1a0d06efe619
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8273197: ProblemList 2 jtools tests due to JDK-8273187
8273198: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188

Reviewed-by: naoto

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

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

From serb at openjdk.java.net  Tue Aug 31 20:17:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 31 Aug 2021 20:17:25 GMT
Subject: RFR: 8272805: Avoid looking up standard charsets [v4]
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <0BjXWeJE25KSeovjDycar9nGsqSQ4vehXgMBrqwWGHQ=.e83aec87-77a8-414d-9acb-bdbdd6bb27ca@github.com>

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

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

 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Update the usage of Files.readAllLines()
 - Update datatransfer
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Fix related imports
 - Merge branch 'master' into standard-encodings-in-non-public-modules
 - Cleanup UnsupportedEncodingException
 - Update PacketStream.java
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7289121a...7fe0327e

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5210/files
  - new: https://git.openjdk.java.net/jdk/pull/5210/files/79829ec8..7fe0327e

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

  Stats: 949 lines in 30 files changed: 678 ins; 166 del; 105 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5210/head:pull/5210

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

From coleenp at openjdk.java.net  Tue Aug 31 21:52:12 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 31 Aug 2021 21:52:12 GMT
Subject: RFR: 8272788: Nonleaf ranked locks should not be
 safepoint_check_never [v3]
In-Reply-To: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
References: <HGLJvVJh69T5_7oQn84nx5fsbc-bt8T4kNRlS9IhE6M=.31117dc0-aad5-4e6a-b853-b5bb1a19458e@github.com>
Message-ID: <KHFjN45Butkaa01MKtDqdLmN2VvyXshyixKGiQQQS84=.f12a6a36-04f2-404d-8afd-06554aa746c3@github.com>

> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
> Tested with tier1-3.  Tier 4-6 testing in progress.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Fix merge error.
 - Merge branch 'master' into nonleaf
 - Remove JfrSream_lock and rerun JFR tests.
 - 8272788: Nonleaf ranked locks should not be safepoint_check_neve

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

Changes: https://git.openjdk.java.net/jdk/pull/5203/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5203&range=02
  Stats: 20 lines in 4 files changed: 3 ins; 13 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5203.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5203/head:pull/5203

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

From amenkov at openjdk.java.net  Tue Aug 31 22:46:52 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 31 Aug 2021 22:46:52 GMT
Subject: Integrated: 8269770: nsk tests should start IOPipe channel before
 launch debuggee - Debugee.prepareDebugee
In-Reply-To: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>
References: <Ul6inNVMRVB_OAtRF6ONX1HfJ1xLxZ-olKE95X_FiF4=.9b6cad69-0927-4750-b28d-e3099ea4f636@github.com>
Message-ID: <0dx8z1T2zxQAbsZz5_SEKhWsf9WtFbP-hygT5RtiBXU=.9cd38b33-3edd-45dd-97c0-590b52551c8b@github.com>

On Thu, 1 Jul 2021 23:21:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes several hundreds tests which launch debugee by using uses Debugee.prepareDebugee() method or use 
> debugee = Binder.bindToDebugee(...);
> IOPipe pipe = debugee.createIOPipe();
> logic.
> Debugee.prepareDebugee() and Binder.bindToDebugee() launch debuggee by using CommandLineLaunch JDI connector with suspend=="true" argument, so they return debuggee suspended before the main class is loaded.
> The fix starts IOPipe listening before debuggee VM is resumed.
> 
> Simplified isPackagePrivate/accipp001.java test to use Debugee.prepareDebugee() - it does exactly the same as Debugee.prepareDebugee() does (the only difference is using deprecated IOPipe ctor instead of Debugee.createIOPipe())
> 
> Tested all affected tests:
> test/hotspot/jtreg/vmTestbase/nsk/jdi
> test/hotspot/jtreg/vmTestbase/nsk/jdwp
> test/hotspot/jtreg/serviceability/dcmd

This pull request has now been integrated.

Changeset: 18a731a3
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/18a731a3e4ec85f0f3e8d6ff619b539c0daaf320
Stats:     31 lines in 3 files changed: 4 ins; 19 del; 8 mod

8269770: nsk tests should start IOPipe channel before launch debuggee - Debugee.prepareDebugee

Reviewed-by: sspitsyn, kevinw

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

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