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: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@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 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: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: <5SYAFqMrZzYAv1C1HVLm7ehQ22NmC401c5hiRA0KfsY=.bad74f4b-2787-44d8-9639-a809be6133ea@github.com> On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev 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: On Fri, 30 Jul 2021 20:20:48 GMT, Daniel D. Daugherty 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: References: Message-ID: On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov 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: References: Message-ID: <6TtyAzEqX8qaEZdhXGv1sX-LnlsO0xWtfGWrO5XUZ2A=.5ad09abe-7bd3-4838-8397-73ecc7dcc59a@github.com> On Thu, 15 Jul 2021 17:22:31 GMT, Serguei Spitsyn 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: References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com> Message-ID: On Mon, 5 Jul 2021 12:04:17 GMT, Lin Zang 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: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev 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: > 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: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev 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: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: On Mon, 2 Aug 2021 15:56:39 GMT, Vladimir Kozlov 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: > 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 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 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: References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com> Message-ID: On 3/08/2021 2:25 am, Igor Ignatyev wrote: > On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev 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: References: Message-ID: On Wed, 28 Jul 2021 10:03:10 GMT, David Holmes 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: > 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: References: <4OaefNh7xye9YZU9SgIcZctAO9cMfKfwXlpQ4K6uuH8=.5c283002-8bba-4c2a-bc79-92a2735a7c2b@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 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: On Mon, 2 Aug 2021 23:30:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: c8add223 Author: Jesper Wilhelmsson 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: References: Message-ID: <8VQ20fh2TVbWEjK0iuu3YDrCfDkCfRyUrpSwykDIv5w=.a83413e0-ee53-41d7-a700-fb2be65f7683@github.com> On Sat, 17 Jul 2021 00:38:44 GMT, Alex Menkov 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: References: Message-ID: On Sat, 17 Jul 2021 00:38:44 GMT, Alex Menkov 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: References: Message-ID: On Wed, 28 Jul 2021 10:03:10 GMT, David Holmes 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: <2q5ydXJwaul0jEF2X2c0mDL6dSPmksfoJ2l1a7T7_JM=.01c14a0f-e336-41db-a287-6807f85c1801@github.com> Message-ID: On Wed, 28 Jul 2021 15:17:19 GMT, Daniel D. Daugherty 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: References: Message-ID: On Tue, 3 Aug 2021 06:12:35 GMT, Serguei Spitsyn 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: References: <2q5ydXJwaul0jEF2X2c0mDL6dSPmksfoJ2l1a7T7_JM=.01c14a0f-e336-41db-a287-6807f85c1801@github.com> Message-ID: <5vwpd4pnJ7qW1F1uop_nR7gog1Xa8rNNSgM1CT5ApqE=.7d672921-4257-4d25-90de-e5c1e8837f2c@github.com> On Tue, 3 Aug 2021 06:11:37 GMT, Serguei Spitsyn 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: On Mon, 28 Jun 2021 07:07:07 GMT, Denghui Dong 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: References: <6aIKhIzZuN1t1DZhSzfV9HLQrKnau9zB77VggMdg1sQ=.a8128116-723d-4384-a1b4-36ba3e7fc46c@github.com> Message-ID: On Mon, 28 Jun 2021 07:39:40 GMT, Denghui Dong 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: <2q5ydXJwaul0jEF2X2c0mDL6dSPmksfoJ2l1a7T7_JM=.01c14a0f-e336-41db-a287-6807f85c1801@github.com> <5vwpd4pnJ7qW1F1uop_nR7gog1Xa8rNNSgM1CT5ApqE=.7d672921-4257-4d25-90de-e5c1e8837f2c@github.com> Message-ID: On Tue, 3 Aug 2021 06:38:55 GMT, David Holmes 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: References: Message-ID: On Sat, 17 Jul 2021 00:38:44 GMT, Alex Menkov 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: References: 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: <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 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: References: Message-ID: On Tue, 3 Aug 2021 18:35:20 GMT, Chris Plummer 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: <8VQ20fh2TVbWEjK0iuu3YDrCfDkCfRyUrpSwykDIv5w=.a83413e0-ee53-41d7-a700-fb2be65f7683@github.com> Message-ID: On Tue, 3 Aug 2021 05:48:08 GMT, Serguei Spitsyn 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: <58_1ZiJHHJtZZqIgVYYW4_mjAsMk8IZw_tQ-Gi5UYDo=.1eeb2b2f-631f-4442-bc16-24a75d9ded26@github.com> Message-ID: On Tue, 3 Aug 2021 19:59:53 GMT, Alex Menkov 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: References: Message-ID: On Tue, 3 Aug 2021 19:21:27 GMT, Alex Menkov 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: References: Message-ID: On Wed, 28 Jul 2021 10:03:10 GMT, David Holmes 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 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: 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: References: Message-ID: On Wed, 4 Aug 2021 13:57:25 GMT, Yasumasa Suenaga 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: <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 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: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Mon, 2 Aug 2021 04:31:55 GMT, David Holmes 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: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Mon, 2 Aug 2021 19:22:04 GMT, Daniel D. Daugherty 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: References: Message-ID: On Wed, 4 Aug 2021 13:57:25 GMT, Yasumasa Suenaga 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 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: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Wed, 4 Aug 2021 22:56:15 GMT, Serguei Spitsyn 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: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Mon, 2 Aug 2021 04:32:31 GMT, David Holmes 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 ` ' (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: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Thu, 5 Aug 2021 04:00:25 GMT, Kim Barrett 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: 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 ` ' (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: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Thu, 5 Aug 2021 05:44:18 GMT, David Holmes 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: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Thu, 5 Aug 2021 07:55:59 GMT, Kim Barrett 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: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Thu, 5 Aug 2021 09:24:13 GMT, Markus Gr?nlund 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: References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net> Message-ID: 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: References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net> 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 ` ' (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: References: <16dd2803-040f-7434-c781-f321c08df3ec@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: 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: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons 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: References: Message-ID: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons 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: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons 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: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons 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: <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 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: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons 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: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com> Message-ID: On Thu, 5 Aug 2021 21:36:58 GMT, Jonathan Gibbons 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: References: <5VznFurUrli9tpiJDmqooJwAZUZy_oLp1iKDIoRP4X8=.e27f9831-478f-48d2-afc6-ecf29f0cb6ae@github.com> <7b4mD0HqCA8-xI1PdJIHax5Zcae4sdFjereDxxPMhgg=.d97f1543-346d-45f3-aad0-2a9beb62bfd3@github.com> Message-ID: On Thu, 5 Aug 2021 21:40:40 GMT, Naoto Sato 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: References: Message-ID: On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons 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 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: 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: References: 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: References: Message-ID: On Thu, 5 Aug 2021 23:49:48 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 14692d5e Author: Jesper Wilhelmsson 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> <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: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Mon, 2 Aug 2021 19:22:04 GMT, Daniel D. Daugherty 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> <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: 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: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Thu, 5 Aug 2021 09:33:34 GMT, David Holmes 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> <5390d861-a112-10c0-8e80-887e877080bd@oracle.com> <7521049a-d476-a1e4-0ff0-4ea06eda844c@oracle.com> <0798bc02-7cba-81af-ea7a-2d7295cebe47@oracle.com> Message-ID: > 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: > 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: References: Message-ID: On Mon, 26 Jul 2021 19:55:09 GMT, Brett Okken 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: References: Message-ID: On Mon, 26 Jul 2021 19:15:55 GMT, Brett Okken 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: 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: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov 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: References: Message-ID: On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov 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 Committer: Jayathirth D V 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: References: Message-ID: <9hTy8U6wk2uDoxCYlENexy2olb-8vaF49ZukcQj_bSA=.b9c53124-ea69-4cee-8698-3781b2b4acc5@github.com> On Tue, 10 Aug 2021 09:18:39 GMT, Alan Bateman 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: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov 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: References: Message-ID: On Sat, 17 Jul 2021 00:38:44 GMT, Alex Menkov 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 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: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov 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: 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: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov 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: References: Message-ID: On Tue, 10 Aug 2021 18:41:04 GMT, Claes Redestad 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: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov 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: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov 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: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov 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: References: Message-ID: On Wed, 11 Aug 2021 13:05:06 GMT, Ralf Schmelter 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: References: Message-ID: On Wed, 11 Aug 2021 13:05:06 GMT, Ralf Schmelter 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: References: Message-ID: On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov 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 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: References: Message-ID: On Wed, 11 Aug 2021 19:19:51 GMT, Chris Plummer 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: References: Message-ID: <3PwAHJTghJ05xA9EOo4_GKQ0QEC03OtbGzyvN5NMI0E=.664a0bb4-aca5-4ee0-9cdb-ad8aca0c3fc6@github.com> On Wed, 14 Jul 2021 05:05:27 GMT, David Holmes 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: <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com> Message-ID: On Fri, 16 Jul 2021 11:53:15 GMT, Lin Zang 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: <7LhykR73th0mZIuFtnZ33lxjoOBuJ6GcThnv5KGKWBA=.1b9d903f-0533-463a-a506-08c95f6e2355@github.com> Message-ID: On Fri, 16 Jul 2021 11:53:15 GMT, Lin Zang 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: References: Message-ID: On Thu, 8 Jul 2021 08:16:51 GMT, Lin Zang 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 Committer: Serguei Spitsyn 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: References: Message-ID: On Thu, 12 Aug 2021 06:10:45 GMT, Ralf Schmelter 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: References: Message-ID: > 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: 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: On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov 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: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Mon, 16 Aug 2021 23:47:04 GMT, Igor Ignatyev 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: On Mon, 16 Aug 2021 23:31:41 GMT, Mikhailo Seledtsov 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: References: Message-ID: <4K0vR12G3TYzHYgOjxrlL23DqsDzRdKZlvtQXPOKhc0=.16e92016-8bd3-49ae-abb6-d21a358c8122@github.com> On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel 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: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Mon, 16 Aug 2021 23:48:46 GMT, Igor Ignatyev 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com> Message-ID: On Wed, 30 Jun 2021 09:17:42 GMT, Serguei Spitsyn 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: References: Message-ID: <2UtKcMi4-HV7wJ-jXgw1eicdGRCKmHdt5MLrEzU2woI=.a01f2eff-0d80-499a-97bc-91bf26ca7b67@github.com> On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel 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: > 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: <2UtKcMi4-HV7wJ-jXgw1eicdGRCKmHdt5MLrEzU2woI=.a01f2eff-0d80-499a-97bc-91bf26ca7b67@github.com> Message-ID: On Tue, 17 Aug 2021 09:07:17 GMT, Severin Gehwolf 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: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Tue, 17 Aug 2021 14:58:48 GMT, Mikhailo Seledtsov 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: References: Message-ID: On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel 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: References: 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: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com> Message-ID: On Tue, 17 Aug 2021 17:39:49 GMT, Harold Seigel 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: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Tue, 17 Aug 2021 14:58:48 GMT, Mikhailo Seledtsov 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: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: On Tue, 17 Aug 2021 20:30:04 GMT, Harold Seigel 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: > 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 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 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: References: <4SKNu6w5QjHcoR97lKEpoANzY4unvE8ZVQVW6LXm2hU=.506e1b8a-a827-4d95-aba3-9287bc87b2cc@github.com> Message-ID: <6nxeZAJ9wzVs6WB41Jcfx-4d3iQ24BJ78aPLA6Mmdpc=.e1298d97-a3cd-44b0-a482-3f51c90b3532@github.com> On Tue, 17 Aug 2021 22:13:54 GMT, Mikhailo Seledtsov 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com> Message-ID: On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry 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:: > (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: References: Message-ID: On Wed, 11 Aug 2021 13:05:06 GMT, Ralf Schmelter 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: <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 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: References: Message-ID: > 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: References: <4hKKCdMZJ4OnLvvdOvTGLkI1DsbMVdPOPMA53U1urWY=.8e11fc69-6756-47ae-b973-cdd114cadfd7@github.com> Message-ID: On Tue, 17 Aug 2021 17:46:29 GMT, Severin Gehwolf 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: References: Message-ID: On Wed, 18 Aug 2021 12:25:45 GMT, Harold Seigel 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: References: Message-ID: > 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: References: Message-ID: On Wed, 18 Aug 2021 12:25:45 GMT, Harold Seigel 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: 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: References: Message-ID: On Wed, 18 Aug 2021 13:04:46 GMT, Harold Seigel 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: References: Message-ID: On Wed, 18 Aug 2021 13:04:46 GMT, Harold Seigel 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: References: Message-ID: On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel 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 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: References: Message-ID: <3plknACpu3AerBPF8SOEh7V_RH8obcHn7I4xclck2sY=.8d3d2872-cef6-439e-afd5-bbe2b308f775@github.com> On Wed, 11 Aug 2021 13:05:06 GMT, Ralf Schmelter 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: References: Message-ID: On Wed, 11 Aug 2021 13:05:06 GMT, Ralf Schmelter 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 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com> Message-ID: On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry 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:: > (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: References: Message-ID: 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 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: References: Message-ID: <2Y5ulI-nScJrXU-odPSJt0mDFuXaE9cbqwnc0U-tqqI=.c714ad19-2cc1-421d-bf57-12767cd60d25@github.com> On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? 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: References: Message-ID: 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 ; 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 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com> Message-ID: 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 wrote: > On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry > 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:: > > (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: 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com> Message-ID: [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 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 wrote: > >> On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry >> 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:: >> > (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: 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: 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: 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: References: Message-ID: <0eO4SD_N9lrP5k5bhEejUKXeMauRC8zuc_slUJSrc5c=.c886ae36-5039-450f-9293-5f9910ce432d@github.com> On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov 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: References: Message-ID: On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov 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: References: Message-ID: On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov 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: References: Message-ID: > 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: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov 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: On Fri, 13 Aug 2021 10:46:02 GMT, Lin Zang 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: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com> Message-ID: On Mon, 19 Jul 2021 09:25:59 GMT, Ludovic Henry 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:: > (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: References: Message-ID: On Fri, 20 Aug 2021 16:41:40 GMT, Coleen Phillimore 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com> Message-ID: On Mon, 23 Aug 2021 10:28:36 GMT, Jaroslav Bachorik 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:: >> (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: References: Message-ID: On Mon, 23 Aug 2021 10:53:18 GMT, David Holmes 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: References: Message-ID: <_yvAqBNWPO9gt0XX0lFRm4PDetoZDQ0YhrUFvzOPnx4=.6f1c8917-2169-4494-93f4-a87af5a2e31e@github.com> On Fri, 20 Aug 2021 16:41:40 GMT, Coleen Phillimore 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: References: Message-ID: > 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: 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: References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net> <1767b645-00ee-299e-2592-5f196d369559@jcornell.net> <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com> Message-ID: 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: References: Message-ID: On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman 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: References: Message-ID: On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov 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: <_yvAqBNWPO9gt0XX0lFRm4PDetoZDQ0YhrUFvzOPnx4=.6f1c8917-2169-4494-93f4-a87af5a2e31e@github.com> Message-ID: On Mon, 23 Aug 2021 12:27:39 GMT, Coleen Phillimore 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: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov 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: References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net> <1767b645-00ee-299e-2592-5f196d369559@jcornell.net> <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com> Message-ID: 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: References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net> <1767b645-00ee-299e-2592-5f196d369559@jcornell.net> <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com> Message-ID: 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: References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net> <1767b645-00ee-299e-2592-5f196d369559@jcornell.net> <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com> Message-ID: 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: On Fri, 13 Aug 2021 10:46:02 GMT, Lin Zang 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com> Message-ID: On Mon, 23 Aug 2021 10:57:54 GMT, David Holmes 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: References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com> <1wdquRFR6BB0JQAZmGaM55Zs9Bd_aucs8RMl8lGzTZU=.afb4d3ae-5014-4462-a211-17827a9e006a@github.com> Message-ID: On Mon, 23 Aug 2021 23:26:14 GMT, Serguei Spitsyn 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com> Message-ID: <2b10zJmYvua1kRntBFLHbMlbetwJEYuviNJ4GN9z9Ko=.d117de14-6e85-4aa3-84c7-e7d88490f9cf@github.com> On Mon, 19 Jul 2021 07:07:04 GMT, Ludovic Henry 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 ) >> 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 >> #12 __pthread_mutex_unlock_usercnt (decr=1, mutex=0x7fa235da5440 ) at pthread_mutex_unlock.c:41 >> #13 __GI___pthread_mutex_unlock (mutex=0x7fa235da5440 ) 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 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@github.com> Message-ID: On Wed, 18 Aug 2021 19:16:39 GMT, Marcus Hirt 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: On Fri, 13 Aug 2021 10:46:02 GMT, Lin Zang 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: > 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: References: <9qfnLj_-jz8MocK7UIIs5-NYZsVPJ7J20ZLiORqpUlM=.cb712662-0eb9-4d17-a67d-42451423f470@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 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: References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com> Message-ID: On Mon, 5 Jul 2021 12:04:17 GMT, Lin Zang 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: References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@github.com> Message-ID: On Tue, 24 Aug 2021 07:12:51 GMT, Lin Zang 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: > 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: References: <_W7saAbiN7RT11gnWnleaVnRjsFk3Pv1_a2-hvFB-xs=.75dae1d4-99e3-4f24-a554-cc90796f7824@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 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: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov 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: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Mon, 7 Jun 2021 08:01:54 GMT, Lin Zang 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: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Mon, 7 Jun 2021 08:01:54 GMT, Lin Zang 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: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Mon, 7 Jun 2021 08:01:54 GMT, Lin Zang 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: References: Message-ID: On Mon, 23 Aug 2021 13:03:10 GMT, Coleen Phillimore 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: References: Message-ID: On Mon, 23 Aug 2021 13:03:10 GMT, Coleen Phillimore 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: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Wed, 25 Aug 2021 09:23:10 GMT, Serguei Spitsyn 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: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Wed, 25 Aug 2021 09:27:54 GMT, Serguei Spitsyn 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: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Thu, 26 Aug 2021 04:14:07 GMT, Lin Zang 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: > 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: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Mon, 7 Jun 2021 08:01:54 GMT, Lin Zang 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: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Thu, 26 Aug 2021 04:27:36 GMT, Lin Zang 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: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Thu, 26 Aug 2021 07:58:37 GMT, Lin Zang 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: > 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: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> <7p7PD78B0fKuSonRZ44rQWvBKHabsz4n9VT4WbVluFI=.e4248320-f134-4ed0-b073-a3466970932c@github.com> <69h5uaXSdgc4Fkhla6QdtoezGPyVcFMNasVI8iNxYWI=.3a7c3e6a-8dfa-4ff1-a7cf-db71d3ea7bbf@github.com> <2J1CEmVaXJuvU3fseIBYDcJCihqoeAf07bt0hgvJWWE=.259496ed-1883-4035-a4e5-e6c45f511707@github.com> Message-ID: On Wed, 17 Mar 2021 06:40:33 GMT, Serguei Spitsyn 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: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov 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: References: Message-ID: On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov 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: References: Message-ID: On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov 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: References: Message-ID: <8NVDrw74Vd0opZm6RUbpEA6fVvZ8OKbFLSor8y_bzpI=.b4962781-157a-4818-81cd-2196b433d1b5@github.com> On Fri, 2 Jul 2021 19:30:11 GMT, Alex Menkov 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: On Wed, 3 Mar 2021 07:01:46 GMT, Lin Zang wrote: > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out This pull request has now been integrated. Changeset: 46684a4e Author: Lin Zang Committer: Serguei Spitsyn 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: 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: 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: References: 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 > , 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: References: Message-ID: On Tue, 24 Aug 2021 12:58:29 GMT, Markus Gr?nlund 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: References: Message-ID: > 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: References: Message-ID: On Fri, 2 Jul 2021 19:30:11 GMT, Alex Menkov 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: References: Message-ID: On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov 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: 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: 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: References: Message-ID: On Sat, 28 Aug 2021 05:37:23 GMT, Jakob Cornell 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: References: Message-ID: > 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: References: <16dd2803-040f-7434-c781-f321c08df3ec@jcornell.net> <1767b645-00ee-299e-2592-5f196d369559@jcornell.net> <0d3a31f0-7c83-26d5-0a2d-61b5812755f3@oracle.com> 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> <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> <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> <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> <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: References: Message-ID: On Sat, 28 Aug 2021 05:48:47 GMT, Jakob Cornell 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: References: Message-ID: > 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: References: 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: References: 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: <5Wo7vItsEvIXn4NnwI_dmQtuECudOw_VOcy5EVyYfxg=.efc62db8-2878-4a38-b646-60d5e0b6a3ac@github.com> Message-ID: On Tue, 31 Aug 2021 00:36:51 GMT, Jakob Cornell 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 ` ` 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 ` ` 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 ` ` 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 ` ` 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: <5Wo7vItsEvIXn4NnwI_dmQtuECudOw_VOcy5EVyYfxg=.efc62db8-2878-4a38-b646-60d5e0b6a3ac@github.com> Message-ID: On Tue, 31 Aug 2021 00:36:51 GMT, Jakob Cornell 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: References: Message-ID: On Tue, 31 Aug 2021 19:44:08 GMT, Daniel D. Daugherty 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: 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: References: Message-ID: On Tue, 31 Aug 2021 19:44:08 GMT, Daniel D. Daugherty 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 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: References: 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: References: Message-ID: > 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: References: Message-ID: <0dx8z1T2zxQAbsZz5_SEKhWsf9WtFbP-hygT5RtiBXU=.9cd38b33-3edd-45dd-97c0-590b52551c8b@github.com> On Thu, 1 Jul 2021 23:21:03 GMT, Alex Menkov 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 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